Invoice duplication: When a technical standard collides with a 20-year-old accounting principle

• The mandate enforces existing accounting rules: Non-alteration and sequential numbering obligations are not new, but the reform makes them technically unavoidable through automated platform checks.
• Duplicate checks cannot be bypassed: Approved platforms are legally required to block duplicate invoice numbers, meaning rejected invoices cannot simply be edited and resent under the same number.
• Upstream validation protects invoice numbers: Validating invoice syntax and business rules in your ERP or accounting software before transmission prevents invoice numbers from being consumed, eliminating costly cancellation and reissuance cycles.

Under French accounting and tax regulations, once a sales invoice is officially issued, it is legally immutable. Businesses cannot alter, overwrite, or re-issue the same invoice under the same identifier. First thing to clarify: the ban on modifying an invoice once issued is not an invention of the e-invoicing reform. It rests on two much older legal texts.

The French Commercial Code, in Article L123-22, has long established a principle of non-alteration of accounting documents: entries recording transactions must be made and kept without blanks or alterations of any kind. This principle is what prohibits, in practice, editing an invoice after the fact — you don’t correct an entry, you reverse it.

The French General Tax Code, in Article 289 (paragraphs V and VII), adds a requirement specific to the invoice itself: authenticity of origin, integrity of content, and legibility must be guaranteed from issuance until the end of the retention period — an obligation that falls on both the issuer and the recipient. Article 242 nonies A of Annex II supplements this foundation by requiring unique, chronological, and continuous numbering, precisely so that tax authorities can rely on a reliable audit trail and detect any invoice that has been omitted, concealed, or added after the fact.

In other words: long before anyone talked about the Portail Public de Facturation (PPF, or Public Invoicing Portal), Plateformes de Dématérialisation Partenaire (PDP, or Partner Dematerialisation Platforms), or Plateformes Agréées (PA, or Approved Platforms — the official regulatory term for state-registered partner platforms), a company was already not allowed to modify the content of an issued invoice. The only legal path has always been cancellation followed by a new issuance.

What changes with the reform isn’t the principle — it’s its systematic technical enforcement. The technical standards established by AFNOR (the French national standardisation organisation) explicitly assign to the approved platform responsibility for performing structure checks, business rule checks, and duplicate checks, before making the invoice available and returning life-cycle statuses.

In practice: as soon as an invoice bearing a given number has been transmitted to an approved platform, that number is “consumed” from the platform’s point of view — whether the invoice was accepted or rejected. The duplicate check, until now largely theoretical or applied inconsistently depending on the software vendor, becomes a systematic, blocking filter.

This is where the two layers collide. Companies, accustomed for years to correcting a rejected invoice and resubmitting it under the same number (a practice technically noncompliant, but tolerated in many EDI or Chorus Pro workflows), now run into a duplicate check that finally enforces, to the letter, what the law has required all along: cancel, then recreate.

The problem, then, isn’t legal — the rule isn’t changing — it’s operational: very few companies have built their ERP processes around this principle of systematic cancellation. Direct correction is often faster, better understood by accounting teams, and deeply embedded in habits.

What truly distinguishes the approaches on the market isn’t the duplicate check itself (which remains, by design, an approved platform prerogative) — it’s where the Schematron compliance checks and business rule checks are executed first. Schematron is an XML-based validation language used across structured e-invoicing formats to test and enforce business rules, data relationships, and conditional validation requirements.

Option A — Dual validation, with prechecking on the accounting solution side. In this model, the company’s accounting solution itself runs the Schematron and business rule checks upstream, before any transmission to the approved platform. If the invoice contains an error, it’s detected and corrected at this stage — since the accounting solution has no duplicate-check obligation, it doesn’t block anything on that front; it only verifies content compliance. Once the invoice is deemed compliant, it’s sent to the platform, which reruns the same Schematron and business rule checks (redundantly, but they pass since already validated upstream), then runs its duplicate check — which poses no problem, since this is the very first and only submission of that invoice number to the approved platform. In this model, the platform never sees a failed version: the error was absorbed before the number was “consumed.”

Option B — A single check, performed on the platform side. Here, there’s no upstream prevalidation layer: the invoice goes directly from the ERP to the approved platform, which runs its checks (Schematron, business rules, duplicates) in a single pass. If an error is detected at this stage, the number is already consumed, and the burden of correction falls entirely on the company, which must cancel the failed invoice and issue a new one under a new identifier — in line with the cancel/recreate principle described above.

The real trade-off, then, isn’t “who checks for duplicates” — the answer is always the approved platform — but “where to invest the prevalidation effort.” Option A shifts the verification burden upstream, into the company’s own tooling, so the blocking mechanism is never triggered. In this case, a company that modifies the invoice is not complying with accounting and tax rules. Option B lets the platform play its role as the single safety net but shifts the entire cost of noncompliance — cancellation, recreation, remapping — onto the company, at the moment it is least prepared to absorb it: after the fact.

Managing prevalidation, format conversion, and life-cycle reporting under France’s mandatory rules requires a resilient compliance architecture.

Businesses navigating their French compliance obligations can get started with Avalara to deploy certified French e-invoicing solutions.