Skip to main content

Issue invoices

Issuing guide ›

Invoice status

Lifecycle guide ›

Receive invoices

Receiving guide ›

Archive invoices

Archiving guide ›
The Sistema di Interscambio (SDI) is Italy’s central e-invoicing hub, run by the tax authority (Agenzia delle Entrate). Electronic invoicing is mandatory for essentially every VAT-registered business in Italy: SDI validates each invoice and delivers it to the buyer. The legal invoice is the cleared FatturaPA XML file.Documents travel as FatturaPA XML. This app owns both directions of that exchange over Invopop’s own accredited SDICoop channel: Invopop is registered with the tax authority as a transmission and reception channel in its own right, so invoices go straight to SDI with no intermediary in between, and SDI delivers inbound invoices straight back.Sending is non-blocking. The send step finishes as soon as SDI accepts the file; SDI’s verdict — delivered, rejected, undeliverable — arrives minutes or days later and is recorded against the invoice as a separate status entry, so a slow response from SDI never holds a workflow open.

Key features

  • Direct accredited channel: Invopop transmits and receives under its own SDI accreditation. No third-party gateway sits between you and the tax authority.
  • FatturaPA both ways: GOBL → FatturaPA for issuing, FatturaPA → GOBL for received invoices, with the original XML kept attached exactly as it was exchanged.
  • Statuses as documents: Every SDI notification becomes a status entry on the invoice, carrying the original Italian code and a plain-language description.
  • Certified archiving: Issued and received invoices are preserved under conservazione a norma through our preservation partner A-Cube, with the receipt attached to the entry.
  • Full sandbox lifecycle: The sandbox simulates SDI end to end — including rejections and non-delivery — so you can exercise every outcome before going live.
Check out the guides below to get started:

FAQ

Invoicing questions
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.
Registering supplier questions
Provide the supplier’s Partita IVA and Codice Fiscale (where different) in their party configuration. No certificate upload is needed — Invopop transmits to SDI over its own accredited channel.
No supplier certificates are required. Invopop exchanges documents with SDI over its own accredited channel; only the Partita IVA and routing metadata are stored.
You don’t need to. SDI has no supplier registration for sending: set the supplier’s Partita IVA on the party and send. Registration is only needed for receiving — see the receiving invoices guide.
None — Invopop exchanges documents with SDI over its own accredited channel, so suppliers don’t manage any certificates. Invoices to public administrations (FPA12) also need a qualified electronic signature, which Invopop applies with its own seal when it sends them.
Receiving questions
Register Invopop’s recipient code (BDCS3JD) with the tax authority and run the registration workflow on the company’s party entry. Invopop automatically receives matching invoices and routes them through the configured import workflow. See the receiving invoices guide.
Inbound FatturaPA XMLs are parsed via gobl.fatturapa. The original signed XML is preserved as a silo entry attachment alongside the GOBL representation.
Register the company for reception in your sandbox workspace, then send a sandbox invoice addressed to it — the app loops it back to you as an inbound delivery and runs your import workflow, exactly as a real delivery would. This is the only way to receive an invoice in sandbox: there is no tax authority to register with, and no real supplier can reach it. See receiving your own invoices.
The import step attempts to convert the FatturaPA document into GOBL. If conversion fails, the step returns KO, but the original file stays stored — the invoice can be re-processed later without SDI needing to redeliver it.If the invoice has significant structural issues that prevent conversion, you may need to contact the sender to request a corrected invoice.
Invoices are typically received within minutes after being sent by suppliers through SDI. The automatic import process in Invopop processes them as soon as they are received by our system.
Yes, multiple companies can be registered to receive invoices through a single Invopop workspace. For each company, you must:
  1. Register the recipient code BDCS3JD with the Italian tax authority for that specific company
  2. Have its tax ID registered by running the registration workflow on the company’s party entry
  3. Use the same import workflow configured in the app settings
This two-step registration process (with the tax authority and with Invopop) must be completed for each company you want to register. This is particularly useful for white-labeling scenarios where a user manages multiple entities.
Yes, but only one party at a time can hold a given tax ID. Run the unregister workflow on the party that currently holds it, then register the new one.Registering a tax ID that another party already holds fails with a clear error.Sandbox and live are counted separately, so the same tax ID can be registered in both at the same time.
The two-step registration process serves different purposes:
  1. Registering with the Italian tax authority - Tells SDI to route invoices addressed to your company to Invopop’s channel using the Codice Destinatario BDCS3JD.
  2. Registering with Invopop (the registration workflow) - Tells Invopop which invoices to accept and process for your workspace.
Both steps are necessary: the first routes the invoices to Invopop, and the second ensures Invopop knows which workspace should receive those invoices.
Signed FatturaPA XML (versions 1.2.x), conforming to the Agenzia delle Entrate schema. The original file is kept attached to the entry exactly as SDI delivered it, alongside SDI’s delivery metadata.
Archiving questions
Add the Archive document step to your workflows, after the step that exchanges the document with SDI. It uploads the exact FatturaPA file, waits for the preservation service to confirm the document is preserved, and attaches the signed receipt to the entry. See the archiving guide for the full setup.
Yes. Italian preservation rules cover both the invoices you issue and the ones you receive, and both are preserved the same way — add the Archive document step after the import step in your receiving workflow.
Nothing — unregistering only stops receiving. Invoices already preserved under conservazione a norma stay preserved, as the law requires.
More answers in our Italy FAQ section

Participate in our community

Ask and answer questions about the Italy app →