About TrustWeaver

TrustWeaver is the Sovos solution for e-invoicing compliance and archiving, with a focus on post-audit models.

TrustWeaver provides signing, validation, and archiving services for e-invoices and other fiscal documents. It supports both clearance and post-audit e-invoicing models and covers more than 60 countries. It is a trusted service in Europe for document signature validation.

You can integrate your existing systems with TrustWeaver through the TrustWeaver API, a SOAP-based web services interface. After integration, you can send, transform, sign, validate, and archive your documents. Through TrustWeaver, you can also access TaxID checks.

You can use TrustWeaver as a standalone solution or alongside Compliance Network, a Sovos solution that handles e-invoicing clearance and transmission. See TrustWeaver and Compliance Network for details on how the two products relate.

Products and services

TrustWeaver provides the following services that can be purchased as standalone services or combined to cover more complex scenarios:

Document signing

Apply legally valid electronic signatures to invoices and other fiscal documents before submission to trading partners or tax authorities. TrustWeaver supports multiple signature formats including XAdES, PAdES, CAdES, EDIFACT, and country-specific formats.

Tax authority clearance

Submit documents to tax authorities for real-time or near real-time approval in countries that require clearance before an invoice is legally valid. TrustWeaver manages the submission, response handling, and status tracking for each clearance country in scope.

Clearance is a sub-process of the Corroborate operation. For details, see Clearance e-invoicing and Corroborate a document through the API.

Compliant archiving

Store signed, validated, or cleared documents, as well as attachments and metadata, in Sovos archive for the retention periods required by local law. TrustWeaver supports retrieval and updating of archived documents through the Storage Service.

Document transformation

Convert XML documents from one format to another before signing or storing, or after reception, using the Transform operation. This allows documents to be mapped to the required format for a specific country or trading partner before processing.

Tax identifier validation

Verify that a tax identifier belongs to a valid registered legal entity using the TaxIdCheck operation. TrustWeaver supports Polish TaxId checks, EU VAT validation through VIES, and Indian GSTIN checks. Tax identifier validation is contracted separately as an add-on to TrustWeaver.

Compliance Map

The Compliance Map centralizes control over localized compliance requirements. It holds structured information about the compliant processes and technical requirements for e-invoicing in each supported country. Sovos maintains the Compliance Map as regulations change. For access details, contact Sovos support.

Service and operation summary


Step	Service and operation	Purpose
1	Signing Service (`Sign`)	Apply a digital signature to the document.
2	Storage Service (`StoreInvoice`)	Archive the signed document and receive its reference.
3 (optional)	Signing Service (`ValidateArchive`)	Confirm the signature remains valid.
Alternative to steps 1-2	Storage Service (`Corroborate`)	Sign, clear (if required), and produce audit data in a single call. Followed by `StoreInvoice`.

How TrustWeaver works

When you submit a document to TrustWeaver:

Your system sends the document to TrustWeaver compliant e-invoicing through the API.
TrustWeaver applies the electronic signature in the format specified in the request, according to the country and document type requirements.
1. For clearance countries, TrustWeaver submits the document to the relevant tax authority and waits for approval. The document is not legally valid until the tax authority confirms it.
2. For post-audit countries, TrustWeaver signs the document and returns it.
You can store the document in Sovos archive for the legally required retention period, defined by local VAT and accounting laws. Requirements and archiving periods vary by country and depend on who issued the invoice and how.
TrustWeaver returns a response according to the process and its status.

The TrustWeaver Compliance Map governs which signing format, clearance process, and archiving and compliance requirements apply for each country and document type. Sovos maintains the Compliance Map as local regulations change. For access details, contact Sovos support.

E-invoicing compliance models

Two primary e-invoicing compliance models determine what TrustWeaver does with a document:

Post-audit e-invoicing: The issuer is responsible for compliance with the local law.
Clearance e-invoicing: The tax authority must approve the invoice before it is legally valid.

The TrustWeaver Compliance Map specifies which model applies for each country and document type in your agreement. If you don't know which model applies to a specific country in your implementation, contact Sovos support

Post-audit e-invoicing

Post-audit is an e-invoicing compliance model in which the issuer must ensure that invoices are compliant with local law from the time of issuance, and tax authorities may audit records after the fact.

Issuer responsibility and electronic signatures

In post-audit countries, the issuer bears responsibility for guaranteeing that the recipient or buyer receives a signed and valid document, and for guaranteeing the authenticity and integrity of each invoice throughout the entire storage period. Electronic signatures and seals are the primary technical means accepted globally to meet this requirement. For European Qualified signatures, when an invoice is signed using a legally recognized electronic signature, the burden of proof regarding authenticity and integrity is reversed: Any party challenging the invoice must demonstrate that the requirements were not met.

TrustWeaver signs the document and returns it to your system without a clearance step.

How TrustWeaver handles post-audit documents

For documents in post-audit countries, TrustWeaver applies the correct electronic signature based on the country and document type specified in the Compliance Map, then returns the signed document to your system.

You can perform post-audit signing and validation through the Signing Service or directly through the Corroborate operation on the Storage Service. The Sign and Validate operations map internally to Corroborate calls. Then, you can distribute the signed documents or store them in the Sovos archive for the legally required retention period.

For the detailed signing workflow, see Sign documents.

Clearance e-invoicing

Clearance is an e-invoicing compliance model in which a government authority must approve an invoice before it can be used. The invoice remains pending until the tax authority responds. In TrustWeaver, clearance is a subprocess of corroboration and is triggered when a clearance-specific signature format is used.

How clearance works in TrustWeaver

Clearance is defined as the process of registering and receiving authorization for an electronic invoice or related document, such as an invoice cancellation request, from a government authority or an authority that a government approved for this purpose.

When you submit a document in a clearance country, TrustWeaver usually signs the document and submits it to the relevant tax authority. The document status changes to pending until the tax authority responds. After approval, the document is legally valid and TrustWeaver returns it to your system along with the clearance information. If the tax authority rejects the document, your system must resolve the rejection and resubmit.

This process typically results in clearance information being added to the invoice data. The form of the tax authority response varies by country. In some countries, clearance information is embedded in the returned document. In others, the tax authority returns a separate signed response or generates artifacts such as a reference number or QR code that are distinct from the original document.

Clearance as part of corroboration

In TrustWeaver, the Corroborate operation handles clearance flows. In this model, an electronic invoice is cleared with the relevant authority on behalf of the supplier. It can also be used for the buyer to check that the supplier clearance information are validated according to the country-specific compliance requirements.

For details on the Corroborate operation and its parameters, see Corroborate a document through the API.

Branch registration for clearance

Clearance operations require at minimum a registered and enabled storage section for the invoicing party. Branch registration is additionally required for countries where TrustWeaver must hold signing keys or access credentials on behalf of the party. Requirements can vary by country. For configuration details, see how to Clear documents and Manage branches.

Main use cases

For background on compliance models, see Post-audit e-invoicing and Clearance e-invoicing.

Send documents

Use these workflows when your organization is the document issuer:

Sign documents, post-audit: Apply when sending documents in post-audit countries. See Sign documents.
Tip:
Besides the document signing service, you may want to do: Pre-processing (TaxID checks and Mapping) and Post-processing (Validate on behalf of your buyer and Archive).
Clear invoices: Apply when sending documents in clearance countries. TrustWeaver usually signs the document and submits it to the relevant tax authority on your behalf. The document is not legal until the tax authority authorizes it. See Clear invoices.

Note:
Besides document clearance and validation, you may want to do: Pre-processing (TaxID checks and Mapping) and Post-processing (archive).

Archive and track documents

Archive documents

Store documents in Sovos compliant archive for the retention period required by local VAT and accounting laws. See Archive documents.

Track document status

Query the status of a document at any point in its lifecycle. See Track document status.

Run a TaxID check

Validate a tax identifier before or during document processing. See TaxID checks.

TaxID checks can be performed when:

You are about to sign or clear an invoice to a buyer.
You have received an invoice to validate and want to check the supplier.
You have to do VAT reporting and need sanity checks on the tax IDs in the report.

Italy-specific workflows

The following workflows apply only to Italy.

Receive documents, clearance: In Italy, cleared inbound invoices arrive through the Sistema di Interscambio (SDI). TrustWeaver makes the invoice available to the customer through query events or push notifications. See Clear invoices for the full clearance flow andRetrieve documents.
Get notifications and events: The Notification Service lets you query and retrieve asynchronous SDI events such as delivery receipts, rejection notices, and outcome notices that occur during document processing. You can also retrieve them using the corroborate operation.

Note:
In addition to these services, you may want to use TaxID checks, Mapping, and Archive documents for Italy workflows.

Key concepts

Audit data

Long-term validation data associated with a signed document. Audit data can be bundled with the document and signature (implicit) or provided separately (explicit).

Branch

A subdivision of a storage section that represents a single tax entity in a specified country. A branch is identified by a country code and a tax identifier, such as a VAT number. Branches are not storage containers. Invoices and cryptographic keys are stored in sections, not in branches. Instead, a branch carries configuration that affects storage and corroboration on a per-tax-entity basis: For example, a branch can be associated with a specific cryptographic key stored in its parent section, allowing TrustWeaver to select the correct key during signing. For some countries, when corroboration includes clearance, the relevant branch must be registered in advance using the RegisterBranch operation. See About branches and Manage branches.

Clearance

Clearance is a sub-process of corroboration in which an electronic invoice is submitted to and authorized by a government authority or a government-approved body. The form of the tax authority response varies by country.

Clearance applies only to clearance countries and can only be performed using country-specific signature formats. In some countries, the clearance response also includes a government-issued signature or identifier that is added to the invoice.

Compliant e-Invoicing

TrustWeaver Compliant e-Invoicing Services. The collective name for the set of web services that make up the TrustWeaver API, including the Signing Service, Storage Service, Admin Service, and Notification Service.

Compliance Map

A matrix that centralizes information over localized compliance requirements. The Compliance Map holds structured information about the compliant processes and technical requirements for e-invoicing in each supported country. Sovos maintains it as regulations change. Contact Sovos support for details on how to access the Compliance Map.

Corroboration

The process of applying and validating a digital signature and creating audit data. The process is governed by a corroboration specification that determines which operations are performed and on behalf of which party. When clearance is involved, the corroboration process communicates with a government authority on behalf of the transacting parties.

Some Corroborate operations may be processed asynchronously, particularly when clearance requires an external authority round-trip.

Corroboration party

For post-audit flows. A role label applied to a transacting party when that party is referenced in a corroboration operation (signing or validation). Like invoicing party, this is a contextual label, not a separate entity type. In Corroborate operation calls, the corroboration party is identified by the SigningFor or ValidatingFor parameters, which specify whether the operation is performed on behalf of the sender or receiver.

Custom Compliance Configuration

Optional configuration that extends TrustWeaver standard compliance models and features. A Custom Compliance Configuration (CCC) is implemented on request and may include, for example: Adding signing or archiving for unsupported countries, using specific certificates, changing storage periods, and adding specific validation certificates for Swiss Edifact or validation in non-EU countries. Contact Sovos support to discuss available options and implications before requesting a CCC.

Document format

The format of the document submitted for signing or archiving. TrustWeaver supports formats including XML, PDF, UBL, FatturaPA, CFDI, Brazilian NF-e, and various EDIFACT formats. The document format determines which signature formats are valid for that document. For the complete list, see Supported document formats.

Hub

The party that calls TrustWeaver operations on behalf of one or both parties in an underlying sales transaction. The hub is identified by the X.509 client certificate used to secure the communications channel. A hub processes data such as archiving invoices, signing documents, and validating signatures on behalf of its transacting parties (supplier or buyer). The hub may be distinct from the transacting parties whose documents it handles.

Invoicing party

A role label applied to a transacting party when that party is associated with a stored invoice, either as the party for whom the invoice was stored (principal party) or as the counterparty. The term doesn't refer to a separate entity type, it is a contextual label used throughout operation descriptions to clarify which transacting party is being referenced in a storage operation.

Reference

A unique identifier assigned to every item stored in TrustWeaver, including invoices and cryptographic keys. A reference consists of 32 hexadecimal digits and is unique across the entire archive. The GetInvoice, ListInvoiceReferences, and ListExpiringInvoiceReferences operations use references to identify and retrieve stored items.

Signature type

How the document, signature, and audit data are defined when a signed document is stored. TrustWeaver supports three signature type structures:

Signature type 1: Implicit signature and audit data: The document, signature, and optional audit data are bundled in one block of data. Used with ImplicitSignatureInfo and ImplicitSignatureSpec elements. Examples: CAdES-A, XAdES-A, PAdES_LTV, and Evidence signatures.
Signature type 2: Explicit signature and audit data: The document is in its original format and the signature and optional audit data are provided separately. Used with ExplicitSignatureInfo and ExplicitSignatureSpec elements. Example: detached signatures.
Signature type 3: Implicit signature and explicit audit data: The signature is bundled with the document, but audit data is provided separately. Used with ExplicitAuditDataInfo and ExplicitAuditDataSignatureSpec elements. Examples: EDIFACT-based signature formats (IDEAL, AECOC, or GS1AT where Evidence was used).

Storage area

The top-level logical storage partition in TrustWeaver assigned to a hub. Every hub has exactly one storage area. A storage area is divided into storage sections, so you can have, for example, one per transacting party or any subdivision you need. The storage area is always implied when the hub authenticates. Developers don't interact with storage areas directly, they interact with the storage sections within them.

Storage section

The unit of storage that represents a single transacting party within a hub's storage area. Every transacting party maps to exactly one storage section. Enabling a storage section is what turns the associated transacting party into a user organization. Sections pass through the following states: Registered and Enabled. The offboarding process also includes Locked and Closed. You must register and enable a storage section before archiving invoices in it.

Stored cryptographic key

Used for clearance flow. A cryptographic key and certificate belonging to a corroboration party, stored in that party's storage section in advance of corroboration operations that require it. Keys are referenced by a key reference (a 32-digit hexadecimal identifier) or by the section name. Store the key when the signing process must use a key that belongs to one of the transacting parties rather than a Sovos-managed key.

Stored invoice

An invoice stored in TrustWeaver on behalf of a single user organization. When you store an invoice for both the supplier and the buyer, TrustWeaver creates two separate stored invoice records. One record is stored in the supplier's storage section and one in the buyer's section, each assigned its own unique reference. Each invoice record is stored with the legally required metadata about both the principal party and the counterparty. You can also stored additional custom metadata and up to eight attachments per invoice.

A stored invoice can only be created in an enabled storage section. The counterparty section doesn't need to be enabled.

Transacting party

The supplier or buyer in an underlying business transaction on whose behalf the hub processes documents. Each transacting party is an independent entity: The hub can process data only for the supplier, only for the buyer, or for both parties. Transacting parties don't invoke TrustWeaver operations directly and don't authenticate directly. The hub performs all operations acting on their behalf. Each transacting party is represented by exactly one storage section within the hub's storage area.

User organization

A transacting party for which the hub has enabled a storage section. At that point, a transacting party and a user organization are the same entity viewed from different perspectives. When a hub calls StoreInvoice, at least one of the invoicing parties must already be a user organization. Attempting to store an invoice for a party whose section is not enabled returns a SectionNotEnabled error.