Since September 1, 2026, appointing an accredited platform — still commonly called a PDP — has been essential for receiving electronic invoices in France. Yet the first monitoring committee reported interoperability and invoice-status transmission issues, even though 75% of VAT-reporting businesses had appointed a receiving platform and 20 million invoices had already been exchanged. The figures published in the government’s first deployment review confirm a key distinction: selecting the regulatory rail does not make the entire invoicing process reliable.
The promise everyone hears: “Choose a PDP and you are ready”
The sales message is straightforward: select an accredited platform, sign the appointment agreement, connect your invoicing software and consider the project completed. The platform will supposedly handle formats, routing, tax data, e-reporting and invoice statuses.
This promise has a solid basis. An accredited platform plays a central role in the French system. It sends and receives invoices, extracts the information required by the tax authorities and communicates with other platforms. Accreditation requires operators to satisfy fiscal, security and interoperability requirements, as explained alongside the official list of accredited platforms.
For an SME director, the one-stop-shop proposition is attractive: one contract, one portal and one provider for a complex regulatory obligation. This is why the decision should be based on operational criteria such as those described in our six-point platform selection guide.
The mistake is to confuse the platform with the complete business process.
What is true: the platform provides the regulatory rail
Since September 1, 2026, every business has had to be capable of receiving electronic invoices. SMEs and microbusinesses must also issue electronic invoices and transmit e-reporting data from September 1, 2027. A standard PDF sent by email does not, by itself, satisfy the regulatory definition: an electronic invoice must use an accepted structured format and travel through an accredited platform. The official reform timetable and requirements make this distinction explicit.
The platform can therefore manage technical capabilities that an SME should not attempt to rebuild: access to the central directory, routing to the customer’s platform, regulatory data transmission and interoperability across the ecosystem.
A business may continue using a compatible accounting application, ERP or invoicing solution. However, that software must rely on an accredited platform for the statutory transmissions. The company must also formally appoint its receiving platform, either directly or through an explicit mandate, according to the French tax authority’s practical implementation guide.
The platform is therefore mandatory. But it can only transmit reliable information if your systems and teams provide reliable information.
What is false, or only true under specific conditions
The platform cannot repair source data
The customer’s SIREN identifier, transaction category, VAT-on-debits option and any separate delivery address must be available in the invoicing system. These mandatory fields are presented in the government’s e-invoicing guidance. A platform may detect a missing or inconsistent field, but it cannot decide which legal entity placed the order, received the goods or owes the payment.
Ask your finance team for a customer-master export containing legal identifiers, billing and delivery addresses, payment terms and VAT information. The expected deliverable is not a vague “data quality assessment”, but an anomaly list with a named person responsible for each correction.
E-reporting requires business classification
Domestic B2B sales, consumer sales and international transactions do not follow the same reporting route. Transaction e-reporting covers, in particular, operations involving non-taxable persons and international transactions. Payment e-reporting applies to certain operations for which VAT becomes chargeable upon payment. The relevant BOFiP tax guidance confirms that these requirements apply to SMEs from September 1, 2027.
An accredited platform cannot compensate for an unknown rule in your ERP. Each transaction must be classified by customer type, country, transaction type, VAT regime, deposit status and payment method.
Technical statuses do not automatically manage receivables
Lifecycle statuses create a common language for submission, availability, rejection, approval and payment. Their purpose is to share invoice progress and support interoperability, according to the external e-invoicing specifications.
However, receiving a rejection status does not automatically create a correction task. A payment status is only dependable if bank or accounting information flows back into the process. A commercial dispute must not trigger the same collection action as an administrative delay.
If these concepts remain unclear, start with our guide to Factur-X, e-reporting and lifecycle statuses. Then assign an action, an owner and an internal rule to every status used by your systems.
Accreditation does not cover every operational requirement
A platform may offer archiving, invoice entry, APIs, business controls and multi-entity management. These features are not necessarily included in the regulatory service, compatible with your ERP or easily transferable to another provider.
Your contract should distinguish between statutory functions, additional operational services and integration work. Otherwise, a company may select an attractive entry-level plan before discovering that connectors, testing environments, archiving or data migration belong to separate service packages.
What it costs when you proceed without preparation
Reducing the project to a platform contract usually moves the workload rather than removing it:
- Manual re-entry appears. Invoices are created in the ERP, corrected in the platform portal and manually reconciled with the accounts.
- Errors become harder to locate. A rejection may originate in customer data, a tax rule, a format or an interoperability problem. Without a shared incident log, each provider blames another component.
- Collection activity becomes unreliable. If statuses, disputes and payments do not converge in one process, customers may be chased for rejected or already-paid invoices. We examine this boundary in our article on managing payment reminders after the reform.
- Technical debt becomes tied to one vendor. If approval rules, tax logic and exceptions are configured entirely inside the platform, changing provider means rebuilding part of the operating process.
- The initial tolerance period creates a false impression of postponement. The authorities stated that no penalties would be imposed before the end of 2026, but that approach does not cancel the receiving obligation already in force. The distinction appears in the monitoring committee’s official review.
The reasonable way to proceed
Do not begin with a vendor demonstration. Begin by deciding where reference data, invoices, approvals and payment evidence will be created and maintained. For the broader architecture decision, see our comparison of SME compliance scenarios.
| Principle | Who does what | Required deliverable |
|---|---|---|
| Define the scope | Finance, accounting and sales administration classify purchases and sales by customer type, country, VAT treatment, deposit and payment method. | A scope matrix assigning e-invoicing, e-reporting or an out-of-scope treatment to each flow. |
| Establish a data contract | The ERP owner and accounting team identify which system creates and maintains every regulatory field. | A data dictionary listing the source, format, control rule and correction owner for each field. |
| Allocate responsibilities | The IT lead brings together the business-software vendor, platform, accountant and integrator to assign each processing step. | An architecture diagram and responsibility matrix covering creation, approval, transmission, archiving and correction. |
| Run end-to-end acceptance testing | Business users test B2B invoices, consumer sales, international operations, credit notes, deposits, rejections, payments and cancellations. | A signed acceptance report with transmission evidence and an anomaly log. |
| Prepare daily operations | The finance manager defines how rejected invoices, inconsistent statuses, blocked documents and payment discrepancies will be handled. | A control dashboard, an assigned incident queue and a documented recovery procedure. |
The most useful document to request is not a product brochure. It is a diagram showing the journey of an invoice from creation to payment, with the responsible system at every step. If no one can explain who produces a status, who consumes it and which action it triggers, the chain is not ready.
Our position at D1 Consulting
At D1 Consulting, we see the accredited platform as a regulated transport and tax-exchange layer, not as the natural owner of the entire invoicing process. Customer master data and accounting truth should remain controlled within the company’s business systems. Orchestration rules must be documented and transferable.
e-Factu, our electronic invoicing application, supports Factur-X invoices and connection to an accredited platform. It sits between the SME’s business requirements, management software and the statutory network without claiming to replace the mandatory platform.
Our electronic invoicing reform service covers flow scoping, data quality, architecture, platform connection, acceptance testing and exception management. The objective is not merely to sign a platform contract, but to make the surrounding process operational.
👉 Book a free 30-minute diagnostic: we will review your invoicing chain, source data and the boundary between e-Factu, your ERP and your accredited platform.
