Step 1: Supplier creates the Standard Business Document

Every invoice sent to Sovos must be part of a Standard Business Document (SBD). This document includes a Standard Business Document Header (SBDH) and a Sovos Document node, which in turn includes a Sovos Canonical Invoice (SCI). To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages. Here are some key elements that should be included in the SBD and in the invoice.

Besides the SCI format the payload can be also of Serbian UBL 2.1 format.

SCI - Invoice

Use the following values in the SBDH for documents that use the SCI format:

Node	Required	Attributes	Value
StandardBusinessDocumentHeader.Sender.Identifier	Yes	Authority="RS"	Supplier's tax ID
StandardBusinessDocumentHeader.Receiver.Identifier	Yes	Authority="RS"
StandardBusinessDocumentHeader.DocumentIdentification.Standard	Yes		urn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion	Yes		2.1
StandardBusinessDocumentHeader.DocumentIdentification.Type	Yes		Invoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: Country Child node Identifier: RS
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: ProcessType Child node Identifier: Outbound
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: CompanyCode Child node Identifier: Supplier's tax ID
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: SenderDocumentId Child node Identifier: A unique document ID, whereby the ERP document ID is recommended.
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: SenderSystemId Child node Identifier: The system ID configured in the backend. This parameter is used to determine which notifications are returned to the client and what attachments they include. If SenderSystemId is not configured on the client side, it'll assume the default value of "DefaultSystemERP". For more information, see this topic.
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: Mapping.OutputSchema Child node Identifier: UBLInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: Mapping.TransformDocument Child node Identifier: SCI-TO-LEGAL_INVOICE
StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceName	Yes		Default
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: BusinessCategory Child node Identifier: B2B or B2G
SovosDocument.SovosCanonicalInvoice.Invoice	Yes		SCI
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: Version Child node Identifier : 1.0

Local format - Invoice

Alternatively, the supplier can use the local format (XML) instead of SCI. Use the following values in the SBDH for documents that use the local format:

Node	Required	Value
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes	Child node Type: Mapping.TransformDocument Child node Identifier: LEGAL-TO-SCI_INVOICE
SovosDocument.SovosLegalDocument.Base64Document	Yes	A local format document encoded in base 64.

Note:

The Local Format (XML) document must be Base64-encoded before it can be added as part of the SBD.

</sbd:StandardBusinessDocumentHeader>
<svs:SovosDocument>
	<svs:SovosLegalDocument>
		<enc:Base64Document>
			<enc:EmbeddedDocument id="1" filename="invoice.xml" mimeCode="application/xml">PD94bWwgdmVyc...FRdHVyYT4NCg==<enc:EmbeddedDocument>
		</enc:Base64Document>
	</svs:SovosLegalDocument>
</svs:SovosDocument>
</sbd:StandardBusinessDocument>

Note:

Include all the required nodes as specified in the SBDH schema. If the information cannot be provided, and the respective required node has not been mentioned on the current page, for example the receiver.identifier, the node can be left empty but must still be included in the SBDH.

SBD Sample

Below is a sample of the SBD.

<?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:n0="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:cct="urn:un:unece:uncefact:data:specification:CoreComponentTypeSchemaModule:2" xmlns:crn="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2" xmlns:dbn="urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2" xmlns:enc="http://www.sovos.com/namespaces/base64Document" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:leg="http://www.sovos.com/namespaces/sovosExtensions/LegalExtension" xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2" xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2" xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2" xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xsi:schemaLocation="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<sbd:StandardBusinessDocumentHeader>
<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
<sbd:Sender>
<sbd:Identifier Authority="RS">SUPPLIER_TAX_ID</sbd:Identifier>
<sbd:ContactInformation>
<sbd:Contact/>
<sbd:EmailAddress/>
<sbd:FaxNumber/>
<sbd:TelephoneNumber/>
<sbd:ContactTypeIdentifier/>
</sbd:ContactInformation>
</sbd:Sender>
<sbd:Receiver>
<sbd:Identifier Authority="RS">BUYER_TAX_ID</sbd:Identifier>
<sbd:ContactInformation>
<sbd:Contact/>
<sbd:EmailAddress/>
<sbd:FaxNumber/>
<sbd:TelephoneNumber/>
<sbd:ContactTypeIdentifier/>
</sbd:ContactInformation>
</sbd:Receiver>
<sbd:DocumentIdentification>
<sbd:Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</sbd:Standard>
<sbd:TypeVersion>2.1</sbd:TypeVersion>
<sbd:InstanceIdentifier/>
<sbd:Type>Invoice</sbd:Type>
<sbd:MultipleType>false</sbd:MultipleType>
<sbd:CreationDateAndTime>2025-07-04T00:00:00Z</sbd:CreationDateAndTime>
</sbd:DocumentIdentification>
<sbd:BusinessScope>
<sbd:Scope>
<sbd:Type>Country</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>RS</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>Mapping.TransformDocument</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>SCI-TO-LEGAL_INVOICE</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>Mapping.OutputSchema</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>UBLInvoice</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>CompanyCode</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>SUPPLIER_TAX_ID</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>SenderDocumentId</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>RS2025/7/00000007</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>SenderSystemId</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>ERPSystem</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>ProcessType</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>Outbound</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>BusinessProcess</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:BusinessService>
<sbd:BusinessServiceName>Default</sbd:BusinessServiceName>
</sbd:BusinessService>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>BusinessCategory</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>B2G</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>SubSchema</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier/>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>Version</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>1.0</sbd:Identifier>
</sbd:Scope>
</sbd:BusinessScope>
</sbd:StandardBusinessDocumentHeader>
<svs:SovosDocument>
<sci:SovosCanonicalInvoice>
<inv:Invoice>
				*UBL Elements*
</inv:Invoice>
</sci:SovosCanonicalInvoice>
</svs:SovosDocument>
</StandardBusinessDocument>

Step 2: Supplier sends the SBD to Sovos

The supplier sends a POST request to the /documents endpoint.

The request must include the following request body parameters:

Request Sample

curl --location --request POST 'https://api-test.sovos.com/v1/documents' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '{
	"data": "PD9...d4=",
	"dataEncoding" : "base64"
}'

Response Sample

{
    "timestamp": 1605282724079,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "DOCUMENT-ID"
    }
}

Step 3: Sovos maps the SCI into XML

Upon receiving the SCI file, Sovos maps it into the required XML format.

Step 4: Sovos validates the XML

Sovos validates the schema based on the information provided by the Tax Authority. If the client's document has errors, Sovos detects them instead of waiting for the Tax Authority's response. This allows Sovos to return errors in a clear and concise manner, which is often not the case when they come from the Tax Authority.

Step 5: Sovos transmits the XML

Sovos transmits the document to the Tax Authority's e-Invoice system (SEF).

Step 6: SEF processes the XML and sends the response to Sovos

SEF validates the schema and verifies that business logic, taxpayer information and duplicates are checked.

After performing its services, the SEF system sends either a success message or a rejection message to Sovos.

Step 7: PDF generation

Sovos generates a PDF that contains the content of the invoice XML in a human-readable format.

Step 8: Distribution

Either Sovos or the taxpayer can communicate the invoice to the Counterparty.

Step 9: Retrieve Counterparty's response

The XML is made available for the Counterparty to retrieve, and potentially accept or reject within 20 days. To make sure the document is correctly categorized, the Scope BusinessCategory in the SBDH is required and should be set, by the client, to either B2B or B2G.

In a B2B flow, if the Counterparty does not respond within 20 days, the document will be deemed rejected (per law).

For B2G flows, when 20 days are due, the document is deemed authorized (also per law).

Taxpayer retrieves the application responses

Clients should configure their Application Response attachments as download links instead of base64-encoded data to avoid potential size limitations when retrieving responses. The default option is download links.

• When using download links the response contains a URL from where the file can be downloaded.

• When using binary data, the file itself is embedded in the response encoded in base64.

The ERP system configuration is available through our Professional Services team.

As a response to the initial sending of the document, the client will receive a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the supplier must retrieve the application responses that become available during the transaction, which provide status information and also contain the signed XML encoded in Base64.

Clients have the option to retrieve application responses (notifications) in one of two ways:

The taxpayer can use the following Indirect Tax API endpoints to retrieve application responses:

• GET /notifications/RS

• GET /documents/RS/{documentId}/notifications

We'll discuss these endpoints in the following subsections.

Step 10: Supplier marks the application responses as acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RS endpoint.

To make this request, set the following request body parameters:

Archiving

Archiving can be done as a bundle, for example as part of the Clearance flow, and is recommended for suppliers integrating with the Sovos solution for Serbia for the first time. It can also be done separately, through an explicit API call, which uses another archive. For more information on standalone archiving, see the e-Archiving documentation page.

Bundled e-invoice archiving on the new platform is optional. Existing customers can choose to use their current solution and include e-Archiving.

When bundled archiving is set, the XML document is archived for 11 years along with the keys that the Tax Authority returns: invoiceId, salesInvoiceId and uniqueId.

Error Handling

Customers need to adhere to the error handling principles outlined on the responses page.

In general, all error codes in the 400 range are client errors, so the customer needs to analyze them. After fixing the error, it's possible to resend the request. Error codes 408 and 429 are exceptions: in these cases, customers should wait at least 60 seconds before retrying. The error codes in the 500 range are server errors. In that case, customers need to resend the request, according to the instructions given on the responses page, which also includes a full list of error codes the Indirect Tax API can return.

Step 1: Supplier sends a POST Request to Sovos

The buyer sends a POST request to the /documents/RS/action endpoint.

To make this request, set the following request body parameters:

Step 2: Sovos transmits Request (to SEF)

Sovos finds the corresponding document in the system and transmits the cancellation request to SEF.

Step 3: SEF processes the Request

SEF validates the request and verifies business logic before returning a success or error message.

Step 4: SEF returns the Response

SEF returns the success message, or the error message if the cancellation could not be performed.

Step 5: Taxpayer retrieves the Application Responses

It is highly recommended that clients configure their Application Response attachments as download links instead of base64 encoded data to avoid potential size limitations when retrieving responses. The default option is "download links".

• When using "download links" the response contains a URL from where the file can be downloaded.

• When using "binary data", the file itself is embedded in the response encoded in base64.

This configuration is available through our Professional Services team.

As a response to the initial sending of the document, the client will receive a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the taxpayer must retrieve the application responses that become available during the transaction, which provide status information.

Clients have the option to retrieve application responses (notifications) in one of two ways:

Step 6: Taxpayer marks the Application Responses as Acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RS endpoint.

To make this request, set the following request body parameters:

Error Handling

Customers need to adhere to the error handling principles outlined on the responses page.

In general, all error codes in the 400 range are client errors, so the customer needs to analyze them. After fixing the error, it's possible to resend the request. Error codes 408 and 429 are exceptions: in these cases, customers should wait at least 60 seconds before retrying. The error codes in the 500 range are server errors. In that case, customers need to resend the request, according to the instructions given on the responses page, which also includes a full list of error codes the Indirect Tax API can return.

Errors coming from the SEF system will be shown in the application response. This means that, in the case of a rejection, the SCIResponseCode will be set to "RE" and any error codes coming from the system will be shown in the SCIGovtStatusCode element. The customer is responsible for taking action upon receiving an error code and a message from the SEF system.

Step 1: Buyer sends a POST Request to Sovos

The buyer sends a POST request to the /documents/RS/action endpoint.

To make this request, set the following request body parameters:

Step 2: Sovos transmits Request (to SEF)

Sovos finds the corresponding document in the system and transmits the acceptance or rejection request to SEF.

Step 3: SEF processes the Request

SEF verifies that the 20 days window has not passed since the original document was issued, and that the document can be rejected/accepted successfully.

Step 4: SEF returns the Response

SEF returns the success message, or the error message if the rejection or acceptance could not be performed.

Step 5: Buyer retrieves the Application Responses

It is highly recommended that clients configure their Application Response attachments as download links instead of base64 encoded data to avoid potential size limitations when retrieving responses. The default option is "download links".

• When using "download links" the response contains a URL from where the file can be downloaded.

• When using "binary data", the file itself is embedded in the response encoded in base64.

This configuration is available through our Professional Services team.

As a response to the initial sending of the document, the client will receive a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the supplier must retrieve the application responses that become available during the transaction, which provide status information.

Clients have the option to retrieve application responses (notifications) in one of two ways:

Fetch everything in one single response (notification)

This means, when polling for responses, Sovos will only return one final notification with SCICloudStatusCode 209 that contains all the relevant attachments/data. Detailed description follows.

Fetch multiple responses (notifications) containing different information

In this case, when polling for responses, Sovos will return multiple notifications with different SCICloudStatusCode values containing different attachments/data until the final one (with status 209) is returned. Detailed description follows.

Step 6: Buyer marks the Application Responses as Acknowledged

After retrieving application responses, the buyer must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RS endpoint.

To make this request, set the following request body parameters:

Error Handling

Customers need to adhere to the error handling principles outlined on the responses page.

In general, all error codes in the 400 range are client errors, so the customer needs to analyze them. After fixing the error, it's possible to resend the request. Error codes 408 and 429 are exceptions: in these cases, customers should wait at least 60 seconds before retrying. The error codes in the 500 range are server errors. In that case, customers need to resend the request, according to the instructions given on the responses page, which also includes a full list of error codes the Indirect Tax API (Application Programming Interface) can return.

Errors coming from the SEF system will be shown in the application response. This means that, in the case of a rejection, the SCIResponseCode will be set to "RE" and any error codes coming from the system will be shown in the SCIGovtStatusCode element. The customer is responsible for taking action upon receiving an error code and a message from the SEF system.

Step 1: Sovos Retrieves the Documents from the SEF System

Sovos uses the buyer's credentials to authenticate with the SEF system to collect the documents that have been made available (either in JSON or XML formats).

Step 2: Sovos Maps the Retrieved Document into SCI and Makes them Available

Sovos stores the retrieved documents, maps them to SCI, and makes them available for buyers to get. The PDF version of the documents is also made available.

Step 3: Sovos Generates the PDF

Sovos generates a PDF for this document.

Step 4: Sovos Distributes the PDF

Sovos can distribute the PDF via email to a configurable email address.�

Step 5: Buyer Retrieves the Available Documents

It is highly recommended that clients configure their Application Response attachments as download links instead of base64 encoded data to avoid potential size limitations when retrieving responses. The default option is "download links".

• When using "download links" the response contains a URL from where the file can be downloaded.

• When using "binary data", the file itself is embedded in the response encoded in base64.

This configuration is available through our Professional Services team.

The buyer can use the following Indirect Tax API endpoint to retrieve application responses:

GET /notifications/RS

To complete a transaction, the buyer must retrieve the application responses until the transaction has finished. If the buyer has subscribed to all notifications, the transaction can generate different application responses, as shown in the table below:

Step 6: Buyer Acknowledges the Retrieved Documents

After retrieving the documents, the buyer must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RS endpoint.

To make this request, set the following request body parameters: