E-invoicing in e-commerce

Since 1 January 2019 an Italian shop does not issue paper invoices: it sends an XML file to the Sistema di Interscambio, and a one-line invoice weighs 2,444 bytes. Building the file is not the hard part. The hard part is what happens when the customer asks for an invoice, asks later, and needs it corrected.

Who must invoice, and when

The duty comes from Article 1, paragraphs 909-928, of Law 205 of 27 December 2017 (the 2018 budget law) and has applied since 1 January 2019 to transactions between VAT-registered parties resident in Italy; towards private customers the invoice is electronic when the customer asks for it. Article 21 of Presidential Decree 633/72 sets the deadline: twelve days from the transaction, or by the 15th of the following month when the invoice is deferred and backed by a transport document. A shop that misses the deadline has a tax problem, not just a bookkeeping one.

The private customer: recipient code and tax code

A private customer has no recipient code: you use 0000000 in the CodiceDestinatario field, or a PEC address when the customer has one. The private customer's tax code is not mandatory when they do not supply it: the invoice stays valid for VAT purposes and is issued to the final consumer. It must be collected when the customer explicitly asks, because it is needed for deduction in specific cases and for the pre-filled tax return. In the checkout that means an optional field, not a required one that pushes people out of the cart.

The document types a shop actually uses

Generating the file is the easy part

The format is XML, with the FPR12 schema for private customers and FPA12 for public bodies. An invoicing library writes the file in a few lines; the real work is the data the file demands: VAT rate per line, the nature of the transaction when VAT does not apply, payment method, the seller's tax regime. If the catalogue sells books at 4% VAT, food at 4% and 10% and clothing at 22%, the rate rule belongs in the catalogue, not in the invoice code, otherwise the first new product breaks the calculation.

xmllint --noout fattura.xml && gzip -9 -c fattura.xml | wc -c

The command checks that the file is well-formed XML and measures it compressed: it is the first test before sending to the SdI, and it does not replace validation against the schema, which needs the XSD file for the version in use. A well-formed file outside the schema is rejected with an error code, and the rejection does not pause the tax deadlines.

Retention: ten years, not until the next backup

Article 39 of Presidential Decree 633/72 requires invoices to be kept for ten years; for electronic invoices, compliant retention needs a service that keeps the original file, the delivery receipt and the timestamp. At 2.44 MB per 1,000 invoices, weight is not the issue: 100,000 invoices a year is 244 MB of XML, less than a video. The issue is retrievability: the invoice must be found by number, by customer and by period, and that is a database design requirement, not a storage provider one.

Personal data and the GDPR

An invoice carries name, address and tax code, so processing rests on a legal obligation (Article 6(1)(c) of Regulation (EU) 2016/679), not on consent. The practical consequence: you cannot delete an invoice at a customer's request before the ten years are up, and you must say so in the notice. You can stop asking for data you do not need: the tax code is optional, and a phone number has nothing to do with invoicing.

The limitation

The measurement covers a sample file produced by a script, not a sample of real invoices: a cart with ten lines, discounts and foreign addresses produces bigger files, and files with attachments can exceed sending limits. The text also skips the special cases (split payment, reverse charge, San Marino transactions) that depend on your tax regime and need checking with your accountant. No article replaces that check.

Where to start