Skip to main content
The SDI Italy app is being retired. New integrations should use the Italy app, which reaches SDI through Invopop’s own accredited channel. See the issuing invoices guide.

​
Introduction

Electronic invoicing is mandatory for all businesses in Italy. The Sistema di Interscambio (SDI) serves as the Italian government’s central hub for transmitting, validating, and delivering all electronic invoices throughout the country. The SDI system operates using a standardized XML format called FatturaPA, which ensures all invoices contain the required information and comply with the strict validation rules established by the Italian tax authority (Agenzia delle Entrate). To ensure proper routing of invoices to the correct recipient, the SDI system uses a unique identifier called a Recipient Code, which is assigned to each registered SDI provider. Invopop simplifies SDI integration by allowing you to work with GOBL format instead of XML, providing synchronous validation before submission, and offering a simple API integration with automatic handling of SDI notifications and status updates. For receiving invoices through SDI, see our companion guide: Italy - SDI: Receiving Invoices.

​
Setup

1

Connect the SDI Italy app

  1. Navigate to Configuration → Apps
  2. Locate SDI Italy in the app discovery list
  3. Tap Connect to activate
Connect SDI Italy app
The initial connection requires no configuration for sending invoices.
2

Configure sending workflow

SDI does not have a sandbox environment. When sandbox mode is selected, Invopop’s third-party submission service, A-Cube, simulates a response from SDI.

SDI send invoice workflow

Add to my workspace →

​
Sending invoices

Invopop uses the GOBL FatturaPA library to process conversions. When creating invoices for SDI, you need to:
  1. Set the regime field to IT in your GOBL invoice
  2. Add the it-sdi-v1 addon to enable Italian-specific validations and extensions
Detailed information about the SDI-specific extensions and validations can be found in: Example invoices are provided below, or you can use the GOBL Builder to create custom invoices.

​
How the Send step works

This step generates the FatturaPA XML and sends it to SDI through our integration partner. Upon successful completion, the XML file is attached to the invoice entry. The SDI service usually responds within seconds but may take up to 24 hours. While waiting, this step remains in a QUEUED state. When the Send step completes, it returns one of three results:
  • OK if successful
  • KO for unrecoverable errors
  • SKIP if the invoice was already sent

​
Archiving (conservazione a norma)

Italian law requires issued electronic invoices to be preserved long-term through a certified archiving process known as conservazione a norma. Keeping a copy of the XML on your own systems is not enough — preservation must follow the rules set by the Italian authorities, which Invopop handles through its integration partner A-Cube. Archiving is built into the standard Italy templates, so no extra setup is needed:
  • The party registration workflow includes a step that enables archiving for the supplier. It requires the party to have a valid Italian tax ID. Re-running it on an already-enabled supplier reports SKIP.
  • The send invoice workflow includes an archive step after the Send step. It preserves the exact FatturaPA file transmitted to SDI and attaches the preservation receipt to the invoice entry as archive-receipt.pdf and archive-receipt.xml, along with an indexed archive-uuid metadata field identifying the archived document.
  • The SDI import invoices workflow from the receiving guide includes the same archive step after the Import step, so the invoices you receive are preserved too, recorded as received.
Preservation is asynchronous: the archive step stays QUEUED until the receipt is ready, then completes with OK. The receipt normally arrives within minutes but can take hours; the step keeps checking, less often as time goes on, and gives up only after several hours. If the preservation service fails partway through, the step retries from where it stopped without uploading the document again. Re-running it on an already-archived invoice reports SKIP, with nothing fetched or attached again.

​
Example invoices

In this example, we’re issuing a standard B2B invoice from an Italian supplier to another Italian business customer.Notice:
  • both supplier and customer have their Partita IVA (VAT number) and Codice Fiscale properly specified,
  • the minimal version contains only essential fields; gobl build handles all calculations,
  • when running gobl build, the system automatically calculates totals, applies IVA rates, and normalizes the document according to SDI requirements,
  • the built version shows all calculated fields including tax breakdowns, line totals, payment terms, and final amounts,
  • the it-sdi-v1 addon validates the document structure for B2B transactions, and,
  • the invoice will be transmitted through the SDI system and delivered to the customer’s designated channel.
In this example, we’re issuing a B2G invoice from an Italian supplier to the Italian government.Notice:
  • both supplier and customer have their Partita IVA (VAT number) and Codice Fiscale properly specified,
  • the minimal version contains only essential fields; gobl build handles all calculations,
  • when running gobl build, the system automatically calculates totals, applies IVA rates, and normalizes the document according to SDI requirements,
  • the built version shows all calculated fields including tax breakdowns, line totals, payment terms, and final amounts,
  • the it-sdi-v1 addon validates the document structure for B2G transactions, and,
  • the invoice will be transmitted through the SDI system and delivered to the customer’s designated channel.
In this example, we’re issuing a simplified invoice for a €49.00 restaurant bill to a private customer identified only by their codice fiscale.Notice:
  • $tags includes simplified, so gobl build sets the format to FSM10 and the document type to TD07,
  • the customer has no name or address: an Italian tax_id without a code, plus their codice fiscale as an it-fiscal-code identity,
  • prices include VAT, and the total with VAT must stay within €400, which the it-sdi-v1 addon checks before the invoice is sent, and,
  • see Simplified invoices for what else the format allows.
This example matches the B2B invoice above but adds a €2.00 Marca da bollo (stamp duty) as a document-level charge.Flat-rate scheme (forfettario): taxpayers using the regime forfettario do not charge VAT on their invoices. When the document total goes above €77.47, they must account for imposta di bollo—typically by adding a €2.00 stamp duty line, as in this sample. (Thresholds and rules can change; confirm with your adviser or the Agenzia delle Entrate if in doubt.)Notice:
  • the charges array includes an entry with "key": "stamp-duty", amount "2.00", and reason Imposta di bollo,
  • the minimal version is otherwise the same as the B2B example; gobl build recalculates totals including the charge,
  • the built version shows totals.charge and a higher payable / total_with_tax than the plain B2B invoice,
  • the it-sdi-v1 addon continues to validate the document for SDI transmission.
In this example, we’re issuing a comprehensive B2B invoice with additional optional fields such as ordering information, payment details, and document references.Notice:
  • this invoice demonstrates advanced SDI features like CIG/CUP codes, payment methods, and bank details,
  • the minimal version includes ordering and payment details; gobl build calculates all totals,
  • when running gobl build, the system validates all additional fields according to SDI specifications and calculates totals,
  • the built version shows the complete document with all calculated fields, tax breakdowns, and properly formatted additional information,
  • additional fields like ordering, payment, and document references are important for public administration invoices (B2G), and,
  • the addon ensures all optional fields are properly validated and formatted for SDI transmission.
In this example, we’re issuing an invoice for goods or services that are exempt from VAT (IVA).Notice:
  • the line item includes a tax with "key": "exempt" indicating this is a VAT-exempt transaction,
  • the minimal version omits the exemption code extension (it-sdi-exempt), which will be automatically added during gobl build,
  • when running gobl build, the system calculates totals with zero VAT and validates the exemption structure,
  • the built version shows the complete document with the exemption code extension (e.g., "it-sdi-exempt": "N4") applied to the tax rate,
  • exemption codes must comply with SDI requirements—consult the complete list of exemption reasons in the GOBL documentation,
  • common exemption codes include N4 (exempt), N3.1 (exports), N3.2 (intra-community supplies), and N6.x (reverse charge scenarios), and,
  • the SDI validates that exempt invoices include proper exemption codes before transmission.
In this example, we’re issuing a credit note (nota di credito) to correct or refund a previously issued invoice.Notice:
  • the type field is set to credit-note to indicate this is a corrective document,
  • the preceding field references the original invoice being corrected,
  • the minimal version contains only essential correction details; gobl build calculates negative amounts,
  • when running gobl build, the system automatically calculates negative totals, IVA refunds, validates the credit note structure, and applies SDI rules,
  • the built version shows all calculated fields including negative amounts for the refund and proper tax adjustments,
  • credit notes must be properly linked to the original invoice and transmitted through SDI, and,
  • the SDI system validates the credit note format before accepting and forwarding it to the recipient.
In this example, a retail sale was first recorded with a Smart Receipt (documento commerciale) and the customer later asked for an invoice. The invoice is an ordinary SDI invoice that references the receipt issued for the same sale.Notice:
  • the line item carries an attributes entry with type N.DOC.COMM, the receipt’s AdE document number in text, its progressive number in amount, and the receipt date in date,
  • the it-sdi-v1 addon converts each item attribute into an AltriDatiGestionali block: type becomes TipoDato, text becomes RiferimentoTesto, amount becomes RiferimentoNumero, and date becomes RiferimentoData, which is the layout the AdE describes for invoices preceded by a receipt,
  • type is limited to 10 ASCII characters and text to 60 characters, and amount is rendered with at least two decimals, so 7816 arrives at SDI as 7816.00,
  • the receipt’s document number is the ade-ref stamp the Smart Receipts app adds to the receipt’s header after the AdE accepts it,
  • issue_date is the day of the sale, because FatturaPA’s Data comes from issue_date (op_date is not written to the XML), and without further tags gobl build sets the document type to TD01,
  • the Smart Receipt itself is not changed by this invoice, and your own VAT records must remove the invoiced amount from that day’s corrispettivi. See Invoice requested after a receipt for the full sequence.

​
Technical details

When the SDI step processes a document, it returns detailed status codes that provide information about the response from SDI:Some SDI notifications (File metadati - MT, Esito committente - EC, Scarto esito committente - SE) don’t directly change the code of the invoice.These codes map to different step results as follows:
  • OK Result: delivered, not-delivered, not-received, accepted-pa, deadline-terms
  • KO Result: rejected, rejected-pa, invoice-error
  • QUEUED Result: sent, delivered-pa
When a step returns QUEUED, the workflow will check again later for updates from SDI.

​
FAQ

Install the Italy app for structured invoicing through SDI, or the Smart Receipts app for B2C-only AdE CF receipts. Run invoices through a workflow with the Send invoice to SDI step — see the issuing guide.
Retail receipts (documento commerciale, commonly called scontrino) are not SDI invoices — they are reported to the tax authority as corrispettivi through a separate channel. Use the Smart Receipts Italy app for those, and see the Smart Receipts issuing guide.
See the Italy tax regime in GOBL for tax categories, codice fiscale rules, and SDI-specific extensions. The it-sdi-v1 addon documents required FatturaPA fields.
The Send invoice to SDI step completes as soon as SDI accepts the file — it doesn’t wait for SDI’s verdict. What takes time is SDI’s own processing: a rejection usually arrives within minutes, but delivery confirmations can take up to 5 days. Each verdict is recorded against the invoice as a status entry, so nothing is stuck while you wait. See the status guide for the full lifecycle.
SDI confirms delivery with an RC (ricevuta di consegna) notification, recorded on the invoice as a status entry with the GOBL status acknowledged. A rejection arrives as NS with status error. Every notification and what it means is covered in the status guide.
Set a reserved codice destinatario on the customer — for example SIMNS00 to simulate a rejection. The sandbox simulates SDI end to end and feeds back the notifications a real exchange would produce; any ordinary code resolves to a successful delivery. The full list of reserved codes is in the issuing guide.
Both Italian tax identifiers have their own place on a party. The partita IVA (VAT number) goes in tax_id, and the codice fiscale goes in identities under the key it-fiscal-code. A party may carry both.An Italian supplier always needs a partita IVA. An Italian customer needs at least one of the two — which one depends on who they are, covered in the issuing guide.Here’s an example showing both identifiers on a supplier:
Supplier with Partita IVA and Codice Fiscale
Send it through SDI as usual — an Italian supplier reports the invoice there whoever the customer is. SDI has no way to deliver outside Italy, though, so it won’t reach the customer that way: send them their copy yourself, normally as a PDF. It’s the same invoice travelling by two routes, and only the FatturaPA file is the legal one.
An Italian customer needs either a partita IVA or a codice fiscale. A customer outside Italy needs neither — their country is enough, so leave the code out rather than inventing a placeholder. See identifying the customer.
Add an item attribute to the invoice line with type N.DOC.COMM and the receipt’s identifier in text, its progressive number in amount and its date in date. The it-sdi-v1 addon writes each item attribute as an AltriDatiGestionali block (TipoDato, RiferimentoTesto, RiferimentoNumero, RiferimentoData). The type is limited to 10 ASCII characters. See the “Invoice after a documento commerciale” example in the issuing guide.
More available in our Italy FAQ section

Participate in our community

Ask and answer questions about invoicing in Italy →