l0grisk intelligence · english

// analysis

The great e-invoicing toll, 5/5: when the pipe breaks

Illustration for the analysis: The great e-invoicing toll, 5/5: when the pipe breaks
Editorial illustration for this analysis.

Audits, pilot, registry, incidents and degraded operation: what France has proved about mandatory e-invoicing, and what remains unpublished.

dated revision: August 22, 2026French originalprimary sourcesno tracker

On 1 September 2026, every business within the French VAT system must be able to receive electronic invoices through an approved platform. The system’s security will no longer be judged only by the quality of its rules. It will be tested by the first widespread rejection, compromised identity, correlated outage and restoration to an accurate accounting state.

France has built substantial defences. It has yet to publish all the evidence Parliament, businesses and researchers need to measure their real-world resilience.

This investigation followed the removal of the direct public service, the multiplication of approved platforms, the boundaries of free plans and the readers of an invoice. The fifth and final part asks what remains after everything is connected: what happens when the flow degrades?

Key points

  • The framework requires ISO/IEC 27001 certification, operation of the information system in the European Union, no extra-EU transfer of hosted service data, and SecNumCloud qualification when a cloud provider is used.
  • Interoperability tests are a condition of final registration. The initial compliance audit report may still be filed up to one year after registration and must review at least one month of subsequent activity.
  • The DGFiP registry, updated on 19 August, contains 148 platforms in its main list and 18 complete applications awaiting tests. But the published list does not show, for each platform, when its approval expires or whether its initial audit has been filed.
  • The national pilot began on 26 February 2026. The official pages reviewed describe its aims, while l0g found no quantified public results on them by 22 August.
  • The go-live guide protects payment continuity. It also requires companies to document incidents, control an alternative channel, prevent duplicates and regularise the flow.
  • DGFiP incidents in February and August 2026 demonstrate the reality of identity and authorised-access risk. No public evidence reviewed links them to electronic invoicing, the PPF, its directory, its concentrator or an approved platform.
  • Aggregate results, audit status, recovery tests, critical dependencies, exit conditions and the division of liability still need to be published.

What approval already requires

Registration is more than a marketing declaration.

Article 242 nonies B of Annex II to the French General Tax Code requires security documentation, ISO/IEC 27001 certification covering the service, commitments concerning EU operation and data transfers, technical documentation, authentication controls and interoperability tests. When a cloud provider is involved, the platform must provide the reference or a copy of its SecNumCloud qualification. If qualification is still in progress, that evidence may be provided with the initial audit report.

In written answers published on 4 August 2026, the government presents the distributed model as protection against a single point of failure. It also cites security approval of state systems, end-to-end and penetration tests, incident management, backup, restoration and access logging.

The rules are demanding on paper. They still do not show what load has actually been sustained, how long recovery takes, what data might be lost or how a customer would change platforms in an emergency.

The audit runs on several clocks

The words “approved platform” combine controls that do not all occur on the same day.

The framework in force since 29 July 2026 allows the initial compliance report to be filed during the year following registration. Article 41 septies A of Annex IV says this audit must cover at least one month of activity after registration. When it identifies non-compliance, the announced corrective period may not exceed three months after the report is filed.

A surveillance report must then be filed by the end of the second year. Renewal, requested before the three-year registration expires, includes a new compliance audit, followed by two surveillance audits during the first two years of the renewed cycle.

The control stages for a French approved platformRegistration, interoperability tests, the initial audit, surveillance audit and renewal follow distinct timetables.APPROVAL RUNS ON SEVERAL CLOCKSRegulatory schedule, not the status of an individual platform.REGISTRATION AND TESTSApplication, security, ISO 27001 and interoperability.The tests condition final registration.BY THE END OF YEAR ONEInitial compliance audit report.At least one month of activity after registration.Announced correction period: three months at most.BY THE END OF YEAR TWOSurveillance audit report.It targets substantial changes since the previous audit.At least one month within the final six-month period.RENEWAL AFTER THREE YEARSA new compliance report accompanies the request.Surveillance follows during the next two years.PUBLIC QUESTIONWhich report was filed, when, and which reservations were closed?Sources: CGI Annex II, Arts 242 nonies B and C; Annex IV, Art. 41 septies A. Accessed 22 August 2026.

In plain terms, a platform may receive final registration before filing its complete initial audit report. This does not mean the platform is non-compliant, that it faced no prior control or that it has yet to file its report. The registry should simply make the position of each application clear.

148 platforms, but no clear view of their audits

The DGFiP page modified on 19 August 2026 publishes two lists. They contain:

  • 148 platforms in the list of operators meeting the conditions, including interoperability tests;
  • 18 operators with a complete and compliant application, still awaiting those tests.

This update corrects the previous count of 147 and 16 in part two, which used an earlier version of the list.

Article 41 septies B of Annex IV says the public list must include the approval’s expiry date, its status and, where applicable, the outstanding initial audit report. Yet the published list does not make those details clear for each platform. A business owner can check that a name appears, but not when its approval expires or where its initial audit stands.

DGFiP can answer that question directly by publishing those three details for every operator.

The public pilot still lacks measurable results

The AIFE says the pilot started on 26 February 2026. Its B2B e-invoicing page states the objectives: test real-world exchanges, secure the ramp-up and prepare participants.

By 22 August 2026, l0g had found no public report on those pages, the DGFiP pilot announcement or linked official documents giving exchanged volumes, success rates, latency, rejections, duplicates, incidents, resolution time or restoration results.

That does not mean the metrics do not exist, that no test took place or that no business participated. It means businesses and Parliament cannot see the results. An aggregate report would answer the question without exposing sensitive details.

At a minimum, mandatory infrastructure deserves results on:

  1. platforms and businesses that were actually active;
  2. invoices and lifecycle events exchanged;
  3. sustained load and tested peaks;
  4. success, rejection and retransmission rates;
  5. resolution times;
  6. restoration, failover and correlated-outage exercises;
  7. gaps opened, fixed or accepted before go-live.

Two recent intrusions raise the evidence threshold

On 18 February 2026, the French Finance Ministry announced illegal access to the national bank-account register, FICOBA, using a civil servant’s impersonated credentials. The statement estimated that 1.2 million accounts may have been affected.

On 14 August, the same ministry documented another intrusion using impersonated credentials belonging to a DGFiP agent and an authorised third party. Investigators had established access to or extraction of data concerning 678,000 individuals and businesses. The CNIL, notified of the breach, said on 18 August that its checks were under way.

These cases concern DGFiP systems and access. No public evidence reviewed links them to electronic invoicing, the PPF, its directory, its concentrator or an approved platform. Treating them as evidence that the reform has been compromised would be false.

The connection to this investigation lies elsewhere: both intrusions used compromised legitimate credentials. Security therefore also depends on controlling authorised accounts and provider access. In its Cyber Threat Overview 2024, in the section on supply-chain attacks, ANSSI had already described the growth of provider compromises used to reach customers indirectly.

A distributed model reduces concentration in one gateway. It may still share dependencies: cloud infrastructure, identity, support software, exchange networks, libraries or administration providers. A count of brands is therefore not automatically a count of independent failure domains.

When an outage becomes the company’s workload

The DGFiP practical go-live guide provides an important economic safeguard. A temporary outage should not stop activity, the processing of a real transaction or payment. An alternative channel can maintain continuity when the expected flow is unavailable.

In return, the company must preserve statuses and errors, contact the relevant parties, link the copy to the initial invoice, prevent duplicate payment, booking, deduction or reporting, then transmit or regularise the same invoice after service recovery.

The continuity path during an electronic invoicing incidentA company identifies the incident, preserves evidence, notifies parties, opens a continuity channel when needed, prevents duplicates, regularises and closes the case.DEGRADED OPERATION IN SEVEN STEPSMaintain activity while keeping one accounting reality.1. IDENTIFYFlow, invoice, period, statusand the symptom actually observed.2. PRESERVEErrors, timestamps, tickets,statuses and relevant exchanges.3. NOTIFYPlatform, vendor, provider,customer or supplier as required.4. MAINTAINAlternative channel if needed,copy linked to the original invoice.5. LOCKOne reference invoice,no duplicate processing.6. REGULARISESame invoice, required data,reconciliation after recovery.7. CLOSEDate recovery and reconciliation,retain evidence and follow-up actions.CONTROL POINTCommercial continuity and later compliance must converge on one transaction.Source: DGFiP practical guide, questions 5, 6 and 13 to 29. Accessed 22 August 2026.

l0g turned that guidance into a local incident log so a small business can apply it. The tool requests no invoice and sends no data. It generates a text file the business can retain in its own document system.

// local continuity log

Document an e-invoicing incident

Prepare a chronological record based on the DGFiP go-live guide. Nothing leaves your browser and nothing remains after the page is closed.

browser only

Privacy: Do not enter login credentials, bank details or personal data. Use a minimal internal reference.

Continuity checklist
Method source: DGFiP practical guide, questions 5, 6 and 13 to 29.

The standalone incident log can remain open during an outage.

What a business cannot compare

The registry says which platforms are approved. It does not say:

  • how long the service may remain unavailable;
  • how quickly it must restart and how much data may be lost;
  • when customers must be notified;
  • when restoration and failover were last tested;
  • which dependencies are shared by several brands;
  • how a customer can retrieve data and change provider during an outage;
  • who bears cash losses, duplicate processing and regularisation costs.

Answers may exist in contracts, audit files, internal plans or insurance policies. They remain scattered and difficult to compare even as platform use becomes mandatory.

Publishing service levels, exercise dates and attestations would not require disclosure of system architecture, vulnerabilities or trade secrets.

Twelve questions for the government

Two written questions, no. 16415 and no. 16666, received answers on 4 August. The government describes the safeguards it has planned. The following questions remain open.

  1. How many platforms have filed their initial audit report by 1 September 2026, and how many remain within the legal filing period?
  2. Which report dates, reservations, corrective actions and closure dates can be published for each platform?
  3. Why does the public list not show, for each platform, the expiry date and status required by Article 41 septies B?
  4. What volumes, success rates, latency, rejections and incidents did the pilot measure?
  5. Which load, restoration, corruption, failover and correlated-outage tests were performed?
  6. Which common availability, recovery-time and data-recovery commitments apply to platforms and state systems?
  7. How many platforms share an engine, cloud, identity provider or critical subcontractor?
  8. Which accelerated procedure applies when a platform or its support engine becomes unavailable for an extended period?
  9. Which incidents must be reported to businesses, DGFiP, CNIL and ANSSI, and within what time limits?
  10. Which emergency export is guaranteed so customers can continue, reconcile and move provider?
  11. Which insurance and liability rules cover cash losses, duplicate processing and regularisation costs?
  12. Which opinions, impact assessments and security reports can be published before full rollout?

None of these questions presumes a failure. They ask only that the stated guarantees can be verified.

Ten days to show the system is ready

The first general reception deadline is ten days away.

The point is not to delay the reform on the strength of a hypothetical scenario. It is to ask, before the switch, for the information the state would demand from any essential operator: test results, audit status, recovery times, the fallback procedure and a clear division of responsibility.

Those elements can still be published: the pilot report, audit status, recovery commitments and the procedure allowing a business to retrieve its data or change provider in an emergency.

Parliament has tools to obtain this evidence: written questions, hearings, information missions, budget scrutiny and document requests. Business owners, accountants, engineers and citizens can find their representative on the National Assembly website and send these twelve questions.

Trust does not come from an “approved platform” logo. It comes from knowing what the logo covers, what remains to be checked and what happens when the pipe breaks.

Method, limitations and main sources

Cut-off date: 22 August 2026. The counts of 148 and 18 come from the two DGFiP lists modified on 19 August and accessed on 22 August.

The search for pilot results covered the cited AIFE and DGFiP pages and accessible linked documents. It does not cover internal material or confidential exchanges with platforms. The registry analysis uses the version published on 22 August; the list may be corrected later. Cyber incidents provide context for access risk, never evidence of an electronic invoicing breach.

Text, registry analysis, infographics and tool content: CC BY 4.0. Tool code: l0g repository licence.

This analysis is not investment advice.

// cite this analysis

l0g, “The great e-invoicing toll, 5/5: when the pipe breaks”, l0g.fr, published August 22, 2026, updated August 22, 2026, https://l0g.fr/en/analysis/the-great-e-invoicing-toll-5-when-the-pipe-breaks/


$ cd ../analysis