Definitions and concepts

Definitions and concepts related to Sovos eArchive, including clearance and post-audit countries, document formats, signature types, and the Sovos TrustWeaver Compliance Map.

Clearance Countries

Countries where the invoicing process must be cleared by the tax authority. Once cleared, the invoice becomes legally valid.

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 storing an invoice with Sovos eArchive:


ARCHIVING.SIGNATURETYPE	ARCHIVING.DOCUMENTFORMAT	ARCHIVING.SIGNATUREFORMAT	ARCHIVING.AUDITCATEGORY
Implicit	XML	XMLCON, XMLSIGED, XMLSIG	XADESA
	CXML	XMLSIG	XADESA
	PDF	PDF	CADESA, PADESLTV
	OTHER	SMIME, PKCS7	CADESA
	FATTURAPA	FATTURAPA	N/A
	ESLOG	ESLOG	N/A
	FACTURAE	FACTURAE	XADESA
Explicit	Any (XML, PDF, OTHER, etc.)	PKCS7D	CADESA
Audit	EANCOM	IDEAL, AECOC, GS1AT	EVIDENCE, N/A
	PDF	PDFE	EVIDENCE
	INIDJSON	INJWS	N/A
	BRNFE	BRNFEP	N/A
	BRCTE	BRCTEP	N/A
	MXCFDI	MXCFDIT	N/A
	PEINV	PEINVP	N/A
	CLDTE	CLDTEP	N/A

Document Formats

Sovos allows you to store any document with Sovos eArchive. When storing a document, it's necessary to specify the document format in the Standard Business Document Header via the Archiving.DocumentFormat Scope information. Sovos supports the following document formats:


ARCHIVING.DOCUMENTFORMAT	DESCRIPTION
XML	A generic XML document
PDF	A generic PDF document
CXML	cXML formatted invoice
UBL	UBL invoice
OTHER	The document is in a format not recognized by Sovos eArchive
EANCOM	EANCOM (EDIFACT) invoice
FACTURAE	Spanish Factura Electrónica formatted invoice
FATTURAPA	Document supporting invoicing in Italy
FATTURAPAR	Provisional form of FATTURAPA document
ESLOG	Document supporting B2G invoicing in Slovenia
CLDTE	Chilean DTE Fiscal Document format
CLRER	Chilean DTE Buyer Goods/Services Response
CLRDTEA	Chilean DTE Buyer Reception Response
CLRDTEC	Chilean DTE Buyer Commercial Response
MXCFDI	Mexican CFDI v3.2 electronic invoice format
MXCFD	Mexican CFD v2.2 (legacy) electronic invoice format
BRNFE	Brazilian goods XML invoice
BRNFSEC	Brazilian canonical services invoice
BRCTE	Brazilian XML document used for carriage of cargo
BRMDFE	Brazilian transport XML document
PEINV	Peruvian UBL XML e-invoice
PECRN	Peruvian UBL XML credit note
PEDEN	Peruvian UBL XML debit note
INIDJSON	Indian Invoice Document JSON
ITSBD	Italian Standard Business Document
FRGS1XML	Sovos XML format holding the mandatory PDF and XML components of a GS1 France standard business document
GRIDXML	Greek Invoice Document XML

Invoicing Party

An invoicing party is an entity registered in Sovos eArchive that sends or receives invoices but doesn't archive them using Sovos eArchive.

Invoices cannot be archived in Sovos eArchive on behalf of an Invoicing Party. However, an Invoicing Party can be registered as a User Organization for which invoices can be archived.

Post-audit Countries

Countries where the invoicing process doesn't require any sort of approval from a local tax authority, leaving the issuer responsible for compliance with the applicable law.

Signature and Audit Data

Sovos eArchive processes both signed and unsigned documents. To provide long-term validation of a signed document, three components are needed:

Document: The signed data. Example: the "raw" invoice data.
Signature: The electronic signature.
Audit data: Long term audit data.

These components can be bundled together or provided separately. Therefore, when storing a signed document, different parameter sets are needed, depending on the type of signature. To describe these two scenarios, Sovos uses the following terms:

Implicit: One component is given, the other is implied, i.e., 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, where all components are bundled together, and can be described as "document with implicit signature and audit data". All scenarios supported by Sovos eArchive are described in the subsections below.

Note:

Even if audit data is not included, the categorization below is still relevant because audit data can be added retroactively. This means that, for a format to be included in the "Implicit Signature and Audit Data" category, it must be possible to add audit data retroactively in the same container as the document and the signature.

Implicit Signature and Audit Data (Signature Type 1)

This is a scenario where the document, signature, and optional audit data are bundled into one chunk of data. A screenshot showing the audit data selected in the signed document interface.

A screenshot showing the audit data selected in the signed document interface.

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 2)

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. Examples of explicit signatures.

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 3)

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. Example of signature type 3

An example of a signature format where this structure may be used is the EDIFACT-based signature format. Note that "detached audit data" is called "detached evidence data" in some documents.

Note:

It's also possible to store unsigned documents. In those cases, only the Archiving.Documentformat information must be communicated in the SBDH and all the values as shown in the table above can be used.

Sovos TrustWeaver Compliance Map

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

User Organization

An organization registered within Sovos eArchive as a legal entity on whose behalf invoices can be archived using Sovos eArchive.