If you work in tax, finance, or compliance, you have probably noticed that e-invoicing mandates are arriving faster than most businesses can absorb them. France, Germany, Belgium, Poland. The list keeps growing. At the same time, VAT returns continue on their own separate track, filed monthly or quarterly with their own rules and deadlines.
Somewhere between these two obligations sits a question that not enough people are asking: do the numbers actually match? And if they don’t, who finds out first, your team or the tax authority?
This is where SAF-T comes in. Not as another reporting burden, but as the mechanism that connects the dots between what you invoice, what you declare, and what your accounting records actually say.
Three Data Streams, One Problem
Most businesses manage three distinct streams of tax-relevant data. The first is e-invoicing: structured invoices sent in real time or near-real time, increasingly through government-controlled platforms. The second is the VAT return, a periodic summary of what the business owes or can reclaim. The third is the accounting system itself, the general ledger, master data, journal entries, and source documents that underpin everything.
In theory, these three streams should tell the same story. In practice, they often don’t. E-invoicing captures transactions as they happen, but it rarely covers everything. B2C sales, exports, certain thresholds, and intra-community supplies are frequently outside scope. VAT returns aggregate the numbers but strip away the detail. And accounting records contain the full picture, just in a format that tax authorities cannot easily access or interrogate.
When these streams are managed in silos, by different teams, on different systems, to different timelines, gaps appear. A tax code mapped one way in the ERP produces a different result on the e-invoice. A VAT return total doesn’t reconcile to the sum of reported invoices. A supplier reference in the ledger doesn’t match the master data. Anyone who has been through a VAT audit will recognise these problems immediately.
Tax Authorities Are No Longer Waiting
The rules of the game have changed. The EU’s VAT in the Digital Age (ViDA) package, formally adopted in March 2025, makes structured e-invoicing mandatory for cross-border B2B transactions from July 2030. E-invoices must be issued within ten days of the chargeable event and reported to tax authorities in near-real time. Member states can introduce domestic mandates without waiting for the EU deadline, and many already have.
The upshot is that tax authorities now hold transaction-level data. In Italy, where mandatory e-invoicing has been in place since 2019, the tax authority detected and blocked fraudulent VAT credits worth nearly EUR 1 billion in the first year alone. By 2022, that figure had risen to EUR 9 billion. Italy’s VAT compliance gap fell by EUR 12.7 billion in 2021, the largest drop of any EU member state.
In jurisdictions operating clearance models (where invoices pass through a government platform before reaching the buyer), the VAT return is becoming what some commentators call a “reverse VAT return.” The tax authority already has the invoice data. The return is no longer a self-contained declaration; it is a reconciliation exercise, confirming what the authority already knows. Discrepancies between declared totals and invoice-level data are increasingly likely to trigger queries, audits, or penalties.
Why Mismatches Keep Appearing
If tax authorities can already see individual invoices, why do reconciliation problems persist? The answer is scope. E-invoicing mandates, even comprehensive ones, rarely cover every transaction a business processes. B2C sales, cross-border supplies, certain financial services, and transactions below reporting thresholds often fall outside the mandate. That means the e-invoice data set is always partial.
At the same time, penalties are tightening. In Poland, where the KSeF e-invoicing platform became mandatory for large taxpayers in February 2026, each error in the JPK SAF-T file related to invoice data can attract a penalty of PLN 500, applied per individual mistake, not per file. The Polish tax authority can now directly compare a company’s VAT return with the sum of its KSeF invoices and flag inconsistencies automatically.
Several tax authorities are also deploying AI and automated systems to analyse the growing volumes of transactional data. The EU’s own impact assessment estimates that ViDA will reduce VAT fraud by up to EUR 11 billion per year. That analysis depends on authorities actively cross-checking data, which means businesses that have not reconciled their own data first are exposed.
Where SAF-T Fits
And this is where the Standard Audit File for Tax earns its place. SAF-T is not a transactional reporting tool like e-invoicing, and it is not a periodic declaration like a VAT return. It is an accounting audit file: a structured extract of the underlying books and records that show how the business arrived at its tax position.
A useful way to think about the three obligations:
- •E-invoicing answers: “Is the right VAT due on this transaction?”
- •VAT returns answer: “How much tax is owed in total?”
- •SAF-T answers: “How did you arrive at those numbers?”
SAF-T includes the general ledger, chart of accounts, customer and supplier master records, tax codes, journal entries, invoices, payments, and (depending on the jurisdiction) inventory movements and fixed assets. It is the complete audit trail. When a tax authority wants to understand why a VAT return shows a particular figure, the SAF-T file is where they look.
This is why SAF-T and e-invoicing are complementary rather than competing obligations. E-invoicing captures individual transactions in real time but has limited scope. SAF-T provides the broader accounting context that ties everything together. Countries like Romania, Poland, and Portugal already operate both systems in parallel, and the trend is clearly towards more integration, not less.
Validation Is Where You Spot the Gaps
If SAF-T is the reconciliation layer, then validating your SAF-T file is the practical step that surfaces mismatches before anyone else finds them. A file that passes schema validation only tells you the file is technically well-formed. The structure is correct and the required fields are present. It does not tell you whether the data inside is consistent.
Business rule validation goes deeper. Do the account references in journal entries match the master data? Are the tax codes valid for the jurisdiction? Do the totals balance across sections? Are supplier and customer records complete, with valid tax identification numbers? These are exactly the kinds of inconsistencies that a tax authority would find when cross-referencing your SAF-T data against your e-invoices and VAT returns.
Romania offers a concrete illustration. ANAF’s SAF-T pilot programme (running from September 2025 to August 2026) introduced automated cross-validation between the D406 SAF-T filing and the D300 VAT return. The system runs eleven consistency checks, comparing taxable amounts, VAT amounts by rate category, transaction counts, and intra-community data. Since January 2026, businesses whose D406 and D300 data are inconsistent must provide explanations within twenty days.
The lesson from Romania is straightforward: if you are not validating your own SAF-T data against your VAT position, the tax authority will do it for you. And by that point, the conversation is no longer about fixing data quality. It is about responding to a compliance inquiry.
From Reactive Checks to Continuous Control
The organisations that handle this well are not running reconciliation as a one-off exercise before an audit. They treat it as a continuous process, validating SAF-T files after every significant system change, after every reporting period close, and as part of their routine month-end procedures.
The goal is a three-way reconciliation: e-invoice data lines up with SAF-T accounting data, which lines up with VAT return totals. When the same tax determination rules drive all three outputs, mismatches become rare rather than routine. When validation is built into the workflow rather than bolted on at the end, errors are caught at the point they are introduced, not months later during an audit.
That shift, from reactive, after-the-fact reconciliation to proactive, continuous control, is where the real advantage lies. The point is not to do more compliance work. The point is to do it once, correctly, and have the data to prove it. Teams that reach this point spend less time on rework, face fewer audit surprises, close their books faster, and have genuine visibility over their tax position at any given moment.
What This Means for Luxembourg
Luxembourg’s FAIA is the country’s implementation of the OECD SAF-T standard. Unlike Romania or Poland, Luxembourg does not require periodic SAF-T submissions. FAIA files are produced on demand, typically when the AED (Administration de l’Enregistrement et des Domaines) requests one during a VAT audit. That on-demand model makes readiness even more important. You cannot start preparing when the request arrives.
There is also a legislative development worth tracking. Bill 8186B proposes extending FAIA obligations beyond VAT to cover direct tax reporting. If enacted, the volume and scope of data in the file would increase, and so would the potential for inconsistencies between the FAIA data and other filings.
For Luxembourg businesses within scope (turnover above EUR 112,000 and subject to the standard chart of accounts), the practical advice is to validate FAIA files regularly, not just when an audit is imminent. Schema validation confirms the file is technically correct. Business rule validation confirms the data is internally consistent: that account references match across sections, that tax codes are valid, and that the numbers tell a coherent story. That is the reconciliation checkpoint that keeps you audit-ready.
The Opportunity Most Businesses Are Missing
The direction of travel across Europe is clear. More countries are adopting SAF-T. More jurisdictions are mandating e-invoicing. Tax authorities are investing in automated cross-checks and data analytics. E-invoicing, VAT returns, and accounting data are converging whether businesses are ready or not.
Most companies still treat these obligations as separate compliance exercises, managed by different teams on different timelines. That approach worked when tax authorities relied on periodic returns and occasional audits. It does not work when they hold real-time transactional data and can compare it against your books at the press of a button.
SAF-T is the piece that closes the loop. It connects invoice-level detail to accounting records to declared tax positions. Validating your SAF-T file is the practical step that tests whether those connections hold. Businesses that build this into their routine are not just reducing risk. They are turning compliance data into something genuinely useful: a single, reliable view of where they stand.
Validate your FAIA files before the AED asks. The SAF-T Validator checks Luxembourg FAIA files against both the official schema and business rules, catching reference mismatches, invalid tax codes, and data inconsistencies before they become audit findings. All validation runs in your browser, so your financial data never leaves your machine.
