# Why does my French e-invoice fail the BR-FR rules?
Source: https://xmlvalid.com/blog/why-does-my-french-e-invoice-fail-br-fr-rules
> FNFE-MPE's own example broken twenty ways: the BR-FR rule each mistake trips, from the billing mode and SIREN to the legal notes, VAT rates and credit notes
Since 1 September 2026 French businesses receive their invoices through an approved platform (plateforme agréée), and large and mid-sized ones issue them that way too. The platform checks each invoice against EN 16931 and against the French rules of the AFNOR standard XP Z12-012, which FNFE-MPE publishes as Schematron: the BR-FR rules. Since 1 October 2026 platforms apply them in their "fatal" form, so an invoice that fails one is refused, however well it passes EN 16931.
To see where invoices fail them, I took use case 1 of FNFE-MPE's own examples, a UBL invoice for services that passes the UBL 2.1 schema, the EN 16931 rules 1.3.16 and the BR-FR rules 1.4.0.04 with no findings, and broke it in about twenty ways. Every message below is what the rules report. They are in French, as FNFE-MPE writes them; each rule's page has an English rendering beside the original.
## The billing mode, where Peppol puts its profile
The French rules reuse BT-23, the business process, for the billing mode (cadre de facturation): `B1` for goods, `S1` for services, `M1` for both, with other digits for other cases. In UBL it is `cbc:ProfileID`:
```xml
S1
```
That is the element a Peppol invoice fills with its profile, so an invoice built from a Peppol template fails on the first rule:
```
BR-FR-08_BT-23 La valeur du cadre de facturation (ram:ID) est absente ou n'est pas autorisée. Valeurs acceptées : B1, S1, M1, B2, S2, M2, S3, B4, S4, M4, S5, S6, B7, S7, B8, S8, M8, B9, S9, M9. Valeur actuelle : "urn:fdc:peppol.eu:2017:poacc:billing:01:1.0". Veuillez utiliser une valeur conforme à la liste des modes de facturation autorisés.
```
Leaving it out fails [BR-FR-08\_BT-23](https://xmlvalid.com/rules/BR-FR-08_BT-23) too, with `Valeur actuelle : ""`. The message names `ram:ID`, the CII element, even in a UBL invoice: several BR-FR messages were written for one syntax and copied to the other, so go by the rule id rather than the element in the text.
The digit matters beyond the code list. With `S2`, an invoice already paid, the amounts have to say so:
```
BR-FR-CO-09_BT-23-1 Si le cadre de facturation (BT-23) est B2, S2 ou M2 (facture déjà payée), alors le montant déjà payé (BT-113) doit être égal au montant total TTC (BT-112). Montant payé : 0.00, Montant total : 12000.00.
BR-FR-CO-09_BT-23-2 Si le cadre de facturation (BT-23) est B2, S2 ou M2, alors le net à payer (BT-115) doit être égal à 0. Net à payer : 12000.00.
```
## The invoice number
EN 16931 accepts any text as the invoice number. The French rules allow letters, digits and `+ - _ /`, at most 35 characters. A number written with a space and a dot, `FA 2025.003`, is reported twice, by two rules that check nearly the same thing:
```
BR-FR-01_BT-1-2 L'identifiant de facture (cbc:ID) contient des caractères non autorisés. Valeur actuelle : "FA 2025.003". Seuls les caractères alphanumériques et les symboles + - _ / sont autorisés, sans espaces.
BR-FR-02_BT-1 [BR-FR-02/BT-1 : L'identifiant de facture (cbc:ID) doit être composé uniquement de caractères alphanumériques (A-Z, a-z, 0-9) et peut contenir les caractères spéciaux autorisés : tiret (-), plus (+), tiret bas (_), barre oblique (/). Il ne doit pas contenir uniquement des espaces, ni commencer ou se terminer par un espace, ni contenir d'espaces consécutifs. Valeur actuelle : "FA 2025.003". Veuillez corriger le format de l'identifiant.
```
A number that spells everything out, `FACTURE-2025-CLIENT-200000008-000003`, has 36 characters and fails [BR-FR-01\_BT-1-1](https://xmlvalid.com/rules/BR-FR-01_BT-1-1). The same limits apply to the preceding invoice reference (BT-25) of a credit note, so a numbering scheme that breaks them breaks every credit note too.
## The three legal mentions
French commercial law requires every B2B invoice to state the late payment penalties, the fixed 40 euro compensation for recovery costs and the early payment discount, or that there is none. On a paper invoice they are lines of small print. In an e-invoice they are notes (BT-22), and the rules find them by their subject code (BT-21): `PMD`, `PMT` and `AAB`. UBL has no element for the subject code, so it goes at the start of the note between hashes:
```xml
#PMD#Tout retard de paiement engendre une pénalité exigible à compter de la date d'échéance, calculée sur la base de trois fois le taux d'intérêt légal.
#PMT#Indemnité forfaitaire pour frais de recouvrement en cas de retard de paiement : 40 €.
#AAB#Les règlements reçus avant la date d'échéance ne donneront pas lieu à escompte.
```
Keep the same three texts and drop only the codes, which is what a generator that knows nothing of the convention writes, and all three are missing as far as the rules can tell:
```
BR-FR-05_BT-22-1 La mention relative aux frais de recouvrement (code PMT) est absente. Elle est obligatoire dans les notes (BG-3).
BR-FR-05_BT-22-2 La mention relative aux pénalités de retard (code PMD) est absente. Elle est obligatoire dans les notes (BG-3).
BR-FR-05_BT-22-3 La mention relative à l'escompte ou à son absence (code AAB) est absente. Elle est obligatoire dans les notes (BG-3).
```
The notes are BG-1 in EN 16931; the message says BG-3. Each code may appear once: a second `#PMD#` note fails [BR-FR-06\_BT-21-2](https://xmlvalid.com/rules/BR-FR-06_BT-21-2).
## SIREN, SIRET and electronic addresses
The seller's legal registration identifier (BT-30) must be its SIREN, scheme `0002`, as nine digits. The way a SIREN is usually printed, `100 000 009`, fails two rules:
```
BR-FR-10_BT-30 Le SIREN du vendeur (CompanyID[@schemeID='0002']) est obligatoire et doit être composé exactement de 9 chiffres. Valeur actuelle : "100 000 009". Veuillez renseigner un identifiant SIREN valide.
BR-FR-32-LEGALID Tout identifiant légal d'une Partie avec schemeID = '0002' DOIT être composé de 9 chiffres.
```
A SIRET, the 14-digit number of one establishment, in the same place fails the same two. A SIRET belongs in the party identifier (BT-29 for the seller, BT-46 for the buyer) with the scheme `0009`, and it has to start with the party's own SIREN:
```
BR-FR-09_BT-29 Le SIRET doit contenir 14 chiffres et commencer par le SIREN. SIRET : "20000000800014", SIREN : "100000009".
```
That one is the buyer's SIRET written on the seller's side, a copy-paste error the rule catches because it compares the two numbers.
Both parties need an electronic address: [BR-FR-13\_BT-34](https://xmlvalid.com/rules/BR-FR-13_BT-34) for the seller, [BR-FR-12\_BT-49](https://xmlvalid.com/rules/BR-FR-12_BT-49) for the buyer. For an invoice between French businesses the address is the buyer's entry in the national directory, scheme `0225`, starting with its SIREN. An invoice can say that it is one with a note of subject code `BAR` and the text `B2B`, and then an email address is not accepted:
```
BR-FR-21_BT-49 Si le traitement est BAR/B2B et que le type de document (cbc:InvoiceTypeCode) n'est pas en autofacture (389, 501, 500, 471, 473, 261, 502), alors le BT-49 (cbc:EndpointID) doit commencer par le SIREN (cbc:ID[@schemeID='0002']) et le schemeID doit être égal à "0225". Valeurs actuelles : BAR = "B2B", EndpointID="factures@client.fr", schemeID="EM", SIREN="200000008".
```
The `BAR` note takes one of `B2B`, `B2BINT`, `B2C`, `B2CINT`, `OUTOFSCOPE` or `ARCHIVEONLY` ([BR-FR-20\_BT-21](https://xmlvalid.com/rules/BR-FR-20_BT-21)), and only once: two `BAR` notes with different values fail [BR-FR-30\_BT-21](https://xmlvalid.com/rules/BR-FR-30_BT-21). Whether the address really is in the directory is for the platform to find out; the rules check only its form.
## VAT rates and categories
EN 16931 checks that the VAT amounts add up, whatever the rate. The French rules also check the rate against a list: the rates of mainland France, Corsica and the overseas departments, and older ones such as 19.6 and 7. A 21 % from a Belgian template, computed correctly, fails [BR-FR-16\_BT-119](https://xmlvalid.com/rules/BR-FR-16_BT-119) on the VAT breakdown and [BR-FR-16\_BT-152](https://xmlvalid.com/rules/BR-FR-16_BT-152) on every line.
The list holds the rates as text, so a correct rate written with three decimals fails too, along with the rule on its form:
```
BR-FR-16_BT-119 Le taux de TVA (cbc:Percent) doit être exprimé en pourcentage sans symbole « % » et faire partie des valeurs autorisées. Taux fourni : "20.000".
BR-FR-DEC-04_BT-119 Le taux de TVA « 20.000 » est invalide. Il doit : - être un nombre strictement positif (sans signe « - »), - comporter au plus 2 décimales (séparateur « . »), - contenir au maximum 4 caractères (hors séparateur). Veuillez corriger ce taux pour respecter le format requis.
```
`20`, `20.0` and `20.00` all pass. Of the VAT categories, `L` and `M` (the Canary Islands' IGIC and the IPSI of Ceuta and Melilla) do not apply in France: [BR-FR-15\_BT-118-2](https://xmlvalid.com/rules/BR-FR-15_BT-118-2).
## Decimals
Amounts already have at most two decimals in EN 16931, and the French rules say so a third time. A line net amount of `8000.000` gets three findings, one per rule set:
```
BR-DEC-23 The allowed maximum number of decimals for the Invoice line net amount (BT-131) is 2.
UBL-DT-01 Amounts shall be decimal up to two fraction digits
BR-FR-DEC-01_BT-131 Le montant « 8000.000 » est invalide. Il doit comporter au plus 2 décimales, être exprimé avec un point comme séparateur, et ne pas dépasser 19 caractères (hors séparateur). Le signe « - » est autorisé. Veuillez corriger ce montant.
```
What is new is the limit on prices and quantities, which EN 16931 leaves open: a price (BT-146) with at most six decimals and no minus sign ([BR-FR-DEC-03\_BT-146](https://xmlvalid.com/rules/BR-FR-DEC-03_BT-146), unless the billing mode ends in 9), a quantity (BT-129) with at most four ([BR-FR-DEC-02\_BT-129](https://xmlvalid.com/rules/BR-FR-DEC-02_BT-129)). A system that stores unit prices with seven decimals has to round them when it writes the invoice.
## Credit notes
EN 16931 lets a credit note leave out the invoice it corrects. The French rules don't. Remove the `cac:BillingReference` from FNFE-MPE's credit note example:
```
BR-FR-CO-05_BT-3 Si le type de facture (BT-3) est un avoir (261, 381, 396, 502, 503), alors : - soit au moins une référence à une facture antérieure (BT-25) avec sa date (BT-26) doit être présente au niveau entête, - soit chaque ligne (BG-25) doit contenir une référence à une facture antérieure (EXT-FR-FE-136) avec sa date (EXT-FR-FE-138). Références entête trouvées : 0. Nbline : 2 LineREF : 0 N° Facture : A202500003
```
A corrective invoice (384, 471, 472, 473) needs exactly one such reference ([BR-FR-CO-04\_BT-3](https://xmlvalid.com/rules/BR-FR-CO-04_BT-3)). A credit note for a global discount, type 262, needs the contract it applies to (BT-12) and the period it covers:
```
BR-FR-CO-03_BT-3 Si le code type de la facture (BT-3) est égal à 262 (Avoir Remise Globale), alors : - Le numéro de contrat (BT-12) doit être présent - La période de facturation (BG-14) doit être renseignée (dates de début et de fin). Valeurs actuelles : BT-12="", période="2025-06-01 à 2025-06-30".
```
In UBL, write a 262 as a `CreditNote`: in an `Invoice` the EN 16931 rules 1.3.16 reject the code itself with BR-CL-01. And the type codes the reform accepts are a short list: a partial invoice, `326`, is a valid UNTDID 1001 code but fails [BR-FR-04\_BT-3](https://xmlvalid.com/rules/BR-FR-04_BT-3).
## Dates and currencies
Three rules that come up less often but are easy to trip:
- A due date before the issue date fails [BR-FR-CO-07\_BT-9](https://xmlvalid.com/rules/BR-FR-CO-07_BT-9), except for advance payment invoices and the already-paid billing modes.
- The issue, due, delivery and period dates must fall between 2000 and 2099. A two-digit year written out as `0025-07-01` is a valid `xs:date`, so the schema lets it through, and [BR-FR-03\_BT-2](https://xmlvalid.com/rules/BR-FR-03_BT-2) stops it.
- An invoice in another currency must give the VAT in euros as well: the VAT accounting currency (BT-6) `EUR` and the VAT total in it (BT-111), [BR-FR-CO-12\_BT-5](https://xmlvalid.com/rules/BR-FR-CO-12_BT-5).
## Reading a BR-FR finding
The id says more than the message. The part after the underscore is usually the business term the rule checks (`BR-FR-10_BT-30` is the seller's legal registration identifier), and the same rule has an id per term it applies to: BR-FR-16 is `_BT-96`, `_BT-103`, `_BT-119` or `_BT-152` depending on where the rate sits. `CO` rules relate several fields, `DEC` rules check how numbers are written. The French text often states the value it found (`Valeur actuelle`), which is the quickest way to see what went wrong.
The `EXT-FR-FE-*` terms in some messages are the ones XP Z12-012 adds to EN 16931, such as the preceding invoice reference on a line (EXT-FR-FE-136). Invoices that need more of them (multiple vendors, sub-lines) use the EXTENDED-CTC-FR profile, whose rules take the place of EN 16931's.
## Try it
Open the [French UBL example](https://xmlvalid.com/schemas/france-ctc-ubl) in the [validator](https://xmlvalid.com/validate?schema=france-ctc-ubl), change the billing mode, the SIREN or a rate, and run it: the schema, EN 16931 and the BR-FR rules run together in the browser, so the invoice is not uploaded. CII and Factur-X PDFs work the same way, and the [France page](https://xmlvalid.com/e-invoicing/france) lists the profiles. Every rule of the [French rule set](https://xmlvalid.com/rules/sets/fr-ctc-ubl) has a page with the French message and its English rendering. To write an invoice that passes from the start, the [e-invoice generator](https://xmlvalid.com/e-invoice-generator) fills in the billing mode, the SIREN and the three legal mentions for a seller in France, and checks the result with the same rules before you download it.
### More from the blog
- [Fixing a quadratic slowdown in libxml2's XSD validation](https://xmlvalid.com/blog/a-quadratic-loop-in-libxml2-xsd-validation)
- [Why is my XML valid but still rejected?](https://xmlvalid.com/blog/why-is-my-xml-valid-but-still-rejected)
- [Validating a 5 GB XML file in the browser](https://xmlvalid.com/blog/validating-5-gb-xml-in-the-browser)