<Report> — codes TB/TT/TG, format e-reporting propre. Prototype v9.48.0 — validateur + PRESET (colonne gauche) et lisible (colonne droite).<Report> 10.1. Rien à importer.| Libellé article | Montant HT (EUR) | Taux TVA % |
|---|
(le XML généré s'affichera ici — utilise « Générer le 10.1 » ci-dessus)
Transactions par date × catégorie × taux de TVA. Codes TB/TT/TG. BETA — validateur + lisible (générateur à venir).Transactions (par date et catégorie) et calcule totaux + ventilations (cohérence G1.53 garantie).| Date | Cat. | Taux % | Base HT (EUR) | Nb |
|---|
Transactions par jour × catégorie. La catégorie est déduite du cadre BT-23 (B→biens, S→services) ; tu peux forcer une catégorie. Pas de limite de nombre (avertissement au-delà de ~500).(le XML généré s'affichera ici — PRESET ou intégration ci-dessus)
CrossDomainAcknowledgementAndResponse conforme au format sémantique Annexe 2 CDV Flux 6 V2.3 (30/04/2026). Codes MDT/MDG. Deux sous-modules : 212 Encaissée et 210 Refusée. Validateur (colonne gauche, en haut) puis PRESET ; rapport et XML à droite.SpecifiedDocumentCharacteristic avec TypeCode = MEN et un ValueAmount renseigné.| Code règle | Sévérité | Couche | Description |
|---|---|---|---|
| Chargement… | |||
L'outil Kaora pour valider, générer, corriger et explorer vos factures électroniques UBL — conforme à la réforme française e-invoicing 2026.
La réforme française de la facturation électronique rend la réception de factures électroniques obligatoire pour toutes les entreprises assujetties à la TVA dès le 1er septembre 2026 ; l'obligation d'émission, elle, s'applique de façon échelonnée selon la taille de l'entreprise. Toutes finiront donc par émettre au format structuré, mais pas à la même date.
Elle ne crée pas un seul type d'échange mais trois — la facture, la déclaration de transaction, le statut de cycle de vie — qui n'ont ni le même contenu ni les mêmes règles. FE Factory couvre les trois, à travers cinq cas d'usage :
Tester qu'un fichier est conforme. Pour une facture UBL, 5 couches de validation en cascade — XSD 2.1, CEN EN 16931, BR-FR-CTC, EXTENDED-CTC-FR, Socle CGI — soit 1 254 contrôles et un verdict à 3 états.
Les flux e-reporting et les cycles de vie ont chacun leur propre validateur, avec leurs règles à eux.
Créer des fichiers de test : 42 presets de facture clé en main, un composeur libre par axes, ou une suite logique — acompte, solde, avoir, rectificative — à partir d'un XML antérieur.
Les modules e-reporting et CDV ont leur propre générateur, avec deux modes : réglementaire ou demi-interface.
Module d'auto-correction : détecte et patche automatiquement les erreurs structurelles — XSD, ordre des balises, namespaces, formats, mentions obligatoires — avec un commentaire explicatif en français à chaque endroit modifié.
Générer des XML contenant des anomalies volontaires — XSD, format, arithmétique, TVA, Socle CGI — pour calibrer un validateur, former des utilisateurs ou faire un audit de régression. 16 mutateurs, avec comparatif automatique attendu contre détecté.
Explorer les 1 254 contrôles et les champs BT/BG via un dictionnaire interactif : définition, XPath UBL, règles de gestion, occurrence par profil (CIUS-FR / EXTENDED).
Au-delà des cinq piliers fonctionnels, FE Factory répond à deux objectifs métier très opérationnels rencontrés sur le terrain.
Vérifier qu'un fichier sorti d'un ERP, d'un SI de facturation, d'une plateforme, d'un connecteur EDI ou d'un middleware est conforme. Détecter les régressions après une mise à jour, qualifier la sortie d'un fournisseur, auditer un flux entrant.
Cela vaut pour les trois familles : une facture UBL, un flux e-reporting 10.1 ou 10.3, un cycle de vie CDAR. Chacun a son onglet et son validateur.
Onglets concernés : Validation XML et son module Auto-fix, F10.1, F10.3, CDV.
Produire en masse des factures fournisseur de test pour qualifier les applicatifs aval — comptabilité fournisseur, SI Achats, ERP, P2P. Couvrir non seulement la validation entrante, mais aussi les cinématiques : réception, rapprochement de commande, écritures, workflow de validation, paiement.
Pourquoi générer aussi des factures fausses ? Parce qu'un système robuste doit savoir rejeter proprement. Tester le chemin nominal ne suffit pas : il faut éprouver les rejets, les messages d'erreur, les retours fournisseur et les workflows dérogatoires.
Onglets concernés : Générateur (cas valides) et Générateur d'anomalies (cas invalides).
42 presets de facture (cas AFNOR et cas métier, dont le secteur public), composeur libre, 16 mutateurs d'anomalies, plus les générateurs e-reporting et cycle de vie.
Un fichier conforme en deux clics. Une série de cinquante factures en quelques minutes, là où la saisie dans un ERP prendrait des heures.
Aucune compétence XML requise. Choix par cartes, listes d'entités issues du référentiel, garde-fous de compatibilité automatiques.
Le mode variation aléatoire produit à chaque clic une nouvelle variante reproductible, sur le générateur valide comme sur celui d'anomalies.
C'est la clé pour s'y retrouver dans l'outil. Les trois échanges n'ont ni le même déclencheur, ni le même contenu, ni les mêmes règles — et FE Factory suit cette division, sans aucune règle partagée entre les familles.
Votre client est assujetti à la TVA et établi en France. La facture elle-même transite par les plateformes, de la vôtre à la sienne. Le secteur public entre dans ce cadre.
Ce qui circule : la facture complète, structurée.
Votre client est un particulier, ou une entreprise établie hors de France. Il n'a pas de plateforme pour recevoir la facture, mais l'opération doit être déclarée.
Ce qui circule : des données de transaction, pas la facture.
Ce qui arrive à la facture après son dépôt : reçue, refusée, encaissée. Chaque étape remonte sous forme de statut.
Ce qui circule : des statuts — et, pour l'encaissement, le montant encaissé avec sa devise et son taux de TVA.
Sur les prestations de services, la TVA est en principe exigible à l'encaissement, pas à la facturation. L'administration doit donc savoir quand vous avez été payé — une information qui ne peut pas figurer dans la facture, puisqu'au moment où vous l'émettez vous ne l'êtes pas encore. C'est le statut « Encaissée » qui la porte.
Nuance importante si vous avez opté pour les débits. Sous cette option, la TVA devient exigible à la facturation, et le statut « Encaissée » perd l'essentiel de sa raison d'être fiscale. Il reste néanmoins dû sur les acomptes : la TVA y est exigible à l'encaissement même avec option sur les débits, pour les livraisons de biens comme pour les prestations de services (XP Z12-014 Annexe A, cas 20/21).
Autrement dit, un émetteur au régime des débits a un périmètre de flux 6 nettement plus restreint, centré sur les acomptes. Les autres statuts — reçue, refusée, rejetée — restent dus dans tous les cas : ils tracent le sort de la facture entre les plateformes, indépendamment de la TVA.
C'est le cœur historique de l'outil, et le plus fourni. Trois modules, qui répondent à trois questions différentes.
« Mon ERP produit ce fichier — est-il conforme ? »
Vous déposez un XML, l'outil le passe dans les cinq couches de contrôle et vous rend un verdict détaillé, règle par règle, avec le chemin de la balise en cause.
« J'ai besoin d'une facture de test, conforme, sur un cas précis. »
Presets AFNOR, composeur libre, scénarios métier, production en lot, enchaînement de factures liées.
« Mon propre validateur détecte-t-il bien les erreurs ? »
Produit des XML volontairement fautifs, une règle enfreinte à la fois, pour calibrer un validateur tiers.
Un fichier peut être refusé pour des raisons très différentes, et l'outil les sépare pour que vous sachiez à qui vous adresser. Le nombre de contrôles de chaque couche est indiqué entre parenthèses.
Structure XSD (33) — la grammaire du document : balises attendues, dans le bon ordre, avec le bon type. Une inversion suffit à faire rejeter le fichier avant tout contrôle métier.
CEN EN 16931 (979) — le socle européen commun à tous les pays.
BR-FR-CTC (168) — les règles françaises appliquées sur ce socle.
EXTENDED-CTC-FR (51) — les champs supplémentaires propres au dispositif français.
Socle CGI (25) — les mentions obligatoires du Code général des impôts, qui ne relèvent d'aucun schématron mais dont l'absence est tout aussi fâcheuse.
Une erreur fatale empêche le dépôt : elle doit être corrigée. Un avertissement signale un écart toléré à l'émission mais susceptible d'être exigé plus loin dans la chaîne. Chaque constat porte le code de la règle — BR-FR-CO-09, BR-CO-16… — qui permet de remonter au texte normatif et de trancher un désaccord avec un éditeur.
Le mode batch produit un lot complet en une passe : vous choisissez les presets, la volumétrie et les entités, l'outil génère les fichiers et le manifeste qui va avec. C'est ce qui permet de charger un SI cible avant même que le SI source soit prêt.
Les scénarios métier vont plus loin : ils enchaînent des factures qui se répondent — une facture, puis son avoir, puis sa rectificative — avec les références croisées correctes.
Ces deux modules sont isolés : ils ne partagent aucune règle avec les factures. Le format n'est pas UBL mais un format e-reporting propre, avec ses propres codes — TB, TT, TG au lieu des BT et BG de la facture. Ne cherchez pas à y appliquer vos réflexes du flux 2.
Vos ventes à des entreprises établies hors de France. La facture ne transite pas par le dispositif français, l'opération doit donc être déclarée.
Maille unitaire : une transaction déclarée par facture, sans agrégation.
Vos ventes aux particuliers. Chez CDA, c'est le gros du volume : forfaits, billetterie, boutique, restauration.
Maille agrégée : les opérations sont regroupées par date, catégorie et taux de TVA.
En 10.1, chaque facture donne lieu à sa propre déclaration, avec ses lignes. En 10.3, on ne déclare pas les ventes une par une — ce serait ingérable sur une caisse — mais des totaux par journée, par catégorie d'opération et par taux. Confondre les deux mailles est l'erreur la plus coûteuse sur ces flux, parce qu'elle ne se voit qu'au moment du rapprochement avec la comptabilité.
Un même fichier peut être jugé de deux façons, et la case « Interface PA (CEGEDIM) » choisit laquelle.
Décochée — contrôle réglementaire, celui du PPF. Les champs que la plateforme renseigne elle-même, émis au marqueur NA ou omis, apparaissent à part et en bleu, sous « Écarts admis par CEGEDIM » : on les voit, mais jamais mêlés aux vraies fautes.
Cochée — contrôle de la demi-interface SI → plateforme. Ces écarts disparaîssent ; il ne reste que ce qui relève de votre ERP.
Attention : ces écarts ne sont pas conformes dans l'absolu. Le même fichier déposé directement au PPF serait rejeté.
Le module produit et contrôle un message CrossDomainAcknowledgementAndResponse, dit CDAR. Encore un format à part : ni UBL, ni e-reporting, avec ses propres codes MDT et MDG.
Vous avez été payé. C'est le statut qui déclenche l'exigibilité de la TVA sur les prestations de services.
Porte le montant encaissé, sa devise et le taux de TVA, obligatoirement réparti par taux.
Votre client refuse la facture. Le statut doit dire pourquoi, avec un code motif tiré d'une liste fermée.
Sans motif, le fournisseur ne sait pas quoi corriger — d'où la règle qui l'impose.
Le module est organisé dans cet ordre parce que c'est l'usage le plus fréquent : on reçoit un CDAR produit par un ERP et on veut savoir ce qui cloche. Vous pouvez donc soumettre n'importe quel CDAR, sans rien générer — le statut contrôlé est lu dans le fichier, pas dans le sélecteur.
Le chargement par fichier ajoute deux contrôles impossibles sur du texte collé : présence de la déclaration XML, et validité de l'encodage sur les octets bruts. Un fichier encodé en cp1252 sans déclaration n'est pas de l'XML bien formé : aucun parseur ne le lit, et la plateforme répond « format non reconnu » sans jamais atteindre les contrôles métier.
Le bouton rouge produit un CDAR 100 % réglementaire. Le bouton à lisieré bleu produit la demi-interface telle que la spécifie le SI source : émetteur du flux au marqueur NA, champs substitués par la plateforme omis. Le second sert à reproduire ce que votre ERP envoie réellement ; le premier, à savoir à quoi ressemblerait un fichier parfait.
Trois onglets servent les trois familles à la fois.
Vos entités — vendeurs, acheteurs, SIREN, SIRET, adresses de routage — et vos commandes. Tout ce que les générateurs consomment vient d'ici.
La liste des règles embarquées, avec leur libellé, leur couche et leur sévérité. C'est là qu'on va quand un code de règle apparaît dans un verdict et qu'on veut comprendre ce qu'il exige.
Audit qualité du parc de presets et du composeur libre. Réservé à l'équipe qui maintient l'outil.
Les XML que vous déposez ou générez sont traités localement. Ils ne sont jamais envoyés sur un serveur. Seul le référentiel d'entités est partagé, pour que l'équipe travaille sur les mêmes données.
Tout XML généré porte une marque : le nom de fichier commence par KaoraTest_, et un commentaire d'avertissement est ajouté en tête. Ne jamais transmettre à un destinataire en production.
Elle tient au destinataire de la facture, pas à sa nature.
Si votre client est une entreprise établie en France, la facture doit transiter par les plateformes agréées : c'est le e-invoicing, flux 2. Le document lui-même circule.
Si votre client est un particulier ou une entreprise étrangère, il n'a pas de plateforme pour recevoir la facture. Vous la lui transmettez comme aujourd'hui, mais vous devez déclarer l'opération à l'administration : c'est le e-reporting, flux 10.x. Seules des données de transaction circulent, jamais la facture.
Une même entreprise émet donc les deux, selon à qui elle vend.
Non, pour une raison fiscale précise. Sur les prestations de services, la TVA est exigible à l'encaissement et non à la facturation. L'administration doit donc savoir quand vous avez été payé.
Or cette information ne peut pas figurer dans la facture : au moment où vous l'émettez, vous n'êtes pas encore payé. C'est le statut « Encaissée » (212) du flux 6 qui la porte, après coup.
Les autres statuts — Reçue, Refusée, Rejetée — servent, eux, à tracer le sort de la facture entre les deux plateformes.
Elle choisit qui le rapport tient pour responsable d'un champ manquant.
Sur une demi-interface, certains champs ne sont pas produits par l'ERP mais renseignés par la plateforme — qui les attend donc absents, ou émis au marqueur NA. Ce ne sont pas des fautes de l'émetteur, mais ce ne sont pas non plus des fichiers conformes dans l'absolu.
Décochée, l'outil les affiche à part, en bleu, sous « Écarts admis » : vous les voyez sans les confondre avec de vraies anomalies. Cochée, ils disparaîssent et il ne reste que ce qui relève de votre ERP — la vue utile pour dire à l'équipe de développement ce qu'elle doit corriger.
Dans les deux modes, une valeur présente mais invalide reste signalée : seule l'absence, ou le marqueur NA, est neutralisée.
Parce que le paquet publié par la FNFE et la version réellement exécutée par votre plateforme ne sont pas le même fichier.
Le paquet officiel est effectivement en avertissement sur l'intégralité de ses assertions. Mais les plateformes appliquent leur propre version, généralement plus récente et durcie, qui émet de véritables erreurs et marque le document invalide.
Conséquence pratique : ne jamais conclure d'un « ce n'est qu'un warning » que le fichier passera. Le pied de chaque rapport CDV le rappelle.
Non, et l'inverse non plus. Les trois familles sont étanches : formats différents, jeux de codes différents, règles différentes.
Une facture utilise UBL et les codes BT/BG. Un flux e-reporting utilise un format propre et les codes TB/TT/TG. Un cycle de vie utilise le format CDAR et les codes MDT/MDG. Aucune règle n'est partagée entre eux, et c'est voulu : les mélanger produirait des faux positifs dans les deux sens.
FE Factory rend un verdict 3 états adossé à la réalité des règles déclenchées (et non à un score arbitraire pondéré) :
Le bloc Triage (5 cellules : OK / Non déclenchées / Bloquant / Recommandé / Bonne pratique) compte les règles uniques (et non les occurrences) : 8 fois la même erreur sur 8 lignes compte pour 1 problème conceptuel à corriger. Les compteurs sont dédoublonnés cross-couche : si la même règle remonte côté CEN et EXTENDED, elle compte pour 1.
Sur certains documents, des règles CEN strictes sont en conflit normatif attendu avec ce que l'AFNOR XP Z12-014 autorise explicitement via le profil EXTENDED-CTC-FR. Les cas connus à date :
<cac:ServiceProviderParty> dans Party du vendeur ou acheteur. Légitime pour les cas 4 / 19a (tiers facturant — EXT-FR-FE-BG-04/05).<cac:InvoiceLine>/<cac:OrderLineReference>/<cac:OrderReference>. Légitime pour le cas 1 multi-commande à la ligne (EXT-FR-FE-135/144) où chaque ligne de facture référence son propre bon de commande.FE Factory marque ces avertissements comme « bénins » (annotation explicite dans le détail) : ils restent affichés pour traçabilité, mais ne basculent pas le verdict en orange. Si un document ne déclenche que ces avertissements bénins, le verdict reste ✓ Conforme.
D'autres règles CEN peuvent se révéler bénignes au fil des cas d'usage EXTENDED-CTC-FR rencontrés — la liste est mise à jour au cas par cas dans EXT_BENIGN_WARNINGS (côté code).
Le module embarque 25 fixers qui couvrent ~94 % des erreurs XSD courantes et un large périmètre des règles CEN/CGI :
currencyID / unitCode.#PMT# (indemnité forfaitaire 40 €), #PMD# (pénalités de retard), #AAB# (escompte / pas d'escompte), #BAR# (cadre B2B/B2BINT/B2C). La note #TXD# (membre d'assujetti unique TVA, art. 256 C bis CGI) n'est injectée que si un indice de groupe TVA est détecté.Chaque correctif peut être désactivé individuellement avant application. Les commentaires <!-- FIX KAORA --> dans le XML corrigé tracent chaque modification.
Le Générateur d'anomalies produit des XML UBL volontairement invalides pour tester / calibrer un validateur (le vôtre, le PPF, une PA tierce, un ERP). C'est un outil de non-régression et de formation.
14 anomalies au catalogue, classées en 7 catégories : A XSD (ordre, namespace, attribut manquant), B BT obligatoires manquants (BT-1, BT-5), C Format (date, décimal, devise), D Arithmétique (BT-106/110/112 décalés), E TVA (catégorie S à 0 %), F Socle CGI (SIREN Luhn cassé, note PMT absente), H Type document (avoir sans BG-3).
Vous cochez les anomalies à injecter, FE Factory génère un XML structurellement parseable mais sémantiquement invalide, puis le passe dans son propre validateur. Un tableau comparatif Attendu vs Détecté indique pour chaque règle si elle a été détectée comme prévu (✓), manquée (✗ régression), ou détectée hors plan (⚠ cascade convergente).
Identification visuelle : la page a un fond jaune crème et un bandeau orange permanent en haut. Les XML produits sont marqués KaoraTest_*.xml, BT-1 préfixé TEST-ANOM-, et portent un commentaire d'avertissement de tête. Ne jamais transmettre en production.
Non — la norme CEN EN 16931 est plus stricte que l'AFNOR sur certains points (multi-vendeurs, sous-lignes, mixage de catégories TVA). AFNOR mandate alors le profil EXTENDED-CTC-FR qui prend le relais via ses propres règles BR-FREXT-*. Ces erreurs CEN sont attendues et présentes dans les samples AFNOR officiels eux-mêmes.
Les deux modes du Générateur produisent plusieurs factures, mais avec des finalités très différentes :
| Aspect | Batch (jeu de données) | Scénarios métier |
|---|---|---|
| Volumétrie | 1 à 200 factures indépendantes | 1 à plusieurs dizaines de factures liées (BG-3, BT-113, BT-20 cohérents) |
| Tirage des cas | Aléatoire selon mix (commerciales, avoirs, acomptes…) | Cas métier réel reconstitué fidèlement |
| Vendeur / acheteur | Rotation aléatoire ou fixe | Fixés (cohérence inter-factures du scénario) |
| Chaînage XML | Non — factures indépendantes | Oui — multi-BG-3 / BT-113 / BT-20 / numérotation incrémentale gérés nativement |
| Objectif | Qualifier une PA / un SI Achats avec un dataset représentatif | Reproduire un cas client réel (BTP, leasing, énergie…) pour un test de bout-en-bout sur l'ensemble du processus métier |
| Description | Hint synthétique par preset | Description Markdown longue : contexte métier, processus en N étapes, mapping EN 16931 / AFNOR, points de vigilance |
En pratique : utilisez le Batch pour stresser une PA / un ERP avec un échantillon varié (« est-ce que tout passe ? »). Utilisez les Scénarios métier pour démontrer un cas concret au métier ou tester un workflow de bout en bout sur un cas BTP / leasing / énergie réaliste.
Les XML que vous validez ne quittent jamais votre poste : les 1 254 contrôles (XSD, CEN, BR-FR, EXT, CGI) sont exécutés dans votre navigateur. Aucune facture n'est uploadée vers un serveur tiers.
En revanche, deux flux passent par Supabase (backend hébergé en UE) :
Aucune autre donnée (XML, brouillons, anomalies générées) n'est transmise.
Cinq couches cumulatives, exécutées en cascade sur chaque XML :
Total : 1 254 contrôles exécutés sur chaque facture.
Les schématrons sont des règles XPath ciblant des éléments précis (BT-X, BG-Y). Si un XML contient un élément inventé (ex. <cbc:PostalCode> au lieu de <cbc:PostalZone>) ou un attribut requis manquant (ex. currencyID sur un montant), les schématrons ne détectent rien : leur règle ne cible pas un élément absent.
La couche XSD vérifie au contraire la structure pure du XML contre le schéma officiel OASIS UBL 2.1 OS : vocabulaire fermé (873 éléments cbc + 669 éléments cac), ordre des sous-séquences (Party, PostalAddress, InvoiceLine, LegalMonetaryTotal), types simples (date YYYY-MM-DD, décimal NNNN.NN, code pays ISO 3166, code devise ISO 4217), attributs obligatoires (currencyID, unitCode), cardinalités strictes des conteneurs (1 supplier, 1 customer). Sans cette couche, ~10 % des XML structurellement défectueux passeraient à 100 % « VALIDE » à tort.
FE Factory est cohérent avec les validateurs officiels du marché (ecosio EN 16931, PEPPOL Authority Validator, etc.) sur le verdict final : un XML invalide selon ecosio l'est aussi selon FE Factory, et inversement. Mais les deux approches diffèrent volontairement sur la stratégie d'exécution :
Conséquence concrète : sur un XML avec 1 erreur XSD + 8 erreurs sémantiques, ecosio affichera "1 erreur" et FE Factory affichera "9 problèmes (1 bloquant XSD + 8 cascades sémantiques)". Les deux ont raison — c'est la politique de présentation qui diffère. Avantage FE Factory : voir l'ensemble du chantier en un seul passage, sans devoir corriger, re-soumettre, corriger, re-soumettre…
Pour une validation "officielle" PPF-like en complément, ecosio EN 16931 (rule set "EN 16931") est l'option en ligne la plus pertinente — c'est le moteur sous-jacent utilisé par plusieurs PA.
KaoraTest_*.xml et porte un commentaire d'avertissement de tête.