Italy pioneered mandatory B2B e-invoicing in Europe. All domestic transactions must go through SDI (Sistema di Interscambio) in FatturaPA format — the invoice reaches your customer through Agenzia delle Entrate, or it does not reach them at all.
Through SdI, Italy's Sistema di Interscambio. You produce the invoice as FatturaPA XML, send it to SdI, and SdI validates the file, routes it to your customer by Codice Destinatario or PEC address, and returns a receipt to you. Nothing reaches the customer until SdI has passed it.
That last sentence is the whole difference between Italy and a country where invoices simply travel from seller to buyer. SdI is not a post box. It is a checkpoint operated by Agenzia delle Entrate, the Italian revenue agency, and it either accepts a document and passes it on or rejects it and delivers nothing. A finance system that treats an invoice as sent the moment the file leaves the building will be wrong in Italy about as often as it makes a typing mistake.
Italy asks several separate things, and they are routinely described as one. One is about the file, one is about the route it takes, one is about what kind of document it declares itself to be, and one is about what comes back afterwards. Each has its own way of going wrong, and the sections after this table take them one at a time.
| Requirement | What it covers | Since |
|---|---|---|
| FatturaPA XML | The invoice file itself — Italy's national XML format, not a PDF | B2G 2014; B2B and B2C 2019 |
| Clearance through SdI | Every domestic invoice passes through Agenzia delle Entrate's exchange system before it is delivered | B2G 2014; B2B and B2C 2019 |
| Codice Destinatario or PEC address | How SdI knows where to deliver the document | In force |
| A TD document type code | Which kind of document this is — invoice, credit note, self-invoice, reverse-charge integration | In force |
| Italian IVA rates and exemption codes | The tax lines SdI validates before it will deliver anything | In force |
| Small enterprises (forfettari) in scope | Who has to do all of the above — the exemption for the smallest businesses ended | 2024 |
SDI is Italy's centralized exchange system operated by Agenzia delle Entrate (Revenue Agency). All domestic invoices must pass through SDI for validation, routing, and delivery.
SDI validates format, tax codes, and business rules before delivery.
Routes to recipients via Codice Destinatario or PEC address.
Every invoice passes through Agenzia delle Entrate's own system before it reaches the customer.
Create FatturaPA XML
Submit to SDI
SDI Validates & Routes
Delivered to Recipient
SdI — Sistema di Interscambio, the Exchange System — is a government platform operated by Agenzia delle Entrate. Every domestic Italian invoice passes through it. SdI checks the file; if the checks pass it delivers the invoice to the customer, and if they fail it returns the document to you and the customer never sees it.
That arrangement has a name. In a clearance model the tax authority stands inside the exchange: the document reaches the buyer through the authority, and only after the authority has accepted it. In a post-audit model the invoice goes straight from seller to buyer and the authority reads the data later. Italy runs clearance. Portugal, for contrast, runs post-audit with a monthly reporting file. The distinction is not academic — it decides whether your finance system has to wait for an answer before it can consider an invoice issued. Our country-by-country view of e-invoicing sets the two models side by side across the markets we cover.
Three consequences follow, and they are the ones that catch out a team arriving from a post-audit country. First, "sent" and "delivered" are different states in Italy, and only SdI can move a document from one to the other. Second, an invoice can be stopped for reasons that have nothing to do with the commercial relationship — a malformed field, a tax code that does not validate, a document number already used. Third, the responses SdI returns are part of the record rather than noise to be discarded: they are how you can show what happened to a given document.
Peppol and SdI are also not the alternatives they are sometimes presented as. Peppol is a delivery network with its own addressing and its own document profiles, used across most of Europe. SdI is Italy's national clearance hub. GoRoute supports Italy's FatturaPA profile and connects to SdI, and is separately a Peppol Certified Access Point and SMP provider (POP000991) for the network side. If you are invoicing an Italian customer and a German one out of the same system, those are two destinations behind one API rather than two projects.
One thing this page does not claim: GoRoute holds no approval, accreditation or designation from any Italian authority, and nothing on this page should be read as one. What we do is produce the FatturaPA file, connect to SdI, and report back what SdI says. Where your own business needs a registration or an appointment in Italy, that is a question for Agenzia delle Entrate and for your Italian tax adviser.
Every document sent through SdI carries a TD code declaring what kind of document it is. TD01 is an ordinary invoice. TD04 is a credit note and TD05 a debit note. TD16 and TD17 are self-invoices. TD18 and TD19 are integration invoices used where the reverse charge applies.
The code is not a label added at the end. SdI validates the document against the rules for the type it declares, which means a document that is commercially a credit note but declares itself TD01 can fail on rules that appear, from the outside, to have nothing to do with credit notes. The commonest form of this in a migration is a system that emits everything as TD01 because that is what its export template was built to do, and which then produces a run of rejections nobody can explain from the error text alone.
Two of these codes describe documents a finance team may not have met outside Italy. A self-invoice is a document the buyer issues in its own name for a purchase, rather than the seller issuing it — TD16 and TD17 cover those cases. An integration invoice is the document that completes the record where the reverse charge applies, meaning the buyer rather than the seller accounts for the VAT; TD18 and TD19 cover those. Both are ordinary parts of Italian practice and both need the right code, not a close one.
The codes above are the ones this page states, and they are not the whole set. Agenzia delle Entrate publishes the full table of TD codes and the rules attached to each at fatturapa.gov.it, and that table — not a vendor page, this one included — is what an accounting system should be mapped against before go-live. Where the correct type for a particular document is genuinely ambiguous, it is a question for your Italian tax adviser rather than for an integration partner.
What GoRoute does with this is narrower than it sounds and more useful than it sounds: we take the invoice data your system already holds, produce the FatturaPA XML with the type and tax treatment you have mapped, and validate it before it goes anywhere. Catching a wrong code in validation costs a retry. Catching it in a Notifica di Scarto costs a place in the five-day queue described further down.
A Codice Destinatario is a seven-character alphanumeric code identifying the channel through which a recipient receives invoices. Companies register their code with SdI so that invoices reach them directly. Where a business has no registered code, a PEC address — posta elettronica certificata, Italy's certified email — can be used instead, and SdI delivers there.
This is the field that decides whether an invoice arrives, and it is the one piece of the Italian picture you cannot produce yourself. There is no rule that turns a company name, an address or a VAT number into a Codice Destinatario. It belongs to the customer. Practically, that makes it master data: something collected when the customer is onboarded, kept in the customer record beside the tax identifiers, and confirmed when it changes — because a customer that moves provider changes channel, and nothing about your system will notice.
The cheapest moment to get it is the conversation where payment terms are agreed. The most expensive is after the first invoice has failed, because by then somebody is chasing a code, a document and a deadline at the same time. This is worth saying plainly to whoever owns the customer master, since it is usually a sales or finance step rather than a technical one, and integration projects tend to assume it has already happened.
Alongside the routing information sit the tax identifiers, which SdI validates in their own right — invalid tax codes are one of the standard reasons a document comes back. So an Italian customer record carries two things many systems have room for and few populate: the identifiers that say who the customer is, and the Codice Destinatario or PEC address that says where their invoices go. Getting both right before the first send is most of what "being ready for Italy" means in practice.
GoRoute handles the routing side once the code is known: the recipient lookup, the FatturaPA fields that carry it, and delivery through SdI. What we cannot do is invent the code, which is why it appears in this section rather than in a feature list.
SdI returns a Notifica di Scarto — a rejection notice — carrying error codes that say why. The invoice is not delivered. You correct the document and resubmit within five days to avoid penalties. Common causes are invalid tax codes, format errors and duplicate invoice numbers.
Five days is the number to design around, and it is short enough that it has to be somebody's job rather than somebody's intention. The clock does not pause for a month-end close, a public holiday or the person who owns Italian invoicing being on leave. A rejection sitting unread in a shared mailbox for a week has already spent the window, and the invoice it refers to is still, as far as the customer is concerned, unsent.
It is worth being precise about what a rejection is not. A Notifica di Scarto is not a commercial dispute. The customer has not refused the invoice, queried the price or complained about the goods — the customer has not seen the document. That distinction matters when a rejection is being explained to a sales team, and it matters again when someone is deciding whether to chase the customer or fix the file. The answer is almost always fix the file.
Which is why status handling belongs in the design rather than in a feature bullet. Every document sent to SdI has a state, and the states that need a human are exactly the ones a system tends to swallow: rejected, and sent-but-not-yet-confirmed. GoRoute reports those states back through the API and through webhooks, so a rejection lands inside the system your team already watches rather than in a portal somebody has to remember to open. The point is not the notification. It is that nothing waits five days for a person who was never told.
The other half of the answer is not sending a broken document in the first place. Validation before submission catches format errors and tax-code problems while a retry is still cheap, which is the difference between an integration that produces occasional rejections and one that produces a backlog.
Most of what this page describes is a property of the Italian system rather than of the sender. Where an invoice goes through SdI it has to be FatturaPA XML, it has to carry a valid Codice Destinatario or PEC address, and it has to survive SdI's validation. None of that changes because your company is in Munich rather than Milan.
What this page will not tell you is whether the Italian mandate reaches your business at all. Whether a supplier established outside Italy must issue through SdI, and what changes if that supplier holds an Italian VAT registration or has a permanent establishment there, is a question about your own VAT position rather than about invoice formats. Agenzia delle Entrate sets it. Any vendor answering that from a web page — this one included — is guessing about facts it does not have, so it is worth getting the answer in writing before a project plan is built on it.
That uncertainty does not have to hold up the work, because four things are worth settling either way, and none of them needs a legal opinion first.
| What to settle | Why it comes first | Where the answer comes from |
|---|---|---|
| The customer's Codice Destinatario or PEC address | SdI needs it to deliver, and it cannot be derived from anything you already hold | The customer |
| The TD code for each kind of document you issue | SdI validates against the type the document declares | Agenzia delle Entrate's published table, confirmed with your tax adviser |
| Whether the Italian mandate applies to your business | Decides whether this is your obligation or a service you offer your customer | Agenzia delle Entrate, in writing |
| Where a Notifica di Scarto will land, and who reads it | The correction window is five days and does not wait for anybody | Your own process |
If Italy is one country in a wider European rollout rather than a one-off, the neighbouring systems are worth reading alongside it, because none of them works the way this one does. Germany and France each run their own model and their own calendar, and the global view puts them next to each other rather than in separate tabs.
On the delivery side the picture is simpler than the compliance one. The same invoice data can be turned into FatturaPA and cleared through SdI for an Italian customer, and sent as a Peppol document to a customer in a country on the Peppol network — from one integration, through one API. That is the case for treating Italy as a destination rather than a project.
GoRoute supports Italy's FatturaPA profile and connects to SdI for sending and receiving, on our own hosted infrastructure.
Automatic recipient lookup via Codice Destinatario or PEC routing.
Proper Italian VAT rates (4%, 5%, 10%, 22%) with exemption code handling.
Real-time notifications for acceptance, rejection, and delivery status.
Attach PDF courtesy copies and supporting documents to FatturaPA.
Get compliant with SDI and FatturaPA for all your Italian transactions.
FatturaPA is Italy's national XML invoice format. It is not a PDF and not a scan: it is a structured file that Italian systems read as data. Invoices in this format are processed through SDI, the exchange system operated by Agenzia delle Entrate, and it has been mandatory for B2G since 2014 and for B2B and B2C since 2019.
Yes, since January 2019, all B2B and B2C domestic transactions in Italy require e-invoices via SDI. This applies to all VAT-registered businesses including small enterprises (forfettari) since 2024.
Codice Destinatario is a 7-character alphanumeric code that identifies the recipient's e-invoicing channel. Companies register their code with SDI to receive invoices directly. Alternatively, PEC (certified email) can be used.
SDI supports various document types including invoices (TD01), credit notes (TD04), debit notes (TD05), self-invoices (TD16/TD17), and integration invoices for reverse charge (TD18/TD19).
SDI returns a "Notifica di Scarto" with error codes explaining the rejection. Common issues include invalid tax codes, format errors, or duplicate invoice numbers. You must correct and resubmit within 5 days to avoid penalties.
Where the invoice goes through SDI, it has to be FatturaPA XML carrying a valid Codice Destinatario or PEC address, and it has to pass SDI's validation — that is a property of the Italian system rather than of the sender. Whether the Italian mandate reaches a business established outside Italy is a question about that business's own VAT position, and it is one for Agenzia delle Entrate rather than for a vendor's website.
