SAF-T: One Schema, As Many Dialects as There Are Administrations

A standard audit file is the only artefact in this field that nobody actually sends. It is generated, or it is generatable, and then it waits. When an inspector asks for it, the accounting record of an entire period leaves the business in a single structured file that nobody composed line by line and, in most cases, nobody read before it went.

The design intent was sound, and it was not European in origin. The OECD proposed a common structure for accounting data so that a tax auditor could receive the books of any business, running any software, in a shape they already knew how to read. Before that, every audit began with somebody learning the export format of whatever system the taxpayer happened to have bought. A shared schema removes that step and turns a heap of records into something that can be queried.

Then the familiar thing happened. Administrations adopted the structure and extended it — extra modules, national account taxonomies, country-specific codes, their own submission rules and their own file-splitting conventions — so that a business operating in five countries produces five files that share a name, a broad shape and not a great deal else.

The contents, and what they are not

The file carries accounting records, not documents. Depending on the country and on which modules have been requested, it will typically include the general ledger entries for the period, the chart of accounts behind them, customer and supplier master records, a product or service master, the invoices issued, and in some national versions payments, stock movements or fixed assets.

Read that list again and notice what is missing. There is no invoice in the sense the rest of this site uses the word — no structured business document with a seller, a buyer and a VAT breakdown that a receiver validates. There are ledger postings that refer to invoices, and there are header-level invoice records derived from the sales sub-ledger. The document itself lives somewhere else, under the rules on keeping a structured invoice for the retention period, and the auditor may well ask for both.

An audit instrument rather than a return

A VAT return is a summary you assert, on which a liability is computed. A transaction report is a stream you push, invoice by invoice, close to the moment of issue. The audit file is neither. It is a reconstruction of your books, produced on demand, in a form the administration can load into its own tooling and interrogate.

Nobody calculates your tax from it. They test what you already declared against it. That difference in purpose explains almost everything about how the file behaves: it is comprehensive rather than timely, it is retrospective, and it is not designed to be read by a human at all.

Three ways an administration takes your data

The column that matters is the fourth one. Each of these three regimes draws from a different system, and in most businesses those systems are separated by an interface, a nightly batch, a set of posting rules and at least one manual step. Three collection models pointed at three different layers of the same architecture will produce three views that agree only if the plumbing between them is sound.

What the file demands of the chart of accounts

The first cost of the file is almost never technical. Several national versions require every account in your chart to be mapped to a prescribed taxonomy, so that an auditor in that country can compare like with like across taxpayers. If your group chart was designed for management reporting, that mapping is a project in its own right, and it has to be maintained every time somebody opens a new account.

The second demand is granularity. Postings have to carry the tax code that produced the VAT treatment, and the counterparty has to be identifiable at entry level. An aggregated journal that summarises a day of sales into one line satisfies your accountants and defeats the file entirely, because the whole point is that each entry can be traced back to the supply that caused it. That traceability is the machine-readable form of the reliable audit trail between an invoice and the supply it records.

Master data travels inside the file

Customer and supplier records do not sit behind the extract. They are in it. A VAT identifier that was never checked against a register, a duplicate supplier created because somebody spelled the name differently, a country code left at whatever the system defaults to — all of it arrives at the administration in a queryable table, next to the transactions it qualifies.

This is the least discussed reason why master data remediation earns its budget. Bad master data in an invoice produces a rejection you can see and fix. Bad master data in an audit file produces a query from an inspector months later, about a period you can no longer correct.

The disagreement is the point

Because the file is generated from the ledger and your reports are generated from the invoice flow, the two are independent accounts of the same events. Comparing them is trivial for an administration that holds both, and several already do.

Some divergence is legitimate and explicable. An invoice reported at issue may be posted in a different accounting period. A correction may exist as a credit note in one view and as a reversing entry in the other. Manual journals for VAT adjustments never existed as invoices at all, so they appear in the ledger and nowhere else.

The rest is not explicable, and that is what the comparison is for. A regime that collects invoice data continuously, such as Spain's immediate supply of information, gives the administration a running record it can set against your books the moment the file arrives. The defensible position is not that the two match, because they will not. It is that you already knew where they differed and why, which is the working discipline described in reconciling what you reported against what you booked.

Dialects with a common name

The national versions differ in ways that are individually small and collectively expensive: which modules are mandatory, how accounts map to the national taxonomy, which code lists apply, whether submission is periodic or on demand, how large files are split, and what the administration does with a file it considers incomplete. Some countries do not even call it a standard audit file in their own language.

The practical consequence is that group-level capability is not something you buy once. What you can build once is the internal extract — a single, complete representation of the ledger with every attribute any national version might ask for — and then derive each country's file from it. The alternative, a separate extract per jurisdiction wired directly into the accounting system, is a maintenance burden that grows with every mandate and every schema revision.