From “6th directive digitalization” to “VIDA digitization”

While the old phrasing focused on the invoice being "issued and received in any electronic format," the new definition is significantly more restrictive to ensure high-speed, automated tax reporting.

1. The Core Change: "Any Format" vs. "Structured Format"

The most notable change is the shift from a broad definition to a technical one.

• Old Definition (Pre-ViDA): An electronic invoice was simply an invoice issued and received in "any electronic format" (which included simple PDFs or even scanned images sent via email).
• New Definition (ViDA new article 217, in force as of transposition, latest 31.12.2030): An electronic invoice is now defined as a document that has been issued, transmitted, and received in a structured electronic format which allows for its automatic and electronic processing.

The very first impact: As of the full implementation (gradually starting now through 2030), unstructured PDFs will no longer be legally considered "electronic invoices." Only formats like XML, EDI, or hybrid formats (like Factur-X, which contains a machine-readable XML file) will qualify.

It means in clear: forget the PDF documents, which your supplier sends. Even if received by email in PDF/A format, that “thing” has no more value. Those who receive it cannot use it to deduct both the principal and the VAT, and those who send it cannot use it to collect its fees. If you want to continue with this type of receiving, you need to shift all your suppliers to Factur-X formats, at best.

But that’s not all, the nightmare continues...

2. The End of Recipient Acceptance (Article 232)

The "received" part of the definition is also changing in its legal weight. Previously, Article 232 stated that the use of an electronic invoice was subject to the acceptance of the recipient.

• The Change: ViDA effectively removes the need for recipient consent for transactions falling under the new Digital Reporting Requirements (DRR).
• Result: A supplier will be able to "send" a structured e-invoice, and the customer is legally obligated to "receive" it in that format, losing the right to demand paper or a simple PDF.

That’s still not all, the nightmare goes on. At this point, the reader should take a deep breath.

3. The prefilling saga: A format “which allows for its automatic and electronic processing”

Let’s take the usual scenario… We are the 27th of the month. Your preferred supplier prepares his invoice, as usual on last days of the month. Nothing exceptional so far...

He sends the list of his invoices to his accountant in a text file. On 28th, the accountant turns the file into his system, and his system sends it to the Access Point of electronic invoicing. We are in a 5-corner model, that invoice hits the server of tax authority, and within an hour, the invoice lays in the portal of the customers, ready for processing. At this point, Article 232 is fulfilled, right?

Yes, and No…

Yes, for the tax portal, it has the invoice and computes into the “pre-filling” data. On that tax period, the supplier will report the invoice, and the pre-filling of the customer will also report it.

So far everything is a marvelous technology at work, right?

No, because we forgot the customer, he hasn’t processed his invoice yet, hasn’t booked it yet and hasn’t approved it yet. And unless a miracle happens, there is no way it will be approved and booked before the 31st of the same month.

Historically a large proportion of companies we have seen, process their invoice -for decades- with a “parking” mode: the invoice is in their system, but not booked on balance sheet. The invoice waits for approval and only once approved, it goes to balance sheet. And to get approved, it takes a few days (in some companies even few weeks!).

The effect? At month end, the indirect tax manager discovers a pre-filled version containing many invoices, which do not exist on his books. This problem is known as the “velocity effect”: Electronic velocity of e-invoices is way faster than traditional velocity of past accounts payable.

Welcome to pre-filling world.

Prefilling is the direct consequence of shifting from digitalization (where documents are simply digital) to digitization (where processing and data intelligence automatically derive from the digital action).

Prefilling is totally incompatible with invoice parking practices!

What comes next? The tax nightmare already started

What comes next is a discrepancy, between the reported tax and the booked tax. The very first task of the indirect tax person is to “opt”, which one he chooses to report:

• Choose the pre-filling data, then he has no problem with tax authority. But he has problem with the statutory auditors, who will eventually see the discrepancy.
• Choose his own books for reporting, and the tax authority systems will raise the red flag, and someone from the tax authority will come for a visit.

Some people already warned about this effect (see the link), but we only see the impacts today.

Now we have described the problem, the solution is straight: companies relying on “invoice parking” must change their process. Simple to say, and very hard to do.

Now go explain to your CFO, that the accounts payable process needs a change.

We wish you fun.