The reform does more than define how an invoice must be transmitted. It also forces companies to decide where invoice processing, due dates, disputes and collection reminders should be managed. On 12 October 2026, the French government reported that 75% of VAT-reporting businesses had designated a receiving platform, while interoperability and invoice-status transmission issues were still disrupting automated processes. The Ministry’s first deployment review therefore confirms that choosing a platform does not automatically solve accounts-receivable management.
The decision you actually need to make
An accredited platform must transmit and receive electronic invoices, extract regulatory data and handle e-reporting flows. Only an accredited platform may perform all these regulated functions on behalf of a business, as explained in the French tax authority’s description of accredited platforms.
This does not mean that the platform should become your collection cockpit. The actual decision is to determine which system is authoritative when answering the following questions:
- Was the invoice transmitted and made available successfully?
- Has the customer rejected it or raised a dispute?
- Which contractual due date applies?
- Has a full or partial payment been matched?
- Who should contact the customer, using which message?
- Which event must suspend an automated reminder?
Lifecycle statuses provide structured information about invoice processing. They do not replace the customer ledger, bank reconciliation or promise-to-pay management. Payment e-reporting also applies specifically to transactions for which VAT becomes due upon collection, according to the tax guidance published on 30 September 2026.
This article therefore does not repeat our comparison of overall e-invoicing compliance scenarios. It addresses a narrower operational choice: where should the accounts-receivable cockpit sit once the accredited platform is connected?
The options available
Option A — Manage reminders from the accredited platform
Some platforms offer monitoring dashboards, notifications and reminder features in addition to regulatory transmission. Finance users then work mainly within the platform’s portal.
This option reduces the number of visible applications. It works best when the platform actually contains the contractual due date, outstanding balance, relevant contacts and dispute information.
Option B — Keep the ERP or accounting system in control
The platform transports invoices and returns their statuses. The ERP or accounting software remains responsible for due dates, payments, credit notes and ageing reports.
This preserves the finance team’s existing working environment. However, it requires a bidirectional connector. Sending an invoice is not enough: the company must retrieve relevant statuses and stop reminders when another system records a payment, rejection or dispute.
Option C — Manage customer interactions from the CRM
The CRM becomes the working environment for sales representatives or account managers. It displays the amount due, customer conversations and collection tasks, while accounting remains the source of financial truth.
This architecture is useful when collection depends heavily on customer relationships, deliverable approval, credit-note negotiations or finding the right contact. It requires reliable synchronisation so that sales teams never see an outdated balance.
Option D — Add a dedicated accounts-receivable layer
An application or workflow receives data from the ERP, platform statuses and CRM information. It applies reminder rules, distributes tasks, logs actions and sends results back to source systems.
In this architecture, e-Factu, our electronic invoicing application, supports compliant invoice preparation, Factur-X and accredited-platform connectivity. Reminder and collection workflows can then be orchestrated separately, avoiding confusion between regulatory transmission and customer-credit policy.
The criteria that really matter
The following levels are relative. They must be confirmed against supplier contracts, available interfaces and the actual condition of your information system.
| Option | Cost | Implementation time | Dependency | Internal skills | Reversibility |
|---|---|---|---|---|---|
| Accredited platform | Low if features are included; variable for additional modules | Short when all required data is already available | High dependency on the platform | Finance configuration and functional administration | Medium: rules and history may remain captive |
| ERP or accounting system | Medium with an existing connector; higher with custom development | Medium, including return-flow testing | High dependency on the ERP and integrator | Accounting, interfaces and master-data management | Medium to good if data can be exported |
| CRM | Medium because financial data and contacts must be synchronised | Medium to long depending on CRM data quality | High dependency on the commercial data model | CRM, finance and access-right management | Good if accounting remains the financial source |
| Dedicated layer | More visible initial investment, with costs separated from business-software licences | Medium, including rule design and exception testing | Distributed across several components | Architecture, automation and monitoring | Good if rules and interfaces are documented |
Licence price should not be the only deciding factor. Each supplier should demonstrate how invoices, statuses, reminder logs, contacts and configured rules can be exported. This requirement complements our six criteria for selecting a French e-invoicing platform.
Which option fits which situation
Choose the accredited platform as the cockpit if invoicing is concentrated in a simple application, payments are easy to match and the platform can export reminder data. The administrative manager should request a written matrix listing available data, triggering events and migration options.
Keep the ERP or accounting software at the centre when it already holds contractual due dates, credit notes, partial payments and ageing information. The finance manager should require an end-to-end test covering invoice issuance, returned statuses, payment and reminder cancellation—not merely a connector demonstration.
Use the CRM as the working environment when account managers must resolve disputes before collection begins. Accounting must remain the owner of the outstanding balance, while the CRM receives timestamped data and assigns an accountable task.
Add a dedicated layer when several applications issue invoices, entities apply different policies or exceptions consume a significant share of administrative work. The expected deliverable is a rule catalogue covering due dates, channels, ownership, suspension conditions, escalation and evidence retention.
If your immediate priority is compliant invoice issuance, start with our electronic invoicing reform service. If late payments are also in scope, treat regulatory connectivity and automated invoice reminders as separate but coordinated workstreams.
The traps in each option
The platform trap: confusing delivery with payment
A status confirming that an invoice was transmitted or made available does not prove that the correct customer department has approved it. Nor does it confirm that the due date is undisputed. Hidden costs appear when finance teams must reconstruct conversations across several portals or lose their history when switching providers.
The ERP trap: treating the connector as a completed process
A connector may transmit an invoice correctly without returning the statuses required for collection. Acceptance testing must cover rejection, refusal, credit notes, partial payments, duplicates and customer-identifier changes. Our guide to Factur-X, e-reporting and lifecycle terminology helps teams define these events consistently.
The CRM trap: displaying outdated debt
A sales representative who contacts a customer after payment damages the relationship. Conversely, an informal sales comment must not suspend collection indefinitely without an owner or review condition. The hidden cost is manual reconciliation between CRM and accounting records.
The dedicated-layer trap: automating the wrong triggers
A poorly designed rule can send duplicate messages or chase a disputed invoice. Each automation must include exclusion conditions, a business owner, an execution log and a manual recovery procedure. Our article on automating invoice reminders with n8n explains which components should remain separate.
How D1 Consulting approaches the decision
We first ask the finance department to designate the source of truth for each item: invoice, regulatory status, due date, dispute, customer contact and payment. The deliverable is a matrix linking each data item to its owning system, responsible person and update rule.
Our team then tests interfaces against explicit acceptance scenarios: successful transmission, rejection, refusal, credit note, partial payment, dispute and platform change. The deliverable is an acceptance protocol listing blocking defects and approved workarounds.
We configure e-Factu for electronic invoice production, Factur-X and accredited-platform connectivity, before implementing reminder workflows in the selected layer. Every rule receives a trigger, stopping condition, recipient, owner and verifiable audit trail.
The purpose is not to impose another application. It is to separate three responsibilities clearly: regulatory invoice transmission, the accounting truth of the outstanding balance and the execution of customer interactions.
👉 Book your free 30-minute diagnostic to receive an initial map of your invoice-status-payment process and identify the right cockpit for your accounts receivable.
