Skip to main content

​
Introduction

Electronic invoicing is mandatory for essentially every VAT-registered business in Italy. The Sistema di Interscambio (SDI) is the tax authority’s central hub: it validates every invoice and delivers it to the buyer. The legal invoice is the cleared FatturaPA XML file. Invopop converts your GOBL invoice into FatturaPA and transmits it over its own accredited SDICoop channel, registered with the tax authority in Invopop’s name. Nothing sits between your workspace and SDI. Companion guides: Status for what SDI reports back about an invoice, Receiving invoices, and Archiving.
The Italy app sends your invoices to the appropriate environment based on whether your current workspace is Sandbox or Live.

Have your agent issue an invoice through SDI in your sandbox.

Open in Cursor

​
Setup

All of the following steps must be carried out from the Invopop Console.
1

Connect the Italy app

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

Configure the sending workflow

This workflow numbers the invoice, seals the envelope, and submits it to SDI.

Italy send invoice workflow

Add to my workspace →
3

Configure the status workflow

This workflow runs on each notification SDI sends about an invoice you issued, and records it as a status entry. Select it in the Italy app’s configuration so incoming notifications run it automatically.

Italy import invoice status workflow

Add to my workspace →
Add whatever your integration needs after the import step — calling a webhook, notifying your systems, or moving the invoice itself.

​
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.

​
Identifying the customer

Italy has two fiscal identifiers — the partita IVA (VAT number) and the codice fiscale — and which one you put on the customer depends on who they are. Codes never carry a country prefix, because the country has its own field: write a partita IVA as 09876543217, not IT09876543217. A codice destinatario is 7 characters, and a codice fiscale is 16 for a person or 11 digits for a company. If you don’t have a code for a party, leave it out rather than inventing a placeholder. Here is each case as a customer party:
The tax_id carries the partita IVA, and the it-sdi-code inbox carries the codice destinatario SDI routes by. A customer who receives through certified email instead has an it-sdi-pec inbox holding the address. A customer who has both can carry both: the invoice routes by the codice destinatario, and the PEC is left out of the file.
The codice fiscale identifies them, as an identities entry keyed it-fiscal-code. They have no VAT number, so the tax_id holds only the country, and there’s no inbox. SDI doesn’t deliver to private individuals — it files the invoice in their personal area on the tax authority portal — so you must give the customer a copy yourself, normally as a PDF.
The country in tax_id is all SDI needs, alongside a VAT number for a business inside the EU. No inbox: SDI cannot deliver outside Italy, so the file always carries the cross-border recipient code XXXXXXX, and an inbox on the party is ignored.

​
How the send step works

The step generates the FatturaPA XML, submits it to SDI, and attaches the transmitted file to the invoice entry. It completes as soon as SDI accepts the file for processing — it does not wait for SDI to decide what happens next, so a verdict that takes days never holds your workflow open. The step returns:
  • OK when SDI accepted the file. The result carries SDI’s identifier for the submission (sdi_id), which every later notification about this invoice shares.
  • KO when the invoice couldn’t be converted or SDI refused the submission outright.
Acceptance is not delivery. An accepted file can still be rejected minutes later, and that arrives as a status.
Invoices addressed to a public administration (FPA12) need a qualified electronic signature. The send step signs them with Invopop’s qualified electronic seal, so the file attached to the entry is the signed .xml.p7m.

​
Simplified invoices

Italian law lets you issue a simplified invoice (fattura semplificata) for a sale of up to €400 including VAT, and for credit and debit notes whatever their amount. It asks less about your customer: their partita IVA or codice fiscale is enough. You can keep issuing ordinary invoices for these sales; the simplified one is an option. To issue one, add the simplified tag to your invoice:
The it-sdi-v1 addon then sets the format to FSM10 and the document type to TD07 (TD08 for a credit note, TD09 for a debit note), and the send step delivers a simplified FatturaPA file to SDI. The invoice still needs a customer, identified in one of two ways: GOBL requires a name for a customer with a partita IVA, but the simplified file carries a name only together with an address: without one, the name stays on your invoice and isn’t sent to SDI. A private individual needs neither. If you only have the partita IVA, put a placeholder such as the partita IVA itself in name: without an address the simplified file doesn’t include the name, so the placeholder stays on your invoice and isn’t sent to SDI. Don’t add an address in that case, or the placeholder would be sent as the customer’s name. The addon rejects a simplified invoice that the format or the law doesn’t allow, before it reaches SDI:
  • A total over €400 including VAT, converted to euros with the invoice’s exchange rate. The limit doesn’t apply to credit and debit notes, or to suppliers in the flat-rate regime (RF19) or the cross-border VAT franchise (RF20).
  • A customer that is a public administration.
  • Intra-EU supplies of goods (N3.2), services taxed on a business in another EU country (N2.1), reverse charge (N6) and VAT due in another EU country (N7).
  • A sale to a habitual exporter (N3.5) or a stamp duty exemption (NB1, NB2, NB3). Only the ordinary format carries the declaration of intent and these exemptions.
  • Withholding taxes, fund contributions, a rounding amount, and charges or discounts without VAT.
Payment terms, bank details, ordering references and notes are not part of the simplified format, so the file leaves them out. To correct a simplified invoice, issue a credit or debit note with the simplified tag. It must refer to the invoice it corrects, with that invoice’s code and issue date and the reason for the correction. If you create the note from the original with previous_id and correct, set reason in the correct object. The Simplified Invoice example below shows a complete document.

​
Invoice statuses

SDI’s verdict on an invoice arrives after the send step has finished, as a notification recorded against the invoice: delivered, rejected, undeliverable, or — for public administrations — accepted or refused by the buyer. Each notification and what it means for the invoice is covered in the Status guide.

​
Archiving (conservazione a norma)

Italian law requires issued electronic invoices to be preserved long-term through a certified process. Add the Archive document step after the send step to preserve each invoice as you issue it. See the Archiving guide for the full setup.

​
Testing in the sandbox

There is no public SDI test environment you can point a workflow at. In sandbox, the app plays SDI’s part itself: it accepts the file, then feeds the status notifications a real exchange would produce back through the same intake the live channel uses. Your workflow cannot tell the difference, and nothing leaves the platform.

​
Choosing the outcome

You choose which outcome to rehearse by setting a reserved codice destinatario on the customer. In GOBL that is an inbox with the key it-sdi-code:
The codes are sized to real FatturaPA recipient-code lengths, so they pass validation. Any code not in this list — including a real customer’s — resolves to a successful delivery.
The sandbox simulates SDI’s responses, not its validation. In practice this distinction rarely matters: the it-sdi-v1 addon validates invoices against the same rules SDI applies, so an invoice that builds cleanly should only rarely be rejected live — though edge cases can still slip through.

​
Receiving your own invoices

Send a sandbox invoice to a company you have registered for reception and the app also loops it back to you as an inbound delivery, running your import workflow exactly as a live delivery would. This is the only way to receive an invoice in sandbox, and a convenient way to exercise sending and receiving in a single run.

​
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.

​
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 →