home

Indirect Tax

Indirect TaxTax and Regulatory ReportingSovos Glossary
Indirect TaxTax and Regulatory ReportingSovos Glossary

Sovos Docs

Show Contents

Show Page Sections

Indirect Tax

Country Setup Guides

Romania

Enabling support for Romania involves confirming prerequisites and product IDs, registering with the Agenția Națională de Administrare Fiscală (ANAF) tax authority, and setting up credentials.

Prerequisites

  • Access token obtained from the ANAF tax authority

  • Refresh token obtained from the ANAF tax authority

  • Client ID and client secret obtained from the ANAF tax authority

Available products

ro_Factura__1.0
Outbound invoicing
ro_Factura_Polling_1.0
Inbound invoicing
ro_Invoice__2.0
e-Transport
RO_DOCUMENT_1_2.0
Pending description

Error handling

When handling errors, the client application must follow the Indirect Tax API's error handling principles, as specified in the error handling documentation.

In general, all error codes in the 400 range are client errors, which you need to analyze. After fixing the error, you can resend the request. Error codes 408 and 429 are exceptions: In these cases, you should wait at least 60 seconds before retrying. Error codes in the 500 range are server errors. In that case, resend the request according to the instructions given on the error handling documentation, which also includes a full list of error codes Indirect Tax API can return.

Errors coming from the tax authority are shown in the application response. This means that if the tax authority rejects the request, SCIResponseCode is set to "RE" and any error codes will be located in the SCIGovtStatusCode element.

Note:

You need to take action after receiving an error code and a message from the tax authority.

For additional help on error handling, see this government webpage and, more specifically, this PDF document, which explains the validation and the possible error messages.

Register with the Romania tax authority

You need to register with the Agenția Națională de Administrare Fiscală (ANAF) to be able to obtain an access token, a refresh token, a client ID, and a client secret.

To integrate ANAF services exposed on the Internet with third-party applications (web, desktop, or mobile), ANAF has implemented a solution to authorize access to API-type services using standard mechanisms based on the use of the OAuth protocol. This solution uses standard mechanisms based on the OAuth protocol and is intended for application developers with knowledge of IT and of the OAuth 2.0 protocol. This is because application development is required to use this solution.

  1. Go to ANAF's website.
  2. Click Servicii Online in the main navigation and select Inregistrare utilizatori from the drop down menu.
  3. Select Dezvoltatori Aplicatii.
  4. Fill in the form and select Continua.
  5. Look for a message with a verification code, which will be sent to the provided email address.
  6. Enter the provided code to finish.

Configure transmission credentials for Romania

You must set up transmission credentials to connect your Sovos account to a valid business that is registered with the Agenția Națională de Administrare Fiscală (ANAF) tax authority in Romania. You must also update these credentials before they expire, specifically before the refresh token expires.
Note:

Sovos uses the refresh token to automatically obtain a valid access token once it expires (every 90 days). However, the refresh token can also expire (365 days) and then needs to be updated with a valid one. This will require you to create a new app and retrieve a new client ID and secret pair.

  1. Add your transmission credentials to the Admin Settings or via the Configuration v2 resource (API).
  2. Complete and return an Appointment Letter to Sovos or your reseller.
  3. Complete and return a Support and Change Management Document to Sovos or your reseller.

Samples for uploading transmission credentials for Romania

Having the ANAF credentials and Organization ID, customers can upload their credentials, which must be unique for the tax ID and environment being configured and uploaded once per configured product.

Request sample

Request sample for uploading new transmission credentials:

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/organizations/YOUR-ORG-ID/settings' \
--header 'x-correlationId: developer-guide' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "context": "transmission",
        "configurations": [
            {
                "name": "partner_credentials_anaf",
                "value": {
                    "accessToken": INSERT-TOKEN-HERE,
                    "refreshToken": INSERT-REFRESH-TOKEN-HERE,
                    "clientId": INSERT-CLIENTID-HERE,
                    "clientSecret": INSERT-CLIENTSECRET-HERE
                },
                "scope": {
                    "category": "RO_INV",
                    "productId": "ro_Factura__1.0",
                    "orgId": YOUR-ORG-ID,
                    "taxId": YOUR-COMPANY-TAXID
                }
            }
        ]
    }
]'

Response sample

Response sample for uploading new transmissions credentials:

{
    "status": 201,
    "message": "Created",
    "success": true,
    "timestamp": 1663855094969,
    "data": [
        {
            "message": "Configurations are created",
            "statusCode": 201,
            "configurationContextResponse": {
                "context": "Transmission",
                "configurations": [
                    {
                        "id": SETTING-ID,
                        "name": "partner_credentials_anaf",
                        "value": {
                            "accessToken": INSERT-TOKEN-HERE,
                            "refreshToken": INSERT-REFRESH-TOKEN-HERE,
                            "clientId": INSERT-CLIENTID-HERE,
                            "clientSecret": INSERT-CLIENTSECRET-HERE
                        },
                        "scope": {
                            "category": "RO_INV",
                            "productId": "ro_Factura__1.0",
                            "orgId": YOUR-ORG-ID,
                            "taxId": YOUR-COMPANY-TAXID
                        },
                        "auditData": {
                            "createdAt": 1663855094,
                            "createdBy": "user@company.com",
                            "isDeleted": false,
                            "version": 1
                        }
                    }
                ]
            }
        }
    ]
}

Samples for updating transmission credentials for Romania

Request sample

Request sample for updating transmission credentials:

curl --location --request PUT 'https://api-test.sovos.com/v2/configurations/organizations/YOUR-ORG-ID/settings/SETTING-ID' \
--header 'x-correlationId: developer-guide' \
--header 'Content-Type: application/json' \
--data-raw '"value": {
    "accessToken": NEW-TOKEN-HERE,
    "refreshToken": NEW-REFRESH-TOKEN-HERE,
    "clientId": NEW-CLIENTID-HERE,
    "clientSecret": NEW-CLIENTSECRET-HERE
},'

Response sample

Response sample for updating transmissions credentials:

{
    "status": 201,
    "message": "Created",
    "success": true,
    "timestamp": 1663855094969,
    "data": [
        {
            "message": "Configurations are created",
            "statusCode": 201,
            "configurationContextResponse": {
                "context": "Transmission",
                "configurations": [
                    {
                        "id": SETTING-ID,
                        "name": "partner_credentials_anaf",
                        "value": {
                            "accessToken": NEW-TOKEN-HERE,
                            "refreshToken": NEW-REFRESH-TOKEN-HERE,
                            "clientId": NEW-CLIENTID-HERE,
                            "clientSecret": NEW-CLIENTSECRET-HERE
                        },
                        "scope": {
                            "category": "RO_INV",
                            "productId": "ro_Factura__1.0",
                            "orgId": YOUR-ORG-ID,
                            "taxId": YOUR-COMPANY-TAXID
                        },
                        "auditData": {
                            "createdAt": 1663855094,
                            "createdBy": "user@company.com",
                            "updatedAt": 1663855936,
                            "updatedBy": "user@company.com",
                            "isDeleted": false,
                            "version": 1
                        }
                    }
                ]
            }
        }
    ]
}

Issue invoice

Issuing invoices in Romania is based on the Default business process, which follows this order: Mapping and Transmission. The following diagram provides a detailed overview:

Romania outbound flow

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:

SCI - InvoiceLocal Format - InvoiceSCI - Credit noteLocal Format - Credit note

Use the following values in the SBDH for invoices that use the SCI format.

NodeRequiredAttributesValue
StandardBusinessDocumentHeader.Sender.IdentifierYesAuthority="RO"Supplier's tax ID
StandardBusinessDocumentHeader.Receiver.IdentifierYesAuthority="RO"
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes2.1
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Country

Child node Identifier: RO

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. We recommend the ERP document ID.

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 will use 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 : Factura

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes for export invoices where the buyer's TIN is outside Romania (the buyer doesn't have a CUI or NIF)

Child node Type: Transmission.OperationType

Child node Identifier: EXPORT

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes in cases where a self-billing invoice is being transmitted

Child node Type: Transmission.OperationType

Child node Identifier: SELF-BILLED

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type : BusinessCategory

Child node Identifier: "B2B" for Business to Business transactions or "B2C" for Business to Consumer transactions

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type : Version

Child node Identifier: 1.0

StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceNameYesDefault
SovosDocument.SovosCanonicalInvoice.InvoiceYesSCI

Alternatively, the supplier can use the local format (UBL only, not CII) for invoices. Use the following values in the SBDH for documents that use the local invoice format.

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes1.0
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: LEGAL-TO-SCI_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier: Factura

SovosDocument.SovosLegalDocument.Base64DocumentYesA local format

You need to encode the local format (XML) document in Base64 before you can add it as part of the SBD. Here is a sample:

    </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>
</svs:StandardBusinessDocument>

Supported document types for the Local Format (XML) document:

  • 380 - Invoice

  • 384 - Corrected invoice

  • 389 - Self invoice

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

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_CREDIT_NOTE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier: Factura

SovosDocument.SovosLegalDocument.Base64DocumentYesSCI

Use the following values in the SBDH for credit notes that use the local format:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesurn:oasis:names:specification:ubl:schema:xsd:CreditNote-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesCreditNote
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: LEGAL-TO-SCI_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier: Factura

SovosDocument.SovosLegalDocument.Base64DocumentYesA local format

Supported document type for the Local Format (XML) document: "381 - Credit note".

Note:

Include all the mandatory nodes, as specified in the SBDH schema. If the information cannot be provided, and the respective mandatory 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. In addition, there's a full sample of the SBD on the Postman Samples page.
<sbd:StandardBusinessDocument xmlns="http://uri.etsi.org/01903/v1.4.1#" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="RO">123456789</sbd:Identifier>
			<sbd:ContactInformation>
				<sbd:Contact>123456789</sbd:Contact>
				<sbd:EmailAddress/>
				<sbd:FaxNumber/>
				<sbd:TelephoneNumber/>
				<sbd:ContactTypeIdentifier/>
			</sbd:ContactInformation>
		</sbd:Sender>
		<sbd:Receiver>
			<sbd:Identifier Authority="RO">444555666</sbd:Identifier>
			<sbd:ContactInformation>
				<sbd:Contact>444555666</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>2022-06-16T00:31:52Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<sbd:Type>Version</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>1.0</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderDocumentId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>321412</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderSystemId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>UAT101</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
                <sbd:Type>CompanyCode</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>444555666</sbd:Identifier>
            </sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>RO</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>ProcessType</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>Outbound</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>Factura</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>BusinessCategory</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>B2B</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SubSchema</sbd:Type>
				<sbd:InstanceIdentifier/>
				<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:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<sci:SovosCanonicalInvoice>
			<inv:Invoice>
			    *UBL Elements*
			</inv:Invoice>
		</sci:SovosCanonicalInvoice>
	</svs:SovosDocument>
</sbd: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:

NameTypeRequiredDescription
datastringYesThe SBD encoded in Base64, as created in step 1.
dataEncodingstringYesEnter "base64".
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": "3add2b7104dc0049ff0bf410f57e0a19afaf"
    }
}

Step 3: Sovos maps the SCI into XML

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

This step will be skipped if the SBD contains the invoice in the local format (UBL).

Step 4: Sovos performs the schema validation

Sovos performs a schema validation based on the information provided by the tax authority. If there are errors in the document, Sovos detects detects them instead of waiting for the tax authority's response.

Step 5: Sovos transmits the XML

Sovos transmits the XML file to the tax authority e-invoice system.

Step 6: RO e-Factura system processes the XML

The RO e-Factura system performs a schema validation and several business validations. Then it generates an approval or rejection response message along with an error message, where applicable.

If the validation succeeds, the RO e-Factura system signs the document before returning a response.

Step 7: RO e-Factura system sends the response to Sovos

The RO e-Factura system sends the response to Sovos.

Sovos downloads the official PDF for each invoice from ANAF and generates a notification.

Step 8: Supplier retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial sending of the document, the client receives 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 the cleared XML encoded in Base64 after it's available during the process.

Additionally, you must consider the following details included in the response:

Transmission message
It maps to the SCIGovtStatusCode and StatusReason elements in the response message, as described in the application responses documentation, which details any warnings or additional notes to consider. The Romanian tax authority doesn't define any specific set of rules about what action to take on each error. Depending on the type of message, the user may have to modify the invoice, take some additional action, or simply make a note for the future.
ANAF credentials

As the credentials eventually expire, you need to recreate them and reconfigure them in the Sovos solution. This expiration is detected when the client transmits a document through Sovos, as ANAF returns the following error, which is visible in the application response:

<cac:Status>
  <cbc:StatusReasonCode listID="SCIGovtStatusCode">access_denied</cbc:StatusReasonCode>
  <cbc:StatusReason>Refresh Token's configured usage limit has been reached</cbc:StatusReason>
</cac:Status>

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification)
When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 209 that contains all the relevant attachments and data. Detailed description follows.
Fetch multiple responses (notifications) containing different information
When polling for responses, Sovos returns multiple notifications with different SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.
Note:

To configure notifications for your company or update your current configuration, contact the Professional Services team.

Single responseMultiple responses

To complete a transaction, the supplier retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

AP
The document's compliance status has been accepted with all the necessary attachments and data included.
RE
The document's compliance status has been rejected, and more parsing is needed:

  • If SCIGovtStatusCode is present, the error can be found by reading StatusReason.

  • if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

#SCICloudStatusCode SCIResponseCode Sample
1 209AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode"/>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed
2209RE 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode"/>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">DownloadError</cbc:StatusReasonCode>
				<cbc:StatusReason>
				E: validari globale
				SCHEMATRON 
				eroare: [BR-O-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Not subject to VAT" shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-48).
				</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed

To complete a transaction, the supplier must retrieve the application responses until the transaction has finished. If the supplier has subscribed to multiple notifications, the transaction can generate different application responses, as shown in the table below. The transaction finishes when a notification containing SCICloudStatusCode with the value of 209 has been received.

#SCICloudStatusCodeSCIResponseCode Sample
1100IP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
				<cbc:StatusReason>Document received successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Document received successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document received successfully
2101IP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
				<cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode"/>
				<cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document mapped successfully
3200AP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">200</cbc:StatusReasonCode>
        <cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">200-Authorized</cbc:StatusReasonCode>
        <cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Authorized by the tax authority
4207AB 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AB</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">207</cbc:StatusReasonCode>
				<cbc:StatusReason>Pdf created successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">207-PDF Created successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Pdf created successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
PDF created successfully
5209AP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed
6400RE 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">DownloadError</cbc:StatusReasonCode>
				<cbc:StatusReason>E: validari globale
 SCHEMATRON 
 eroare: [BR-CL-01]-The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">DownloadError</cbc:StatusReasonCode>
				<cbc:StatusReason>E: validari globale
 SCHEMATRON 
 eroare: [BR-RO-020]-Codul tipului facturii (BT-3) trebuie sa fie unul dintre urmatoarele coduri din lista de coduri UNTDID 1001: 380 (Factura), 389 (Autofactura), 384 (Factura corectata), 381 (Nota de creditare), 751 (Factura — informatii în scopuri contabile).
 			#The invoice type code (BT-3) must be one of the following codes in the UNTDID 1001 code list: 380 (Invoice), 389 (Self-invoice), 384 (Corrected invoice), 381 (Credit note), 751 (Invoice - i ...</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Rejected by the tax authority or the counterparty
7401RE 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">401</cbc:StatusReasonCode>
				<cbc:StatusReason>Error processing document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">401-Document error</cbc:StatusReasonCode>
				<cbc:StatusReason>Error processing document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
				<cbc:StatusReason>The element 'Invoice' in namespace 'urn:oasis:names:specification:ubl:schema:xsd:Invoice-2' has incomplete content. List of possible elements expected: 'InvoiceLine' in namespace 'urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2'.</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Error processing document
Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.

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

  • GET /notifications/RO

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

GET /notifications/RO
The supplier can send a GET request to the /notifications/RO endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo

Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.

Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.

pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications, within 24 hours of their acknowledgment, must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/RO?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "ro_Factura_1.0",
                    "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf",
                    "erpDocumentId": "321412",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "08AAACI9260R002",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "100"
                },
                "appPrefix": "DLT",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}
GET /documents/RO/{documentId}/notifications
The supplier can send a GET request to the /documents/RO/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameter:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 2
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/RO/{documentId}/notifications?' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "ro_Factura_1.0",
                    "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf",
                    "erpDocumentId": "321412",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "08AAACI9260R002",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "100"
                },
                "appPrefix": "DLT",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}

Step 9: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RO endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/RO' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-fd3e-4dcf-aea3-a73d73e0de76"
    }
]'
Response sample
{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Step 10: Archiving

You can compliantly archive the XML, the application response, and any graphical representation, such as a PDF, using Sovos' Compliant Archive.

For suppliers integrating with the Sovos solution for Romania for the first time, we recommend the bundled approach, in which archiving is part of the invoice clearance flow. Archiving can also be done separately through an explicit API call that uses another archive. For more information on standalone archiving, see the eArchiving documentation page.

Note: Bundled e-invoice archiving is optional. This means you can use your current solution and include Sovos e-Archiving.

Step 11: Supplier sends the invoice to the buyer

The delivery of the invoice to the buyer is outside the scope of Sovos, so it's up to the supplier to design a solution which accommodates the preferred business processes. It can be sent to the buyer after it has been signed by and retrieved from the RO e-Factura system.

Retrieve invoice

The diagram below provides a detailed overview of the inbound flow process for retrieving e-invoices in Romania:

Romania inbound invoice retrieval flow

Step 1: Sovos retrieves the documents from the RO e-Factura system

Sovos uses the buyer's credentials to authenticate with the RO e-Factura system to collect the available documents. Sovos downloads the official PDF for each invoice from ANAF and generates a notification.
Note:

The Sovos solution doesn't support self-billing reception (as a supplier) due to ANAF's design.

.

Step 2: Sovos maps the retrieved documents into SCI

Sovos maps the retrieved XML documents into the SCI format.

Step 3: Sovos makes the documents available

Sovos stores the retrieved documents and makes them available to buyers for retrieval.

Step 4: Buyer retrieves the available documents

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

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. See the table below:

#SCICloudStatusCodeSCIResponseCode Sample
1100IP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document received successfully
2101IP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">101-Mapped successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document mapped successfully
3204AB 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AB</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">204</cbc:StatusReasonCode>
        <cbc:StatusReason>Document distributed successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">204-Distributed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document distributed successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document distributed successfully
4207AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">207</cbc:StatusReasonCode>
        <cbc:StatusReason>Pdf created successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">207-PDF Created successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Pdf created successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
PDF created successfully. The PDF is part of the attachments in the notification (see the attached document).
5209AP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed

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

GET /notifications/RO
The buyer can send a GET request to the /notifications/RO endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNoInclude only notifications related to the specified taxId.
pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "1" to only include notifications related to inbound documents.
orgId stringNo Unique identifier for the organization. When provided, restricts the notifications listed to documents associated with this organization ID (only applicable for Worskspace tenants).
senderDocumentIdstringNo Unique identifier for the sender's document. When provided, restricts the notifications listed to this sender document ID (only applicable if the scope SenderDocumentId has been provided in the POST /v1/documents endpoint).
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/RO?processType=1&sourceSystemId={sourceSystemId}&taxId={taxId}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "status": 200,
    "message": "Notifications Listed",
    "success": true,
    "timestamp": 0,
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 10,
            "totalEntries": 1,
            "totalPages": 1
        },
        "notifications": [
            {
                "notificationId": "ba056226-...-a111e24acd51",
                "correlationId": "49a75544-...-5f672c2a814d",
                "appPrefix": "DLT",
                "metadata": {
                    "productId": "ro_Factura_Polling_1.0",
                    "transactionId": "47514154-...-77a72ab75731",
                    "documentId": "04c...151",
                    "erpDocumentId": "YOUR-DOCUMENT-ID",
                    "erpSystemId": "YOUR-SYSTEMERP",
                    "processType": "1",
                    "taxId": "YOUR-TAXID",
                    "sciCloudStatusCode": "209",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA"
                },
                "content": "PD...T4=",
                "createdDate": 1674572920
            }
        ]
    }
}

Step 5: Buyer acknowledges the retrieved documents

The buyer must process the retrieved documents and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RO endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/RO' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-...-a73d73e0de76"
    }
]'
Response sample
{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Issue e-Transport document

Issuing e-Transport documents in Romania is based on the Default business process. The following diagram provides a detailed overview:

Romania outbound flow for e-Transport

Step 1: Supplier creates the Standard Business Document

Every e-Transport electronic document 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) or Legal format. To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages.

Note:

If you have to issue a correction, you can do it the same way you posted the initial document, with a slight difference. The corrected document should contain a UIT reference, which is a reference ID provided by the e-Transport system for the initial document.

Here are some key elements that should be included in the SBD and in the invoice:

SCI - InvoiceLocal Format - Invoice

Use the following values in the SBDH for invoices that use the SCI format.

NodeRequiredAttributesValue
StandardBusinessDocumentHeader.Sender.IdentifierYesAuthority="RO"Supplier's tax ID
StandardBusinessDocumentHeader.Receiver.IdentifierYesAuthority="RO"
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes2.1
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Country

Child node Identifier: RO

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. We recommend the ERP document ID.

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 will use 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 : Invoice

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type : BusinessCategory

Child node Identifier: "B2B"

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type : Version

Child node Identifier: 2.0

StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceNameYesDefault

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

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesmfp:anaf:dgti:eTransport:declaratie:v2
StandardBusinessDocumentHeader.DocumentIdentification.TypeYeseTransport
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: LEGAL-TO-SCI_INVOICE

Note:

Include all the mandatory nodes, as specified in the SBDH schema. If the information cannot be provided, and the respective mandatory 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. In addition, there's a full sample of the SBD on the Postman Samples page.
<sbd:StandardBusinessDocument xmlns="http://uri.etsi.org/01903/v1.4.1#" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="RO">123456789</sbd:Identifier>
			<sbd:ContactInformation>
				<sbd:Contact>123456789</sbd:Contact>
				<sbd:EmailAddress/>
				<sbd:FaxNumber/>
				<sbd:TelephoneNumber/>
				<sbd:ContactTypeIdentifier/>
			</sbd:ContactInformation>
		</sbd:Sender>
		<sbd:Receiver>
			<sbd:Identifier Authority="RO">444555666</sbd:Identifier>
			<sbd:ContactInformation>
				<sbd:Contact>444555666</sbd:Contact>
				<sbd:EmailAddress/>
				<sbd:FaxNumber/>
				<sbd:TelephoneNumber/>
				<sbd:ContactTypeIdentifier/>
			</sbd:ContactInformation>
		</sbd:Receiver>
		<sbd:DocumentIdentification>
			<sbd:Standard>mfp:anaf:dgti:eTransport:declaratie:v2</sbd:Standard>
			<sbd:TypeVersion>2.1</sbd:TypeVersion>
			<sbd:InstanceIdentifier/>
			<sbd:Type>Invoice</sbd:Type>
			<sbd:MultipleType>false</sbd:MultipleType>
			<sbd:CreationDateAndTime>2022-06-16T00:31:52Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<sbd:Type>Version</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>2.0</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderDocumentId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>321412</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderSystemId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>UAT101</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
                <sbd:Type>CompanyCode</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>444555666</sbd:Identifier>
            </sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>RO</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>ProcessType</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>Outbound</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Mapping.TransformDocument</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>LEGAL-TO-SCI_INVOICE</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Mapping.OutputSchema</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>Invoice</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>BusinessCategory</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>B2B</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:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<svs:SovosLegalDocument>
			<enc:Base64Document>
				<enc:Base64Document>*UBL Elements*</enc:EmbeddedDocument>
			</enc:EmbeddedDocument>
		</svs:SovosLegalDocument>
	</svs:SovosDocument>
</sbd: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:

NameTypeRequiredDescription
datastringYesThe SBD encoded in Base64, as created in step 1.
dataEncodingstringYesEnter "base64".
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": "3ad...faf"
    }
}

Step 3: Sovos performs the schema validation

Sovos performs a schema validation based on the information provided by the tax authority. If there are errors in the document, Sovos detects detects them instead of waiting for the tax authority's response.

Step 4: Sovos transmits the XML

Sovos transmits the XML file to the tax authority e-Transport system.

Step 5: RO e-Transport system processes the XML

The RO e-Transport system performs a schema validation and several business validations. Then it generates an approval or rejection response message along with an error message, where applicable.

If the validation succeeds, the system generates a UIT code and sends it to the client.

Step 6: RO e-Transport system sends the response to Sovos

The RO e-Transport system sends the response to Sovos.

Step 7: Supplier retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial sending of the document, the client receives 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 the cleared XML encoded in Base64 after it's available during the process.

Additionally, you must consider the following details included in the response:

Transmission message
It maps to the SCIGovtStatusCode and StatusReason elements in the response message, as described in the application responses documentation, which details any warnings or additional notes to consider. The Romanian tax authority doesn't define any specific set of rules about what action to take on each error. Depending on the type of message, the user may have to modify the invoice, take some additional action, or simply make a note for the future.
ANAF credentials

As the credentials eventually expire, you need to recreate them and reconfigure them in the Sovos solution. This expiration is detected when the client transmits a document through Sovos, as ANAF returns the following error, which is visible in the application response:

<cac:Status>
  <cbc:StatusReasonCode listID="SCIGovtStatusCode">access_denied</cbc:StatusReasonCode>
  <cbc:StatusReason>Refresh Token's configured usage limit has been reached</cbc:StatusReason>
</cac:Status>

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification)
When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 209 that contains all the relevant attachments and data. Detailed description follows.
Fetch multiple responses (notifications) containing different information
When polling for responses, Sovos returns multiple notifications with different SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.
Note:

To configure notifications for your company or update your current configuration, contact the Professional Services team.

Single responseMultiple responses

To complete a transaction, the supplier retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

AP
The document's compliance status has been accepted with all the necessary attachments and data included.
RE
The document's compliance status has been rejected, and more parsing is needed:

  • If SCIGovtStatusCode is present, the error can be found by reading StatusReason.

  • if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

#SCICloudStatusCode SCIResponseCode Sample
1 209AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed
2209RE 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">invalid_client</cbc:StatusReasonCode>
				<cbc:StatusReason>Invalid client_id dummy_client</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed

To complete a transaction, the supplier must retrieve the application responses until the transaction has finished. If the supplier has subscribed to multiple notifications, the transaction can generate different application responses, as shown in the table below. The transaction finishes when a notification containing SCICloudStatusCode with the value of 209 has been received.

#SCICloudStatusCodeSCIResponseCode Sample
1100IP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document received successfully
2102IP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">102</cbc:StatusReasonCode>
				<cbc:StatusReason>Document validated successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">102-Document validated successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Document validated successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document validated successfully
3104IP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">104</cbc:StatusReasonCode>
				<cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">104-Transmitted to the tax authority</cbc:StatusReasonCode>
				<cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Transmitted to the tax authority
4200AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">200</cbc:StatusReasonCode>
				<cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">200-Authorized</cbc:StatusReasonCode>
				<cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Authorized by the Tax Authority
5208AB 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AB</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">208</cbc:StatusReasonCode>
				<cbc:StatusReason>Document archived successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">208-Document archived successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Document archived successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document archived successfully
6209AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed
7400RE 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">UploadError</cbc:StatusReasonCode>
				<cbc:StatusReason>CIF-ul din apel nu este identic cu codDeclarant din fisierul transmis</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Rejected by the Tax Authority or the counterparty
8401RE 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">401</cbc:StatusReasonCode>
				<cbc:StatusReason>Error processing document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">401-Document error</cbc:StatusReasonCode>
				<cbc:StatusReason>Error processing document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
				<cbc:StatusReason>The element 'notificare' in namespace 'mfp:anaf:dgti:eTransport:declaratie:v2' has invalid child element 'codTipOperatiune' in namespace 'mfp:anaf:dgti:eTransport:declaratie:v2'. List of possible elements expected: 'corectie, bunuriTransportate' in namespace 'mfp:anaf:dgti:eTransport:declaratie:v2'.</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Error processing document
Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.

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

  • GET /notifications/RO

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

GET /notifications/RO
The supplier can send a GET request to the /notifications/RO endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo

Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.

Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.

pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications, within 24 hours of their acknowledgment, must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/RO?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN'
Response sample
{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "ro_Invoice_2.0",
                    "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf",
                    "erpDocumentId": "321412",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "08AAACI9260R002",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "100"
                },
                "appPrefix": "DLT",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}
GET /documents/RO/{documentId}/notifications
The supplier can send a GET request to the /documents/RO/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following path parameter:
NameTypeRequiredDefaultDescription
documentIdstringYesThe ID of the document returned in step 2
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/RO/{documentId}/notifications' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "ro_Invoice_2.0",
                    "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf",
                    "erpDocumentId": "321412",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "08AAACI9260R002",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "100"
                },
                "appPrefix": "DLT",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}

Step 8: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RO endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/RO' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-fd3e-4dcf-aea3-a73d73e0de76"
    }
]'
Response sample
{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Step 9: Archiving

You can compliantly archive the XML, the application response, and any graphical representation, such as a PDF, using Sovos' Compliant Archive.

For suppliers integrating with the Sovos solution for Romania for the first time, we recommend the bundled approach, in which archiving is part of the invoice clearance flow. Archiving can also be done separately, through an explicit API call that uses another archive. For more information on standalone archiving, see the eArchiving documentation page.

Note: Bundled e-invoice archiving is optional. This means you can use your current solution and include Sovos e-Archiving.

Confirm e-Transport document (finalization)

Confirming e-Transport in Romania is based on the Default business process, which follows this order: Mapping and Transmission. The following diagram provides a detailed overview:

Romania e-transport confirmation (finalization) flow

Step 1: Supplier sends a POST request to Sovos

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

The request must include the following request body parameters:

NameTypeRequiredDescription
actionCodestringYesEnter "document.finalize".
documentsarray of objectsYesAn array of objects to include the metadata and the document ID.
metadataobjectNoAn object that includes the required metadata.
reasonCode stringYes

This field indicates the reason. Available code values are:

  • 10 - Confirmat

  • 20 - Confirmat partial: Partial confirmation of the goods received (part of the goods is being returned)

  • 30 - Infirmat: The consignment of goods is being returned

descriptionstringNoThis field describes the reason code.
documentIdstringYesThe ID of the document to be finalized. This is the ID that Sovos returns when you send the document.
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents/RO/action' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '{
    "actionCode": "document.finalize",
    "documents": [
      {
        "metadata": {
            "reasonCode": "10",
            "description": "All goods were received"
        },
        "documentId": "DOCUMENT-ID"
      }
    ]
  }'
Response sample
{
    "status": 202,
    "message": "Accepted",
    "success": true,
    "timestamp": 1708017506863,
    "data": [
        {
            "status": 202,
            "documentId": "DOCUMENT-ID"
        }
    ]
}

Step 2: Sovos maps the file into the confirmation XML

Sovos maps the file into the required confirmation XML format.

Step 3: Sovos transmits the request

Sovos transmits the request to the tax authority EKAER system.

Step 4: Sovos triggers a call to the e-Transport system

Sovos triggers an asynchronous call to the e-Transport system with "FINALIZE" as an operation and receives a success or an error response.

Step 5: Supplier retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial sending of the document, the client receives 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 include the acceptance or rejection message.

To complete a transaction, the supplier must retrieve the application responses until the SCIResponseCode in the response has the value of either "AP" or "RE", which indicates that the transaction is finished. If the supplier has subscribed to all notifications, the transaction can generate different application responses. See the table below:

#SCICloudStatusCodeSCIResponseCode Sample
1104IP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">104</cbc:StatusReasonCode>
				<cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">104-Transmitted to the tax authority</cbc:StatusReasonCode>
				<cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Transmitted to the tax authority
2206AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">206</cbc:StatusReasonCode>
				<cbc:StatusReason>Finalized</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">206-Finalized successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Finalized</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Finalized
3209AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed

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

  • GET /notifications/RO

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

GET /notifications/RO
The supplier can send a GET request to the /notifications/RO endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNoInclude only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.
pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/RO?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533798766,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 59,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "97a2cc72-c947-4311-bfcd-0d5032e3b270",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "ro_Invoice__2.0",
                "transactionId": "be...a87",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "172012265",
                "erpSystemId": "ERPSystem",
                "processType": "0",
                "taxId": "11161161",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "RE",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "TC_INVALID_ARRIVALDATE"
            },
            "content": "PD...2U+",
            "createdDate": 1708533782661
GET /documents/RO/{documentId}/notifications
The supplier can send a GET request to the /documents/RO/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameters:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 1
includeAcknowledgedbooleanNoQueryfalse Enter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location 'https://api-test.sovos.com/v1/documents/RO/{documentId}/notifications?includeAcknowledged=false' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533798766,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 59,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "97a2cc72-c947-4311-bfcd-0d5032e3b270",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "ro_Invoice__2.0",
                "transactionId": "be...a87",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "172012265",
                "erpSystemId": "ERPSystem",
                "processType": "0",
                "taxId": "11161161",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "RE",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "TC_INVALID_ARRIVALDATE"
            },
            "content": "PD...2U+",
            "createdDate": 1708533782661

Step 6: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RO endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/RO' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '[
    {
        "status": "read",
        "notificationId": "e7b32eda-cb67-43b9-91de-f6d9c90f60d9"
    }
]'
Response sample
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1708440016669,
    "data": {}
}

Delete e-Transport document (cancellation)

Deleting e-Transport in Romania is based on the Default business process, which follows this order: Mapping and Transmission. The following diagram provides a detailed overview:

Romania e-transport deletion (cancellation) flow

Step 1: Supplier sends a POST request to Sovos

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

The request must include the following request body parameters:

NameTypeRequiredDescription
actionCodestringYesEnter "document.cancellation".
documentsarray of objectsYesAn array of objects to include the metadata and the document ID.
documentIdstringYesThe ID of the document to be canceled. This is the ID that Sovos returns when you send the document.
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents/RO/action' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--data '{
    "actionCode": "document.cancellation",
    "documents": [
      {
        "documentId": "DOCUMENT-ID"
      }
    ]
  }'
Response sample
{
    "status": 202,
    "message": "Accepted",
    "success": true,
    "timestamp": 1708018192828,
    "data": [
        {
            "status": 202,
            "documentId": "DOCUMENT-ID"
        }
    ]
}

Step 2: Sovos maps the file into the deletion XML

Sovos maps the file into the required deletion XML format.

Step 3: Sovos transmits the request

Sovos transmits the request to the tax authority e-Transport system.

Step 4: Sovos triggers a call to the e-Transport system

Sovos triggers an asynchronous call to the e-Transport system with "DELETE" as an operation and receives a success or an error response.

Step 5: Supplier retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial sending of the document, the client receives 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 include the acceptance or rejection message.

To complete a transaction, the supplier must retrieve the application responses until the SCIResponseCode in the response has the value of either "AP" or "RE", which indicates that the transaction is finished. If the supplier has subscribed to all notifications, the transaction can generate different application responses. See the table below:

#SCICloudStatusCodeSCIResponseCode Sample
1104IP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">104</cbc:StatusReasonCode>
				<cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">104-Transmitted to the tax authority</cbc:StatusReasonCode>
				<cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Transmitted to the tax authority
2201AP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">201</cbc:StatusReasonCode>
        <cbc:StatusReason>Cancelled</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">201-Cancelled successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Cancelled</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Canceled
3209AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed

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

  • GET /notifications/RO

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

GET /notifications/RO
The supplier can send a GET request to the /notifications/RO endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNoInclude only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.
pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/RO?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "40e2ef57-7b59-408c-8034-8e1c9e8de016",
            "correlationId": "developer-guide",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "ro_Invoice__2.0",
                "transactionId": "78...5f0",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "172012265",
                "erpSystemId": "ERPSystem",
                "processType": "0",
                "taxId": "11161161",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255
GET /documents/RO/{documentId}/notifications
The supplier can send a GET request to the /documents/RO/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameters:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 1
includeAcknowledgedbooleanNoQueryfalse Enter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location 'https://api-test.sovos.com/v1/documents/RO/{documentId}/notifications?includeAcknowledged=false' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "40e2ef57-7b59-408c-8034-8e1c9e8de016",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "ro_Invoice__2.0",
                "transactionId": "78...5f0",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "172012265",
                "erpSystemId": "ERPSystem",
                "processType": "0",
                "taxId": "11161161",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255

Step 6: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RO endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/RO' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '[
    {
        "status": "read",
        "notificationId": "e7b32eda-cb67-43b9-91de-f6d9c90f60d9"
    }
]'
Response sample
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1708509282198,
    "data": {}
}

Modify vehicle on e-Transport document

Modifying a vehicle on an e-Transport document in Romania is based on the Default business process, which follows this order: Mapping and Transmission. The following diagram provides a detailed overview:

Romania e-transport modify vehicle flow

Step 1: Supplier sends a POST request to Sovos

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

The request must include the following request body parameters:

NameTypeRequiredDescription
actionCodestringYesEnter "document.modification".
documentsarray of objectsYesAn array of objects to include the metadata and the document ID.
metadataobjectNoAn object that includes the required metadata.
modificationDatestringNo Invoice modification date.
vehicleNumberstringNo Vehicle registration number.
towNumber1stringNoTow registration number 1.
towNumber2stringNo Tow registration number 2.
descriptionstringNo Some notes about the modification.
documentIdstringYesThe ID of the document to be canceled. This is the ID that Sovos returns when you send the document.
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents/RO/action' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '{
    "actionCode": "document.modification",
    "documents": [
        {
            "metadata": {
                "modificationDate": "2024-07-01T12:30",
                "vehicleNumber": "BV01ZZZ",
                "towNumber1": "98765",
                "towNumber2": "12345",
                "description": "new vehicle will be used"
            },
            "documentId": "DOCUMENT-ID"
        }
    ]
}'
Response sample
{
  "status": 202,
  "message": "Accepted",
  "success": true,
  "timestamp": 1721054049959,
  "data": [
    {
      "status": 202,
      "transactionId": "TRANSACTION-ID",
      "documentId": "DOCUMENT-ID"
    }
  ]
}

Step 2: Sovos maps the file into the modify vehicle XML

Sovos maps the file into the required modify vehicle XML format.

Step 3: Sovos transmits the request

Sovos transmits the request to the tax authority e-Transport system.

Step 4: Sovos triggers a call to the e-Transport system

Sovos triggers an asynchronous call to the e-Transport system with "MODIFY VEHICLE" as an operation and receives a success or an error response.

Note:

This modification can be done after starting transport and during the following three days.

Step 5: Supplier retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial sending of the document, the client receives 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 include the acceptance or rejection message.

To complete a transaction, the supplier must retrieve the application responses until the SCIResponseCode in the response has the value of either "AP" or "RE", which indicates that the transaction is finished. If the supplier has subscribed to all notifications, the transaction can generate different application responses. See the table below:

#SCICloudStatusCodeSCIResponseCode Sample
1101IP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">101-Mapped successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document mapped successfully
2200AP 
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">200</cbc:StatusReasonCode>
        <cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
Authorized by the tax authority
3209AP 
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed

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

  • GET /notifications/RO

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

GET /notifications/RO
The supplier can send a GET request to the /notifications/RO endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNoInclude only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.
pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/RO?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \ --header 'Content-Type: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "40e2ef57-7b59-408c-8034-8e1c9e8de016",
            "correlationId": "developer-guide",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "ro_Invoice__2.0",
                "transactionId": "78...5f0",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "172012265",
                "erpSystemId": "ERPSystem",
                "processType": "0",
                "taxId": "11161161",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255
GET /documents/RO/{documentId}/notifications
The supplier can send a GET request to the /documents/RO/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameters:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 1
includeAcknowledgedbooleanNoQueryfalse Enter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location 'https://api-test.sovos.com/v1/documents/RO/{documentId}/notifications?includeAcknowledged=false' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "40e2ef57-7b59-408c-8034-8e1c9e8de016",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "ro_Invoice__2.0",
                "transactionId": "78...5f0",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "172012265",
                "erpSystemId": "ERPSystem",
                "processType": "0",
                "taxId": "11161161",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255

Step 6: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/RO endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/RO' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '[
    {
        "status": "read",
        "notificationId": "e7b32eda-cb67-43b9-91de-f6d9c90f60d9"
    }
]'
Response sample
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1708509282198,
    "data": {}
}

Mock tax authority integration

You can test the integration with the Sovos solution for Romania using a mocked tax authority communication. For that, you can use Sovos' mocked services, which replace the tax authority communication in the solution and let you make limited tests of business scenarios.

You can also dynamically distinguish between mocked services and testing against the real tax authority UAT environment on a document-by-document basis.

Testing with Sovos’ mocked services is not a replacement for the UAT/Sandbox environment tests. With that in mind, you should keep making tests in the UAT/Sandbox environment before moving to the Production environment. This is because Sovos’ mocked services cannot fully simulate the tax authority behavior and validations due to the vast amount of different business scenarios that are applicable to Romania.

Outbound Mock

The Outbound Mock simulates sending documents to the tax authority. Before issuing your documents, you must upload specific credentials using the Configurations v2 API resource.
Outbound Mock configuration
To use the mock services for Romania Outbound, configure arbitrary credentials (inside the value object) using the POST /v2/configurations/organizations/{organizationId}/settings endpoint from Configurations v2.

Here is a sample request:

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/organizations/YOUR-ORG-ID/settings' \
--header 'x-correlationId: developer-guide-mock' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "context": "transmission",
        "configurations": [
            {
                "name": "partner_credentials_anaf",
                "value": {
                    "accessToken": "INSERT-ARBITRARY-TOKEN-HERE",
                    "refreshToken": "INSERT-ARBITRARY-REFRESH-TOKEN-HERE",
                    "clientId": "INSERT-ARBITRARY-CLIENTID-HERE",
                    "clientSecret": "INSERT-ARBITRARY-CLIENTSECRET-HERE"
                },
                "scope": {
                    "category": "RO_INV",
                    "productId": "ro_Factura__1.0",
                    "orgId": "YOUR-ORG-ID",
                    "taxId": "YOUR-COMPANY-TAXID"
                }
            }
        ]
    }
]'
Outbound Mock usage

When sending a document with the POST /v1/documents endpoint to reach the mocked services, the x-correlationId value must end with "-mock". For example, x-correlationId = "123-mock". Sovos' solution distinguishes between the mocked Outbound services and the real tax authority UAT environment based on the presence of this value.

When using the GET method with the Notifications endpoints, the x-correlationId doesn't need to end with "-mock". This is because the Sovos solution doesn't differentiate between mocked notifications and notifications related to the real tax authority UAT environment — they are both treated as "notifications", which can be retrieved normally. The same reasoning applies to marking notifications as acknowledged with the PUT method: there's no need to add an x-correlationId ending with "-mock".

To test Outbound against the real tax authority UAT environment, it is crucial to follow the correct prerequisites and configuration steps. This involves obtaining the real tax authority credentials and configuring them in the Sovos solution. So, when issuing the document, make sure that x-correlationId doesn't end with "-mock".

Outbound Mock validation

The main purpose of the mocked services is to let you test the end-to-end flow early in the integration process, without being blocked by the need for real tax authority credentials. You can only test a limited set of scenarios based on the document's content.

  1. The maximum taxId length is 13 characters.

  2. The document should not be null.

  3. You can't use a previously registered document.

  4. The supplier taxId should not be null.

  5. The buyer taxId should not be null.

Inbound Mock

The Inbound Mock simulates the receipt of documents from the tax authority. To use it, you need to pre-upload your specific tax authority credentials using the the Configurations v2 API resource. When enabling the polling job, make sure that x-correlationId value ends with "-mock". This tells the Sovos solution to show notifications for the mock services that the client app can consume.

Inbound Mock configuration

To use the mock services for Romania Inbound, you must configure the credentials using the POST /v2/configurations/organizations/{organizationId}/settings endpoint from Configurations v2.

Here is a sample request:

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/organizations/YOUR-ORG-ID/settings' \
--header 'x-correlationId: developer-guide-mock' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "context": "polling",
        "configurations": [
            {
                "name": "partner_credentials_anaf",
                "value": {
                    "accessToken": "INSERT-ARBITRARY-TOKEN-HERE",
                    "refreshToken": "INSERT-ARBITRARY-REFRESH-TOKEN-HERE",
                    "clientId": "INSERT-ARBITRARY-CLIENTID-HERE",
                    "clientSecret": "INSERT-ARBITRARY-CLIENTSECRET-HERE"
                },
                "scope": {
                    "category": "RO_INV",
                    "productId": "ro_Factura_Polling_1.0",
                    "orgId": "YOUR-ORG-ID",
                    "taxId": "YOUR-COMPANY-TAXID"
                }
            }
        ]
    }
]'

Afterward, when you make the API call to "Configure an Inbound Service" in Configurations v2 (polling job enablement), you must include the x-correlationId value that ends with "-mock".

Inbound Mock usage

Before you can test document retrieval using the Inbound Mock, you must use the Outbound Mock to generate documents.

When you use the GET method with the Notifications endpoints for the Inbound Mock, the client app must filter the request with processType = "1" (inbound). You don't need to send an x-correlationId ending with "-mock". This is because the Sovos solution doesn't differentiate between mocked notifications and notifications related to the real tax authority UAT environment — they are both treated as "notifications", which can be retrieved normally. The same reasoning applies to marking notifications as acknowledged with the PUT method: there's no need to add an x-correlationId ending with "-mock".

You need to follow the correct prerequisites and configuration steps to test Inbound against the real tax authority UAT environment. This involves obtaining the real tax authority credentials and configuring them in the Sovos solution, disabling the existing polling job (as it is running using the mock) and re-enabling it without x-correlationId ending with "-mock".

Payload samples

The provided SCI and Local XML samples are meant to be guidelines for integration with the Indirect Tax API and should be treated as such, since each integrating system is unique and has different requirements. This means that the samples cannot be copied directly, and must be adapted to your system when integrating with the Indirect Tax API.

SCI foreign currency

Sample with a foreign taxID for the customer party and a foreign DocumentCurrencyCode: Romania_SCI-Foreign-Currency.xml

SCI with an attachment

Here is the sample: Romania_SCI-with-an-attachment.xml

SCI without an attachment

Sample without an attachment, containing 20 InvoiceLines: Romania_SCI-without-an-attachment.xml

SCI with negative amounts

Here is the sample: Romania_SCI-with-negative-amounts.xml

SCI credit note

Here is the sample: Romania_SCI-credit-note.xml

SCI authorized sample

This sample contains a VAT category. VAT is exempt if it has an "O" category. Here is the sample: Romania_SCI-authorized.xml

SCI credit note with foreign currency

Here is the sample: Romania_SCI-credit-note-with-foreign-currency.xml

SCI not subject to VAT

This sample contains a VAT category. A sample is exempt from tax if it has the "E" category. "E" is the code specifying that taxes are not applicable. Here is the sample: Romania_SCI-not-subject-to-vat.xml

SCI allowance charge

The ChargeIndicator value must be "true" or "false". If ChargeIndicator is "true", then there is a charge in the sample. If ChargeIndicator is false, then there is an allowance (discount). Here is the sample: Romania_SCI-allowance-charge.xml

This example contains information on seller 1111111111118, fiscal representative RO19, buyer 8609468, VAT currency =RON, and bill currency = RON. Here is the sample: Romania_legal-example-zero.xml

This example contains information on seller RO1111111111118, buyer 8609468, bill currency = RON. Here is the sample: Romania_legal-example-one.xml

This example contains information on seller 1111111111118, fiscal representative RO427320, buyer 8609468, and bill currency = RON. Here is the sample: Romania_legal-example-two.xml

Here is the sample: Romania_legal-credit-note.xml

Romania
Compliance Network
PDF

Last updated: August 22, 2025

sovos-footer

The Always-On Tax Compliance Company

More than 100,000 customers – including half the Fortune 500 – trust Sovos' tax and regulatory expertise and unparalleled integration with their business applications.

Contact Support

Sovos Platform

Compliance Cloud

Indirect Tax Suite

Compliance for SAP

Product Suites

Value-Added Tax

Tax Information Reporting

Sales and Use Tax

For Developers

Connector Marketplace

Trust APIs

© 2025 Sovos Compliance. All rights reserved.

Privacy Policy

About Us