ERP and accounting software for Italy — SdI clearance, FatturaPA XML and OIC accounts

Italy is mature, so the question is a different one

On most of the market pages on this site, the question is whether a business will be ready in time. In Italy that question was settled years ago. Mandatory business-to-business e-invoicing began on 1 January 2019, the first such regime in the European Union, and it has been ordinary practice for long enough that nobody is surprised by it.

The honest Italian question is therefore not whether you will comply but whether your system does this properly, and there is a real difference. A great many Italian businesses comply through a combination of software, an intermediary and a person who knows which files to move where. That works, and it also means the process depends on that person and breaks quietly when they are away.

The symptoms of a system that complies without doing it properly are recognisable. Invoice status lives somewhere other than the invoice. Rejections are discovered when a customer chases payment. The XML is produced by a separate tool from the ledger entry, so the two can disagree. Corrections are handled by convention rather than by the system.

None of that is a compliance failure on its own. It is operational debt, and in a mature regime operational debt is the thing worth fixing, because the deadline that would otherwise force the issue has long passed.

• Invoice status held somewhere other than the invoice record
• Rejections discovered when the customer chases payment
• XML produced by a different tool from the one that posts the ledger
• Corrections handled by convention rather than by the system
• One person who knows which file goes where

How clearance actually changes the shape of invoicing

In most countries an invoice is a document you send to your customer. In Italy it is a document you submit, which is then validated and delivered on your behalf. The Sistema di Interscambio sits in the middle, and until it has done its work the invoice has not arrived anywhere.

That single structural fact has consequences throughout the process. Issuing is not complete when the document is generated. Receiving is not a matter of watching an inbox. Credit notes and corrections have to travel the same route as the originals. And the question your accounts receivable team most often needs answered, whether the customer has the invoice, is now a question about a system state rather than about an email.

It follows that status has to be first-class information in your finance system rather than something looked up in a portal. Each invoice should carry what happened to it, when, and if it failed, why. A collections conversation that begins with uncertainty about whether the invoice was ever delivered is a conversation that should not have been necessary.

The same applies to the receiving side. Invoices arrive through the same channel, and they should arrive into your purchase ledger as data, matched against the order and the goods receipt, rather than being downloaded and retyped by somebody who has become expert at doing so.

• Submission, validation and delivery treated as distinct states
• Status and failure reason held against the invoice itself
• Credit notes and corrections routed like the originals
• Incoming invoices posted from data, not from a downloaded file
• Collections able to see delivery status without leaving the system

FatturaPA is validated, which raises the cost of untidy data

FatturaPA XML is a structured format with defined fields and rules about what those fields may contain. A document that does not satisfy them is not accepted, and the practical consequence is that data problems which would have been invisible on a printed invoice become a delivery failure.

That is genuinely useful discipline, and it is also the reason data quality work never really ends here. Customer identifiers, addresses as structured fields, tax detail that reconciles to the document total, and references where they are expected all have to be right at the moment of issue rather than corrected afterwards.

The design point that matters is single-sourcing. The XML, the human-readable copy and the ledger entry should all be produced from the same invoice record. Where they are produced separately, they can drift, and reconciling a ledger against a set of transmitted files is a task nobody should be doing monthly.

Retention follows from the same principle. The transmitted file is the record of what was actually sent, and it belongs with the transaction rather than in a folder organised by date. When a question is asked years later, the answer should be one click from the entry.

• FatturaPA XML, validated on the way through rather than read on arrival
• Data problems become delivery failures, not untidy invoices
• Identifiers, structured addresses and reconciling tax detail required
• XML, readable copy and ledger entry produced from one record
• The transmitted file retained with the transaction, not in a date folder

Rejections, corrections and the numbering problem

In a clearance regime, an invoice that fails validation has not been issued. It has to be corrected and resubmitted, and how your system handles that determines whether the process is routine or a source of quiet inconsistency between what your ledger says and what your customer has.

The place this goes wrong most often is numbering. If a failed submission has already consumed an invoice number in your ledger, and the resubmission takes a new one, the sequence now contains a document that exists in your books and nowhere else. Handled the other way, with the number reused, the sequence is intact but two different documents have shared a number over the course of a day.

There is no clever software trick that removes this; there is only handling it deliberately and consistently, recording what happened, and being able to explain it. What a system owes you is that the choice is made once and applied by the system, rather than made differently by whoever is at the desk.

Corrections after successful delivery are a different matter again, and they follow the ordinary rule for a posted document: it is not edited or deleted, it is corrected by a further document that travels the same route, with both retained. How a specific correction should be treated for tax purposes is a question for your commercialista or Agenzia delle Entrate.

• A failed invoice has not been issued, only attempted
• Decide once how numbering behaves on a failure, and apply it always
• Keep the failure reason and link the replacement to the attempt
• Corrections after delivery travel the same route as the original
• Both the original and the correction retained, neither overwritten

A migration into a live regime needs more care than a greenfield one

Changing finance systems in Italy is not like changing them in a market with no mandate. You are moving between two systems while a clearance channel is live in both, and the transition has to leave a coherent record on both sides of the cutover.

Numbering continuity is the first thing to settle. The new system has to continue the sequence rather than starting again, and the point at which responsibility passes has to be a moment rather than a period, or you will have a day on which both systems believed they were issuing.

Then there is the history. Invoices issued from the old system, and the files transmitted for them, remain your records, and they need to be available for the retention period that applies. Migrating balances without migrating or reliably archiving the documents behind them produces a set of numbers you cannot substantiate.

And there are the documents in flight: invoices submitted but not yet resolved at the moment of cutover. Decide in advance which system finishes them, write it down, and do not leave it to be discovered on the day.

• Invoice numbering continued, not restarted
• A single moment of cutover, not an overlapping period
• Historical invoices and transmitted files retained and reachable
• Documents in flight assigned to one system in advance
• Opening balances reconciled to the old trial balance before go-live
• Receiving tested before issuing is switched over

VAT at 22%, and what a system owes you

The Italian standard rate is 22%. Reduced rates and exemptions apply to particular goods and services, and cross-border supplies inside and outside the European Union follow their own rules. Those are questions of tax law, and the answer comes from Agenzia delle Entrate guidance or from your commercialista, not from a software vendor.

What a system owes you is that the treatment you have been advised to apply is held at line level with the transaction, that the line detail reconciles to the document total, and that rate changes are dated so historical documents keep showing what was actually charged.

Under clearance this is not a presentational nicety. Tax detail that does not reconcile is a reason for a document to be rejected, which means a data problem in your item master becomes a delivery failure in front of a customer rather than a tidy-up task for the accountant.

Domestic, intra-EU and third-country transactions should also be separately identifiable in the ledger rather than merged into a single total, because the reporting you have to produce distinguishes between them even when your management accounts do not.

• A standard rate of 22%, with reduced rates on particular supplies
• Tax held at line level and reconciling to the document total
• Rate changes dated, so old documents keep the rate they carried
• Domestic, intra-EU and third-country supplies separately identifiable
• Treatment questions taken to your commercialista, not to a vendor

OIC, IFRS and the Italian chart of accounts

Italian individual entities generally prepare their accounts under the national standards issued by the Organismo Italiano di Contabilità, while listed groups in the European Union report under IFRS as adopted by the EU. A group with an Italian operating entity and a listed parent will need both views from the same underlying transactions.

As with the other European markets, the differences begin at the transaction rather than at consolidation, because the frameworks disagree about when revenue arises and how certain assets and provisions are measured. A ledger that stores only a net effect cannot produce the second view without reconstruction.

The workable answer is a chart of accounts and posting dimensions detailed enough to support both, with framework differences recorded as adjustments that can be listed and explained. Your commercialista will have views on the account structure, and the system should accommodate them rather than imposing a scheme of its own.

Which framework applies to which entity, and how a particular transaction should be treated under it, is a question for your auditor. A system holds the detail that lets the answer be applied consistently; it does not supply the answer.

• Individual entities generally under OIC national standards
• Listed EU groups under IFRS as adopted by the European Union
• Differences that begin at the transaction, not at consolidation
• Framework adjustments listed and explained, not hidden in a journal
• An account structure your commercialista recognises

Italian groups, branches and cross-border trade

Italian businesses of moderate size commonly operate several locations and often more than one legal entity, with a good deal of trade across the European Union. That makes intercompany transactions, consolidation and a shared account structure ordinary requirements, and it makes location a dimension that belongs on the posting rather than in a report definition.

Currency follows. Transactions should be recorded in the currency in which they occurred, with the rate applied and the date it applied, so that the difference realised on settlement is explained by the record rather than reconstructed from bank statements at the year end.

Skyline Nexus records transactions in their original currency with the applied rate, carries entity and location as dimensions on the posting, holds tax at line level, keeps the transmitted file with the transaction, and shows the clearance status of each invoice against the invoice itself. It does not decide your tax position and it is not certified for any Italian regime; those are matters for Agenzia delle Entrate and your commercialista.

Where an Italian entity sits inside a larger group, the clearance record is also part of the group audit trail. An invoice whose delivery status exists only in an intermediary's portal is evidence the group cannot reach, and that becomes obvious at the worst possible moment, which is when somebody outside the business asks for it.

• Several entities and locations under one account structure
• Intercompany balances that agree in both directions
• Original currency and applied rate stored on the transaction
• Domestic, intra-EU and third-country supplies separately identifiable
• Transmitted files and clearance status retained with the posting

A diagnostic for a system already in a mature regime

If you are already compliant, the case for change has to be made on the quality of the process rather than on the risk of a penalty. That makes it worth running a short diagnostic on what you have, using questions whose answers you can check today rather than opinions about software.

Pick one invoice from last month at random. Can you see, from the invoice record itself, that it was submitted, accepted and delivered, and when. Pick one that failed. Can you see why it failed, what was corrected, and which document replaced it. Pick a supplier invoice. Was it posted from data, or did somebody read it and type it in.

Then ask the organisational version of the same question. If the person who handles the exchange were away for two weeks, would invoicing continue normally, or would it accumulate. A process that depends on individual knowledge is working, but it is working for a reason that will not always be present.

Where the answers are uncomfortable, the fix is usually consolidation rather than replacement of everything: bringing the document, its status and its ledger entry into one place so that they cannot drift apart. That is a smaller project than it sounds and it is the one that removes the most daily friction.

• One invoice: status visible on the record, with dates
• One failure: reason retained and the replacement linked
• One supplier invoice: posted from data, not retyped
• One absence: would invoicing continue without the usual person
• One year-old document: reachable from the ledger entry in one step

What to ask a vendor in Italy

Ask to see a live invoice submitted and its status appear on the invoice record, not in a separate portal. Ask to see a rejected one, with the reason retained and the corrected document linked to it. Those two demonstrations tell you most of what you need to know.

Ask how the XML, the readable copy and the ledger entry are produced, and specifically whether they come from one record or from separate processes. Ask where the transmitted file is stored, and for how long, and how you would find it from a ledger entry three years from now.

Ask how the system handles numbering when a submission fails, because the answer reveals whether the vendor has actually operated in this regime or has merely built an export. And ask what happens on migration: numbering continuity, historical documents, and documents in flight.

Finally, be sceptical of certification language. Software can produce documents in the required format and record what happened to them; whether your business complies depends on your data and your processes. Confirm your own position with Agenzia delle Entrate or your commercialista.

• A live submission with the status appearing on the invoice record
• A rejection with the reason kept and the replacement linked
• One record behind the XML, the readable copy and the ledger entry
• A three-year-old transmitted file found from its ledger entry
• How numbering behaves when a submission fails
• Migration: continuity, history and documents in flight

Common questions

Is e-invoicing mandatory in Italy?

Yes, and it has been for years. Italy was the first country in the European Union to mandate business-to-business electronic invoicing, from 1 January 2019. Invoices are cleared through the Sistema di Interscambio in FatturaPA XML format. The regime is fully in force and mature, so the practical question is not readiness but whether your system handles it properly.

What is the SdI and why does it matter?

The Sistema di Interscambio is the exchange system that sits between seller and buyer. Invoices are submitted to it, validated, and delivered to the recipient by it, rather than being sent directly. That is why an invoice can exist in your system and still not have reached your customer, and why per-invoice status needs to be visible on the invoice record itself.

What happens when an invoice is rejected?

An invoice that fails validation has not been issued: it must be corrected and resubmitted. The point that most often causes inconsistency is numbering, because a failed submission may already have consumed a number in your ledger. Handle it deliberately and consistently, record what happened, and confirm the tax treatment of any correction with your commercialista.

What is the standard rate of Italian VAT?

The standard rate is 22%. Reduced rates and exemptions apply to particular supplies, and cross-border transactions follow their own rules; confirm the treatment of a specific transaction with Agenzia delle Entrate guidance or your commercialista. Under clearance, tax detail that does not reconcile to the document total can cause a rejection rather than merely an untidy invoice.

Which accounting framework applies to an Italian company?

Italian individual entities generally prepare accounts under the national standards issued by the Organismo Italiano di Contabilità, while listed groups in the EU report under IFRS as adopted by the European Union. Groups needing both views should keep the ledger detailed rather than summarised. Which framework applies to your entity is a question for your auditor.

Rates, regimes and deadlines in this summary change, and many countries are actively legislating on e-invoicing. This is general information, not tax or legal advice — confirm the current position with the authority named above or with your tax adviser before you rely on it.