On October 12, 2026, the French Ministry of the Economy reported that 75% of VAT-reporting businesses had appointed an inbound e-invoicing platform. Yet the same assessment identified offer pricing, platform switching and software adaptation among the remaining difficulties. The next management decision is therefore not merely which provider to select, but whether to use one approved platform, split inbound and outbound flows, or orchestrate several providers. The official deployment update shows that this has become an architecture and governance issue.
The choice to be made: a provider or an architecture?
Since September 1, 2026, all French businesses subject to VAT must be able to receive electronic invoices. Large companies and mid-sized companies must also issue them and transmit transaction and payment data through e-reporting. Smaller businesses and micro-enterprises will become subject to these outbound obligations on September 1, 2027, according to the official reform timetable.
Selecting an approved platform, still frequently referred to as a PDP in implementation projects, is not only a feature and price comparison. That initial selection is covered in our article on the criteria for choosing a French e-invoicing platform.
Management must also decide how responsibilities will be distributed:
- which platform receives supplier invoices;
- which platform transmits customer invoices;
- which provider handles transaction and payment e-reporting;
- which system stores the authoritative invoice lifecycle status;
- where users correct rejected invoices and monitor payments.
A business may appoint one or several approved platforms. It may also use different providers for inbound invoices, outbound invoices and e-reporting, as confirmed by the French tax authority’s e-invoicing FAQ. This flexibility should address an actual business constraint rather than create unnecessary contracts and interfaces.
The available options
One platform for all flows
The same approved platform receives supplier invoices, transmits customer invoices and handles e-reporting. The ERP, accounting software or compatible solution sends the required data and retrieves invoices and lifecycle statuses.
This model limits the number of integrations and commercial contacts. It works well when business entities share similar processes and service requirements. However, all regulatory flows depend on one operator, making interface quality, data exports and exit clauses critical.
Separate platforms for inbound and outbound flows
One platform receives supplier invoices, while another handles customer invoices and possibly e-reporting. This can preserve an existing procurement solution while allowing the sales side to use a service better suited to invoice generation, customer statuses or payment monitoring.
The split remains manageable when every data item has a clearly designated system of record. It becomes fragile when accounting teams need several portals to reconstruct the full processing history of an invoice.
Several platforms managed through a compatible solution
Each legal entity, business unit or billing system can retain its own platform. A shared orchestration layer prepares data, applies routing rules and returns statuses to internal applications.
This model can protect existing investments and avoid forcing every entity onto the same tool immediately. It nevertheless requires strong data governance for customer identifiers, company records, formats, statuses and recovery rules.
A compatible solution does not perform the regulatory functions reserved for an approved platform. It must connect to at least one such operator. This is the role of e-Factu, our e-invoicing application: preparing and validating invoice flows, generating Factur-X and connecting business applications to the selected approved platform.
The criteria that actually matter
The levels below are relative. They must be validated against provider contracts, available APIs and the systems that need to be connected.
| Option | Overall cost | Implementation time | Dependency | Internal skills | Reversibility |
|---|---|---|---|---|---|
| One platform | Usually lighter integration, but a concentrated contract | Shortest when the ERP already has a usable connector | High dependency on one operator | Functional ownership and interface monitoring | Good only when invoices, data and statuses can be exported |
| Separate inbound and outbound platforms | Separate contracts and additional reconciliation work | Intermediate, with accounting synchronisation required | Distributed provider risk but more interfaces | Procurement, sales and accounting flow ownership | Reasonable when each provider has an autonomous scope |
| Multi-platform architecture | Higher initial orchestration and monitoring cost | Longest because of routing rules and cross-system tests | Lower commercial concentration but higher architecture dependency | API, master data, architecture and support expertise | High by component but more complex globally |
Licence prices alone are therefore insufficient. The decision must include connectors, monitoring, rejected-flow processing, archive exports, lifecycle status recovery and the accounting team’s workload across different interfaces. This is also why appointing an approved platform does not ensure end-to-end compliance.
Before signing, the finance or IT owner must verify the operator on the official list of approved platforms. Updated on November 3, 2026, the page distinguishes operators that have completed all requirements from those still awaiting final approval after interoperability testing.
When to choose each option
Choose one platform when processes are homogeneous
This option fits organisations whose customer invoices originate from one main system, whose accounts payable process is centralised and whose entities follow similar rules.
Before committing, ask the finance and IT owners to produce a flow matrix. Each flow should be linked to its source system, business owner, approved platform and fallback procedure. The contract must explicitly cover inbound invoices, outbound invoices, e-reporting, lifecycle statuses, attachments, exports and end-of-contract data recovery.
Split inbound and outbound platforms when ownership differs
This scenario is relevant when procurement already has an approved workflow, while sales requires a specific integration with an ERP, CRM or collection process.
The finance director should designate the system of record for the original invoice, regulatory status, commercial dispute, due date and payment. The IT team should document how these systems exchange information and what happens when a status is missing or delayed.
Use several platforms when information-system diversity is permanent
A multi-platform architecture can be justified when several ERPs must remain in operation, entities have genuinely different billing cycles, or business applications cannot connect to the same provider without a disproportionate redesign.
Do not select this model merely because the organisation has several legal entities. If their data can be standardised before transmission, a shared compatible solution connected to one platform may remain simpler. The deciding factor is persistent process and system diversity, not the legal organisation chart.
Decide now if inbound invoices work but outbound flows do not
Being able to receive electronic invoices does not mean the project is complete. Outbound readiness requires structured-data controls, mandatory invoice fields, rejection handling, e-reporting and the return of statuses to accounting systems. Our operational timetable through September 2027 places these decisions in the correct sequence.
The pitfalls of each option
The single-platform pitfall: confusing simplicity with lock-in
A single portal may conceal limited APIs, incomplete exports or separately billed services. The problem often surfaces during an ERP change, an acquisition or a provider migration.
Contracts should specify export formats, recovery of invoices and statuses, migration conditions and service continuity. Reversibility must be testable rather than reduced to a general contractual statement.
The split-platform pitfall: losing the end-to-end view
An invoice may be created in one application, transmitted through a platform, monitored in another interface and reconciled in the accounting system. Without a common identifier and synchronisation rule, users must reconstruct its history manually.
The required deliverable is a lifecycle-status dictionary stating the source, business meaning, internal recipient and expected action for every status used by the organisation.
The multi-platform pitfall: underestimating daily operations
Initial integration is only part of the project. Someone must monitor interfaces, process duplicates, maintain master data and intervene when a flow remains blocked between systems.
IT needs a shared monitoring view, while finance requires an actionable exception queue rather than technical logs. Without this operating model, architecture flexibility becomes recurring administrative work.
How D1 Consulting approaches the decision
Our e-invoicing reform support service starts by mapping inbound, outbound and e-reporting flows. The resulting deliverable connects each flow to its legal entity, source application, business owner, approved platform and system of record.
We then define the target architecture: one platform, a split-flow model or multi-platform orchestration. Each decision is documented through an ownership matrix, an interface diagram and reversibility requirements that can be incorporated into provider contracts.
Acceptance testing uses verifiable scenarios covering issuance, reception, rejection, correction, lifecycle status changes, payment and accounting updates. It also checks that users know which interface to use, without navigating through several portals to diagnose the same incident.
When the ERP or business application does not cover the complete process, e-Factu can provide the operational layer for preparing invoices, generating Factur-X, applying controls and connecting to the chosen approved platform. The platform retains the regulatory role, while e-Factu carries the business logic and supports future reversibility.
👉 Book a free 30-minute diagnostic to obtain an initial recommendation between one platform, split flows and a multi-platform architecture.
