Supported countries and formats | Product Documentation Documentation

Supported countries

Country support in TrustWeaver is defined by the Compliance Map, which documents the compliant processes and technical requirements for e-invoicing compliance and archiving for each supported country, organized by supplier and buyer functionality.

The Compliance Map is the authoritative source for country-specific information. Sovos maintains it on a continuous basis as regulations change, and it serves as the primary reference for country scope, document format requirements, and compliant process definitions. Contact Sovos Support for access to the Compliance Map and to confirm the countries active in your contract.

The Compliance Map is designed to serve as a structured information backbone for the hub's compliance documentation. Based on it, someone such as a tax auditor reviewing the hub's processes can check the requirements and compliant processes used for any given e-invoice at any time.

The Compliance Map also indicates when previous contact with local authorities, including obtaining pre-approval, is required or recommended before storing e-invoices in a given country. Review the Compliance Map before implementing support for a new country.

Note: The countries available to you depend on your specific contract. Contact Sovos Support to confirm which countries and compliance levels are active in your implementation, or to request coverage for a new country.

Compliance Map structure

The Compliance Map is organized by functionality, divided into supplier and buyer perspectives. Each perspective is further divided into two areas:

Supplier

Issuance: Covers the requirements and supported processes for issuing e-invoices on behalf of the supplier. This includes signing, clearance submission, and any country-specific steps required before the invoice is delivered to the buyer.
Storage: Covers the archiving obligations that apply to the supplier after issuance, including required document formats, retention periods, metadata requirements, and any automated preservation processes that runs on the supplier's behalf.

Buyer

Receipt: Covers the requirements that apply when the buyer receives an e-invoice, including signature validation obligations. In most post-audit countries, the buyer is implicitly required to validate the supplier's signature on receipt to be able to demonstrate the integrity and authenticity of the invoice throughout the storage period.
Storage: Covers the archiving obligations that apply to the buyer, which may differ from those of the supplier in the same country. Many countries require separate storage for supplier and buyer copies.

Not all levels apply to every country. Some countries require only signing and archiving, while others also require clearance. The Compliance Map defines the applicable levels for each country and the specific requirements within them.

Supported document formats

The following table lists all supported input document formats. Not all formats are compatible with all signature types. For valid pairings, see Document and signature format combinations.


Format	Description
Binary	No restrictions exist for this document type.
MIME	The document must be MIME-encoded by specifying at least `Content-Type` and `Content-Transfer-Encoding`, if applicable.
PDF	The document must be a valid PDF. When signing with S/MIME, the MIME representation is `Content-Type: application/pdf` and `Content-Transfer-Encoding: base64`.
XML	The document must be well-formed XML with the XML declaration omitted or set to version 1.0 and encoding UTF-8. Any other XML version or encoding is not supported and is considered a client error. When signing with S/MIME, the MIME representation is `Content-Type: text/xml; charset="utf-8"`.
cXML	The document must be well-formed XML with the XML declaration omitted or set to version 1.0 and encoding UTF-8. When used with an XML signature, you must canonicalize the document before sending it (C14N or C14N v1.1) and then the the signature element is automatically inserted as an enveloped signature. When signing with S/MIME, the MIME representation is `Content-Type: text/xml; charset="utf-8"`.
EANCOM	The document must be a well-formed EDIFACT message with no line breaks. The document must contain at least the mandatory UNB segment, with the optional UNA segment detected automatically. The EDIFACT document segment structure must match `UNA(O)+UNB(M)+UNH(M)+[Message]+UNT(M)+UNZ(M)`, where "O" is "optional" and M is "mandatory". The filter function specified in the USH segment determines which filter is applied in the entire message. It must be compatible with the character set specified in the UNB segment.
Facturae	The document must be well-formed XML with the XML declaration omitted or set to version 1.0 and encoding UTF-8. The document root must be in the Facturae namespace, starting with `http://www.facturae.es`.
FatturaPA	Document supporting B2B and B2G invoicing in Italy.
FatturaPA Relaxed (FATTURAPAR)	FatturaPA v1.2 document supporting B2B and B2C clearance invoicing in Italy. A relaxed version of the standard FatturaPA format, where TrustWeaver adds certain elements as intermediary service provider. See fatturapa.gov.it. Use FatturaPA Relaxed for B2B and B2G clearance flows. A valid FatturaPA Relaxed document must comply with the following constraints: Must not contain more than one `FatturaElettronicaBody` element. Must not contain the XMLDSIG `Signature` element. Must not contain the `FatturaElettronicaHeader/DatiTrasmissione/IdTrasmittente` element. Must not contain the `ProgressivoInvio` element. Must not contain the `FatturaElettronicaHeader/TerzoIntermediarioOSoggettoEmittente` element. The `FormatoTrasmissione` element must not be set to `FPA12`. B2G invoicing is not supported.
eSLOG	Document supporting the Slovenian eSLOG format.
Mexican CFDI XML invoice (MXCFDI)	CFDI version 4.0. Supports both issuance and CTC validation.
Brazilian (BRNFE) invoices and CT-e invoices	Only CTC validation is supported.
HashedDoc	The document must be well-formed XML and comply with the HashedDoc schema. Use this format when you need a detached PKCS7 signature and the document data should not be sent in the request, for example, due to size or non-disclosure requirements. The algorithm for calculating the digest is specified by its OID. When signing with S/MIME, the MIME representation is `Content-Type: text/xml; charset="utf-8"`.
Peruvian invoice (PEINV)	Only CTC validation is supported.
UBL invoice	UBL invoice document.
Indian Invoice Document JSON (INIDJSON)	Invoice documents used to issue Indian invoices.
INCDJSON	Indian Cancellation Document JSON
INEDJSON	Indian EWB (e-Waybill) Issuance Document JSON
INECDJSON	Indian EWB Cancellation Document JSON
JSON Web Token	JSON Web Signature (JWS), an IETF-proposed standard (RFC7515) for signing arbitrary JSON data.
KRREGNTSD	South Korean Invoice Document XML
Malaysian Invoice UBL (MYUBL)	Invoice documents used to issue Malaysian invoices, UBL 2.1 format.
Malaysian JSON Invoice (MYJSON)	Invoice documents used to issue Malaysian invoices using the UBL 2.1 JSON Alternative Representation Version 2.0.
Turkish UBL Invoice (UBLTR)	Turkish UBL invoice.
Turkish UBL Invoice for e-Arsiv (UBLTRA)	Turkish UBL invoice for e-Arsiv.
CII	UN/CEFACT Cross Industry Invoice (CII) format, version D16B.
PEPPOL BIS 3	PEPPOL BIS 3 format, UBL version 2.1.

Note: The document format also applies when submitting documents for archiving. Specify the format using the Archiving.DocumentFormat field in the SBDH. For archiving-specific format codes such as CLDTE, BRNFE, and MXCFDI, refer to Archive documents or contact the Sovos Support.

Supported signature formats

Standard signature formats

The following signature formats are available for general signing and validation operations:


Signature format	Description
IDEAL (EDIFACT)	An EDIFACT signature profile. Only a single signature is supported. The EDIFACT input document segment structure must match `UNA(O)+UNB(M)+UNH(M)+[Message]+UNT(M)+UNZ(M)`. The signed output matches `UNA(O)+UNB(M)+UNH(M)+SG1(M)+[Message]+SG54(M)+UNT(M)+UNZ(M)`. The signature algorithm is SHA1 with RSA . The signing certificate identification in the USC segment contains the certificate serial number, issuer DN, and subject DN. Supported filters are HEX, EDA, and EDC. All signatures produced by TrustWeaver-Signing can also be validated.
IDEAL2	Equivalent to IDEAL, configured to use the SHA256 signature hash algorithm.
GS1AT (EDIFACT)	An EDIFACT signature profile. Only a single signature is supported. The EDIFACT input document segment structure must match `UNA(O)+UNB(M)+UNH(M)+[Message]+UNT(M)+UNZ(M)`. The signed output matches `UNA(O)+UNB(M)+UNH(M)+SG1(M)+[Message]+SG54(M)+UNT(M)+UNZ(M)`. The signature algorithm is SHA1 with RSA. The signing certificate identification in the USC segment contains the certificate serial number and issuer DN. The filter function is BASE64. All signatures produced by TrustWeaver-Signing can also be validated.
GS1AT2	Equivalent to GS1AT, configured to use the SHA256 signature hash algorithm.
AECOC (EDIFACT)	An EDIFACT signature profile. Only a single signature is supported. The signature uses RSA with ISO/IEC 9796-2 scheme 2 and the SHA1 hash algorithm. The AECOC signature format requires EDC as the filter function. The certificate package is a certificates-only PKCS7 object. The sender and receiver GLN values are retrieved from the UNB segment (S002/0004 and S003/0010 respectively). All signatures produced by TrustWeaver-Signing can also be validated. Note: Because AECOC requires EDC as the filter function, the character set specified in the UNB segment must be compatible; use UNOC. AECOC is a Spanish standard and only works for signatures that fulfill the sufficient requirements in Spain.
AECOC2	Equivalent to AECOC, configured to use the SHA256 signature hash algorithm.
PKCS #7	Extended to the CAdES-EPES, CAdES-T, and CAdES-A profiles. Both encapsulated and detached signatures are supported. CAdES-EPES Has the type `SignedData`. The PKCS #7 container includes the complete certificate chain of the signing certificate and the signed attribute `SignaturePolicyIdentifier`. CAdES-T Includes all CAdES-EPES attributes, with the additional unsigned attribute `SignatureTimeStamp`. CAdES-A Includes all CAdES-T attributes, with the following additional unsigned attributes: `CompleteCertificateRefs`, `CompleteRevocationRefs`, `CertificateValues`, `RevocationValues`, `Archive-time-stamp`, and `ValidationPolicyIdentifier`. The `ValidationPolicyIdentifier` is a proprietary unsigned attribute containing a validation policy OID and qualifier URL. All signatures produced by TrustWeaver-Signing can also be validated.
S/MIME	When signing with S/MIME, all MIME headers not starting with "Content" are placed at the beginning of the resulting S/MIME. The remaining "Content" headers stay as part of the plain text. If no MIME header exists, `Content-Type text/plain; charset=us-ascii` is added and assumed. The S/MIME produced by sign is a detached S/MIME of type `multipart/signed` with protocol `application/pkcs7-signature`, encapsulating the PKCS #7 SignedData profiles. The `Mime-Version: 1.0` header is added to the resulting S/MIME. TrustWeaver-Signing doesn't canonicalize the input data before signing. All signatures produced by TrustWeaver-Signing can also be validated.
XML Signature	The XML signature produced can be XadES-BES, XadES-EPES, XadES-T, or XadES-A, and is either enveloped or enveloping. If XML is the input format, an enveloping signature is generated. If cXML is the input format, an enveloped signature is generated. Multiple signers are not supported for enveloping signatures. The canonicalization algorithm is inclusive C14n v1.0. All signatures produced by TrustWeaver can also be validated.
Enveloped XML Signature	The XML signature produced can be BASIC, XadES-BES, XadES-EPES, XadES-T, or XadES-A, and is always enveloped. All signatures include the KeyInfo element, regardless of job type. BASIC is pure XMLDSIG without XadES extensions. Multiple signers are not supported for signatures using the `EnvelopedSignatureTransform`, because any additional signature applied after the first will invalidate the previous ones. All signatures produced by TrustWeaver-Signing can also be validated.
PDF	Creates non-visible signatures of type `ADBE.PKCS7.DETACHED`. The following PDF signature types can be constructed: CadES-EPES Consistent with PKCS7 combined with job type CADESEPES. CadES-T Consistent with PKCS7. CadES-A Consistent with PKCS7 combined with job type CADESA. Not supported by the PDF standard in the sense that a compliant PDF viewer can't display the archive contents. PadES-BES Consistent with a CAdES-T signature, but without a signature policy. PadES-EPES Consistent with a CAdES-T signature, including a signature policy. PadES-LTV Stores the archive content (certificates, CRLs, and OCSP responses) outside the PKCS7, in the PDF itself, as recognizable PDF objects. Enables a compliant PDF viewer to display the archive contents. Mandates an additional PDF document timestamp encompassing the signature and archive content. All signatures of type `ADBE.PKCS7.DETACHED` and `ADBE.PKCS7.SHA1` can be validated.
Facturae	Based on FACTURAE. An enveloped signature using the enveloped signature transform. Multiple signers are not supported. Includes a XadES signature policy identifier and a XadES `SignerRole` with `ClaimedRole`: third party, and a XadES `SigningTime` as signed attributes. Note: The following values apply to the XAdES signed attributes added by TrustWeaver to Facturae signatures: Signature policy identifier `http://www.facturae.es/politica_de_firma_formato_facturae/politica_de_firma_formato_facturae_v3_1.pdf` Description `facturae31` Hash `Ohixl6upD6av8N7pEvDABhEL6hM=` ClaimedRole `third party`
FatturaPA	Signed document supporting B2G invoicing in Italy. Important: This signature format is deprecated. Use document format XML combined with signature format XML Signature instead.
eSLOG	Signed document supporting the Slovenian eSLOG signature format. The XML signature is enveloped. All signatures produced by TrustWeaver-Signing can also be validated.
UBL signature	Enveloped XML signature conforming to the UBL Digital Signature Profiles 1.0 specification.
MYUBL	Malaysian signature format.
MYJSON	Malaysian signature format.
CII	UN/CEFACT Cross Industry Invoice (CII) format, version D16B.
BIS3	PEPPOL BIS 3 format, UBL version 2.1.

Note:

For XML-based signature formats (XML Signature, Enveloped XML Signature), all insignificant white space is removed when processing XML by default. To preserve white space for specific elements, set the xml:space attribute to preserve on those elements.

Cleared invoice signature formats

Cleared invoice signature formats require you to send the invoice to a government body of the country of issuance, which approves (clears) the invoice as part of the signature process.


Signature format	Description
Mexican CFDI XML Signature	Proprietary format, not based on XMLDSIG. No applicable signature audit category. Supports the full list of complementos.
Brazilian NF-e signatures	Only validation is supported.
Turkish UBL Signature	An enveloped XML signature (UBL-TR) based on XMLDSIG.
Peruvian e-invoice Signature	An enveloped XML signature (UBL) based on XMLDSIG.
Peruvian credit note Signature	An enveloped XML signature (UBL) based on XMLDSIG.
Peruvian debit note Signature	An enveloped XML signature (UBL) based on XMLDSIG.
FatturaPA clearance signature	An enveloped XML signature based on XMLDSIG and XAdES-BES, supporting clearance invoicing in Italy.
INJWS	Indian JSON Web Signature (JWT-based).

Document and signature format combinations

The document format determines what can be signed, and the signature format specifies the type of signature to apply or validate. The table lists valid combinations only. Combinations not listed are not supported.


Document format	Applicable signature formats
Binary	PKCS #7
MIME	PKCS #7, S/MIME
PDF	PKCS #7, S/MIME, PDF
XML	PKCS #7, S/MIME, XML Signature, Enveloped XML Signature
cXML	PKCS #7, S/MIME, XML Signature
EANCOM	EDIFACT signature profiles (IDEAL, IDEAL2, GS1AT, GS1AT2, AECOC, AECOC2)
Facturae	Note: The following values apply to the XAdES signed attributes added by TrustWeaver to Facturae signatures: Signature policy identifier `http://www.facturae.es/politica_de_firma_formato_facturae/politica_de_firma_formato_facturae_v3_1.pdf` Description `facturae31` Hash `Ohixl6upD6av8N7pEvDABhEL6hM=` ClaimedRole `third party`
FatturaPA	FatturaPA
eSLOG	eSLOG
Mexican CFD XML Invoice (MXCFDI)	Mexican CFD XML Signature
Turkish UBL Invoice (UBLTR)	Turkish UBL Signature
Turkish UBL Invoice for e-Arsiv (UBLTRA)	Turkish UBL Signature
HashedDoc	Detached PKCS #7
FatturaPA Relaxed (FATTURAPAR)	FatturaPA clearance signature
UBL invoice	UBL signature
Indian Invoice Document JSON (INIDJSON)	Indian JSON Web Signature
JSON Web Token	JSON Web Signature
Malaysian UBL Invoice (MYUBL)	Malaysian UBL signature
Malaysian JSON Invoice (MYJSON)	Malaysian JSON Web Signature
French Invoice CII	CII
French Invoice Peppol Bis3	BIS3