Prerequisites

To get started with Sovos' Sandbox (UAT) or Production environments, you must meet some prerequisites.

Sandbox (UAT)

A valid UAT TLS certificate from Sovos. To apply for a certificate, you must fill in the following documents and share them with the Professional Services (PS) team.

• Appointment letter

• Support and change management document

Production

A valid Production TLS certificate. Sovos provides it during the official integration project, after the testing phase.

Available business processes

You must specify the business processes in the Standard Business Document Header (SBDH) and determine which microservices you want to apply to the document. In some cases, you can specify multiple business processes in the header, but not all business processes are available for every country or document.

Business processes available for post-audit countries:

• "Signing"

• "SignatureValidation"

• "Archiving"

Sample using "Signing" as the BusinessServiceName:

<sbd:Scope>
			<sbd:Type>BusinessProcess</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:BusinessService>
				<sbd:BusinessServiceName>Signing</sbd:BusinessServiceName>
			</sbd:BusinessService>
		</sbd:Scope>

Combining document formats, signatures, and audit data

The following table gives an overview of the recommended combinations of document formats, signature type, and audit data when signing invoices, validating signatures, or both:

Document formats

Sovos has a service for signing and validating any document. When using this service, you need to specify the document format in the Standard Business Document Header (SBDH) using the Signing.DocumentFormat and SignatureValidation.DocumentFormat scope information. Sovos supports the following document formats:

Electronic signatures

Sovos applies electronic signatures on e-invoices for post-audit countries. Electronic signatures created for countries in the European Union can be either signatures (Qualified or Advanced) or seals (Qualified or Advanced), as defined by the applicable EU legislation, and depending on the applicable VAT legislation.

To learn more on the legal background for these signature types, see the compliance documentation available in the Sovos Partner Portal. The specific type of signature and the certificate authorities used are described in the ERROR - unresolved reference (sovos_trustweaver_compl_map_post-audit).

Signature and audit data

Sovos has a service that lets you sign and validate any document, including invoices. It distinguishes three components:

Document

The signed or unsigned data

Signature

The electronic signature to be applied or validated in the transaction

Audit data

The data to be created during the transaction

These components can be bundled together or exist separately, so that different parameter sets are required to sign or validate a document, depending on the type of signature. To describe these two scenarios, Sovos uses the following terms:

Implicit

Given one component, the other is implied. In other words, they are bundled into one chunk of data.

Explicit

The components must be provided explicitly, as two separate chunks of data.

The implicit scenario is the most straightforward one and can be described as "document with implicit signature and audit data". You can find all scenarios Sovos supports in the subsections below.

Scenarios involving implicit and explicit signatures:

Implicit signature and audit data (signature type one)

This is a scenario where the document, signature, and optional audit data are bundled into one chunk of data.

Example signature formats that use this structure:

• Implicit CAdES-A signatures (with audit data)

• Implicit CAdES-T signatures (without audit data)

• Enveloping/enveloped XAdES-A signatures (with audit data)

• Enveloping/enveloped XAdES-T signatures (without audit data)

Explicit signature and audit data (signature type two)

This is a scenario where the document is provided in its "raw" format. Signature and optional audit data are provided separately, in a format that supports both.

Example signature formats that use this structure:

• Explicit (often called detached) CAdES-A signatures (with audit data)

• CAdES-T signatures (without audit data)

Implicit signature and explicit audit data (signature type three)

This is a scenario where the signature is bundled with the document, but the audit data is provided separately — if at all. This is usually due to limitations in the signature format used.

An example of a signature format where this structure may be used is the EDIFACT-based signature format.

Note:

Some documents use the expression "detached evidence data" instead of "detached audit data".

Sovos TrustWeaver compliance map

An instrument designed to centralize the control over localized compliance. It consists of structured information based on the requirements and compliant processes used for e-invoicing purposes.

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.