Imagine the following situation: A German company supplies goods to a customer in another EU country. The invoice is generated and sent as an e-invoice as usual. Until now, things usually remained quiet at this point from a tax perspective, as the VAT was accounted for later as part of periodic reporting.
At a certain point, that changes fundamentally. And it is precisely at this juncture that a term emerges which is still hardly known in Germany: the Tax Data Document, or TDD for short.

The trigger: ViDA changes the timing of the tax audit

The reason for this change lies in the EU initiative ViDA (VAT in the Digital Age). It shifts VAT reporting from a retrospective, aggregated approach to reporting at the level of the individual transaction: almost in real time. From 1 July 2030, a new obligation will apply to transactions between businesses in different EU countries: every single invoice must not only electronically issued, but must also be reported individually to the tax authority. The previous practice (a aggregated report at the end of the month or quarter) is thus discontinued.

For the invoice itself, there is a 10-day issuance deadline following the time of supply. Irrespective of this, the actual reporting to the tax authorities must take place much faster: the supplier generally reports at the time the invoice is issued, whereas the recipient of an invoice must report within 5 days. Month-end reprocessing, as is still practised by many finance departments today, is effectively made impossible as a result; the tax verification of an invoice must practically take place the moment the invoice is created.

What happens to the invoice now?

Let us stick with our example company. As soon as the invoice is issued, the system must know immediately: does this business transaction trigger a reporting obligation to the tax authority? And if so, which one?

This is precisely where the tax data document comes into play. It is not the invoice itself, but an additional, structured message that is generated in parallel with the e-invoice. As part of the Peppol-based model, it is transmitted to the relevant tax authority via the Peppol network. This is made possible by an extension of the well-known Four-Corners Model of the e-invoice: Alongside the seller, the buyer and their respective access points, the tax authority comes into play as an additional party. This is a concept that is known among experts as CTC architecture is referred to as (CTC stands for Continuous Transaction Control).

And what happens at the customer's end?

This is where an aspect comes into play that surprises many: under ViDA, the buyer (in our example, the company in the other EU country) is also placed under an obligation. Basically, two approaches are conceivable: the buyer adopts the tax data transmitted by the seller, but must verify themselves whether they are correct. Or they recalculate the tax according to their own domestic rules. Exactly how this buyer-side reporting will be structured in detail has not yet been finally clarified at EU level. Further technical and legal clarifications at EU level are expected regarding this.

Particularly noteworthy: the ViDA regulations allow member states to introduce a reporting obligation even in cases where an expected invoice has not been received at all. If a tax-relevant transaction has taken place, but no invoice has arrived, the respective member state can require the buyer to actively report this themselves. From the perspective of many companies, e-invoicing has so far been primarily the supplier's obligation. This shows that this picture may shift under ViDA.

Whether a buyer is obliged to report at all also depends on the respective EU member state: the ViDA directive allows member states to exempt their businesses from the buyer-side reporting obligation. This status is not set in stone, as it can change during the implementation phase up to 2030 and beyond. A one-off check of the business partner during onboarding is therefore no longer sufficient; master data management must become an ongoing task.

What changes for ongoing processes?

In practice, this means that the tax engine can hardly function as a downstream, separate step anymore, but should be integrated directly into invoicing and accounts payable so that reporting can take place on time at the moment the invoice is issued. Checking individual invoice items against different tax categories also becomes more demanding as a result. Furthermore, corrections such as credit notes or replacement invoices are themselves independent invoices subject to reporting obligations, which can result in multiple interrelated reports per business transaction.

Would you like to know how ViDA and the Tax Data Document will specifically impact your invoicing processes? We help companies future-proof their e-invoicing processes.

Arrange a personal consultation

Note on the status of this post: As of August 2026, the underlying OpenPeppol specification for the Tax Data Document is still in a pilot status (version 1.0.0-HotFix) and is subject to further development. Furthermore, the precise configuration of individual reporting details has not yet been finally clarified in all respects at EU level.