France’s new e-invoicing regime provides a useful preview of what businesses will face as mandatory e-invoicing spreads across Europe. An invoice can fail for many reasons, and not all of them have much to do with invoicing.
France distinguishes between an invoice that is rejected (Rejetée – status 213) by a platform because it fails required controls and one that is refused (Refusée – status 210) by the customer for a business reason after receipt. The distinction sounds technical, but it exposes a much bigger problem.
What exactly constitutes a successful e-invoice?
There is more than one type of validation
An invoice might contain perfectly correct VAT but fail because of its format or missing mandatory data. Another may pass technical validation and reach the customer, only to be refused because the purchase order is wrong. And an invoice can successfully pass through the entire e-invoicing network while still applying the wrong VAT treatment.
So e-invoicing increasingly creates several tests:
Technically valid ≠ correctly routed ≠ commercially accepted ≠ VAT correct.
More importantly, responsibility for those tests is scattered across the organisation.
IT and the “Approved Platforms“, Plateforme agréée ‘PA’ may own the XML format and transmission. Finance may be responsible for invoice data. Procurement controls purchase orders and supplier information. Master-data teams maintain customer identifiers. Tax determines whether VAT should have been charged, at what rate and under which exemption or reverse-charge rule.
The customer can then introduce another layer of validation before agreeing to pay.
An invoicing error is becoming an operational problem
Under traditional invoicing, many errors could be identified and corrected during accounting or VAT return preparation. E-invoicing moves that validation much further upstream.
A technical failure can prevent an invoice reaching the customer. Incorrect master data can stop it being routed correctly. A commercial refusal can delay payment. A VAT error may pass the first two tests but subsequently create a discrepancy between the e-invoice, accounting records and VAT return.
That turns what looks like a tax-compliance project into an order-to-cash and procure-to-pay issue. Poor e-invoicing data can affect compliance, accounts receivable, cash collection and customer relationships at the same time.
France is an early warning; but e-reconciliation to the rescue
France is particularly interesting because its model makes the invoice lifecycle visible. Submitted, rejected, received, refused and paid are no longer simply events buried inside two companies’ accounting systems. They become structured digital statuses moving through the e-invoicing infrastructure.
Other European models will differ, but the underlying problem will not. As e-invoicing and ViDA digital reporting develop, businesses will increasingly have to get transaction data right before it leaves their systems.
This is why VAT determination cannot sit at the end of the process. At VATCalc, we increasingly see determination, e-invoicing and e-reconciliation as parts of the same transaction lifecycle. The VAT treatment can be tested before invoicing, while the resulting e-invoice can later be reconciled against the accounting transaction and VAT return.
The important lesson from France is therefore not how to fix a rejected XML file. It is that “valid e-invoice” is becoming a much more complicated concept than businesses expected.
Passing one validation test does not mean the invoice is right.
