India

India has mandated e-invoicing for certain taxpayers. The archiving requirements differ depending on whether the taxpayer is subject to the clearance e-invoicing regime or not.

If an Indian taxpayer stores e-invoices for multiple companies or tax registrations, you must create each Goods and Services Tax Identification Number (GSTIN) as a separate storage section, so that the invoices are stored in a separate archive.

For taxpayers subject to the Continuous Transaction Controls (CTC) clearance regime, the primary document to store is the signed JSON that the Invoice Registration Portal (IRP) returns, as it proves successful clearance. You must store the following:

• The signed JSON as the main document. Set DocumentFormat to INIDJSON, Archiving.SignatureType to Audit, and Archiving.SignatureFormat to INJWS.

• The PDF as a human-readable copy, strongly recommended for audit purposes.

• The IRP portal responses as required metadata. You must store the QR code data, AckNo, and AckDt.

• The RegistrationOutcome from the clearance process, which includes the signed QR code and additional metadata, as an attachment to the stored invoice.

Populate InvoiceInfo.InvoiceNo with the invoice number as specified in the DocDtls.No parameter within the JSON. Set the Invoice Reference Number (IRN) as a CustomProperty. Set AckNo and AckDt as additional CustomProperty entries.

If a signed JSON is converted to PDF and exchanged with the buyer, store the PDF either as the main document with the signed JSON as an attachment, or the signed JSON as the main document with the PDF as an attachment.

For taxable persons not subject to the CTC clearance regime, GST invoices must be issued in three copies:

• ORIGINAL FOR BUYER

• DUPLICATE FOR TRANSPORTER

• TRIPLICATE FOR ASSESSEE (supplier)

At least the first copy for the buyer and the third copy retained by the supplier must be digitally signed. The second copy is typically presented in paper form during transportation and it can also be signed electronically. To archive a transport invoice, store it as an attachment to the respective party's e-invoice, either in the initial StoreInvoice call or added later with UpdateInvoice. Cancelled invoices must not be deleted from the archive. They must be retained along with the cancellation response.

Several sectors, including financial services, are required by Indian law to store invoices on Indian soil. TrustWeaver offers the option to store invoices in Indian data centers. This is a custom configuration that Sovos must set up and is subject to separate terms.

To request Indian data localization for your configuration, contact Sovos Support.

Italy

Italian law requires that all issued invoices undergo a preservation process on a regular basis. In Italy, preservation means that invoices must be hashed, grouped together in an archiving package, signed with a Qualified Digital Signature, and time-stamped by an accredited third-party Time-Stamping Authority. TrustWeaver runs this preservation process automatically for all invoices stored under the IT country code.

Italian law requires the creation and maintenace of a VAT register for all issued and received e-invoices, and that a VAT protocol number be assigned to each Italian e-invoice in the VAT register. To propagate VAT protocol numbers to TrustWeaver, set a CustomProperty with a label of VatProtocolNo and a value equal to the VAT protocol number in the StoreInvoice request.

Italian law requires that you produce a deposit report (Rapporto di Versamento) whenever you archive an invoice or collection of invoices, known as a deposit package (Pacchetti di Versamento). The deposit report contains the date and time the package was deposited into the archive, a hash of the package at the moment it was archived, and the hash algorithm used.

To generate a deposit report for an invoice, invoke StoreInvoice with DepositInfo populated within the AdditionalOutputs element. TrustWeaver generates all mandated information about the invoice and returns it in the StoreInvoice response. You can then use the response as the deposit report. This process must be understood by the Responsabile della Conservazione (RDC), the Electronic Preservation Manager. See Store an invoice through the API for details on the AdditionalOutputs element.

By default, TrustWeaver creates a metadata report as required by the Italian legislation. The metadata report is a set of structured required metadata in XML format that must be stored alongside the invoice. The metadata report differs for outbound and inbound transactions, so ensure correct usage of the StoreFor parameters in the StoreInvoice call.

If you don't want TrustWeaver to generate the default metadata report, include the CreateMetadataFile element in the StoreInvoice call and set it to false. You can then attach a custom metadata report to the invoice using the Attachments element.

Mexico

Mexican law requires that both the supplier and the buyer archive Comprobante Fiscal Digital por Internet (CFDI) invoices. TrustWeaver supports storage of Mexican CFDI invoices.

To store a CFDI, set DocumentFormat to MXCFDI in the StoreInvoice request. Populate InvoiceInfo.InvoiceNo with the UUID as specified in the CFDI. Optionally, set the Serie and Folio values from the CFDI as CustomProperty entries.

Both the supplier and the buyer must store their copy of the CFDI. Additionally, Mexico uses different country-code lists for both roles, supplier and buyer. See CountryCode and filtering.

For cancellation responses (Acuses), there is no explicit legal requirement to archive them. However, it is strongly recommended to archive them as attachments to the previously stored CFDI as evidence for potential legal disputes. For waybills (Carta Porte), Sovos recommends that the buyer archive them as attachments to the corresponding CFDI. Both cancellation responses and waybills can be stored as attachments, either in the initial StoreInvoice call or added later with UpdateInvoice.

For the clearance flow for Mexican CFDI invoices, see Mexico clearance requirements.