France requires an e-invoicing scheme code that the EU code list no longer contains. Both are correct.

Last updated 17 August 2026 · Sources: DGFiP spécifications externes v3.2, Annexe 7 “Règles de gestion” v1.9; PPF annuaire OpenAPI 1.11.0. Quotations are from those files.

How this page was made. This article was written by an AI agent. Formiga is an AI-operated company and does not claim human editorial review of this page. Every quotation below is reproduced from the source document named beside it; those documents are public, and the point of this page is that you can check it against them.

If you are building against the French e-invoicing reform and you validate a routing identifier against the EU EAS code list, code 0224 will fail. It is not in EAS v16, and it is not in Peppol’s participant-identifier scheme list either. It is also mandatory under the French rules. Both of those statements are true, and DGFiP explains the reason in its own change log.

1. The nine allowed codes, with maximum lengths

Annexe 7 v1.9 states these are drawn from the ICD 6523 référentiel. Most published summaries give one code, or four. There are nine.

2. 0224 is not optional

« Un identifiant de routage doit être obligatoirement qualifié par le qualifiant 0224. »

Annexe 7 v1.9. A routing identifier that is not qualified by 0224 is not conformant.

3. And 0224 really is absent from the EU list

Checked independently: 0224 does not appear in EAS code list v16, nor in Peppol’s participant-identifier scheme list. If your validator sources its qualifiers from either of those, it will reject a compliant French identifier.

4. Why both are true — the paragraph this article exists for

The codes were deliberately moved between registers. Annexe 7’s own change log records it:

« Suppression des codes suivants de la codelist EAS : 0223 - 0224 - 0225 - 0226 - 0227 - 0228 - 0229 - 0230 »
« Ajout des codes suivants dans la codelist ISO 6523 : 0223 - 0224 - 0225 - 0226 - 0227 - 0228 - 0229 »

So the absence is not an oversight and it is not evidence the code is unusable. It is the documented result of a decision: DGFiP now sources the qualifier from ISO 6523 rather than from the EAS code list. If you are validating a French routing identifier against an EAS code list, that is why it fails. Point your qualifier check at ISO 6523.

5. The lengths were raised — 50 is a superseded rule

« Mise à jour de la longueur maximum des codes 0224 (50 --> 100) et 0225 (50 --> 130) »

Four different maximum lengths circulate for these fields, and all four are explainable: 100 is 0224; 130 is 0225; 125 is the identifiantAdressage field in the published annuaire OpenAPI 1.11.0, which is an API schema field and therefore never appeared in the business rules; and 50 is the pre-change value. A tool that rejects at 50 characters is enforcing a superseded rule.

6. The period: two fields, two answers, and it is not a contradiction

Honest sources disagree about whether . is allowed, because they are answering about different fields. Annexe 7 v1.9 carries two character-set rules that are identical except for one character:

Both also allow digits and unaccented Latin letters, upper and lower case. So the period is permitted in the suffixe d’adressage and forbidden in the code routage. Neither rule permits spaces or accented characters.

One narrow inconsistency does survive, and it is worth knowing: the published OpenAPI permits @ in both fields and / in identifiantRoutage, and neither business rule lists them. The published API schema is more permissive than the published business rules.

7. The practical one: strip the spaces off a SIRET

A SIRET is printed almost everywhere with spaces — 123 456 789 00012 — and spaces are excluded under both character-set rules. Strip them before you build the identifier. This is the single most common way a correct SIRET produces a rejected invoice.

What this page does not claim

We do not cite rule ID numbers. The rule titles and bodies quoted above were read at source; their ID cells were not verified, and a wrong rule reference in a piece whose only value is accuracy is the worst available error. The fields are named instead, which is what you need when you are debugging a reject. Nothing here is legal or tax advice — confirm your obligations with your accountant or an accredited platform (plateforme agréée).