e-invoicing transaction data

E-Invoicing Just Made Your Actuals Machine-Readable. Your Forecast Should Notice.

Anthony Barbey

Anthony Barbey

· 11 min read

Share

E-Invoicing Just Made Your Actuals Machine-Readable. Your Forecast Should Notice.

On 1 September 2026, France's business-to-business e-invoicing mandate took effect. Every VAT-subject company established in France must now be able to receive electronic invoices, and large companies and mid-caps must issue them. Small and medium enterprises follow in September 2027. Belgium has been live since January, Poland since February, Germany requires receiving since 2025, and the EU's ViDA directive puts intra-Community transactions on a single European standard by July 2030.

Almost everything written about this is about compliance: which platform to pick, what the penalties are, whether your invoicing tool is accredited. Fair enough, that is the urgent question, and there is a tolerance period through the end of 2026 while everyone sorts it out.

The interesting consequence is somewhere else, and nobody is talking about it. For the first time, an entire continent is being obliged to emit its commercial transactions in a structured, machine-readable format, with a timestamped lifecycle attached to each one. If you build forecasts for a living, that is not a compliance event. It is the arrival of the data layer you have been faking for your whole career.

What actually changed under the hood

Two obligations were created, not one.

The first is the invoice itself. It has to travel in a structured format, one of Factur-X, UBL or CII, through an accredited platform (in France, a plateforme agréée, previously called a plateforme de dématérialisation partenaire). Factur-X is the interesting one for finance teams because it is a hybrid: a human-readable PDF with the structured XML embedded in the same file. The document a person reads and the record a machine parses stop being two different artefacts that drift apart.

The second obligation is quieter and matters more. It is called e-reporting, and it requires transmitting transaction data and payment data to the tax administration, covering the operations that fall outside the invoicing mandate: sales to consumers, and dealings with foreign operators. So the reform does not just standardise invoices between businesses. It pushes an entire company's transaction flow, plus the payment events attached to it, into a defined format on a defined cadence.

Alongside the document, each invoice carries lifecycle statuses as it moves through the platform. Vendor documentation across the accredited platforms consistently describes fourteen possible statuses, of which four are mandatory: deposited, rejected (an anomaly caught by the platform), refused (a business dispute raised by the customer), and collected, this last one applying to service provision, where VAT falls due on payment rather than on delivery. The rest, including payment sent, approved, partially approved, disputed and suspended, are recommended rather than required.

Hold on to that distinction between mandatory and recommended. It is the whole point of this article, and we will come back to it.

Why a forecaster should care

Here is what reconciling actuals looks like today, in almost every finance team, at every size.

Your model says revenue for August was 412k. Your accounting system says 419k. Someone spends a morning finding out why. The answer is usually some combination of a credit note issued late, an invoice dated on the wrong side of a month end, a customer who was billed in two instalments where the model assumed one, and a rounding convention nobody documented. The number gets fixed. The reason it was wrong gets forgotten. Next month, the same morning is spent again.

This is not incompetence. It is the predictable result of a structural gap: the forecast lives in one artefact, the transactions live in another, and nothing connects a line in the model to the events that produced it. Bridging that gap is manual archaeology, so it gets done once a month at best, and only at aggregate level.

A mandated structured invoice with a mandated lifecycle closes that gap, at least in principle. Revenue for August stops being a number you reconcile and becomes a set you can enumerate: these invoices, with these dates, these amounts, these customers, in these statuses. A variance stops being a delta to explain and becomes a list of specific transactions to look at. Drill-down to source, the thing every planning tool promises and almost none deliver, becomes possible because the source finally exists in a form a machine can read.

And it gets better for the specific case of a services business, which covers most of the consultancies, agencies and software companies I work with. Because VAT falls due on payment for service provision, the collected status is mandatory for them. The date the money actually arrived becomes a required, machine-readable field on the invoice lifecycle. Days sales outstanding stops being an estimate derived from bank reconciliation and becomes a computation over primary data. So does the collection curve you feed into a cash forecast.

That is a genuinely new capability, and it arrived by legislation rather than by product.

The trap: the mandate standardises the document, not your access to it

Now the part that will decide whether any of this is real for you.

The mandate obliges your platform to move a structured invoice and to report a minimum set of statuses to the administration. It says nothing whatsoever about whether you can read your own data back out, on demand, programmatically. Nothing requires an accredited platform to expose an API. Nothing requires it to surface the lifecycle statuses to you rather than merely transmit them onward. Nothing requires it to let you export at transaction level rather than as a monthly PDF.

Worse, the statuses that matter most for forecasting are precisely the optional ones. The compliance minimum tells you an invoice was deposited, and possibly rejected or refused. That is enough for the tax authority. It is close to useless for a cash forecast. What you want is payment sent, approved, disputed, suspended: the events that tell you when money is actually going to move and which receivables are at risk. Those are recommended, not mandatory. Whether you get them depends entirely on the platform you happen to have chosen.

So the reform creates a magnificent standardised dataset and leaves your access to it as a vendor feature.

I went looking at what the official registry says about this, and the answer is nothing. The list of accredited platforms published as open data on the French government portal carries the commercial name, the website, the registration date and a contact address. There is no field for programmatic access, no field for supported formats, no field for which lifecycle statuses the platform exposes. One hundred and thirty seven platforms in the June dataset, and the one dimension that determines whether you can build on them is not recorded anywhere.

Every comparison of accredited platforms I could find ranks them on compliance features, sector fit and price. None of them ranks the criterion that matters if you intend to do anything with the data.

The five questions to ask your platform

Since nobody publishes this, here is the list I would send to any accredited platform before signing. It is short on purpose, and each question is answerable with a link to documentation or a no.

1. Is there a documented API that returns invoices at transaction level, and where are the docs? Not an export button, not a monthly file drop. A documented endpoint you can call. If the answer involves a sales call, that is a no.

2. Which lifecycle statuses do you expose to me, and specifically do you expose the recommended ones? Ask by name: payment sent, approved, disputed, suspended. The four mandatory statuses are table stakes. The recommended ones are the product.

3. Do you push status changes, or must I poll? A webhook on status change is the difference between a forecast that reflects reality and one that reflects last Tuesday. Ask for the event name.

4. Can I get the structured payload, not just the rendered PDF? Factur-X carries the XML inside the PDF. Some platforms will hand you the whole thing, some will hand you a rendered document and keep the structure. You want the structure.

5. What is my exit? You are about to route every commercial transaction your company makes through this vendor. Establish, in writing, how you get the full history out, in what format, and how long it takes.

Two accredited platforms already answer these publicly, which is worth noting because it shows the questions are answerable. Pennylane documents e-invoicing status on both customer and supplier invoices, a method to update the lifecycle status of a received invoice, and a webhook event for status changes. Qonto exposes an einvoicing_status property on its client invoices endpoint, and generates Factur-X. Both have public developer documentation you can read without talking to anyone, which is itself the answer to question one.

If your platform cannot answer these five, you have bought compliance and sold your data access. That trade is worth making consciously rather than by accident.

The uncomfortable part, for the Americans in the room

There is a story that European regulation kills innovation while American markets create it. On this specific topic, the opposite is happening, and it is worth sitting with.

By September 2027, a French mid-market company will have, as a legal obligation, structured transaction records and payment lifecycle events on every business-to-business invoice it sends or receives. So will a Belgian one, a Polish one, an Italian one, and by 2030 the whole intra-EU flow will run on one European standard. That is a continent-wide, vendor-neutral, machine-readable financial substrate, created by decree.

The best part is that Europe did not set out to build it. EU law used to forbid this. Article 232 of the VAT Directive made the use of an electronic invoice conditional on the recipient's acceptance, which meant no member state could impose one unilaterally. France had to apply to the Council of the European Union for a derogation, and got it in January 2022, from Articles 218 and 232. Only then could the French instruments be written. Three years later the ViDA directive removed the acceptance requirement outright, so the obstacle Brussels had created was also removed by Brussels, and the same directive then set 2030 as the date it becomes compulsory across the union.

Blocked, then authorised by exception, then made mandatory. Nobody designed that arc as industrial policy for AI-driven finance. It is the by-product of a VAT-fraud enforcement programme. The substrate is real anyway.

An American company has none of that. Business-to-business invoicing in the United States runs on PDF email, paper cheques, ACH, and a dozen incompatible portals. There is no federal mandate and no serious prospect of one.

The honest objection is that American companies do not need a mandate because their software already does it. Ramp, Bill.com, Brex and their peers deliver structured payables data with better product design than any accredited platform will manage. That is true, and it is a real counterargument. But it is voluntary, per-vendor and partial. It gives you structured data about the transactions that happen to flow through the tool you bought. It does not give you a standard your counterparties are also obliged to speak, which is the thing that makes data interoperable rather than merely tidy. Coverage by adoption is not coverage by definition.

So the paradox stands. The bloc with the reputation for strangling innovation is the one accidentally building the foundation that AI-driven finance actually needs, because the useful thing was never the software. It was the standard.

If you are building finance tooling, or buying it, that asymmetry is going to matter for the next decade. European finance teams are about to be able to answer questions about their own transactions that American ones cannot, not because their tools are better, but because their data has a shape.

What to do in the next month

Nothing about this is urgent in the compliance sense. The tolerance period runs to the end of 2026, and your accountant is already on it.

What is worth doing now, while the platform decision is still open or still reversible, is running the five questions above. Platform choice is the moment your data access is decided, and it is being decided almost everywhere on criteria that ignore it entirely. Once every transaction your company makes is routed through a platform that hands you a PDF, the mandate will have made your data structured for the tax authority and left it opaque to you.

The forecast that traces to the transaction is finally buildable. Whether you get to build it is a procurement decision you are probably making this quarter.

Figures and dates in this article are collected with their sources on our e-invoicing mandate statistics page.

Anthony Barbey

Anthony Barbey · Founder, Layerz

Anthony spent his career in finance and consulting, close to the modeling workflows of M&A, transactions, and advisory. He now builds Layerz, the finance workspace that keeps Claude in the context of your model so it doesn’t drift, forget between sessions, or burn tokens on grids.

Related articles

Ready to build models that are defensible by design?

Layerz separates model structure from data so every number is traceable.

Explore Layerz