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.

Setup

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

Connect the Italy app

  1. Navigate to ConfigurationApps
  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.

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) are not yet supported: they require a qualified electronic signature. Sending one raises a clear error rather than being rejected by SDI later.

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

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.
Invopop handles both Italian tax identification numbers in the supplier and customer sections of invoices:
  • Partita IVA (VAT number): Automatically extracted from the tax_id/code field.
  • Codice Fiscale (fiscal code): Must be specified as an identity with the key it-fiscal-code.
Here’s an example showing both identifiers in a supplier object:
Supplier with Partita IVA and Codice Fiscale
More available in our Italy FAQ section

Participate in our community

Ask and answer questions about invoicing in Italy →