The «Prefilling» headache

The VAT in the Digital Age (ViDA) directive introduces a fundamental change to Article 217 of the VAT Directive (2006/112/EC). For people old enough to recall the introduction of Article 217 in 2019, that article was the founding article for the digitalization of invoices: “For the purpose of this Directive, the ‘electronic invoice’ is an invoice that contains the information required in this Directive, and which has been issued and received in electronic format.”

Already in 2010, the expression “sent and received” triggered significant rambling from tax advisors. The usual questions were as such:

• What about an invoice sent, received, and not processed?
• Is “received” meaning booked in the balance sheet?
• Is “received” meaning booked and approved?

Behind all of those questions hides the processing of invoices: an invoice may be technically received but simply parked. Then from parked to booked, but not approved. Then from booked to approved. Then payment comes next.

With ViDA, all of this changes — and yet nearly nobody noticed.

Warning: the outcome will be bitter. This is not a simple change; it's a change that will trigger a full reformatting of invoice reprocessing in companies.

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 upon transposition, by 31 December 2030 at the latest): 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 full implementation rolls out (gradually, from 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.

In plain terms: forget the PDF documents your supplier sends you. Even received by email in PDF/A format, that “thing” no longer has any value. Recipients won't be able to use it to deduct either the principal amount or the VAT, and senders won't be able to use it to collect their fees. If you want to keep receiving invoices this way, you'll need to move all your suppliers to Factur-X format, 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 recipient's acceptance.

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 will be 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. It's the 27th of the month. Your preferred supplier prepares his invoice, as usual, in the last days of the month. Nothing exceptional so far.

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

Yes, and no.

Yes, for the tax portal — it has the invoice and factors it into the “pre-filling” data. For that tax period, the supplier will report the invoice, and the customer's pre-filling will report it too.

So far, it's all 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's no way it will be approved and booked before the 31st of the same month.

Historically, a large proportion of companies we've seen have processed their invoices — for decades — using a “parking” mode: the invoice sits in their system, but isn't booked to the balance sheet. It waits for approval, and only once approved does it move to the balance sheet. Getting approved takes a few days — in some companies, even a few weeks.

The effect? At month-end, the indirect tax manager discovers a pre-filled version containing many invoices that don't exist in his own books. This is known as the “velocity effect”: the electronic velocity of e-invoices is far faster than the traditional velocity of accounts payable.

Welcome to the 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 flow from the digital action).

Prefilling is totally incompatible with invoice-parking practices.

What comes next: the tax nightmare has already started

What comes next is a discrepancy between the reported tax and the booked tax. The indirect tax manager's very first task is to choose which figure to report:

• Choose the pre-filling data, and there's no problem with the tax authority — but there will be a problem with the statutory auditors, who will eventually spot the discrepancy.
• Choose his own books for reporting, and the tax authority's systems will raise a red flag — someone from the tax authority will come for a visit.

Some people already warned about this effect, but we're only seeing the impact today.

Now that we've described the problem, the solution is straightforward: companies relying on “invoice parking” must change their process. Simple to say, very hard to do.

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

We wish you fun.