Points essentiels à retenir
Le code type ne décrit pas seulement une mise en page : il détermine la catégorie fonctionnelle de la facture et les contrôles qui lui sont associés. Un libellé ERP imprécis peut donc produire un document techniquement valide, mais incohérent avec son contenu comptable ou son historique.
Le champ BT-3 porte le code type du document. La règle BR-FR-04 encadre les valeurs utilisables dans le format socle français : 380 pour la facture commerciale, 386 pour la facture d’acompte, 384 pour la facture rectificative, 381 pour l’avoir standard et 262 pour l’avoir correspondant à une remise globale. D’autres variantes existent notamment pour l’auto-facturation, l’affacturage et l’avoir de facture d’acompte.
Les autres codes de la liste UNTDID 1001 ne doivent pas être utilisés sans correspondance autorisée dans le cadre français. Le mapping ne peut donc pas consister à reprendre automatiquement un code historique EDI ou une valeur libre de l’ERP.
Le socle couvre les syntaxes UBL, UN/CEFACT CII et Factur-X. Le format de cycle de vie repose sur UN/CEFACT CDAR. Le choix de la syntaxe ne remplace jamais la qualification métier portée par BT-3.
Les mentions générales identifient les parties, l’opération, la TVA, les montants et les conditions de règlement. Le typage ajoute une logique conditionnelle : selon le code retenu, des références à des documents antérieurs, une date de versement ou un cadre de facturation particulier deviennent attendus.
Il faut donc traiter séparément le contrôle des champs généraux, détaillé dans notre checklist des mentions obligatoires pour l’ERP, et le contrôle du scénario documentaire. Dans nos projets, nous recommandons de ne jamais déduire BT-3 du seul nom du modèle d’impression.
La DAF définit le traitement comptable, la comptabilité précise les règles de lettrage et l’IT traduit ces décisions en données ERP. La Plateforme Agréée contrôle et transmet le document, tandis que les clients, fournisseurs ou partenaires EDI doivent reconnaître les mêmes références.
Generix conseille de formaliser un dictionnaire commun comprenant le libellé ERP, l’événement métier, le code BT-3, les références exigées, l’effet attendu sur le solde et les statuts. Cette gouvernance évite qu’un même document soit interprété comme un avoir par la finance, une facture négative par l’ERP et une rectificative par la PA.
La table de mapping doit relier chaque scénario ERP à un code autorisé, aux références nécessaires et au résultat comptable attendu. Elle constitue la base commune de paramétrage, de contrôle et de recette avec la PA.
La première colonne décrit l’intention métier, et non le nom technique du document dans l’ERP. Le code BT-3 vient ensuite. Les autres colonnes identifient les dépendances à contrôler avant transmission : référence antérieure, date associée, date d’acompte, cohérence du montant et traitement du cycle de vie.
La documentation applicable doit être surveillée pendant le projet. La DGFiP publie les spécifications externes V3.2 datées du 30 avril 2026 et renvoie aux normes XP Z12-012, XP Z12-013 et XP Z12-014. En août 2026, la fiche AFNOR XP Z12-012 affiche une édition en vigueur datée de juin 2026. Toute matrice issue d’une version antérieure doit donc faire l’objet d’une analyse d’écart.
| Document produit par l’ERP | Code BT-3 à envisager | Références et données à contrôler | Résultat attendu |
|---|---|---|---|
| Facture commerciale simple | 380 | Mentions générales et cohérence avec le cadre de facturation | Création d’une créance client |
| Facture d’acompte | 386 | Date de versement en BT-9 si elle est connue et différente de la date d’émission | Constatation de l’acompte sans confusion avec la facture finale |
| Avoir standard | 381 | Au moins une référence BT-25 et sa date BT-26, ou des références portées sur chaque ligne | Réduction ou annulation d’une créance antérieure |
| Avoir pour remise globale | 262 | Périmètre de la remise, période et rattachement comptable à documenter | Réduction globale distincte d’une correction unitaire |
| Facture rectificative | 384 | Une et une seule référence BT-25 à la facture corrigée, avec sa date BT-26 | Remplacement ou correction maîtrisée de la facture antérieure |
| Avoir de facture d’acompte | 503 | Référence à l’acompte et date de versement en BT-9 lorsque la règle s’applique | Annulation ou réduction de l’acompte facturé |
| Facture récapitulative | Souvent 380, à confirmer selon le scénario | Période, détail des opérations et rattachement des lignes | Regroupement de plusieurs opérations sans créer un type non autorisé |
| Note de débit | À déterminer selon sa nature fiscale | Vérifier si le document constitue une facture, un document hors facture ou une dette inverse | Éviter l’emploi automatique d’un code non admis |
Cette table doit être adaptée aux variantes d’auto-facturation ou d’affacturage réellement utilisées. Generix recommande de conserver la justification de chaque choix afin que la finance, l’IT et la PA valident la même règle.
Le traitement d’un acompte exige de distinguer le versement initial, sa date et la facture définitive qui le régularise. Le code 386 ne doit pas être conservé sur la facture finale, même si celle-ci reprend l’historique de l’acompte.
Une facture d’acompte utilise le code 386. Selon la règle BR-FR-CO-06, lorsque la date de versement est connue et différente de la date d’émission, elle doit être renseignée en BT-9. Cette donnée doit provenir d’un événement fiable : encaissement, confirmation de paiement ou information comptable rapprochée.
Une difficulté fréquente apparaît lorsque l’ERP utilise le même champ pour la date d’échéance ordinaire et la date liée à l’acompte. Nous recommandons de documenter la source, la priorité et la règle de transformation de BT-9, puis de tester les cas où le versement précède, coïncide avec ou suit l’émission.
La facture définitive relève d’un cadre adapté à la nature de l’opération : B4 pour un bien, S4 pour une prestation de service et M4 pour une opération mixte. Son code type ne doit pas être celui d’une facture d’acompte.
Le scénario doit préserver le lien avec l’acompte et reprendre le montant déjà payé afin d’obtenir un net à payer cohérent. Dans l’ERP, il faut distinguer la reprise informative de la facture d’acompte, son imputation comptable et sa déduction financière. Sans cette séparation, le même montant peut être comptabilisé ou soustrait deux fois.
Le code 503 est réservé à l’avoir de facture d’acompte. Il ne doit pas servir d’avoir générique dès qu’une facture finale comporte une déduction d’acompte. Le document doit viser l’acompte concerné et conserver une piste d’audit entre la facture d’acompte, l’avoir éventuel et la facture définitive.
Generix préconise un test combinant annulation totale, réduction partielle et remplacement de l’acompte. Le rapprochement doit démontrer que le solde client, les montants transmis et les statuts restent alignés dans notre chaîne ERP-PA.
L’avoir réduit ou annule une créance, tandis que la rectificative corrige une facture antérieure selon un lien documentaire plus strict. Les deux scénarios ne doivent pas être transformés en simples factures négatives sans référence ni règle de rapprochement.
Pour un avoir standard 381, la règle BR-FR-CO-05 prévoit au moins une référence à une facture antérieure en BT-25 avec sa date BT-26. Une autre possibilité consiste à porter une référence et sa date sur chaque ligne au moyen des extensions françaises prévues.
Cette seconde méthode convient notamment à un avoir partiel rapproché de plusieurs factures ou de plusieurs lignes sources, à condition que toutes les lignes soient documentées. Le code 262 correspond pour sa part à un avoir pour remise globale : il ne doit pas être utilisé pour masquer une correction détaillée dont les factures sources sont identifiables.
La règle BR-FR-CO-04 impose qu’une facture rectificative 384 comporte une et une seule référence BT-25 à une facture antérieure, ainsi que sa date BT-26. Cette unicité doit être bloquante dans l’ERP ou dans le connecteur avant l’envoi.
Une rectificative ne doit donc pas agréger la correction de plusieurs factures. Si un traitement commercial porte sur plusieurs documents, le scénario doit être requalifié, par exemple sous la forme d’avoirs correctement référencés. Generix recommande de rendre le motif de correction exploitable par la comptabilité, même lorsqu’il n’est pas utilisé comme clé technique.
Après paiement, la correction ne modifie pas seulement le document : elle peut créer une somme à rembourser, une créance complémentaire ou un montant à imputer sur une opération future. Le mapping doit donc être cohérent avec le net à payer, le lettrage et les écritures de règlement.
Le type documentaire ne remplace pas le mapping ERP des statuts de cycle de vie. Nous testons séparément l’acceptation du nouveau document, son rapprochement avec la facture initiale et l’effet du paiement déjà enregistré.
Un libellé métier sans code dédié doit être requalifié selon sa fonction fiscale et comptable. Il ne faut ni inventer un code BT-3, ni reprendre automatiquement un code EDI historique absent de la liste autorisée.
Une facture récapitulative regroupe plusieurs livraisons ou prestations sur une période. Son caractère récapitulatif ne crée pas nécessairement un type documentaire autonome : si elle constitue une facture commerciale, le code 380 peut rester pertinent, sous réserve de la validation du scénario complet.
La recette doit vérifier la période couverte, les références de commandes ou de livraisons, la ventilation des lignes et l’absence de factures unitaires déjà comptabilisées pour les mêmes opérations. Generix recommande de partir des événements sources de l’ERP et des flux EDI plutôt que du seul PDF récapitulatif. La norme AFNOR XP Z12-014 relative aux cas d’usage B2B constitue la référence à confronter au processus réel.
Le terme « note de débit » peut désigner plusieurs réalités. Un document purement informatif, non assimilé à une facture, n’entre pas comme tel dans le flux de facturation électronique. S’il matérialise une opération soumise à TVA et remplit la fonction d’une facture, il doit être qualifié avec un code de facture autorisé correspondant à sa nature réelle.
Lorsque le document exprime une dette en sens inverse, le scénario peut relever d’un avoir, notamment dans un contexte d’auto-facturation. La décision appartient aux responsables fiscaux et comptables ; l’IT ne doit pas traduire seul un libellé « note de débit » en code technique. Notre rôle consiste ensuite à rendre cette décision contrôlable et reproductible dans les interfaces.
La recette doit tester des chaînes documentaires complètes, pas seulement des fichiers isolés. Chaque cas doit partir de l’événement ERP, traverser les contrôles de la PA et revenir dans la comptabilité avec ses références et ses statuts.
Le socle de recette doit couvrir les scénarios réellement utilisés, avec des variantes positives et négatives :
Pour chaque jeu, nos équipes recommandent de conserver le fichier source, le fichier transformé, le résultat des contrôles, le statut reçu et l’écriture comptable attendue.
Les contrôles doivent être placés au plus près de la donnée source afin d’éviter des rejets tardifs :
Le calendrier publié par la DGFiP prévoit la réception obligatoire pour toutes les entreprises au 1er septembre 2026, ainsi que l’émission obligatoire à cette date pour les grandes entreprises et les ETI. L’émission devient obligatoire le 1er septembre 2027 pour les PME, TPE et microentreprises, selon la mise à jour DGFiP du 16 janvier 2026.
Une architecture fragmentée multiplie les endroits où BT-3, les références ou les statuts peuvent être transformés différemment. La performance vient au contraire d’une chaîne collaborative dans laquelle finance, IT, clients et partenaires partagent les mêmes identifiants et règles.
Generix s’appuie sur son expérience des flux EDI et des réseaux B2B pour relier les données ERP, les contrôles documentaires et les retours de cycle de vie. Notre Plateforme Agréée Generix pour la facturation électronique est immatriculée par la DGFiP. À compter du 1er septembre 2026, les entreprises assujetties doivent recourir à une plateforme agréée pour transmettre et recevoir leurs factures et adresser les données requises à l’administration, comme le précise la présentation officielle des plateformes agréées.
Nous vous invitons à auditer vos scénarios non standards et à demander un atelier de mapping ERP avec nos équipes. L’objectif est de tester les codes BT-3, les références de factures antérieures, les règles d’acompte et les statuts de cycle de vie avant le passage en production.
En résumé
Le code type d’une facture commerciale simple est 380 dans la liste autorisée du format socle. Les factures auto-facturées, affacturées ou combinant ces deux situations disposent de variantes à traiter séparément dans le mapping ERP.
Une facture d’acompte utilise le code 386. Si la date de versement est connue et différente de la date d’émission, elle doit être renseignée en BT-9 selon la règle BR-FR-CO-06.
Le code de l’avoir standard est 381. Selon le scénario, les codes 261, 262, 396, 502 ou 503 peuvent s’appliquer à l’auto-facturation, à la remise globale, à l’affacturage ou à l’avoir de facture d’acompte.
Un avoir réduit ou annule tout ou partie d’une facture, tandis qu’une facture rectificative corrige une facture antérieure. L’avoir 381 doit comporter au moins une référence antérieure, globalement ou par ligne ; la rectificative 384 attend une seule référence BT-25 et sa date BT-26.
Oui. Selon la règle BR-FR-CO-04, une facture rectificative 384 doit comporter une et une seule référence à une facture antérieure en BT-25, accompagnée de sa date en BT-26.
Une note de débit non assimilée à une facture n’entre pas comme telle dans le champ de la facturation électronique. Si elle constitue une facture soumise à TVA, elle doit être qualifiée avec un code de facture autorisé ; si elle matérialise une dette inverse, le scénario d’avoir doit être examiné.
Préparez une recette par scénarios couvrant la génération ERP, BT-3, les références BT-25 et BT-26, les références au niveau ligne, les règles d’acompte et les contrôles de la PA. Vérifiez ensuite les statuts de cycle de vie, le net à payer et le rapprochement comptable de chaque chaîne documentaire.
Non. Factur-X est une syntaxe du format socle et ne remplace pas la donnée métier BT-3. Le même typage documentaire doit rester cohérent que la facture soit exprimée en UBL, en UN/CEFACT CII ou en Factur-X.
Pilotez votre entrepôt avec 15 KPI opérationnels. Retrouvez pour chacun la formule, la fréquence de suivi, le seuil d’alerte indicatif et l’action corrective.
Comprenez le régime applicable à l’indexation gazole, choisissez le bon indice CNR et recalculez chaque surcharge. Une méthode opérationnelle pour contrôler vos factures et documenter une contestation.
Travaillez avec nos équipes pour concevoir et mettre en œuvre la Supply Chain qui accompagnera votre croissance, adaptée à vos spécificités métier.
