Sovos.com
Contact SupportArchive documents
TrustWeaver stores and manages archived documents on behalf of invoicing parties, supporting long-term validation and compliance.
TrustWeaver Compliant Archiving is the TrustWeaver component responsible for storing, organizing, and preserving signed documents and their associated audit data. Anything stored in TrustWeaver Compliant Archiving is assigned a unique reference of 32 hexadecimal digits. This reference is unique within the entire archive and never changes.
A stored invoice is an invoice stored on behalf of a single user organization. An invoice stored on behalf of both the supplier and the buyer results in two stored invoices, one for each party. When storing an invoice, at least one of the invoicing parties must be a user organization.
Documents are organized in storage sections. You can only store an invoice in an enabled storage section. Attempting to store an invoice for a party whose section hasn't been enabled returns a SectionNotEnabled error.
For a description of storage sections and their states, see Manage storage sections.
You don't need to enable the counterparty section, even if it's referenced in metadata to support counterparty searches.
Signed document structure
TrustWeaver processes both signed and unsigned documents. You can sign and store unsigned documents and validate and store signed documents. To enable long-term validation of a signed document, you need three components:
- Document
-
The data that was signed. For example, the invoice data.
- Signature
-
The electronic signature.
- Audit data
-
Long-term audit data required for future signature validation.
These components can be bundled together or provided separately. TrustWeaver uses the following terms to describe component combinations:
- Implicit
-
Given one component, another is implied. They are bundled into one chunk of data.
- Explicit
-
The components must be provided explicitly, as two distinct chunks of data.
TrustWeaver supports three signature type structures:
- Implicit signature and audit data (Signature Type 1)
-
The document, signature, and optional audit data are all bundled in one block of data. Examples include implicit CAdES-A and enveloping or enveloped XAdES-A signatures.
- Explicit signature and audit data (Signature Type 2)
-
The document is provided in its original format. Signature and optional audit data are provided separately in a format that supports both. An examples is an explicit (detached) CAdES-A signature.
- Implicit signature and explicit audit data (Signature Type 3)
-
The signature is bundled with the document, but audit data is provided separately. This structure is typically used when the signature format doesn't support adding long-term audit data. An examples is an EDIFACT-based signature format.
Even if audit data is not included at storage time, it can be added retroactively. For a format to qualify as Signature Type 1, it must be possible to add audit data to the same container as the document and signature retroactively.
The signature type structure of a document determines which Document sub-elements (ImplicitSignatureInfo, ExplicitSignatureInfo, and ExplicitAuditDataInfo) are required when calling StoreInvoice. For the audit categories, long-term archiving requirements, and the Details parameter reference, see Long-term archiving and audit data.
Store an invoice through the API
Before storing an invoice, confirm the following:
-
The invoicing party (supplier or buyer) has been enabled for storage. Call EnableSection first if needed.
-
The storage section is not locked or closed.
-
If you specify a non-storing counterparty by name, that party must already be registered.
-
To confirm a trading partner's tax identifier before storing, see Validate a tax identifier through the API.
-
If your source document requires format conversion before signing, see Transform a document through the API.
The StoreInvoice operation stores an invoice on behalf of one or both invoicing parties. At least one party must have the StoreFor element set to true. The invoice includes the signed document, invoice metadata, and up to seven optional attached documents.
Example response:
<StoreInvoiceResponse xmlns="http://www.trustweaver.com/trustarchive/storage/v1">
<Result>
<SupplierReference>ABCD1234</SupplierReference>
<BuyerReference>ABCD1234</BuyerReference>
<DepositInfo>
<DocumentHash>
68e6...
</DocumentHash>
<DocumentHashAlgorithm>Sha256</DocumentHashAlgorithm>
<DocumentDate>2018-12-04T14:33:11</DocumentDate>
</DepositInfo>
<ExpirationDate>2025-11-29T00:00:00</ExpirationDate>
</Result>
</StoreInvoiceResponse>Store the SupplierReference and BuyerReference values returned in the response. You need these references to retrieve the invoice later.
Attach documents to an invoice
.
Each attachment is represented by an Attachment element inside the Attachments collection. Attachments are not sorted, so there's no guarantee that the order is preserved when storing or retrieving documents.
Attachment elements
| Element | Required | Type | Description |
|---|---|---|---|
| Filename | Yes | string (1-50 chars) | The filename shown when listing or downloading the document. |
| MimeType | Yes | string (max 250 chars) | The MIME type of the document (for example, text/xml or application/pdf). Must conform to RFC 2046. |
| Description | No | string (1-250 chars) | A description of the document. |
| Data | No | xs:base64Binary | The Base64-encoded document data. Required if DataReference is not present. |
| DataReference | No | string | Reserved for future use. Attempting to use this element results in a client fault. |
Data or DataReference must be present. Because DataReference isn't yet supported, Data is effectively required.
Attachment example
<Attachments>
<Attachment>
<Filename>Attachment.xml</Filename>
<MimeType>text/xml</MimeType>
<Description>Aattachment</Description>
<Data>ABCD1234</Data>
</Attachment>
</Attachments>CountryCode and filtering
The CountryCode parameter identifies the applicable law for each stored invoice and must be set to a country code supported by TrustWeaver.
The CountryCode parameter is set in the SupplierInfo or BuyerInfo element of the StoreInvoice request. It is required when StoreFor is set to true for that party. The value must be a valid ISO 3166-1 alpha-2 country code.
The CountryCode value should reflect the country of the applicable law for the invoice, which is not necessarily the physical location of the invoicing party. Set the supplier's country code in SupplierInfo.CountryCode and the buyer's country code in BuyerInfo.CountryCode.
Only ISO 3166-1 alpha-2 country codes corresponding to countries listed in the Compliance Map can be used in StoreInvoice requests. Contact Sovos Support to confirm the country codes enabled in your configuration.
Filtering country codes
Implement a filtering function so that only invoices with country codes TrustWeaver supports are submitted to the StoreInvoice operation. TrustWeaversupports the full country matrix, with the same country list for suppliers and buyers. Mexico is the exception, with different country-code lists for suppliers and buyers.
The filtering algorithm works as follows:
-
Identify the supplier's country code, for example, by parsing the first two characters of the supplier's VAT number.
-
Identify the buyer's country code, for example by parsing the first two characters of the buyer's VAT number).
-
Check whether the supplier's country code is in the set of Sovos-supported countries from the Compliance Map.
-
Check whether the buyer's country code is in the set of Sovos-supported countries from the Compliance Map.
-
If both checks pass, submit the StoreInvoice request with
SupplierInfo.CountryCodeandBuyerInfo.CountryCodeset to the identified codes.