France e-invoicing: the “authorized platforms” list is out — what ERP teams should do now

France e-invoicing: the “authorized platforms” list is out — what ERP teams should do now

France’s e-invoicing programme is moving from abstract policy into executable delivery. In January 2026, the French administration published the list of registered “authorized platforms” (Plateformes de Dématérialisation Partenaires, or PDPs) that can participate in the upcoming mandate.

If you’re running Dynamics 365 Finance & Operations (or any enterprise ERP) across France, this is the moment to shift your planning from “we’ll pick a provider later” to a concrete design and rollout plan.

1) The platform decision is not an integration decision — it’s an operating model decision

Most organisations treat e-invoicing as a connector: ERP generates invoice, provider sends it, done. France is stricter. You’re not just “sending XML”; you’re adopting an operating model for clearance, status management, rejections, and reporting.

What changes in practice:

  1. Invoices will be accepted, rejected, or require correction based on structured validations.
  2. Status flows (delivered, rejected, accepted, paid) become part of your receivables process.
  3. Disputes and exceptions are no longer “email + PDF”; they are workflow events your ERP team must operationalise.

Pragmatic takeaway: choose a PDP that supports your target operating model, not just your preferred technical stack.

2) Start with exception handling, not the happy path

The happy path demo always looks great. Projects fail in the exceptions:

  1. Customer master data mismatches
  2. VAT/tax code mapping errors
  3. Product/service classification gaps
  4. Address/identity validation issues
  5. Credit notes and cancellations that don’t match the original invoice semantics

In D365FO terms, that means your data quality workstream is not optional:

  1. Validate customer identifiers and addresses at scale
  2. Normalize VAT/tax group logic across legal entities
  3. Define rules for when invoices are “blocked for correction” vs “posted with follow-up”
  4. Build a clear reissue policy (new invoice number vs corrected version) aligned with the PDP flow

Pragmatic takeaway: your “exceptions backlog” is your real project plan.

3) Define the ERP event model: what triggers what

Treat France e-invoicing as an event-driven process. Even if you don’t implement an event bus, you need the mental model.

Minimum event set to design for:

  1. Invoice posted in ERP
  2. Invoice submitted to PDP
  3. Technical acceptance/rejection
  4. Business acceptance/dispute (if applicable)
  5. Lifecycle status updates (delivered/paid)
  6. Credit note issued / cancellation / correction

What to lock down now:

  1. Where statuses are stored (ERP vs integration database vs a compliance hub)
  2. Who owns monitoring (finance ops vs IT vs shared service)
  3. SLAs for rejection handling (e.g., “same day” for blocking errors)
  4. Audit trail requirements (who changed what, when, and why)

Pragmatic takeaway: if you can’t explain your status model on one page, you’re not ready to build.

4) Don’t underestimate the reporting and audit layer

France’s model isn’t just “invoice exchange”; there’s also reporting obligations (often called e-reporting in broader discussions). Even when a provider handles transmission, you still need governance for:

  1. Data retention and evidencing
  2. Reconciliation between ERP, PDP, and bank/cash application
  3. Handling of invoices created outside ERP (portals, marketplaces, manual billing tools)
  4. Internal controls: separation of duties, access to resend/void/correct

Pragmatic takeaway: aim for “reconcilable truth” — you should be able to reconcile invoice counts/amounts by day between ERP and PDP without heroics.

5) A practical 30-day action plan for Dynamics 365 F&O teams

If you want to make progress this month, here’s a realistic sequence.

Week 1: Scope and realities

  1. Identify which French legal entities and invoice streams are in scope (B2B, B2G, export, credit notes)
  2. Confirm current invoice formats and channels (EDI, PDF email, portals)
  3. Document the current “invoice lifecycle” and pain points

Week 2: Data readiness sprint

  1. Profile customer master data (identifiers, addresses, VAT IDs)
  2. Profile product/service classification needs
  3. Identify top 20 rejection causes you’d expect with structured validation

Week 3: Provider shortlisting using the authorized list

  1. Create evaluation criteria: coverage, onboarding speed, monitoring UX, API maturity, support model, cost transparency
  2. Confirm the provider is on the registered list and understand what “registered” means in practice for your timeline

Week 4: Target design

  1. One-page status and exception model
  2. Monitoring and support runbook (who watches what, where)
  3. Integration approach (direct API, middleware, compliance hub)
  4. Test approach: “exceptions-first” test packs

Pragmatic takeaway: by the end of 30 days you should have a clear operating model, a preferred PDP, and a test strategy—not a vague “integration project”.

6) A message for programme leaders: budget for change management

Even with the best platform, the biggest shift is behavioural:

  1. Finance teams will have to act on structured rejections fast
  2. Sales ops may need to fix customer master data at source
  3. IT must provide monitoring and incident response that feels like “core ERP”, not “nice-to-have integration”

If you’re leading a rollout, treat this like a business process change with compliance urgency, not a technical interface.

Final thought

The publication of France’s registered platform list is your cue to move from concept to plan. The teams who win won’t be the ones who build the fastest connector — they’ll be the ones who design the cleanest exception handling and the most reliable reconciliation.