France PPF e-Invoicing Requirements 2026 — A Full Guide to PPF, PDP for Finance, Tax and ERP Teams

Why the French government is doing this — and why it will not back down

The EU loses around €93 billion in VAT revenue every year. Not through sophisticated offshore structures or complex tax planning — largely through simple invoice fraud and process error. Invoices that never existed. Invoices duplicated. VAT claimed on purchases that never happened. The paper and PDF invoice system, which relies almost entirely on trust and periodic audit, has been spectacularly exploited for decades.

E-invoicing fixes this not by asking companies to behave better, but by making it structurally difficult to behave badly. When every invoice flows through a certified platform before reaching the buyer, and that platform reports the transaction to the tax authority in near real-time, the opportunity for manipulation collapses. Italy introduced mandatory B2B e-invoicing in 2019 and recovered billions in previously lost VAT within three years. France has been watching.

This is why the mandate will not be postponed again. The financial case for the DGFiP is overwhelming. Every quarter of delay costs the French state hundreds of millions in unrecovered tax. The September 2026 deadline is real, and the enforcement will follow.

How it actually works

The structure is called the Y-model — named after the shape of the data flow. Your invoice does not go directly from you to your customer anymore. It goes from you to a certified platform (a PDP — Plateforme de Dématérialisation Partenaire), which validates it, routes it to your customer's PDP, and simultaneously reports the transaction data to the DGFiP via the public portal (PPF). The buyer's PDP delivers the invoice, the buyer sends back status updates, and those statuses also flow back through the chain.

The key actors are: the PPF (the public portal — free, basic, operated by the French state), the PDP (certified private platforms — Pagero, Edicom, Basware, Cegedim, and 70+ others), and the Annuaire (the central directory where every French entity must register with their SIRET and PDP routing information so invoices can find them).

The Annuaire is step zero. You cannot send or receive e-invoices until you are registered. It costs nothing. It takes minutes. A significant number of companies reading this in mid-2025 have not done it.

One point that trips up almost every company: the obligation to receive e-invoices applies to everyone from 1 September 2026 — regardless of your own issuance deadline. A company with 30 employees does not need to issue structured e-invoices until September 2027, but if one of their large suppliers hits the September 2026 deadline first, that invoice will arrive as a structured e-invoice and the small company's system must be able to process it. Many small companies do not know this yet.

The mandate also introduces formal invoice lifecycle statuses — Received, Approved, Rejected, Payment Initiated, Payment Received — which must be communicated back through the platform. These are not courtesy notifications. They are legally required responses. Your systems need to be able to generate and send them automatically.

Factur-X, UBL, CII — which format and why it matters less than you think

Three formats are accepted under the French mandate, all conforming to the European standard EN 16931. Factur-X is a hybrid — a PDF/A-3 with an embedded XML layer. The human reads the PDF; the machine reads the XML. It is the most pragmatic choice for companies coming from PDF-based processes because it looks familiar and requires the least cultural change for finance teams and suppliers. UBL 2.1 is pure XML, widely used in PEPPOL-based countries and the natural choice if you are also rolling out in Belgium, Germany, or the Netherlands. CII (Cross Industry Invoice) is another XML standard, common in Germany and used natively by some ERP vendors.

The format debate absorbs an enormous amount of project time and energy that would be better spent on data quality. The format is the container. What matters is what is inside it — and specifically, whether your data is complete, accurate, and structured enough to populate a valid EN 16931-compliant invoice. Most companies discover during testing that their data is not. The format choice becomes irrelevant if the data going into it is wrong.

The trash bin problem

This is the conversation that almost never happens in e-invoicing projects — and it is the one that determines whether you go live successfully or not.

Walk into any large enterprise finance department and ask how invoices arrive. You will get a long list: email attachments in PDF, invoices uploaded to three different supplier portals, EDI files from major suppliers, scanned paper from smaller ones, invoices keyed directly into the ERP by AP staff because the PDF cannot be parsed, Excel spreadsheets for intercompany, expense receipts mixed in with formal invoices, and occasionally — genuinely — still a fax.

All of this works, after a fashion, because human beings are extraordinarily adaptable. An AP clerk who processes 200 invoices a day has developed workarounds, muscle memory, and informal rules that make the chaos function. None of those workarounds survive contact with a structured e-invoicing mandate, because the mandate does not accommodate chaos. Every invoice must be a valid, complete, structured document before it can even enter the platform.

What you are actually doing when you implement France PPF is not installing a new piece of software. You are recycling invoices from a trash bin — sorting through years of accumulated process debt, asking which of it can be cleaned up and which needs to be replaced entirely. The software is the easy part. The recycling is the hard part. And most companies budget for the software and underbudget catastrophically for the recycling.

The companies that fail their go-live are almost never the ones that chose the wrong platform. They are the ones that never sorted the bin.

Accounts Payable — the side everyone focuses on, still gets wrong

AP is usually the first team invited to the e-invoicing project meeting, which gives it a false sense of priority. The truth is that the AP obligation — receiving structured e-invoices — is genuinely simpler than the AR side. Your suppliers will figure out how to send you the invoice. Your job is to be ready to receive it, process it, and send back the right status responses.

Being ready to receive means: registered in the Annuaire, connected to a PDP, AP system configured to ingest structured XML (not just display a PDF), PO matching rules updated to handle structured data fields, and a process defined for the lifecycle statuses you need to send back.

The status response point deserves emphasis. Under the Y-model, when you receive an invoice, you must acknowledge it. When you approve it, you must confirm that. When you reject it, you must reject it formally — through the platform, with a reason code — not by sending an email to the supplier. Your AP team almost certainly does not have a defined rejection process that works this way. Most rejections today are handled by a quick phone call or an email saying "can you resend with the correct PO number." That process does not exist in a structured e-invoicing world.

One more thing AP teams consistently underestimate: archiving. Every invoice — received and sent — must be archived for 10 years from the invoice date, with legally guaranteed integrity. No modifications possible after archiving. Your current document management system may not meet this standard. Check before you assume it does.

Accounts Receivable — the data problem hiding in plain sight

AR is harder than AP because it requires you to produce something, not just receive it. And producing a legally valid French e-invoice requires data that most billing systems currently do not capture, do not capture consistently, or capture in the wrong format.

Every outbound invoice under the mandate must include: the SIRET of both the issuer and the buyer, VAT numbers for both parties, the invoice type code (380 for a standard invoice, 381 for a credit note, 384 for a corrected invoice), delivery address, payment terms and due date, VAT breakdown by rate and by line, the nature of goods or services, and the transaction category. Look at your current invoice output and count how many of these fields are reliably populated. In our experience, most billing systems are missing at least four.

The SIRET issue alone is a significant project. You need a valid SIRET for every French customer on every invoice. If you have 800 French customers, you need 800 SIRETs — validated, current, and stored in your CRM or ERP customer master. Some of those customers will have changed their SIRET due to restructuring. Some will never have had one entered. Collecting and validating that data is not a half-day task.

Then there is the e-reporting obligation, which most AR teams discover late. Transactions that are not covered by e-invoicing — B2C sales, exports, intra-EU services to non-French entities — must be reported to the DGFiP via the PPF within 10 calendar days of the transaction. This is a separate, parallel obligation running alongside your e-invoicing implementation, with its own penalty structure (€250 per missing submission). It requires a separate process and a separate data flow. It is not handled automatically by your PDP. Many companies build their entire e-invoicing project plan without a single line item for e-reporting, then discover it four weeks before go-live.

The payments team — invited last, blamed first

Ask the project manager of any e-invoicing implementation which teams are in the room from day one. You will hear: AP, AR, IT, Tax. Ask when the payments team joined. You will usually hear a pause, then something like "we brought them in for UAT."

This is a serious structural mistake — and it is almost universal.

The France PPF mandate introduces mandatory payment status reporting. When your company initiates a payment against an invoice, that event — Paiement transmis — must be communicated back through the PDP to the invoice issuer. When payment is confirmed received — Paiement reçu — that too must be reported. These are not optional. They are legally required statuses in the invoice lifecycle.

In practice, this means the payment event in your treasury system or ERP payment run must trigger a status update in your PDP. In most organisations, these two systems have never talked to each other in this way. Your treasury management system, your bank connectivity, and your payment file formats may all need changes before this works. None of that is in scope for a typical e-invoicing project plan — because the payments team was not in the room when the plan was written.

Bring the payments team in from week one. Not week twelve.

ERP complexity — what the vendor demo never shows you

Every PDP vendor will tell you they integrate with SAP. This is true. What it does not tell you is whether they integrate with your version of SAP, your enhancement package level, your country-specific configuration, your custom ABAP developments from 2009, and your particular way of mapping document types and number ranges — all of which determine whether the integration works cleanly or requires three months of custom development.

The demo environment is perfect. Your environment is not. The demo environment has clean master data, standard configuration, and no twelve-year-old customisations. Your environment has all three, and the gap between the two is where implementation projects quietly die.

SAP ECC 6.0 — still the most common ERP in European enterprises — is the most challenging. SAP's native e-invoicing tooling is designed for S/4HANA. ECC customers typically need a middleware layer, a certified third-party connector, or a clear migration timeline to S/4HANA before their e-invoicing implementation can begin. Many organisations discover this three months into an implementation that assumed native connectivity.

Oracle and Microsoft D365 users face similar challenges at different points. D365's Electronic Reporting framework gives reasonable flexibility but requires country-specific configurations that need to be built, tested, and maintained. Oracle Fusion has better native support; on-premise Oracle instances are a different story entirely.

The worst scenario — and more common than it should be — is a multinational running different ERPs in different countries. SAP in France, Oracle in Germany, a local system in Poland. Each one needs a separate integration to the PDP. The PDP's promise of a single platform for all countries is real at the platform level; it is not real at the ERP integration level. Budget and plan accordingly.

Master data — the silent killer of every go-live

If you asked us to identify the single factor most likely to cause an e-invoicing go-live failure, it would not be the wrong platform choice, insufficient budget, or late project start. It would be master data.

Specifically: missing, incorrect, or outdated SIRET numbers.

The SIRET is how the PPF Annuaire routes invoices between parties. Without a valid SIRET for your customer on an outbound invoice, the PDP cannot route it. The invoice fails at the platform level before it ever reaches the buyer. For incoming invoices, if your supplier does not have your correct SIRET in their system, their invoice cannot find you. None of this is visible until you run your first test transaction.

A typical large enterprise with significant French operations has between 500 and 2,000 French vendors in their master data. Some percentage of those — in our experience, consistently between 20% and 40% — have SIRET issues. Missing entirely. Entered incorrectly. Outdated because the supplier restructured. Duplicated across vendor records. The same supplier appearing three times under slightly different names with different SIRET formats.

Cleaning this up is not a technical project. It is a manual, labour-intensive data exercise that requires someone to go through the vendor master record by record, validate each SIRET against the INSEE database (sirene.fr), contact suppliers whose data is wrong or missing, and update the records. For 500 vendors with a 30% error rate, that is 150 records that need manual intervention. Budget time for it.

The same problem exists on the customer side for AR. Every French customer in your system needs a valid, current SIRET before you can issue them an e-invoice. This means going back to customers — sometimes customers you have invoiced for ten years — and asking for data they may not immediately know how to provide. Some will not understand why you need it. Some will give you the wrong number. Start this early.

And once you have done the cleanse — build the governance to keep it clean. Every new supplier, every new customer, must have SIRET validation at the point of onboarding. Otherwise you will be back in the same position in eighteen months.

Intercompany — the stream nobody thought about

Intercompany invoicing is the e-invoicing stream that most project teams discover last and understand least. The typical conversation goes: "We have covered AP, AR, and Tax. Are there any other streams?" Pause. "What about intercompany?" Longer pause.

Intercompany invoices between French legal entities — or from a French entity to a foreign group entity that holds a French VAT registration — are subject to the mandate. If both parties are French VAT registered, it is an e-invoicing obligation. If one party is French and the other is foreign without French VAT, it is an e-reporting obligation. Most groups have not mapped their ICO flows with this distinction in mind.

The more significant problem is that most intercompany invoicing in large groups runs on processes that cannot be plugged into a PDP. Excel spreadsheets, email attachments, shared drives, manual journal entries in the ERP that produce no formal invoice document at all. These need to be rebuilt in the ERP's intercompany module before any e-invoicing integration can work. That is not a small project.

There is also a transfer pricing dimension that Tax needs to think about carefully. E-invoices create a real-time, verifiable audit trail of intercompany transactions that is now visible to the DGFiP. If your intercompany pricing, your transfer pricing documentation, and your actual e-invoice data are inconsistent — even slightly — you have created an audit risk that did not exist when ICO invoices lived in a shared drive that nobody outside the group ever saw. Group Tax and Transfer Pricing need to be involved in the ICO e-invoicing design, not informed about it afterwards.

Expenses — a grey area that is not as grey as people think

Employee expenses sit in an area of genuine confusion. The key distinction is simpler than it appears once you understand it.

Consumer receipts — a restaurant meal, a taxi, a coffee at the airport — are B2C transactions. The mandate does not apply to them. An employee can still submit a paper receipt or a scanned PDF for reimbursement. Nothing changes.

But invoices addressed to your company from a French B2B supplier — a hotel billing your legal entity directly, a car rental company, a training provider, a professional services firm — these are B2B transactions and will be sent as structured e-invoices through the supplier's PDP once they hit their issuance deadline. If your expense management system only processes PDFs or scanned receipts, it has a gap.

More importantly: from September 2026, a PDF invoice received from a French B2B supplier is not a legally valid document for input VAT reclaim purposes. If an employee submits a PDF hotel invoice after the supplier's issuance deadline, your VAT reclaim on that expense is at risk. This is not a hypothetical — it is a direct consequence of the mandate that most expense teams have not been told about.

Ask your expense platform vendor when you are having the next conversation: is their roadmap PPF-compliant for receiving e-invoices addressed to the company? The honest answer from most of them, as of mid-2025, is "we are working on it."

Tax — who actually owns this

The France PPF mandate is fundamentally a tax initiative dressed up as a process change. It exists to give the DGFiP real-time visibility into every B2B transaction in France. And yet, in a remarkable number of implementation projects, the Tax team is involved late, consulted occasionally, and never given formal ownership of the outcome.

Tax needs to own three things specifically: the e-reporting obligations, the archiving requirements, and the VAT return implications going forward.

The e-reporting obligation — reporting B2C sales, exports, and cross-border transactions to the DGFiP within 10 days — is a Tax obligation. It requires a data source, a reporting process, a transmission mechanism, and an ongoing monitoring process. Building it is an IT project; owning it is a Tax responsibility. These two things need to be clearly separated and assigned.

The 10-year archiving requirement is not IT housekeeping. It is a legal obligation owned by Tax. The archive must be unalterable, accessible for audit, and retrievable at the request of the DGFiP at any point within a decade. Who in your organisation is responsible for ensuring that SLA holds in year 8? That question needs an answer before you go live, not after.

On VAT returns: with the DGFiP now receiving near real-time invoice data, the era of undetected discrepancies between your VAT filing and your actual transaction data is ending. Inconsistencies that previously surfaced in a tax audit three years later will now be visible within weeks. Tax teams that have relied on the gap between filing and audit to manage timing differences need to plan for a different operating environment.

Choosing a PDP — the decision that gets too much attention

Companies spend enormous amounts of time and energy on platform selection. RFPs with 200-line questionnaires. Demo marathons. Scoring matrices. Weeks of internal debate. And then they sign a contract and spend the next six months discovering that the real work — process redesign, data remediation, ERP integration, master data governance — had nothing to do with which platform they chose.

The platform decision matters. But it is not the most important decision in an e-invoicing project. The most important decisions happen before you open a single vendor conversation.

With that said, here is what actually distinguishes platforms once you get past the marketing:

On vendor neutrality: Lumara does not receive referral fees or commissions from any platform. When we recommend Pagero over Edicom, or Basware over Cegedim, for a specific client — it is because of the client's ERP, their volume, their multi-country footprint, and their team structure. Not because of a commercial relationship. We mention this because it is genuinely rare in this market, and because the number of consultants who will steer you toward their preferred vendor while claiming neutrality is higher than you might expect.

Timeline — the honest version

The version you will hear from most vendors: "We can have you live in twelve weeks." This is technically possible in a greenfield scenario with a simple ERP, clean master data, and a dedicated internal team. It describes almost no large enterprise in existence.

The realistic timeline for a complex organisation — multiple entities, SAP ECC, messy master data, multiple countries — is six to nine months from first assessment to stable go-live. Broken down roughly:

Assessment and scoping (3–5 weeks). Map every invoice flow. Audit master data. Define scope across all streams. Identify the ERP integration approach. This phase cannot be rushed — what you find here determines every other decision.

Platform selection (4–8 weeks). RFP, demos, contract negotiation. Four weeks if you are decisive and have done the assessment properly. Eight weeks if you have not.

ERP configuration and integration (8–14 weeks). The most variable phase. Clean SAP S/4HANA with standard content: 8 weeks. SAP ECC with custom developments and three countries: 14 weeks or more.

Master data remediation (runs in parallel). Start immediately. Do not wait for the ERP configuration to be complete. Every week you delay the master data exercise is a week added to your overall timeline.

Testing (4–6 weeks). Unit testing, integration testing, end-to-end testing with real suppliers. Budget more time than you think you need here. The issues you find in testing are the issues that would have caused go-live failures.

Go-live and hypercare (4 weeks). Monitor everything. Exceptions will happen. Have a clear escalation process and a dedicated resource for the first month.

Total: 23 to 37 weeks. If you are reading this in the first half of 2026 with a September deadline, you are in a difficult position. Not impossible — but you need to make decisions this week, not next month.

This guide reflects our practical experience working on e-invoicing implementations across France, Poland, Belgium, Germany, and the UAE. It is updated as the DGFiP publishes new technical specifications. For the official regulatory text, refer to impots.gouv.fr and the PPF portal at portail-facturation.dgfip.finances.gouv.fr. This guide does not constitute legal or tax advice. © 2025 Lumara Advisory. All rights reserved.