Italy SdI eInvoicing: 6 Proven Rules Foreign Businesses Still Get Wrong | OasisPro

🇮🇹 OasisPro · Italy SdI eInvoicing · FatturaPA · Clearance Model

Italy has done this since 2019.
6 rules foreign businesses still get wrong.

 · 8 min read ·  6 Rules Clearance Model Live Since 2019

Italy SdI eInvoicing FatturaPA Sistema di Interscambio clearance model OasisPro

Italy SdI eInvoicing is the oldest mandatory B2B regime in Europe and the one every other country studied before building its own. Since January 2019, every VAT-registered business in Italy has issued invoices in FatturaPA XML format through the Sistema di Interscambio, with no turnover threshold and no meaningful exemptions. It works, it is mature, and it still catches out foreign businesses in the same six ways.

If you are preparing for France, Poland or the UK, Italy SdI eInvoicing is worth understanding regardless. It is the reference implementation of the clearance model.

Here is how it works and where the traps are.

In a clearance country, the tax authority is not auditing your invoices afterwards. It is standing in the middle of the transaction, and an invoice it rejects has not legally been issued at all.

This is the mental shift that catches businesses coming from exchange-model countries. In Belgium or the UK, your invoice travels from you to your customer and the tax authority is not in the path. In Italy, everything routes through SdI first. It validates, it accepts or rejects, and only then does the document reach your customer. Rejection is not a warning, it is a non-event.

FatturaPA XML SdI Clearance No Threshold Digital Signature Cross Border via SdI 10 Year Retention
2019
Year mandatory domestic B2B eInvoicing went live in Italy
0
Turnover threshold. Every VAT-registered business is in scope
12 days
Typical window for reporting cross-border transactions to SdI
10 yrs
Retention period for invoices under Italian rules
Comparison of the clearance model used by Italy and the exchange model used by Belgium and the UK Clearance against exchange, the two European models Where does the tax authority sit? Clearance: Italy, Poland Invoice routes through the taxplatform firstRejected invoice is not legallyissuedNational format, FatturaPA orFA(3)Authority sees every transaction Exchange: Belgium, UK Invoice travels supplier to buyerAuthority not in the transactionpathPeppol BIS aligned to EN 16931Reporting layer can be added later
France sits between the two, using accredited platforms with a central directory.

The 6 rules of Italy SdI eInvoicing foreign businesses get wrong

  • 1. Assuming a VAT registration puts you in scope. It generally does not. Entities registered for Italian VAT without a permanent establishment are outside the issuing obligation. Having an SRL, branch or subsidiary is what brings you in.
  • 2. Treating rejection as a formatting nuisance. An invoice SdI rejects has not been issued. It cannot be paid, it does not support a VAT deduction, and the clock on your payment terms has not started.
  • 3. Forgetting cross-border reporting. Esterometro is gone, replaced by SdI transmission using TD17, TD18 and TD19 document types, generally within twelve days. This is the obligation most often missed entirely.
  • 4. Overlooking the digital signature. Signature requirements apply in defined situations, particularly for public sector invoices, and an unsigned document where one is required will not clear.
  • 5. Underestimating identifier accuracy. The most common rejection is an invalid Partita IVA or Codice Fiscale on either party. Master data quality is a compliance control in Italy, not an internal preference.
  • 6. Assuming FatturaPA equals the European standard. It does not map natively to EN 16931. Businesses operating across Europe end up maintaining both, which is an architecture decision worth making deliberately.

The point most cross-border finance teams miss

Because FatturaPA is not natively EN 16931 compliant, a business trading in Italy and elsewhere in Europe needs its invoice data to serve two different specifications. Handling that inside your ERP means maintaining two output paths forever. Handling it in middleware means maintaining one dataset and letting the gateway produce whichever format each country requires.

What Italy SdI eInvoicing tells you about the rest of Europe

Italy SdI eInvoicing proved the clearance model works at national scale, which is why Poland and others followed it rather than the lighter exchange approach.

It also demonstrated the cost of a purely national format. Italy is now working toward convergence with the European standard, and businesses there face dual compliance in the meantime.

That is the lesson for anyone building eInvoicing capability today: design for the standard, not for one country's dialect.

The Italian Revenue Agency publishes the specifications at agenziaentrate.gov.it, and independent trackers follow the incremental technical updates.

Our Poland KSeF guide covers the other major clearance regime now live.

Design for EN 16931 and treat national formats as outputs. Build for FatturaPA alone and you will rebuild for everywhere else.

How Italy SdI eInvoicing works in practice, day to day

Italy SdI eInvoicing starts in your system, which produces a FatturaPA XML file and transmits it to SdI, either directly or through an accredited intermediary. Most businesses use an intermediary.

SdI validates against dozens of structural and format checks. Acceptance or rejection typically returns within seconds, and the response has to be captured and acted on automatically.

On acceptance, SdI delivers the invoice to the recipient using their destination code or certified email address. Your customer never receives a document you sent directly.

On rejection you correct and resubmit within the permitted window. Handling rejections manually is workable at low volume and untenable at scale.

Retention is a separate obligation. Italy SdI eInvoicing requires compliant electronic archiving for ten years, which is not the same thing as keeping a copy on a file server.

Preparing for Italy SdI eInvoicing alongside other mandates

The practical question for a business trading across Europe is where the format logic lives. Inside each ERP, or once in a middleware layer.

Putting it in the ERP means every country's rules, every version change and every validation quirk becomes a change request against your core system.

Putting it in middleware means the ERP publishes one clean dataset and the gateway handles Italy SdI eInvoicing, KSeF, Peppol and the rest as outputs.

That decision gets progressively more expensive to reverse, which is why it is worth making deliberately at the first mandate rather than the third.

🌐

One dataset, every national format.

The OasisPro EU eInvoicing Gateway takes invoice data once from any ERP and produces whatever each country requires: FatturaPA for Italy, FA(3) for Poland, Factur-X for France, Peppol BIS for Belgium and the UK. Clearance, exchange, and reporting models all handled through one connection.

See how the gateway works

Trading in Italy and elsewhere in Europe?

We will map your Italian obligations against your structure, check whether your entity is genuinely in scope, review your cross-border reporting position, and show you what running Italy alongside the rest of Europe looks like through a single integration.


How does Italy SdI eInvoicing work?

Italy operates a clearance model. Every invoice is issued in the FatturaPA XML format and transmitted to the Sistema di Interscambio, the platform run by the Agenzia delle Entrate. SdI validates the document against structural and format rules, then delivers it to the recipient, usually within seconds. An invoice rejected by SdI has not been legally issued.

Does Italy SdI eInvoicing apply to foreign businesses?

It depends on your structure. If you have an Italian entity such as an SRL, subsidiary or branch, you issue through SdI exactly as an Italian company does. Entities registered in Italy for VAT purposes only, without a permanent establishment, are not required to issue or receive through SdI, though in practice you still need a way to handle invoices your Italian suppliers send.

How are cross-border invoices reported in Italy?

The quarterly Esterometro report was replaced from July 2022 by transmission through SdI. Cross-border transactions are reported using specific document types, TD17 for services purchased abroad, TD18 for goods from the EU and TD19 for goods from outside it, generally within twelve days of issue or receipt.

What are the penalties for Italy SdI eInvoicing non-compliance?

Penalties can reach a significant percentage of the VAT involved, and there are separate per-invoice penalties for late cross-border reporting subject to a monthly cap. The more immediate consequence is operational: an invoice rejected by SdI has no legal validity, so it cannot be paid until it is corrected and resubmitted.

Italy SdI eInvoicing is mature, strict, and worth learning from

Seven years of operation have removed most of the ambiguity from Italy SdI eInvoicing. The rules are clear and the platform is fast.

What remains difficult is running Italy alongside six other countries with six other specifications, which is an architecture problem rather than a compliance one.

Solve it once, centrally, and each new mandate becomes a configuration exercise.

If you are entering the Italian market rather than already operating there, the sequence matters. Establish the entity structure first, because that determines whether Italy SdI eInvoicing applies to you at all.

Then appoint an intermediary, connect your ERP, and run test transmissions well before your first real invoice. SdI is unforgiving of surprises on day one.

Businesses that treat Italy as their first structured invoicing country usually find the second and third mandates far easier, because the discipline transfers.

One last practical point. Italy runs an automated assessment mechanism that validates every invoice against structural checks before delivery, so errors surface immediately rather than at audit.

That is genuinely helpful once your data is clean, and genuinely painful while it is not. Which is the whole argument for cleansing customer and supplier identifiers before you start rather than after.