Exemple de XML Factur-X commenté
Le CII d'une vraie facture, balise par balise, avec la correspondance des codes BT de la norme EN 16931 et les erreurs qui reviennent le plus souvent.
Tous les extraits ci-dessous proviennent de ce fichier. 1 conversion gratuite, sans compte ni carte bancaire.
Par Rayan Sekkat
CII, UBL, EN 16931 : de quoi parle-t-on ?
Le XML embarqué dans un PDF Factur-X suit la syntaxe CII (Cross Industry Invoice, UN/CEFACT). La norme EN 16931, elle, ne décrit pas une syntaxe mais une liste de données métier numérotées BT-1, BT-2, etc. Lire un XML Factur-X, c'est faire la correspondance entre les deux : une balise CII porte un code BT.
Le fichier est structuré en deux niveaux seulement : un en-tête de document (ExchangedDocument) et une transaction commerciale (SupplyChainTradeTransaction) qui contient elle-même trois blocs et les lignes. Une fois cette carte en tête, le reste se lit.
Le fichier, bloc par bloc
rsm:ExchangedDocumentContextQuel profil vous parlez
Le tout premier bloc annonce le profil du fichier. Un lecteur qui ne sait pas si vous êtes en MINIMUM ou en EN 16931 ne sait pas quels champs exiger. C'est la seule balise qui conditionne la lecture de toutes les autres.
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>- urn:factur-x.eu:1p0:minimum — données fiscales seules, pas de lignes.
- urn:factur-x.eu:1p0:basicwl — en-tête complet, toujours sans lignes détaillées.
- urn:cen.eu:en16931:2017 : le profil complet, celui attendu par défaut en B2B.
rsm:ExchangedDocumentL'identité du document
Trois informations, trois codes BT. Le TypeCode est celui qui distingue une facture d'un avoir : ce n'est jamais le signe des montants qui porte ce sens.
<rsm:ExchangedDocument>
<ram:ID>FAC-2026-042</ram:ID> <!-- BT-1 : numéro de facture -->
<ram:TypeCode>380</ram:TypeCode> <!-- BT-3 : 380 facture, 381 avoir -->
<ram:IssueDateTime>
<udt:DateTimeString format="102">20260210</udt:DateTimeString>
</ram:IssueDateTime> <!-- BT-2 : date d'émission -->
</rsm:ExchangedDocument>- format="102" impose AAAAMMJJ sans séparateur. 2026-02-10 dans cette balise est invalide.
- BT-1 doit être unique chez l'émetteur : un doublon est un motif de rejet fréquent.
ram:ApplicableHeaderTradeAgreementQui vend, qui achète
Vendeur et acheteur, avec leurs identifiants légaux. C'est le bloc qui concentre le plus de rejets, parce qu'un SIRET ou un numéro de TVA absent passe le schéma XSD mais échoue au contrôle métier.
<ram:SellerTradeParty>
<ram:ID>12345678900014</ram:ID> <!-- SIRET, 14 chiffres -->
<ram:Name>Dupont Consulting SARL</ram:Name> <!-- BT-27 -->
<ram:PostalTradeAddress>
<ram:PostcodeCode>75008</ram:PostcodeCode>
<ram:LineOne>12 avenue des Champs-Élysées</ram:LineOne>
<ram:CityName>Paris</ram:CityName>
<ram:CountryID>FR</ram:CountryID> <!-- BT-40, obligatoire -->
</ram:PostalTradeAddress>
<ram:SpecifiedTaxRegistration>
<ram:ID schemeID="VA">FR12345678901</ram:ID> <!-- BT-31 : TVA intracom -->
</ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>- schemeID="VA" identifie un numéro de TVA. Sans cet attribut, la valeur n'est pas reconnue comme telle.
- BT-40 (CountryID vendeur) et BT-55 (CountryID acheteur) sont obligatoires même pour une facture franco-française.
- BuyerOrderReferencedDocument porte le bon de commande (BT-13) — exigé par la plupart des donneurs d'ordre publics.
ram:ApplicableHeaderTradeDeliveryLa livraison, même vide
Pour une prestation de services sans livraison physique, le bloc reste présent et vide. L'omettre casse la validation : le schéma attend les trois blocs de la transaction dans l'ordre.
<ram:ApplicableHeaderTradeDelivery/>- L'ordre des trois blocs est imposé : Agreement, puis Delivery, puis Settlement.
ram:ApplicableHeaderTradeSettlementArgent, TVA et totaux
Le bloc le plus long, et celui où se logent les erreurs d'arrondi. Chaque taux de TVA appliqué exige son propre ApplicableTradeTax : une facture à 20 % et 5,5 % en contient deux.
<ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode> <!-- BT-5 -->
<ram:SpecifiedTradeSettlementPaymentMeans>
<ram:TypeCode>58</ram:TypeCode> <!-- 58 = virement SEPA -->
<ram:PayeePartyCreditorFinancialAccount>
<ram:IBANID>FR7630001007941234567890185</ram:IBANID>
</ram:PayeePartyCreditorFinancialAccount>
</ram:SpecifiedTradeSettlementPaymentMeans>
<ram:ApplicableTradeTax>
<ram:CalculatedAmount>200.00</ram:CalculatedAmount> <!-- BT-117 : TVA du taux -->
<ram:TypeCode>VAT</ram:TypeCode>
<ram:BasisAmount>1000.00</ram:BasisAmount> <!-- BT-116 : base HT -->
<ram:CategoryCode>S</ram:CategoryCode> <!-- BT-118 -->
<ram:RateApplicablePercent>20</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount> <!-- BT-106 -->
<ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount><!-- BT-109 -->
<ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>
<ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount> <!-- BT-112 -->
<ram:DuePayableAmount>1200.00</ram:DuePayableAmount> <!-- BT-115 -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>- currencyID sur TaxTotalAmount est obligatoire, et doit valoir la même devise que BT-5.
- Les codes de catégorie TVA : S (standard), E (exonéré), Z (taux zéro), AE (autoliquidation), K (livraison intracommunautaire), G (export).
- Tous les montants à 2 décimales. La somme des BT-116 doit égaler BT-109 au centime près.
ram:IncludedSupplyChainTradeLineItemLe détail des lignes
Une balise par ligne de facturation, répétée autant de fois que nécessaire. Absente des profils MINIMUM et BASIC WL : c'est ce qui les distingue d'EN 16931.
<ram:IncludedSupplyChainTradeLineItem>
<ram:AssociatedDocumentLineDocument>
<ram:LineID>1</ram:LineID>
</ram:AssociatedDocumentLineDocument>
<ram:SpecifiedTradeProduct>
<ram:Name>Prestation de conseil</ram:Name> <!-- BT-153 -->
</ram:SpecifiedTradeProduct>
<ram:SpecifiedLineTradeAgreement>
<ram:NetPriceProductTradePrice>
<ram:ChargeAmount>500.00</ram:ChargeAmount> <!-- BT-146 : PU HT -->
</ram:NetPriceProductTradePrice>
</ram:SpecifiedLineTradeAgreement>
<ram:SpecifiedLineTradeDelivery>
<ram:BilledQuantity unitCode="DAY">2</ram:BilledQuantity>
</ram:SpecifiedLineTradeDelivery>
<ram:SpecifiedLineTradeSettlement>
<ram:ApplicableTradeTax>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>20</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount> <!-- BT-131 -->
</ram:SpecifiedTradeSettlementLineMonetarySummation>
</ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>- unitCode suit la codification UN/ECE : C62 (unité), DAY (jour), HUR (heure), MTR (mètre), KGM (kilogramme).
- BT-131 = BT-146 × quantité, arrondi à 2 décimales. La somme des BT-131 doit égaler BT-106.
Quatre erreurs qui reviennent tout le temps
Dates au mauvais format
format="102" attend 20260210. Écrire 2026-02-10 produit un fichier refusé alors que la date est juste.
Un seul ApplicableTradeTax pour plusieurs taux
Une facture mêlant 20 % et 5,5 % doit porter deux blocs de TVA, chacun avec sa base et son montant.
Arrondi ligne par ligne contre arrondi global
Arrondir la TVA sur chaque ligne puis sommer donne parfois un centime d'écart avec la TVA calculée sur la base totale. Les contrôles comparent les deux : calculez la TVA sur la base agrégée par taux.
Blocs dans le désordre
Agreement, Delivery, Settlement, puis les lignes. Le XSD impose cette séquence et ne donne aucun message explicite quand elle est violée.