In short
- A national XML schema, older than the European standard, built for a clearance platform.
- Rich in document type codes that carry treatment meaning and do not fail validation when wrong.
- A mapping target, not a data model to build your systems around.
- A useful case study in what a country pays for a format of its own.
Italy's national format is often described as an obstacle. That is unfair. It was built before the European semantic model existed, it has carried an enormous volume of documents reliably for years, and replacing it would be a project of national scale for a benefit that accrues mostly to foreigners.
It is nonetheless a second target, and second targets have a cost that is easy to underestimate because it is not a licence fee.
What is distinctive about it
It was designed around a platform. The document carries the addressing the clearance system needs, and the way it is structured reflects the system's processing rather than a general model of what an invoice means. Compare with EN 16931, which was designed to be format-independent and platform-independent by construction.
It carries transmission data in the document. Sender identification, transmission format and the recipient's code sit inside the file. On a network model those things belong to the envelope, not to the invoice. Neither approach is wrong; they are different separations of concern, and code that assumes one will get the other wrong.
Its document type set is rich. Beyond an ordinary invoice and a credit note there are codes for self-billing, for reverse charge situations, for documents raised to account for tax on transactions where the counterparty is not the one issuing. Each carries treatment consequences.
The document type problem
This is the part worth studying even if you never send an Italian invoice.
A wrong document type code does not fail validation. The schema is satisfied, the platform accepts, the document is delivered. The error is invisible until somebody reconciles a VAT position or an auditor asks why a particular transaction was treated the way it was.
That is the general shape of the most expensive errors in structured invoicing: the ones that pass validation. A missing mandatory field is caught in seconds by a machine. A valid value that is the wrong valid value is caught, if at all, by a person, months later.
Reconcile document type codes against the transaction types your ledger recorded, as a periodic control rather than as a one-off test. It catches a class of error that no validator will ever report.
The same reasoning applies to exemption and reverse charge reason codes, which have exactly this property in every jurisdiction.
The multinational architecture question
If you operate in Italy and elsewhere, you have two targets: a European profile for the countries that adopted one, and this schema.
The right architecture is the one described throughout this site — one internal representation of an invoice, from which each target is derived. Two rules make the difference between that working and not.
The internal representation must be the superset. It has to carry every business term any target needs, including national elements that exist nowhere else. A model built on a European profile cannot carry an Italian document type code, and retrofitting one means touching everything downstream.
Every dropped field must be a decision. When mapping loses something because the target has no home for it, that has to be recorded, reviewed and defensible. Silent loss is how an archived document ends up disagreeing with the ledger, and it is the failure mode described in assuring integrity.
| Cost | One-off or ongoing | Usually underestimated because |
|---|---|---|
| Building the mapping | One-off | It looks like a table and behaves like software |
| Testing each document shape | One-off per shape | Nobody counts their document shapes before starting |
| Following schema versions | Ongoing | Two targets means two release cycles to track |
| Reconciling national codes | Ongoing | It is a business control, not a technical one |
Where information is lost, in each direction
Mapping between a national schema and a European core invoice is usually described as a conversion, which understates it. A conversion implies equivalence. What actually happens is that each target holds concepts the other does not, and every element with no counterpart has to go somewhere or be dropped.
Going from the national document to the European model, the losses are typically national specifics: document type distinctions the European set does not draw, addressing elements meaningful only to the national platform, and administrative references that exist because the platform requires them. None of that is needed by a European receiver, so dropping it is usually right — provided somebody decided to.
Going the other way is more dangerous, because the European model is the richer one in the areas commercial businesses care about. Structures the national schema handles differently, or handles less granularly, get flattened. Line-level detail can be aggregated. Allowance and charge structures may not survive with their reasons attached.
The rule that prevents this becoming a defect is simple to state and rarely followed: every dropped element is a documented decision, not an omission. A mapping specification that lists what is deliberately not carried, with the reason, can be reviewed. A mapping that silently discards produces an archived document which does not say what the ledger says, and the discrepancy surfaces during an audit, years later, when nobody remembers the mapping was written.
What Italy teaches about format choices
For a country: adopting the European model is cheaper for your businesses' foreign counterparties and roughly neutral for your own. Having your own schema is cheaper for you and imposes a cost on everyone who trades with you. Neither is unreasonable, and the calculation changes with how much cross-border trade your economy does.
For a business: never let a national schema become your data model. It is narrower than the European standard, specific to one jurisdiction, and versioned by an authority you cannot influence. Map to it. Do not become it.
For a project plan: budget the second target as its own workstream. The first structured invoice format a company implements takes months. The second one takes less time and more attention, because the interesting work moves from "how do we produce XML" to "what does this field mean here", and the second question is the one that goes wrong quietly. The wider point about profiles narrowing a common model is in CIUS and extensions.
