Champs obligatoires EN16931 Factur-X : mapping ERP vers XML

Quels champs sont obligatoires dans une facture EN16931 / Factur-X ? EN16931 définit 160+ Business Terms (BT) — mais seule une partie est obligatoire selon le profil (MINIMUM → EXTENDED). Ce guide cartographie les champs les plus souvent oubliés lors du mapping ERP → XML CII, avec XPath et erreur Schematron BR-* associée. Pour obtenir un diagnostic structuré : /api/v1/validate retourne les champs manquants avec XPath.

En bref

• 160+ Business Terms répartis en Business Groups (BG), cardinalité 1..1 (obligatoire) à 0..n (optionnel).
• Champs les plus oubliés : BT-5 devise, BT-30 identifiant légal vendeur, BT-40 code pays vendeur, BT-81 moyen de paiement, BT-84 compte de paiement (IBAN ou identifiant propriétaire) si virement.
• Profil EN16931 (recommandé B2B France) : le plus strict en champs obligatoires. MINIMUM et BASIC WL ont moins d’exigences.
• Règles de présence : chaque champ obligatoire manquant déclenche un code BR-* spécifique (ex. BR-05 pour la devise, BR-06 pour le nom vendeur, BR-08 pour l’adresse).
• Checklist complète en fin d’article — imprimable pour vos sprints d’intégration ERP.

La norme EN 16931 définit plus de 160 Business Terms (BT) répartis en Business Groups (BG). Tous ne sont pas obligatoires — la cardinalité varie de “obligatoire” à “optionnel” en passant par “conditionnel”. Mais une facture remise à une Plateforme Agréée avec un champ obligatoire manquant peut être rejetée par la validation Schematron avant même d’atteindre le destinataire.

Ce guide cartographie les champs que les développeurs oublient le plus souvent lors du mapping ERP → XML, et explique comment les renseigner correctement dans un XML CII (Factur-X).

Pour passer de ce mapping à un appel API : JSON ERP vers Factur-X PDF/A-3 ou XML CII et le contrat des champs invoice_data.

Pour le contexte général de la validation, voir Facturation électronique 2026 : le guide technique complet. Pour comprendre les erreurs Schematron qui en résultent, voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*.

Structure du modèle EN16931

Le modèle sémantique est organisé en Business Groups (BG) qui regroupent des Business Terms (BT). Chaque BT a un identifiant unique (BT-1, BT-2, etc.), un type de données, et une cardinalité.

Les cardinalités possibles :

Un champ marqué 1..1 dans EN16931 doit être présent dans le XML pour passer la validation Schematron. Un champ 0..1 peut être absent — mais certaines règles Schematron conditionnelles (BR-CO-, BR-S-) le rendent obligatoire selon le contexte fiscal.

Vous avez déjà un fichier ? Testez votre PDF Factur-X ou votre XML CII. Déposez un PDF Factur-X ou un XML CII : le rapport sépare le verdict Factur-X/EN16931, les contrôles France 2026 concernés, ce qui bloque et les compléments à fournir quand le profil et les parties sont lisibles. Le scan ne modifie pas votre fichier. Gratuit sans compte · jusqu’à 30 scans/heure et 50/jour par IP.

Les Business Groups clés

BG-1 — En-tête de facture

Erreurs fréquentes : BT-1 vide ou absent — BT-2 au format JJ/MM/AAAA au lieu de AAAAMMJJ — BT-3 avec un code UNTDID 1001 incorrect (380 = facture, 381 = avoir) — BT-5 absent ou non ISO 4217 — BT-24 avec une URN incorrecte pour le profil.

XPaths complets (depuis rsm:CrossIndustryInvoice) :

BT-1  → rsm:ExchangedDocument/ram:ID
BT-2  → rsm:ExchangedDocument/ram:IssueDateTime/udt:DateTimeString
BT-3  → rsm:ExchangedDocument/ram:TypeCode
BT-5  → …/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode
BT-24 → …/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID

BT-24 — Specification identifier : ce champ est rendu obligatoire par la règle BR-01. Il identifie la spécification à laquelle la facture se conforme (ex: urn:cen.eu:en16931:2017 pour le profil EN16931). Son absence provoque un rejet immédiat.

BT-2 — Format de date : en CII, le format attendu dans udt:DateTimeString est AAAAMMJJ (ex: 20260401) avec l’attribut format="102". C’est une source d’erreur fréquente car les ERP stockent souvent les dates en ISO 8601 (2026-04-01).

BG-4 — Vendeur

Tous les XPaths ci-dessus sont relatifs à ram:SellerTradeParty.

BT-35 et BT-37 : ces champs ont une cardinalité 0..1 dans le noyau EN16931 (optionnels). Cependant, ils sont fortement recommandés et peuvent devenir obligatoires selon le profil Factur-X ou les exigences de la PA. Ne pas les confondre avec BT-40 (code pays) qui est véritablement 1..1.

Attention BT-30 vs BT-31 : BT-30 est l’identifiant d’enregistrement légal du vendeur. En France, ISO 6523 ICD sépare le SIREN (9 chiffres, schemeID 0002) du SIRET (14 chiffres, schemeID 0009). Un SIRET ne se code pas 0002. D’autres pays utilisent d’autres identifiants (ex: numéro de registre du commerce en Belgique, Handelsregisternummer en Allemagne). BT-31 est le numéro de TVA intracommunautaire. BT-29, BT-30 et BT-31 sont marqués 0..1 dans EN16931, mais la règle Schematron BR-CO-26 exige qu’au moins un identifiant vendeur soit présent parmi ces trois champs.

Pour ces identifiants, le schemeID désigne le registre. En France : SIREN → 0002 sur BT-30 (SpecifiedLegalOrganization/ID) ; SIRET → 0009 sur BT-29 (GlobalID).

<ram:SellerTradeParty>
  <ram:Name>Ma Société SAS</ram:Name>
  <ram:GlobalID schemeID="0009">12345678901234</ram:GlobalID>
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0002">123456789</ram:ID>
  </ram:SpecifiedLegalOrganization>
  <ram:SpecifiedTaxRegistration>
    <ram:ID schemeID="VA">FR12345678901</ram:ID>
  </ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>

BG-7 — Acheteur

Tous les XPaths ci-dessus sont relatifs à ram:BuyerTradeParty.

BT-50 et BT-52 : comme pour le vendeur (BT-35/BT-37), ces champs sont 0..1 dans EN16931 (optionnels), même s’ils sont fortement recommandés en pratique. Seul BT-55 (code pays) est véritablement obligatoire (1..1).

Le minimum pour l’acheteur est le nom et le code pays. En B2B, l’identifiant légal (BT-47) ou le numéro de TVA (BT-48) est fortement recommandé pour le routage via PA, même si EN16931 ne les rend pas systématiquement obligatoires.

BG-22 — Totaux du document

XPaths relatifs à ram:SpecifiedTradeSettlementHeaderMonetarySummation.

BT-110 — Total TVA : ce champ est toujours obligatoire dans le noyau EN16931, y compris pour les factures exonérées de TVA. Dans ce cas, la valeur doit être 0.00. Ne pas confondre “exonéré de TVA” et “TVA non applicable” — dans les deux cas, BT-110 doit être présent.

Ces champs sont les plus contrôlés par Schematron. Les règles BR-CO-10 (somme des lignes = total HT lignes), BR-CO-13 (total HT = lignes + charges − remises), et BR-CO-15 (TTC = HT + TVA) vérifient la cohérence arithmétique. Un écart d’un centime suffit à déclencher un rejet.

BG-23 — Ventilation TVA

XPaths relatifs à chaque ram:ApplicableTradeTax (ventilation TVA).

La règle BR-48 exige un taux de TVA (BT-119) dans chaque ligne de la ventilation, sauf si la facture n’est pas soumise à la TVA, et la règle BR-S-05 porte sur le taux de la ligne de facture (BT-152, catégorie “Standard rated”, code S, taux > 0). La règle BR-CO-17 vérifie que BT-117 = BT-116 × BT-119 / 100, arrondi à 2 décimales. Ces trois règles font toutes intervenir le taux de TVA.

BG-25 — Lignes de facture

Chaque facture doit contenir au moins une ligne (règle BR-16).

BT-126 : XPath complet ram:AssociatedDocumentLineDocument/ram:LineID.

BT-130 — Unité de mesure : doit être un code UN/ECE Rec 20 ou Rec 21 (ex: C62 = unité, HUR = heure, KGM = kilogramme). Les ERP utilisent souvent des labels en clair (“pièce”, “heure”) qu’il faut mapper vers les codes normalisés.

Les 10 champs les plus souvent manquants

En analysant les erreurs Schematron les plus fréquentes, voici les champs que les intégrations ERP oublient le plus souvent :

Ce que renvoie l’API quand on casse un seul champ

Chaque ligne a été rejouée le 09/11/2026 sur l’API de test (build 74aba5e). Nous partons de la facture de démonstration publique facturx-valid-basic.xml (fictive, celle que le site sert ; seule, elle ne renvoie aucune erreur sur le scan), nous retirons ou cassons ce seul champ, puis nous lisons les règles que l’API renvoie. Le tableau dit ce que l’API a rendu, pas ce que la norme prévoit.

Deux lectures utiles. Les listes de codes (unité, catégorie de TVA) sortent sous des identifiants FX-SCH-A-… et non sous BR-CL-23 ou BR-CL-18 : pour un XML CII, l’autorité Schematron déclarée par /meta est celle du schematron Factur-X (cii_schematron_authority : facturx), alors que BR-CL-23 et BR-CL-18 sont les identifiants du jeu de règles CEN du tableau ci-dessus. C’est le même défaut, un code hors liste, sous un autre identifiant. Et une date au format local ne sort pas en erreur de format : l’API n’a pas pu évaluer la règle française de date, et le statut de la réponse est unsupported.

Les versions des règles exécutées sont lues sur /meta : relisez-les avant de comparer avec votre propre sortie.

Mapping ERP → XML : méthodologie

Étape 1 : Inventaire des champs ERP

Pour chaque champ obligatoire EN16931, identifier dans votre ERP :

• Où la donnée est stockée (table, colonne, relation)
• Sous quel format (date ISO vs locale, code interne vs code normalisé)
• Si elle existe (certains champs EN16931 n’ont pas d’équivalent natif dans l’ERP)

Étape 2 : Table de correspondance

Créer une table de mapping explicite. Exemple pour les champs vendeur :

Étape 3 : Transformations de format

Les transformations les plus courantes :

Étape 4 : Validation en boucle

Après chaque ajustement de mapping, valider le XML produit contre les trois couches : XSD, Schematron EN16931, et (pour Factur-X) la conformité PDF/A-3. Les erreurs Schematron sont les plus informatives — elles indiquent exactement quel BT pose problème.

Conditions de paiement et coordonnées bancaires

BG-16 — Instructions de paiement

BT-81 — Code moyen de paiement : les ERP stockent souvent un label (“Virement bancaire”, “Prélèvement SEPA”) qu’il faut convertir en code UNTDID 4461. Les codes les plus utilisés en France :

BT-9 et BT-20 — Échéance et conditions de paiement

Dans le modèle de données EN 16931, BT-9 et BT-20 ont chacun une cardinalité 0..1. La règle de validation BR-CO-25 a été retirée des artefacts EN 16931 en 1.3.16 ; en France, la date d’échéance reste une mention obligatoire de la facture (art. L441-9 du Code de commerce).

Checklist de mapping

CHAMPS OBLIGATOIRES EN16931 — VÉRIFICATION MAPPING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

En-tête
☐ BT-1  Numéro de facture — non vide
☐ BT-2  Date — format AAAAMMJJ + format="102"
☐ BT-3  Type — code UNTDID 1001 (380/381)
☐ BT-5  Devise — ISO 4217 alpha-3
☐ BT-24 Specification identifier — URN du profil (BR-01)

Vendeur (BG-4)
☐ BT-27 Nom — non vide
☐ BT-30 ou BT-31 — au moins un identifiant (BR-CO-26)
☐ BT-35 Adresse ligne 1 (0..1 EN16931, recommandé)
☐ BT-37 Ville (0..1 EN16931, recommandé)
☐ BT-40 Code pays ISO 3166

Acheteur (BG-7)
☐ BT-44 Nom — non vide
☐ BT-50 Adresse ligne 1 (0..1 EN16931, recommandé)
☐ BT-52 Ville (0..1 EN16931, recommandé)
☐ BT-55 Code pays ISO 3166

Totaux (BG-22)
☐ BT-106 Total HT lignes
☐ BT-109 Total HT
☐ BT-110 Total TVA — toujours requis (0.00 si exonéré)
☐ BT-112 Total TTC
☐ BT-115 Montant à payer
☐ Cohérence arithmétique (BR-CO-10, BR-CO-13, BR-CO-15)

TVA (BG-23)
☐ Au moins une ventilation TVA
☐ BT-116 Base taxable
☐ BT-117 Montant TVA
☐ BT-118 Code catégorie (UNCL 5305)
☐ BT-119 Taux — présent si catégorie S (BR-48)
☐ BR-CO-17 vérifiée (BT-117 = BT-116 × BT-119 / 100)

Lignes (BG-25)
☐ Au moins une ligne (BR-16)
☐ BT-126 Identifiant de ligne
☐ BT-129 Quantité
☐ BT-130 Unité — code UN/ECE Rec 20 (pas de label)
☐ BT-131 Montant net
☐ BT-146 Prix unitaire
☐ BT-151 Code catégorie TVA
☐ BT-153 Nom article

Paiement (BG-16)
☐ BT-81 Moyen de paiement — code UNTDID 4461
☐ BT-84 compte de paiement (IBAN ou identifiant propriétaire) si virement

Ressources

• Facturation électronique 2026 : le guide technique complet — contexte réforme, pipeline, calendrier
• Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — comprendre les erreurs quand un champ manque
• Factur-X vs UBL vs CII : quel format choisir — quel format selon votre intégration
• PDF/A-3 pour Factur-X : checklist de conformité — la couche conteneur PDF

Erreurs fréquentes liées aux champs obligatoires

Quand un champ obligatoire est absent ou mal renseigné, la validation Schematron produit un code BR-* spécifique :

• BR-05 — Code devise BT-5 absent — InvoiceCurrencyCode non mappé dans l’export ERP
• BR-15 — Montant à payer BT-115 absent — DuePayableAmount omis (même pour un avoir)
• BR-33 — Raison de remise documentaire absente — Reason ou ReasonCode manquant sur BG-20
• schemeID SIREN/SIRET/GLN/DUNS — code ISO 6523 incorrect — BT-29/BT-30 avec code maison au lieu de 0002/0009
• BT-84 — IBAN dans le mauvais élément — IBANID vs ProprietaryID, pas GlobalID
• N° TVA intra-UE — format pays incorrect — préfixe ISO manquant, schemeID VA absent

Les 24 fiches unitaires sont listées dans le catalogue des erreurs BR-*.

Et maintenant ?

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer VOTRE_CLE" \
  -F "file=@./facture.pdf"

Quand le profil et les parties sont lisibles, le rapport JSON retourne chaque champ manquant avec son code BR-* et le XPath du nœud absent — diagnostic structuré pour votre mapping. Clé Sandbox : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois. Le validateur public reste gratuit et séparé du quota API. Obtenir une clé API.

De votre mapping à un premier test

Collez votre JSON invoice_data dans le testeur « Valider mon JSON en direct » : le moteur renvoie le diagnostic sans compte, et ce test ne produit pas de fichier final.