In Eight Days Your French Invoices Become API Calls. Nobody Told Your Engineering Team.

Why Did Invoicing Turn Into an Integration Project?

For thirty years an invoice was a document. You generated a PDF, you attached it to an email, and somebody at the other end read it with their eyes or ran it through OCR and corrected the fields the OCR got wrong. Both ends tolerated an enormous amount of ambiguity, because a human was always available to resolve it. Wrong entity on the header? Someone notices. Missing purchase order reference? Someone chases. The format was prose with numbers in it, and the error-handling layer was people.

What is replacing that across Europe is not a nicer PDF. It is a structured message, in a mandated semantic model, exchanged over a defined network, addressed with a defined identifier scheme, acknowledged with machine-readable lifecycle statuses, and in several countries cleared through a government platform before it is legally an invoice at all. The tax authority is no longer an auditor who might look at your records in three years. It is a participant in the transaction, sometimes a synchronous one.

The calendar is what makes this urgent rather than interesting. Belgium made structured e-invoicing compulsory for domestic B2B on 1 January 2026, with Peppol BIS BILLING 3.0 as the mandated default format and the Peppol network as the transmission method. Poland's KSeF became mandatory on 1 February 2026 for taxpayers whose 2024 turnover exceeded PLN 200m, on 1 April 2026 for other VAT-registered businesses, and on 1 January 2027 for micro-entrepreneurs. France arrives on 1 September 2026. Germany requires structured issuing from 1 January 2027 for businesses above EUR 800,000 of turnover and from 1 January 2028 for everyone. Spain's Verifactu certified-software regime slipped again, with Royal Decree-Law 15/2025 moving corporate income taxpayers to 1 January 2027 and everyone else to 1 July 2027.

Above all of it sits ViDA, the VAT in the Digital Age package, which was adopted in March 2025 and makes EN 16931-compliant e-invoicing mandatory for intra-Community transactions from 1 July 2030, with domestic regimes required to converge by 2035. That last date matters more than it looks. It means the national mandates arriving now are not twenty-seven permanent snowflakes. They are twenty-seven divergent implementations of a standard that will be forced back together, which is a strong argument for how you architect the thing you build this year.

The reason this lands badly in most organisations is organisational rather than technical. It arrives through the finance function, gets a tax owner, and gets budgeted as a vendor selection. Then somebody reads the specification and discovers that the deliverables are master data cleanup, XML generation, an asynchronous state machine, API authentication against a government endpoint, and an exception queue with money attached to every item in it. By that point the deadline is a quarter away and the engineers who would do it are committed to the roadmap.

What Actually Changes on 1 September in France?

France imposes two separate obligations on two separate schedules, and conflating them is the single most common planning error. The obligation to receive electronic invoices is universal and starts on 1 September 2026: every business in scope, regardless of size, must have designated an approved platform and be capable of receiving structured invoices through it. The obligation to issue is phased, landing on large enterprises and mid-sized companies on 1 September 2026 and on SMEs and micro-enterprises on 1 September 2027. Large means above 5,000 employees or above EUR 1.5bn of turnover; the intermediate category runs from 250 to 5,000 employees.

For domestic B2B, paper and ordinary PDF stop being invoices. The permitted formats are the EN 16931-compliant structured ones: UBL 2.1, CII, and Factur-X, the French national hybrid. Factur-X deserves a sentence of its own for engineering purposes, because it is a PDF/A-3 file with an EN 16931-compliant XML payload embedded inside it. You are not generating a document with some metadata attached. You are generating two synchronised representations of the same commercial fact, and the one your customer's accounts payable team looks at is not the one that carries legal and fiscal weight.

Transmission runs through an approved platform, the plateforme agréee, which is what the earlier plateforme de dematerialisation partenaire was renamed to. The state portal was scaled back and no longer acts as a free universal exchange: the public portal maintains the central directory of SIREN and SIRET routing data and acts as the concentrator that collects invoicing and reporting data from the platforms. Your invoice goes from your system to your platform, across to your counterparty's platform, and onward to them, while a defined set of lifecycle statuses travels back.

Then there is the third obligation that gets forgotten because it is not called e-invoicing. E-reporting covers the transactions that fall outside the domestic B2B flow: B2C sales, cross-border transactions, and payment data. It is a different dataset on a different cadence to a different endpoint, and it is a separate build.

The penalties are not catastrophic in isolation and are dangerous in aggregate. Non-compliant invoices attract EUR 50 per invoice with an annual cap of EUR 15,000, and failed or incorrect e-reporting transmissions attract EUR 500 each under a separate EUR 15,000 cap. Failure to register with an approved platform at all gets a warning and three months, then a EUR 500 fine, rising to EUR 1,000 after a further three months. The tax administration has signalled that it will not apply automatic penalties in the fourth quarter of 2026 and will assess each company's trajectory individually. Read that as it is written: it is a tolerance for organisations that can demonstrate a real implementation in progress, not a grace period for organisations that did nothing.

Why Is the Readiness Number This Bad Eight Days Out?

The public readiness picture in France is worse than any deadline this close should permit. An estimate from the e-invoicing lead at the accountancy firm In Extenso, reported as around three in ten businesses yet to register with a platform, is exactly what it says it is, an informed estimate across a very heterogeneous business population rather than a measured census. Treat it as an order of magnitude and it still says the same thing.

The figure that should worry engineering leaders more comes from the supply side. As of June 2026, only 21 approved platforms were actively sending e-invoicing flows and just four were sending e-reporting flows, while roughly a quarter of France's largest billing organisations had still not selected a platform. A market with four live e-reporting providers is not a market that has absorbed the volume it is about to receive, and the organisations that pick a provider in the last month will be onboarding alongside everyone else who did the same.

The reason the timeline slipped in so many companies is that the work presents itself as a procurement decision. Choose a certified provider, sign, done. That framing is comfortable and wrong, because the provider is a pipe. It will faithfully transmit whatever your systems hand it, including invoices carrying an unvalidated SIRET, a routing code your counterparty does not recognise, tax codes that map to the wrong EN 16931 category, or a Factur-X file whose embedded XML disagrees with the human-readable page above it. The platform will not fix any of that. It will transmit it and return a rejection.

There is a second-order effect that catches out companies who believe they are out of scope for another year. The receiving obligation is universal from September, which means every one of your French customers now has a structured channel and an increasing institutional preference for using it, and every one of your French suppliers will start pushing structured invoices at you whether or not you have built anything to consume them. An unhandled inbound flow does not produce a compliance breach on day one. It produces an accounts payable backlog nobody planned for.

The recommended runway for this class of work is not short. A standard implementation roadmap suggests allocating at least six to nine months to cover testing, data accuracy, stakeholder engagement and training. Anyone starting France now is not running that plan; they are running triage, and the correct triage is to get receiving working first, because that is the obligation that binds universally on 1 September.

What Does Your Engineering Team Actually Have to Build?

Strip away the tax vocabulary and five concrete workstreams remain, none of which a platform vendor delivers for you.

The first is master data, and it causes more failures than everything else combined. Every counterparty needs a validated legal identifier, in France a nine-digit SIREN and frequently a fourteen-digit SIRET identifying the specific establishment, plus whatever routing suffix decides which branch of a large customer actually receives the document. Most ERPs hold this data in a free-text field that has been maintained by hundreds of people over a decade, with trailing spaces, defunct entities, head-office numbers standing in for branch numbers, and duplicates. Validating and deduplicating that dataset is unglamorous, has no demo, and is on the critical path for everything downstream.

The second is format mapping. Your ERP's invoice model has to be projected onto the EN 16931 semantic model, and the interesting part is never the header fields. It is tax categories, exemption reason codes, allowances and charges at line and document level, unit codes, rounding behaviour, and multi-currency handling. Each of these is a place where a mapping that passes schema validation still expresses the wrong commercial fact, and schema validation is the only automatic check you get.

The third is the lifecycle state machine, and it is the one most ERPs are structurally unprepared for. The French model requires the exchange of a defined sequence of statuses, covering deposited, sent, received, approved or rejected, payment due and payment done. Your system is now consuming asynchronous callbacks about documents it has already emitted, and it has to reconcile them against its own state, surface them to humans, and act on them. A great many ERP implementations model an invoice as having two interesting states, sent and paid. Retrofitting a real state machine onto that, with idempotent handlers and out-of-order delivery, is a systems problem, not a configuration screen.

The fourth is e-reporting, which is a genuinely separate pipeline over B2C, cross-border and payment data with its own cadence and its own failure modes. The fifth is rejection handling, and it is the one that decides whether this project is judged a success. A rejected invoice is not a failed API call to be retried at leisure. It is a receivable that does not legally exist, aging quietly in a queue. That queue needs an owner, an alerting threshold, a resolution path back into the ERP, and a reporting line to somebody who cares about days sales outstanding.

Why Doesn't the French Build Work in Poland?

Because the three countries that went live within eight months of each other chose three different architectural models, and the differences are not cosmetic.

Poland runs a clearance model. The invoice is submitted to the national KSeF platform, and it is legally issued at the moment the platform assigns it a number. The tax authority is in the synchronous path. The technical surface is correspondingly specific: the Ministry of Finance published the KSeF 2.0 API documentation as an OpenAPI 3.0.4 specification alongside the final FA(3) invoice schema, with FA(3) replacing FA(2) on 1 February 2026 and defined offline issuance modes requiring QR codes to establish authenticity. Authentication moves too: KSeF certificates became available to apply for in late 2025 and replace tokens from 1 January 2027. That is a credential rotation with a deadline, in a system where an authentication failure means you cannot invoice.

Belgium runs an interoperability model. There is no central clearance; invoices travel over the four-corner Peppol network in Peppol BIS BILLING 3.0, and the European Commission's own guidance is blunt that Peppol is the default and no single party can unilaterally derogate from it. The state is not in the path today, but it will be: Belgium is scheduled to move to near-real-time VAT reporting through a five-corner Peppol model around 2028, which is the same architectural shift France has already made.

France sits between the two, with accredited private platforms doing the exchange, a state directory doing the addressing and a state concentrator collecting the data. Germany, arriving in 2027, is closer to Belgium's posture with XRechnung and ZUGFeRD as its national formats.

The engineering conclusion is the useful part. If you build three point-to-point integrations, one per country, you will build a fourth for Germany, a fifth when Belgium adds reporting in 2028, and you will rebuild all of them as ViDA forces convergence toward 2035. The alternative is the boring one that works: a single canonical internal invoice model expressed in EN 16931 semantics, with thin per-country adapters handling transport, authentication, schema dialect and status vocabulary. The first country costs more that way. Every country after it costs dramatically less, and there is a documented pattern of organisations that spent six months per country under the old model completing rollouts in quarters rather than years once the integration layer is built once. The Peppol network's own ViDA pilot exists precisely because the destination is a shared model rather than a permanent patchwork.

Can an AI Coding Agent Just Do This?

Partly, and it is worth being precise about which part, because the honest answer changes how you staff the work rather than whether you staff it.

Coding agents are genuinely good at the bulk of this. Generating typed bindings from an XSD, scaffolding a client from an OpenAPI document, writing the hundred mapping functions between an ERP field and a semantic element, producing test fixtures for two dozen invoice shapes, drafting the retry and backoff logic: this is high-volume, well-specified, pattern-dense code, which is exactly where agentic tooling earns its cost. A team that refuses to use it here is choosing to pay for typing.

Where it fails is where this project actually fails. The ground truth for a mandate lives in a government sandbox and a specification that changed three times this year, not in a training corpus. An agent asked to implement Polish e-invoicing will confidently produce something for FA(2), because FA(2) is what most of the material written about KSeF describes, and FA(2) stopped being the schema in February. It will produce a plausible SIRET routing implementation without knowing which of your customer's forty establishments should receive the document, because that is a commercial fact held by your account managers rather than a technical one held anywhere.

The deeper problem is the shape of the feedback loop. Most software gives you forgiving failure: a bug ships, a user complains, you fix it, nobody counts. Here the failure is a rejected invoice that is not legally an invoice, discovered a week later by someone reconciling receivables, with a statutory clock and a payment term attached. Conformance against the real sandbox, deliberate negative testing of every rejection path, and a human who understands why a tax category is what it is are not optional overhead. They are the work.

The split we use on this kind of engagement is straightforward: let the agents write the volume, and put senior engineers on the canonical model, the state machine, the conformance suite and the failure paths. That is not an AI-scepticism position. It is the recognition that the expensive defects in an integration project are semantic, and semantic defects are precisely the ones that pass every automated check you have.

What Does Day Two Look Like?

The most expensive planning mistake is treating this as an event with an end date. It is a rolling calendar, and the calendar does not stop when you go live.

Look at what is already scheduled. Poland's micro-entrepreneurs join in January 2027 and its authentication model changes to certificates on the same date. Germany's issuing obligation lands on companies above EUR 800,000 in January 2027 and on everyone in January 2028. Belgium adds transactional reporting in 2028. France finishes its own phase-in in September 2027. Spain's certified-software regime arrives for corporate income taxpayers in January 2027. Intra-Community e-invoicing on EN 16931 becomes mandatory in July 2030, and domestic regimes have to converge by 2035. Somebody has to own a compliance-driven backlog continuously across that span, and it will compete with your product roadmap every single quarter, because it always looks deferrable right up until it is not.

There is an operational dimension too, and it is sharper in clearance countries than most teams appreciate. The EY alert on the Polish mandate makes the consequence explicit: failure to comply means losing the ability to issue valid sales invoices, which hits cash flow directly. That is not a compliance finding written up in an audit report next year. That is an incident, in the middle of a business day, in a European timezone, that requires an engineer who understands the integration, a finance person who understands the invoice, and a decision within hours rather than days.

Which is why the support model matters as much as the build. An integration whose failure mode is unbilled revenue needs people awake in the same working day as the tax administration whose platform just returned an unexpected status code, and it needs those people to be the ones who wrote it. A rotating pool of contractors who delivered a France go-live and left cannot triage a schema change in Poland eighteen months later, because the knowledge that makes triage fast is the knowledge of why the mapping was built the way it was.

Who Owns Work That Sits Between Finance, the ERP and Engineering?

This work has a characteristic organisational failure mode. It belongs to nobody. Tax owns the obligation but cannot build. The ERP team owns the system of record but treats the mandate as an external integration. Engineering owns integrations but has never read a VAT directive and is fully committed to the product roadmap. So it gets a project manager, a vendor, and a steering committee, and the actual construction is done late, by whoever is available, under time pressure, which is the reliable recipe for the semantic defects described above.

It also has an unusual property that makes the staffing question easier. Almost none of the artefacts expire. A validated counterparty master data set, a canonical EN 16931 invoice model, a conformance test suite that runs against real sandboxes, an exception queue with ownership and alerting: all of these remain valuable when the next country is added, when a schema version increments, and when ViDA reshapes the landscape at the end of the decade. They are also the same artefacts that make an audit survivable and a due diligence process quick. Build them once, properly, and each subsequent mandate is an adapter and a test run.

That is the shape of engagement Stepto is built around. We put senior engineers in Serbia onto a product rather than a ticket queue, working Central European hours that overlap the full European business day, which is the window in which a rejected invoice batch in Warsaw or an unexpected status from a French platform actually has to be resolved. Working inside the European regulatory perimeter means EN 16931, GDPR and data residency are constraints our engineers already operate under rather than requirements to be translated for them, and a dedicated team that stays with the system through the 2027 and 2028 waves accumulates exactly the context that makes each subsequent country cheap.

On sequencing, the practical advice depends on where you are. If France is in scope and you have not started, the only rational plan for the next eight days is receiving: designate an approved platform, get inbound structured invoices landing somewhere a human can process them, and document the implementation trajectory you are on, because the administration has said it will assess trajectories individually and a documented plan is materially better than silence. Issuing follows, properly, on a real timeline. If your exposure is Germany in 2027, you have the runway to do this the right way round, which means building the canonical model first and treating Germany as the first adapter rather than the whole project.

The one option that is not available is waiting to see how it settles. It settles in 2035, and there are five mandate waves between here and there.