Skip to main content
Sending an invoice to SDI happens in two phases. First, SDI answers the submission itself: it either takes charge of the file or refuses it outright. Everything after that is asynchronous — SDI works through validation and delivery on its own schedule and reports each outcome by posting a notification back. Those notifications are what tell you whether the invoice actually reached the buyer, and for public administrations, whether the buyer accepted it. Each one becomes a bill/status entry attached to the invoice.

​
The lifecycle

​
Submission

The send step reports SDI’s immediate answer. When SDI takes charge of the file it returns an identifier for the submission, and every later notification about that invoice refers to it. When SDI refuses the file outright it returns an error code instead, and the step fails with KO. Being taken in charge is not the same as being accepted. Validation comes next, and an invoice can still be rejected minutes later.

​
Business invoices

For invoices to businesses and consumers, the lifecycle is short: SDI validates, then either delivers or parks the invoice. A rejected invoice has no legal existence. Correct it and send a fresh one — this is not a case for a credit note. MC is not a failure. The invoice is filed and the recipient can collect it from their cassetto fiscale, which is why it counts as acknowledged rather than an error.

​
Public administration invoices

Invoices to public administrations are not yet supported for sending. This section describes the lifecycle they follow, and applies once they are.
Invoices to a public body carry a second act: after delivery, the buyer has 15 days to accept or reject.
SDI gave up delivering to the public body, and issues an attestation: legal proof that you transmitted the invoice and that the failure is not yours.This is not a fix-and-resubmit like NS. The invoice stands, but it is now on you to send both the invoice and the attestation to the public body directly, outside SDI. That direct delivery is required for the invoice to be payable — the attestation is what authorises the public body to process an invoice that did not reach it through SDI.It reports as an error because it needs you to act, not because anything is wrong with the invoice.
The public body had 15 days to accept or reject and did neither, so SDI closes the process. From then on it discards any further communication about that invoice, which means the public body can no longer reject it.SDI does not call this an acceptance. In practice the invoice proceeds as one: rejection is off the table, and it appears as accepted in the PCC (Piattaforma dei Crediti Commerciali), which tracks what public administrations owe. Any remaining dispute is settled between you and the buyer, outside SDI.

​
Receiving the notifications

Each notification runs the status workflow configured on the Italy app, which records it against the invoice it belongs to.
Recording the status is where the app’s job ends. What follows — updating the invoice, alerting someone, telling your own systems — is yours to build as steps after the import. The step reports the status it recorded as its result code, so your workflow can treat acknowledged differently from rejected.

​
What a status entry holds

Every entry carries the SDI series and the SDI message identifier as its code, with the submission identifier in its metadata so it can be traced back to the invoice. The status line records the outcome as one of GOBL’s own keys — acknowledged, accepted, rejected, error or processing — with the exact Italian notification code preserved alongside it in the it-sdi-notification extension, and a plain-language description of what happened. Entries are typed by who is speaking. Notifications from SDI are an update, since the platform is reporting; a NE is a response, because there the buyer is answering.

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