What changes on September 1
Three separate obligations share the date, and they apply to different populations:
| Obligation | Who | From |
|---|
| Receive structured e-invoices | Every business subject to French VAT | September 1, 2026 |
| Issue structured e-invoices (domestic B2B) | Grandes entreprises and ETIs | September 1, 2026 |
| Issue structured e-invoices (domestic B2B) | PME and micro-enterprises | September 1, 2027 |
| E-reporting (B2C and cross-border transaction data) | Phased with the issuing waves | September 1, 2026 / 2027 |
The asymmetry in that table is the part that catches teams out. An SME has a year of slack on issuing, but zero slack on receiving: its large suppliers are mandated issuers from day one, so structured invoices arrive in September whether the SME is ready or not. Reception readiness is the universal deadline.
The reform also changes the invoice itself. Four mentions become mandatory on French invoices: the buyer's SIREN, the delivery address when it differs from the billing address, the nature of the transaction (goods, services, or both), and the VAT-on-debits option mention where the seller has elected it. If your invoice data model has nowhere to put these, that is a schema migration to schedule now, not in August.
The delivery model: PDPs and the directory
Under the reform, domestic B2B invoices do not travel by email. They are exchanged through PDPs (Plateformes de Dématérialisation Partenaires), platforms registered with the tax administration that transmit documents between trading partners, manage invoice lifecycle statuses (deposited, rejected, refused, payment received), and report tax data to the administration. The public portal, originally planned as a free exchange platform, was scaled back in 2024 to a central directory (annuaire) and data concentrator, which means in practice: every business needs a PDP relationship for transport.
Routing works through the directory: recipients are registered by SIREN/SIRET, and your PDP resolves where to deliver each invoice. Two engineering consequences follow. First, your customer master data needs reliable SIREN/SIRET values, because they are now routing keys, not just legal trivia. Second, a PDP runs acceptance checks on the documents it transports, so a malformed Factur-X does not fail quietly in an inbox; it bounces with a rejection status your billing team has to handle. That is why validation appears in the checklist as a gate before submission rather than a nice-to-have.
B2G is the exception to all of this: invoices to the public sector continue through Chorus Pro exactly as before, and Factur-X remains an accepted format there.
Checklist A: receiving invoices (everyone, September 1, 2026)
A1. Contract a PDP and get registered in the directory. This is a commercial and administrative step with lead time, not a code change: platform selection, contracting, and directory registration by SIREN. If this has not started, it is the critical path.
A2. Ingest all three socle formats. Incoming invoices may be Factur-X (hybrid PDF), UBL, or CII, and you do not control which your suppliers choose. One intake endpoint normalizes all of them: POST /v1/extract/json parses the embedded XML of a hybrid PDF, or a standalone UBL/CII file, deterministically into one InvoiceDocument JSON shape for your ERP or accounting import. What the supplier declared is exactly what you book, and your code handles one schema instead of three.
A3. Keep a lane for the stragglers. Foreign suppliers and transitional cases will keep sending plain PDFs for years. POST /v1/parse/json reads those with AI into the same JSON shape, with per-area confidence scores so certain reads book automatically and uncertain ones go to review. Same pipeline, two entry points; the extraction and AI parsing references cover both.
A4. Handle lifecycle statuses. The reform makes invoice status a managed object: your systems should be able to accept or refuse an incoming invoice through your PDP and record the status trail. Plan where refusals live in your AP workflow.
A5. Archive the original. French rules require the invoice to be retained in its original form for the statutory period (up to ten years under commercial law). Archive the received file itself, not just the booked data; a Factur-X conveniently archives as one self-contained document.
Checklist B: issuing invoices (grandes entreprises and ETIs now, everyone within a year)
B1. Close the data gaps. Audit your invoice data model against the EN 16931 fields plus the four new mentions. The recurring gaps in practice: buyer SIREN (goes in buyer.legalRegistration with SIRENE scheme code 0002), seller intra-community VAT number, delivery address as a distinct field, and the transaction-nature classification. Missing data is the top cause of late-stage failures, because no generator can invent a SIREN.
B2. Generate a socle format, validated. For most issuers that means Factur-X at the EN 16931 profile: the only core format your customer can also open as a PDF. One call does the whole document:
curl -X POST https://api.invoicexml.com/v1/create/facturx \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d @invoice.json \
--output facture-facturx.pdf
The response is a finished PDF/A-3 hybrid with the embedded factur-x.xml, totals and the VAT breakdown computed from your line items, already validated against the EN 16931 rule set and the French business rules before it leaves the server. Data that cannot produce a compliant invoice is refused with the violated rules listed as structured findings, so nothing broken ever reaches a customer or a PDP.
B3. Gate every outgoing document with validation. If any invoices enter your pipeline from other systems, run them through POST /v1/validate/facturx before PDP submission. The verdict comes back as JSON findings with rule ids and field paths, including the French rule layer, which turns a would-be PDP rejection into a fixable error message inside your own workflow. The online validator runs the identical check interactively for spot checks.
B4. Wire the lifecycle in both directions. As an issuer you consume statuses too: rejected, refused, payment received. Decide now which statuses drive dunning and revenue recognition, and where they land in your billing system.
B5. Keep B2G on its existing rails. Chorus Pro submission continues unchanged, and the same Factur-X pipeline serves it. No separate generation stack needed.
Checklist C: e-reporting
The mandate's quieter sibling covers what e-invoicing does not: B2C sales and cross-border transactions. For those, businesses transmit transaction and payment data to the administration via their PDP, on the same phased calendar as the issuing obligation. The developer takeaway is scoping, not panic: identify which of your revenue flows fall outside domestic B2B e-invoicing, and confirm with your PDP how their reporting feeds expect that data. If all your revenue is domestic B2B, e-reporting may touch you barely or not at all; if you run B2C or export flows, it needs an owner before September.
Checklist D: engineering hygiene
D1. Put compliance in CI. One test that generates an invoice from representative data and asserts the validation verdict pins your entire field mapping. Run it on every build; it catches the schema drift and rounding edge cases that otherwise surface as September rejections. Every per-language guide below includes a ready-made version of this test.
D2. Test the ugly cases, not the happy path. Mixed VAT rates (20% alongside 5.5% or 10%), line discounts, credit situations, zero-rated and exempt lines. The EN 16931 totals rules are where hand-rolled pipelines fail, and the API computing the breakdown from your lines is what makes those cases boring.
D3. Do not hardcode the specification. The reform's technical artifacts are still moving: specifications and rule sets have been revised repeatedly on the road to September, and they will keep evolving after it. This is exactly why the compliance layer belongs server-side: the current FNFE-MPE and EN 16931 artifacts are live behind the API the day they take effect, with nothing for you to monitor, no library update to wait for, and no redeploy. Your integration is finished when it works; tracking the moving target is our job, backed by professional support when a finding needs a human.
D4. Confirm data-protection posture. Invoice flows carry SIREN numbers, IBANs, and customer relationships. InvoiceXML processes every document statelessly: in memory, purged on response delivery, nothing stored, nothing logged, no training on your data. Worth a line in your DPO's records now rather than a scramble later.
| Situation | Format | Endpoint |
|---|
| Default: customers expect an openable invoice | Factur-X (EN 16931 profile) | /v1/create/facturx |
| Fully automated B2B exchange, UBL-based stack | UBL | /v1/create/ubl |
| CII-native trading partners | CII | /v1/create/cii |
| French public sector (unchanged) | Factur-X via Chorus Pro | /v1/create/facturx |
All three socle formats carry the same EN 16931 semantics and the API accepts the same invoice JSON for each, so this is a per-customer routing decision, not an architecture decision. Factur-X is the sensible default because it degrades gracefully: the customer whose automation is not ready in September can still open the PDF, while the one whose automation is ready books the XML. The naming footnote worth knowing: Factur-X is technically identical to Germany's ZUGFeRD, so the same integration covers German customers by swapping the endpoint.
Where the API fits (and where it does not)
Honesty about the boundary makes the architecture obvious. Transport is the PDP's job: delivery to your trading partner, directory routing, lifecycle status exchange, and the administration's data feeds all run through the registered platform you contract. The document layer is ours: generating compliant Factur-X, UBL, or CII from your data, validating anything before it goes out or after it comes in, and turning received documents into normalized JSON your systems can book. The two meet at a simple contract: what you hand your PDP has already passed the official rules, and what your PDP hands you becomes data in one call.
That split is also the argument for not building the document layer in-house five weeks before the deadline: PDF/A-3 conformance, roughly 200 EN 16931 business rules, the French rule layer, and a specification that is still being revised are a poor fit for a Q3 side project, and every revision after September would be your maintenance forever. As an API, it is one HTTP integration that stays current by itself. That is the complete compliance service, and it is why the checklist above contains no item that says "implement Schematron".
Pick your language
Every item in checklists A and B has a full implementation walkthrough with working code in your stack:
Building on Microsoft's stack instead? The Business Central guide and the Power Automate guide cover the same pipeline without leaving your ERP, and the Salesforce guide does it from Flow and Apex.
Get started
Five weeks is enough if the sequence is right: PDP contracting first (longest lead time, least engineering), intake pipeline second (universal obligation), issuance third (mandated for the large, valuable for everyone), CI test last to freeze it all in place.
Create a free InvoiceXML account → get 100 credits for free, no credit card required.
Related resources:
InvoiceXML is a REST API for European e-invoice compliance covering Factur-X, UBL, CII, ZUGFeRD, XRechnung, and Peppol profiles. Stateless processing, GDPR compliant by architecture, and callable from any stack in minutes.