As of 18 August 2026, an SME should no longer select a “PDP” solely because it promises regulatory compliance. France’s Decree No. 2026-677 of 27 July 2026 now uses the term “approved platform” and clarifies the conditions governing platform mobility. Reversibility has therefore become a practical selection criterion rather than a clause to review after signing.
All businesses subject to French VAT must be able to receive electronic invoices from 1 September 2026. SMEs and microbusinesses must issue electronic invoices and transmit applicable e-reporting data by 1 September 2027 at the latest, according to the French tax authority’s guide to approved platforms.
The choice you actually face
The real decision is not “which platform has the longest feature list?” It is “which operating model will fit our invoicing process without creating another information silo?”
An approved platform provides the regulated transmission and receipt of invoices, extracts tax data and sends e-reporting information. Only a provider included in the official list published by the French tax authority can perform these functions directly. An invoicing application or non-approved operator must therefore connect to an approved platform.
Approval is an entry requirement, not a quality ranking. Approved platforms may differ significantly in their interfaces, integrations, pricing models and operational services.
Management should answer four questions before selecting a provider:
- Where will employees create, check and approve invoices?
- How will data move between sales software, accounting and the platform?
- Where will rejections, credit notes, payments and lifecycle statuses be processed?
- How will the company retrieve its data when changing providers?
Our article on preparing an SME for mandatory e-invoicing in 2026 covers the timetable and internal responsibilities. The decision here is narrower: choosing the right platform architecture.
The available options
Option 1 — Use an approved platform’s web portal directly
Employees enter, upload, check and retrieve invoices through the platform interface. This keeps the initial integration project limited when invoicing is straightforward and centralised.
It also introduces another business application. If accounting, CRM or cash-management data must subsequently be re-entered, regulatory compliance is achieved at the cost of a broken process.
Option 2 — Stay within the existing invoicing system or ERP
The business retains its usual interface. Its software provider transfers invoices through an approved platform, either because the provider is approved itself or because it has selected a partner.
This option makes sense when the connector is available, documented and included in a compatible software version. A generic roadmap statement is insufficient. Ask for the platform’s name, the exact flows covered, the delivery schedule and a complete pricing structure.
Option 3 — Add a business application connected to an approved platform
A specialist application sits between existing systems and the approved platform. It can centralise Factur-X generation, controls, approvals, lifecycle statuses, accounting exports and collection workflows.
This architecture avoids replacing an ERP that still performs its other functions correctly. It is also relevant when invoices originate from several systems or when the current software does not adequately cover the new flows.
Option 4 — Build a multi-system or multi-platform architecture
The company orchestrates several applications, legal entities or platforms through APIs and workflows. This option addresses organisations with several ERPs, separate approval paths or a shared finance function.
It provides more control but turns the reform into an integration project. Routing rules, customer master data, lifecycle statuses and errors must be managed as one coherent system.
The criteria that really matter
1. Actual functional coverage
Check receipt, issuance, transaction e-reporting, payment data, credit notes, deposits and lifecycle statuses separately. A “compliant” entry-level package may cover only part of your process.
2. Integration with existing systems
Request the exact list of connectors, available APIs, import and export formats, and synchronisation mechanisms. The decisive test is whether an invoice can be followed from creation to payment without manual re-entry.
3. Exception handling and accounts receivable
Rejections must be understandable and actionable. Check whether statuses can return to your management system and trigger a task such as correcting data, requesting approval or contacting a customer.
4. Total cost
Compare configuration, subscriptions, usage charges, connectors, archiving, test environments, support and exit exports. The advertised price per invoice represents only one component of total cost.
5. Operational service model
Identify who responds when an invoice is rejected or blocked: the platform, the software vendor or the integrator. Require a responsibility matrix, escalation process and access to a test environment.
6. Dependence and reversibility
The July 2026 decree requires platforms to provide free documentation about mobility and regulates directory updates when a business changes platforms. It does not replace a contractual review of export formats, document retention, exit charges and migration support.
The following comparison is indicative and must be confirmed through demonstrations and quotations:
| Option | Total cost to examine | Deployment lead time | Dependence | Internal skills | Reversibility |
|---|---|---|---|---|---|
| Direct portal | Low initial cost, but employee handling time matters | Short | High dependence on the selected interface | Low | Medium if exports are complete |
| Existing software or ERP | Depends on version and connector | Short to medium | High dependence on the vendor ecosystem | Low to medium | Medium, depending on available formats |
| Connected business application | Subscription and configuration versus avoided re-entry | Medium | Shared between application and platform | Medium | Good when interfaces are documented |
| Multi-system architecture | Integration, maintenance and monitoring costs | Longer | Controllable but distributed | High | Good when flows and master data are documented |
When to choose each option
Choose the direct portal when invoicing is handled by a central team, approval rules are straightforward and other systems do not need automatic status updates. Before signing, ask a business user to complete an entire cycle: creation, submission, rejection, correction, credit note and accounting export.
Stay with your current software when its provider can name the approved platform, demonstrate the connector and provide a price covering all relevant flows. Include these commitments in the purchase order rather than relying on a product roadmap.
Add a specialist application when the ERP should remain in place but lacks Factur-X generation, centralised approvals or lifecycle-status processing. It is also suitable for standardising invoices produced by several source systems.
Build a multi-system architecture when several entities, ERPs or invoicing channels must use shared master data. Appoint one owner for routing and produce a matrix showing the source system, platform, expected status and error-handling system for every flow.
An SME that initially needs only to receive invoices in September 2026 can deploy in stages. It should nevertheless define its future issuance architecture now, or its temporary interface may become a constraint during the 2027 rollout.
The pitfalls of each option
A direct portal may relocate work instead of automating it. Hidden costs include duplicate data entry, manual checks and the lack of synchronisation with accounting or accounts receivable.
An integration supplied by the current software vendor may lock the company into a platform or software version. Confirm that changing platforms will not require migrating the entire business application.
An intermediary application can create uncertainty over support responsibilities. The contract should state who corrects data, resubmits rejected invoices and handles synchronisation incidents.
A multi-system architecture can become unnecessarily complex. Without clear data ownership and acceptance scenarios, errors circulate between systems without being assigned to a team.
The selection should not stop at regulatory transmission. Lifecycle statuses can feed accounts-receivable monitoring and collection workflows. Our article about automating overdue-invoice reminders with n8n explains how to handle this process without confusing commercial collection with tax reporting.
How D1 Consulting approaches the decision
Our e-invoicing reform support service begins with a flow matrix covering domestic B2B invoices, international transactions, consumer sales, public-sector invoices, credit notes, deposits and payments. For each flow, the deliverable identifies the source system, regulatory obligation, target format and operational owner.
We then prepare a selection scorecard shared by finance and IT. Shortlisted platforms must demonstrate critical journeys using representative test data rather than simply presenting their product catalogue.
When a company wants to retain its current systems, we can implement e-Factu, our electronic invoicing application, to generate expected formats, organise controls and connect the business process to the selected approved platform. e-Factu does not replace that platform: it provides the business layer between employees, existing software and the regulatory infrastructure.
Acceptance testing covers receipt, issuance, rejections, corrections, credit notes, lifecycle statuses and payment data. The expected outcome is not merely a technical connection, but an operating procedure that assigns every exception to a named role.
👉 Book your free 30-minute diagnostic to obtain an initial map of your invoicing flows and identify which platform architecture your SME should test.
