They are not three stages of one evolution. They are three different objects. E-invoicing carries the document you sent to your buyer. CTC transmits the transaction you issued, at the moment you issued it. SAF-T exports what you booked — the general ledger, the master files, the whole accounting record — either when the tax authority asks, or on a monthly cycle.
Those three things can disagree with each other. That is the entire reason a tax administration wants all three. And it’s why ViDA — which people keep describing as the end of periodic reporting — explicitly preserves SAF-T in the same breath as it mandates real-time transmission.
The map: what distinguishes them is the source object
Most explanations sort these by speed, which is why they end up confusing. Sort them by what the data is extracted from and the model resolves.
j
- E-invoicing — source object: the invoice document. Recipient: the buyer. Governed by Directive 2014/55/EU and EN 16931. Deadline under ViDA: ten days from the chargeable event (Article 222). Integrity model: schema plus Schematron validation.
- CTC — source object: the transaction as invoiced. Recipient: the tax authority. Governed by Chapter 6 of the VAT Directive as replaced by ViDA. Deadline: the moment the invoice is issued (Article 263(1)). Integrity model: cross-checking your report against your counterparty’s.
- SAF-T — source object: the accounting record. Recipient: the tax authority or an auditor. Governed by national law, built on an OECD template. Deadline: on request, or periodically. Integrity model: referential integrity across the file.
Different objects, different owners inside your business. The invoice belongs to billing. The CTC report belongs to tax. The SAF-T file belongs to finance and the chart of accounts. A project that treats them as one integration will discover this the hard way.
SAF-T: the ledger, on request
The OECD’s Committee on Fiscal Affairs published SAF-T version 1.0 in May 2005, built around entries from a General Ledger Chart of Accounts together with master file data for customers and suppliers, and details of invoices, orders, payments and adjustments. Version 2.0, published in 2010, added inventory and fixed assets, and moved the schema from DTD to XML Schema — not fully backward compatible with 1.0.
Read the OECD’s own statement of purpose and the difference from CTC is immediate: SAF-T exists so that errors can be identified and quantified efficiently in the initial stages of an audit, letting auditors target resources at errors with material impact. It is audit tooling. The guidance even frames self-audit as a benefit — businesses reviewing their own transactions and adjusting before a return is filed. Nothing about that is real-time, and nothing about it is transactional control.
Two design details matter for anyone building to it. First, constraints are a deliberate feature: where a customer reference appears at transaction level, there must be a corresponding entry in the customer master file. SAF-T’s integrity model is referential integrity across the whole extract — a fundamentally different test from “does this invoice validate”. Second, the schema includes deliberate extension points, and the OECD is explicit that adding elements anywhere else makes the file incompatible with the OECD model. That is the same narrow-and-widen pattern EN 16931 uses with CIUS and Extensions, arrived at independently.
In practice there is no harmonised European SAF-T. Portugal went first in 2008 — mandatory for large firms using computerised accounting from 2009, extended to all VAT-registered entities by 2013 — and SAF-T (PT) integrates with the e-fatura system. Austria implemented it in 2009 on an on-demand basis. Luxembourg’s FAIA followed in 2011, on request, with penalties reported at up to EUR 5,000 per infraction or EUR 50–1,000 daily. Norway serves it on demand through Altinn. France uses FEC, its own SAF-T-inspired format, entirely separate from the OECD schema. Each country adapts, and the extension points are why they can.
CTC: the transaction, as it happens
Continuous transaction controls invert SAF-T’s direction. Instead of the authority reserving a right to come and look, the data arrives on its own.
Under ViDA, from 1 July 2030, an intra-EU B2B supply is transmitted per individual transaction at the moment the invoice is issued or should have been (Article 263(1)), carrying ten data points fixed identically across every member state (Article 264) — Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where applicable. The customer reports within five days of receipt unless the member state waives it. Recapitulative statements are abolished outright: Articles 265 to 271 are deleted.
What CTC can see is exactly one thing: invoices, as issued. That is a narrow window, and it is the reason SAF-T survives.
E-invoicing: the exchange, which is neither of the above
E-invoicing is the only one of the three that isn’t a reporting obligation at all. It’s a private exchange between a supplier and a buyer, and its purpose is that the buyer can book and pay.
The historical proof sits in the Euro Retail Payments Board’s 2016 working group report, which categorises e-invoicing solutions by the number of intermediary platforms in the presentation flow: Supplier Direct, Buyer Direct, three-corner, four-corner. The tax authority is not a corner in any of them. In 2016 that wasn’t an omission — e-invoicing was defined as a two-party exchange, and the industry only invented a fifth corner once tax authorities arrived.
The dependency now runs the other way, and only one way. ViDA’s new Article 217 requires an invoice to be structured “at least in relation to the data referred to in Articles 262 and 271b” — the reporting articles. The reporting layer sets the structured floor for the exchange layer. Not your buyer’s needs. Not yours.
Why ViDA doesn’t kill SAF-T — and says so
This is the part the vendor explainers skip, and it’s decided in the directive’s own text.
ViDA’s recital 23 states that member states should be allowed to keep their national reporting tools — based, for example, on a SAF-T system — alongside the real-time obligations the directive introduces, together with non-general obligations such as those covering cash registers. It then draws the line explicitly: the ability of member states to request information from taxable persons during audits should not be limited, insofar as such information is obtained only at the member state’s request and does not result from active communication by taxpayers.
That sentence is the architecture. Pull versus push. Information the authority asks for is audit logic and stays permitted without limit. Information the taxpayer actively transmits is reporting logic and is now governed by Chapter 6. Article 273 carries it into the operative text: member states may not impose new general transaction-based reporting obligations on Article 262 transactions beyond Chapter 6 — but they may require taxable persons to keep transaction data for preparing the VAT return or for audit purposes, and they may impose reporting obligations for transactions outside Chapter 6’s scope.
So the boundary isn’t speed. It’s who initiates. And it means the practical answer to “does CTC replace SAF-T” is no: CTC takes the invoice-shaped transactions inside Chapter 6, and SAF-T keeps everything else — accruals, fixed assets, stock movements, bad debt relief, the credit note you never issued, the journal entry that reclassified a cost. CTC cannot see any of that, because none of it is an invoice.
Where the three collapse into one: Greece, Lithuania, Poland
The clean model above is a way to reason, not a description of what countries build. Three examples show the layers fusing.
Greece is the sharpest case, and SAP’s August 2024 implementation guide for Greek e-invoicing states it outright: myDATA accepts all revenue, expense and VAT-related documents from Greek businesses, thereby fulfilling the eBooks requirement — and the purpose of myDATA is the reconciliation of the accounting records of the liable entities with the tax authority’s e-books. That is a SAF-T objective. It is delivered over CTC plumbing (real-time submission through a certified service provider, with the platform returning a MARK, a UID and an authentication code) which itself rides on the e-invoicing exchange layer. All three layers, one message.
The tell is in the field list. The myDATA XML carries invoice type, total amount, net amount, VAT category — and then classification category and classification type. Those last two aren’t invoice fields at all; they’re accounting classifications, and SAP’s mapping derives them per document type from the G/L revenue or supplier offsetting account. A field in the invoice message whose value comes from the chart of accounts is the ledger layer bleeding into the transaction layer, in production.
Lithuania keeps them separate and names them. The i.MAS platform runs i.SAF for invoices, i.SAF-T for accounting data, and i.VAZ for goods transport — three modules, three source objects, one platform. The architecture in this article is not a theory; one member state shipped it as a product structure.
Poland runs both, and merged one of them with the VAT return. JPK arrived in July 2016 for large taxpayers and covered everyone by 2018. In 2020 JPK_VAT was replaced by JPK_V7M and JPK_V7K, which fold the VAT return and the underlying records into a single file — the return stopped being a separate document. Of the seven JPK structures, only JPK_V7M/K is submitted on a cycle, by the 25th; the rest, including the general ledger structure, are produced on request. And Poland mandates KSeF for e-invoicing on top. Two obligations, two layers, no overlap in the data.
The decisions, in the order you’ll face them
First: which layer does this requirement live on? If it names a document going to a counterparty, it’s exchange. If it names a transmission at the moment of issue, it’s CTC. If it names the general ledger, master files, or “on request”, it’s SAF-T. Requirements that name a G/L account inside an invoice message — Greece — are telling you the country has fused two layers, and your project scope just doubled.
Second: pull or push? Pull obligations are a data-availability problem: can you regenerate a consistent, referentially intact extract for a period that closed three years ago, after a chart-of-accounts migration? Push obligations are a latency and failure-handling problem: what happens at 14:59 when the endpoint is down and the invoice is issued at 15:00? These are not the same engineering problem and they rarely belong to the same team.
Third: assume they’ll be reconciled against each other. The reason to hold all three is that they’re derived from different objects and should agree. Greece says so explicitly — reconciliation of your accounting records against the authority’s copy. If your invoice data and your ledger data have never been reconciled internally, a tax authority is about to do it for you.
Frequently asked questions
Is SAF-T being replaced by CTC?
No. ViDA’s recital 23 explicitly permits member states to keep national reporting tools based on a SAF-T system alongside the directive’s real-time obligations, and Article 273 lets them require data retention for VAT return preparation and audit, and impose reporting on transactions outside Chapter 6. What Article 273 blocks is new general transaction-based reporting duplicating Chapter 6 for Article 262 transactions.
What’s the actual difference between SAF-T and CTC?
Source object and direction. SAF-T extracts the accounting record — general ledger, master files, fixed assets, inventory — and is typically produced on request. CTC transmits individual invoice transactions as they are issued. A CTC system can’t see a journal entry; a SAF-T file doesn’t arrive in real time.
Is e-invoicing a reporting obligation?
Not inherently. It’s an exchange between two businesses. Mandatory e-invoicing exists in countries with no tax authority controls at all, and in those cases nothing is reported to anyone. It becomes entangled with reporting only where a mandate connects the two — which, from 1 July 2030 for intra-EU supplies, ViDA does.
If a country has CTC, do I still need to file SAF-T?
Country by country, and frequently yes. Poland runs KSeF and JPK. Romania runs RO e-Invoice and the D406 SAF-T declaration. France is introducing mandatory e-invoicing while FEC remains a separate on-demand obligation. Budget for both unless the specific national law says otherwise.
Do the three ever carry the same data?
They overlap and none contains another. The invoice carries line items and delivery details the tax authority never receives. The ViDA report carries ten fields and not the parties’ names and addresses. SAF-T carries fixed assets and journal entries that never touched an invoice. Greece’s classification fields exist in the invoice message purely because myDATA is doing an accounting job through an invoicing channel.