Outil pédagogique et autonome pour valider, générer et explorer les factures électroniques UBL conformes à la réforme française. Choisissez une porte d'entrée ci-dessous.
Charger un XML existant
Validez un fichier UBL 2.1 reçu d'un fournisseur ou émis par votre ERP. Tout reste local — aucune donnée transmise.
Parcourir mon disque →
Tester un cas type AFNOR
33 presets clé en main couvrant la majorité des cas d'usage XP Z12-014 : commerciales, acompte/solde, avoir, multi-vendeurs, débours, mandats…
Ouvrir le Générateur →
Tester un XML d'anomalie
Générez un XML UBL contenant des erreurs volontairement injectées (XSD, format, arithmétique, TVA, Socle CGI). Idéal pour calibrer son validateur, former des utilisateurs, ou faire un audit de régression.
Ouvrir le Générateur d'anomalies →
Découvrir l'outil
Première visite ? Comprenez en 2 minutes les 5 couches de validation, les onglets disponibles et les principaux cas d'usage.
Lire le tuto →
Déposez votre XML UBLou cliquez pour parcourir
▸ Log technique (Saxon-JS)
⏳ Initialisation…
Résultats
Glissez un XML dans la zone du haut · ou cliquez sur la zone pour parcourir
Astuce : Accueil pour générer un cas test ou découvrir l'outil
Représentation lisible
Lancez une validation pour visualiser la facture ici.
Dictionnaire des contrôles
Référentiel exhaustif des 1 254 contrôles appliqués lors de la validation — Structure XSD UBL 2.1 · CEN EN 16931 · BR-FR-CTC · EXTENDED-CTC-FR · Socle CGI
30
Structure XSD
979
CEN EN 16931
168
BR-FR-CTC
51
EXTENDED
26
Socle CGI
|
Code règle
Sévérité
Couche
Description
Chargement…
Référentiels
Gestion de vos référentiels métier : entités (vendeurs / acheteurs / tiers) et commandes (numéros de bon de commande issus de votre SI Achats). Le référentiel est partagé entre tous les utilisateurs de votre organisation et synchronisé en temps réel (stockage Supabase scopé par organisation, isolation RLS).
Ajouter une entité
Identification (obligatoire)
Données techniques (auto par défaut · pour saisir manuellement)
Import / Export CSV
Importez vos entités depuis un fichier CSV (séparateur point-virgule, encodage UTF-8). Seuls le SIREN et la dénomination sont obligatoires ; toutes les autres colonnes peuvent être laissées vides — elles seront alors générées automatiquement par le validateur. Téléchargez le template ci-dessous pour partir d'un fichier prêt à compléter.
Mes entités personnelles (0)
ℹ
Ajouter une commande
Enregistrez ici les numéros de bon de commande issus de votre SI Achats pour pouvoir les sélectionner directement lors de la génération d'une facture via le composeur libre. Vous pouvez optionnellement rattacher chaque commande à une entité (vendeur / fournisseur) — dans ce cas, sélectionner la commande dans le composeur libre auto-sélectionnera l'entité vendeur correspondante.
Identification (numéro obligatoire)
Import / Export CSV
Importez vos commandes depuis un fichier CSV (séparateur point-virgule, encodage UTF-8). Seul le numéro de commande est obligatoire ; la description et l'entité rattachée sont optionnelles. Le rattachement à une entité utilise le trigramme (colonne « EntityIdLiee »).
Mes commandes (0)
ℹ
Bienvenue dans FE Factory by Kaora
L'outil Kaora pour valider, générer, corriger et explorer vos factures électroniques UBL — conforme à la réforme française e-invoicing 2026.
Pourquoi cet outil ?
À partir de septembre 2026, toutes les entreprises françaises devront émettre et recevoir leurs factures B2B au format électronique structuré. Le format UBL 2.1 est l'un des trois socles autorisés (avec CII et Factur-X). FE Factory couvre cinq cas d'usage :
Vérifier
Tester qu'un XML UBL est conforme aux 5 couches de validation (XSD UBL 2.1, CEN EN 16931, BR-FR-CTC, EXTENDED-CTC-FR, Socle CGI) — 1 254 contrôles en cascade et un verdict 3 états (Conforme / Valide avec réserves / Non conforme bloquant).
Générer
Créer des factures de test : 33 presets AFNOR clé en main, ou composeur libre par axes, ou suite logique (acompte → solde, avoir, rectificative) à partir d'un XML antérieur.
Corriger
Module d'auto-correction : 23 fixers détectent et patchent automatiquement les erreurs structurelles (XSD, ordre, namespaces, formats, mentions obligatoires) avec commentaires explicatifs en français.
Tester (anomalies)
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. Comparatif automatique attendu vs détecté.
Comprendre
Explorer les 1 254 contrôles et les ~400 champs BT/BG via un dictionnaire interactif : définition, XPath UBL, règles de gestion, occurrence par profil (CIUS-FR / EXTENDED).
Deux usages concrets
Au-delà des cinq piliers fonctionnels, FE Factory répond à deux objectifs métier très opérationnels rencontrés sur le terrain dans le contexte de la réforme 2026 :
① Tester les XML générés par les SI / ERP
Vérifier qu'un XML produit par un ERP, un SI de facturation, une PA, un connecteur EDI ou un middleware est conforme aux 5 couches (XSD, CEN, BR-FR, EXTENDED, Socle CGI). Détecter les régressions après une mise à jour, qualifier la sortie d'un fournisseur, ou auditer un flux entrant.
Onglets concernés : Validation XML + module Auto-fix.
② Générer des jeux de données fournisseur
Produire en masse des factures fournisseur de test pour qualifier vos applicatifs aval — Comptabilité Fournisseur / Accounts Payable (PA), SI Achats, ERP, P2P / Procure-to-Pay. Couvrir non seulement la validation entrante mais aussi les cinématiques de flux (réception, rapprochement bon de commande, écritures comptables, workflow de validation, paiement) et l'intégration côté SI Achats / ERP.
Pourquoi générer aussi des factures volontairement en anomalie ? Parce qu'un système robuste doit savoir rejeter proprement les factures non conformes. Tester le chemin "happy path" ne suffit pas : il faut aussi tester les rejets, les messages d'erreur, les retours fournisseur, les exceptions et les workflows dérogatoires. C'est précisément le rôle de l'onglet Générateur d'anomalies.
📚 Exhaustivité des cas 33 presets AFNOR officiels + composeur 8 axes + 14 mutateurs d'anomalies — tous les cas de la réforme couverts.
⚡ Gain de temps Un XML conforme en 2 clics. Une suite de 50 factures en quelques minutes — versus des heures de saisie ERP.
🎯 Facilité de création Aucune compétence XML requise. Choix par cartes, dropdowns d'entités, garde-fous de compatibilité automatiques.
📦 Volume de test Mode « Variation aléatoire » sur le Générateur valide et le Générateur d'anomalies : chaque clic produit une nouvelle variante reproductible.
Comment ça marche ? (les 6 onglets utilisateurs + Admin)
Accueil
Point d'entrée : 4 cartes raccourcies pour démarrer rapidement — charger un XML existant, tester un cas AFNOR, générer un cas d'anomalie, ou lire ce tuto.
Validation XML
Collez ou chargez un XML. À droite : la facture en mode Lisible. À gauche : verdict de conformité (Conforme / Valide avec réserves / Non conforme bloquant), bloc Triage (OK / Bloquant / Recommandé / Bonne pratique), badges par couche, détail des contrôles, et module auto-fix si erreurs détectées.
Générateur
Preset : 33 cas AFNOR par famille. Composeur libre : 8 axes (type, TVA, tiers, modalités…). Suite : avoir, solde ou rectificative à partir d'une facture antérieure. Batch : génération en lot d'un jeu de données fournisseur (1-200 factures) + ZIP avec manifest CSV.
Générateur d'anomalies
Zone de test identifiable au fond jaune. Composez un XML UBL volontairement invalide en cochant 1 à 14 anomalies (XSD, format, arithmétique, TVA, Socle CGI). Comparatif Attendu vs Détecté automatique pour valider la couverture de votre validateur.
Référentiels
Deux sous-onglets : Mes entités (vendeurs / acheteurs, 62 préchargées, validation Luhn SIREN/SIRET + mod-97 TVA/IBAN) et Mes commandes (numéros de bon de commande issus de votre SI Achats, optionnellement rattachés à une entité vendeur et avec montant HT pour cohérence). Import / Export CSV avec templates téléchargeables. Recherche par SIREN / dénomination / numéro. Persistance localStorage.
Dictionnaire des contrôles
Référentiel des 1 254 règles : recherchez un BT, BG ou EXT-FR-FE-*. Définition, XPath UBL, couche d'application et profil.
Admin Réservé admin
Onglet en haut à droite, séparé du reste — réservé aux administrateurs fonctionnels (équipe Kaora, référent qualité du projet). Module d'audit de non-régression à 2 modes : Audit preset (lance N variantes randomisées de chaque preset AFNOR et valide chacune — détecte les régressions après modification du randomizer, d'un preset ou d'un fixer) et Audit composeur libre (teste les paires d'axes du composeur en mode matrice ~258 paires ou en mode combinatoire random — détecte les bugs d'interaction multi-axes). Rapport tableau exploitable + export CSV. Pas destiné aux utilisateurs finaux : c'est un outil de qualification interne pour garantir la robustesse de l'application avant chaque déploiement.
Fonctionnalités types
« Je veux valider un XML existant »
Ouvrez l'onglet Validation XML (ou Accueil → « Charger un XML existant »).
Glissez votre XML sur la zone ou cliquez pour parcourir.
Lisez le Verdict de conformité en haut : Conforme (✓ vert, aucun bloquant) / Valide avec réserves (⚠ orange, recommandations à examiner) / Non conforme bloquant (✗ rouge, à corriger avant émission). La facture est lisible à droite en mode Lisible.
Sous le verdict, le bloc Triage 5 cellules (OK / Non déclenchées / Bloquant / Recommandé / Bonne pratique) compte les règles uniques distinctes, dédoublonnées cross-couche.
À gauche, parcourez le détail par couche : XSD → CEN → BR-FR → EXTENDED → Socle CGI.
Corrigez les bloquants en priorité, puis idéalement les recommandations — ou utilisez le module Auto-fix décrit ci-dessous.
« Je veux corriger automatiquement les erreurs de mon XML »
Après validation, si des erreurs corrigeables sont détectées, le module Auto-fix apparaît sous le résumé.
La liste des correctifs applicables s'affiche avec le nombre d'occurrences détectées par fixer (jusqu'à 23 disponibles : namespaces UBL, ordre des éléments, formats décimaux/dates, attributs obligatoires, mentions légales socle CGI…).
Décochez les corrections que vous ne souhaitez pas appliquer ; cochez « Inclure les commentaires explicatifs » pour tracer chaque modification dans le XML.
Cliquez sur Appliquer & télécharger : le XML corrigé est téléchargé avec le suffixe _KaoraFix.xml.
Re-validez le fichier corrigé pour vérifier le delta. La couverture XSD atteint 94 % (28 règles sur 30) — les cas non auto-corrigeables sont signalés explicitement.
« Je veux tester un cas d'usage AFNOR »
Ouvrez l'onglet Générateur, mode « Preset ».
Dépliez l'une des 5 catégories (Commerciales, Cycle, Corrections, TVA, Tiers).
Cliquez sur le preset souhaité — son détail s'affiche dans le panneau droit.
Surchargez éventuellement le vendeur / acheteur dans le panneau de détail.
Cliquez sur « Générer & Valider » : le XML est généré, validé, et l'onglet Validation s'ouvre automatiquement.
« Je veux créer une facture maison sur mesure » (Composeur libre)
Dans le Générateur, sélectionnez « Composeur libre ».
Cochez vos options dans les 8 axes, dans l'ordre logique : A Type, B Régime TVA, D Tiers, E Modalités, C Parties (vendeur / acheteur), H Référence BdC, F Lignes, G Remise / frais.
Les cartes incompatibles sont automatiquement grisées et des bannières contextuelles expliquent les effets (profil EXTENDED forcé, BT-3 swappé…).
Pour certains types (ACOMPTE, SOLDE, AVOIR, RECTIFICATIVE), des cartes complémentaires apparaissent (ratio acompte, mode solde, référence BG-3).
Axe H — Référence Bon de commande : 4 modes au choix dans la liste déroulante :
Saisir manuellement : champ libre pour taper votre propre référence.
Choisir dans Mes commandes : sélecteur des commandes enregistrées dans Référentiels → Mes commandes. Si la commande est rattachée à une entité, le vendeur (Axe C) est automatiquement verrouillé sur cette entité (fond jaune, bandeau d'info — désélectionnez la commande pour reprendre la main). Si la commande a un montant HT renseigné, un rappel vert s'affiche pour vous aider à composer des lignes en cohérence.
Cliquez sur « Générer & Valider ».
« Je veux gérer mes entités et mes commandes » (Référentiels)
Ouvrez l'onglet Référentiels (anciennement « Mes entités »).
Sous-onglet « Mes entités » :
Saisie manuelle : seuls la dénomination et le SIREN sont obligatoires. Le reste (SIRET, TVA, IBAN, mention légale, adresse, contact) est généré automatiquement par défaut, avec possibilité de basculer chaque champ en mode manuel (icône crayon).
Import CSV : téléchargez le template (17 colonnes, 2 exemples — minimal et complet), complétez vos entités en n'ayant à remplir que SIREN et dénomination si besoin, puis importez. Les colonnes vides sont auto-générées par le validateur.
Export CSV : sauvegarde de toutes vos entités au format point-virgule UTF-8 (compatible Excel FR).
Recherche en haut de la liste : filtre temps réel par SIREN, dénomination ou trigramme.
Sélecteur d'entité filtrable : dans tous les modules de génération (preset, composer libre, batch, commandes, anomalies), le sélecteur d'entité supporte la recherche live (tape un trigramme ou une dénomination pour filtrer la liste, navigation clavier ↑↓ Enter Esc).
Sous-onglet « Mes commandes » :
Saisie manuelle : seul le numéro de commande est obligatoire. Description, montant HT et entité vendeur rattachée sont optionnels.
Le rattachement à une entité (sélecteur peuplé depuis Mes entités) permet l'auto-sélection du vendeur dans le composeur libre (et son verrouillage tant que la commande est sélectionnée).
Le montant HT optionnel s'affiche dans la liste et sert d'aide à la cohérence dans le composeur libre (rappel visuel vert quand la commande est sélectionnée).
Import CSV : template avec 4 colonnes — Numero;Description;MontantHT;SirenEntiteLiee. Le rattachement à une entité se fait via le SIREN (pas le trigramme), pour cohérence avec le template entités.
Recherche : par numéro de commande, description ou trigramme d'entité rattachée.
Toute modification de référentiel est immédiatement répercutée dans le composeur libre (sélecteurs vendeur / acheteur / commande mis à jour à chaque ouverture du composer).
💡 Cas d'usage typique : import en masse de votre référentiel d'entités fournisseurs (depuis votre SI achats) via CSV, puis import des bons de commande ouverts. Lors de la génération d'une facture de test pour un fournisseur donné, sélectionnez son BdC dans le composer libre → vendeur et montant HT sont auto-rappelés, vous gagnez sur la saisie et limitez les incohérences.
Réservé admin fonctionnelModule d'audit qualité
Les deux étapes ci-dessous concernent l'onglet Admin (en haut à droite, séparé du reste). Elles ne sont pas destinées aux utilisateurs finaux : ce module sert à l'équipe Kaora et au référent qualité du projet pour qualifier le validateur avant déploiement, détecter les régressions après une mise à jour de preset / fixer / randomizer, et garantir la robustesse industrielle de l'application.
Ouvrez l'onglet Admin (en haut à droite), sous-onglet Audit preset.
Choisissez le nombre de variantes par preset (1-50, défaut 10). L'audit lance ce nombre de générations randomisées pour chacun des 33 presets, soit 330 validations par défaut.
Cliquez sur « Lancer l'audit ». La progression est affichée en temps réel (preset courant, % avancement, compteurs Conforme / Réserves / Non conforme / Erreur).
À la fin (~30 s à 2 min selon le N choisi), un tableau par preset apparaît : Total, ✓ Conformes, ⚠ Réserves, ✗ Non conformes, Erreurs, et un libellé Statut (« Robuste », « Avertissements », « Régression bloquante »).
Cliquez sur une ligne de preset en problème pour déplier le détail : variante en échec, règles déclenchées, et bouton Télécharger XML pour reproduire le cas à part.
Cliquez sur « Rapport CSV » en haut à droite pour exporter le bilan complet (compatible Excel FR).
Cas d'usage : qualifier le Générateur après modification d'un preset, d'un fixer ou du randomizer. Pour la mise en service de nouvelles entités. Pour détecter qu'une combinaison aléatoire spécifique produit une erreur (ex. multi-TVA + escompte + sous-traitance qui casse une mention légale).
Ouvrez l'onglet Admin (en haut à droite), sous-onglet Audit composeur libre.
Choisissez le mode d'audit :
Matrice (par défaut) — teste systématiquement toutes les paires d'options des 4 axes (Type × Régime × Tiers × Modalités) + exclusions mutuelles intra-axes (~258 paires).
Combinatoire — tire N (10-500) combinaisons aléatoires valides (3-4 axes activés simultanément) pour débusquer les bugs d'interaction multi-axes.
Cliquez sur « Lancer l'audit composer ». Suivez la progression avec les 5 compteurs : Conforme / Réserves / Non conf. / Skip (paires marquées incompatibles par la matrice) / Erreur.
À la fin (~30 s à 1 min), le tableau des combinaisons problématiques uniquement s'affiche (les conformes ne polluent pas la vue). Pour chaque : la combinaison testée + les règles déclenchées + bouton XML pour télécharger le cas reproductible.
Cliquez sur « Rapport CSV » pour exporter le bilan complet (avec colonne Compat_matrice indiquant si la paire était attendue compatible ou non).
Cas d'usage : qualifier la matrice de compatibilité du composer après modification d'un axe, détecter les combinaisons rares qui produisent un XML invalide en pratique (et que la matrice laisse passer à tort), ou inversement vérifier que la matrice n'est pas trop stricte (incompatible déclaré mais XML valide).
« Je veux fabriquer un jeu de données fournisseur de test » (Mode batch)
Ouvrez l'onglet Générateur, sous-onglet Batch (jeu de données).
Configurez la composition : nombre de factures (1-200), type de dataset (Mix simple, Mix varié recommandé, Cycle complet AP, Tous les cas AFNOR, ou Personnalisé en cochant manuellement).
Choisissez le mode Vendeur et Acheteur : rotation aléatoire sur les entités du référentiel partagé, ou fixe pour reproduire un flux fournisseur unique (cas typique : qualifier un connecteur EDI dédié).
Configurez si besoin les tiers (mandataire, affactureur, agent acheteur…) — par défaut tirés aléatoirement, ou fixés à une entité, ou avec un raccourci « Appliquer à tous » pour utiliser la même entité partout.
La convention de nommage est appliquée automatiquement : BT-1 au format {vendor}-{YYYY}-Q{trimestre}-{XXXX} et nom de fichier {preset}_{numero}.xml.
Cliquez sur « Générer le jeu & télécharger ZIP » — la barre de progression suit la génération. À la fin : un fichier dataset_FEFactory_{date}.zip est téléchargé.
Le ZIP contient : N fichiers XML UBL nommés selon votre convention + un manifest.csv récapitulatif (numéro, type, vendeur, acheteur, montants HT/TVA/TTC, dates, devise — directement exploitable Excel ou import SI Achats) + un README.txt.
💡 Cas d'usage : qualifier la Plateforme Agréée (PA) en réception, alimenter le SI Achats avec un échantillon réaliste, tester les cinématiques P2P / Comptabilité Fournisseur, ou créer un référentiel de non-régression. Variation aléatoire des dates / lignes / montants forcée pour la diversité du dataset.
« Je veux créer une facture liée à une facture antérieure » (Suite de facture)
Dans le Générateur, sélectionnez « Suite de facture ».
Collez ou chargez le XML de la facture antérieure (acompte ou facture commerciale).
FE Factory analyse le XML source et propose les suites logiques : solde après acompte, avoir total ou facture rectificative.
Choisissez la suite, ajustez si nécessaire et générez : numéro et date source sont référencés en BG-3 (BT-25 / BT-26). Les parties (vendeur / acheteur) sont reprises à l'identique.
« Je veux comprendre un champ »
Ouvrez l'onglet Dictionnaire des contrôles.
Tapez le code recherché (ex. BT-128, EXT-FR-FE-167) ou un mot-clé (ex. affacturage).
Filtrez par couche ou par sévérité si besoin.
Lisez la définition, l'XPath UBL où ce champ se trouve dans le document, et sa cardinalité selon le profil (CIUS-FR ou EXTENDED).
« Je veux tester / calibrer mon validateur avec des XML d'anomalie »
Ouvrez l'onglet Générateur d'anomalies (bandeau orange, zone de test).
Choisissez les entités vendeur / acheteur dans les dropdowns de configuration.
(Optionnel) Cochez « Variation aléatoire » pour produire une nouvelle variante de lignes/montants à chaque clic.
Dépliez les catégories (A — XSD, B — BT obligatoire, C — Format, D — Arithmétique, E — TVA, F — Socle CGI, H — Type document) et cochez une ou plusieurs anomalies à injecter.
Cliquez sur « Générer l'XML composé » — le XML produit (préfixé TEST-ANOM-…, marqué KaoraTest_*.xml) contient le mutateur ciblé.
Cliquez sur « Lancer la validation » — FE Factory passe l'XML dans son propre validateur, puis affiche un tableau comparatif Attendu vs Détecté avec un diagnostic par règle (Prévue et détectée / Prévue mais NON détectée / Détectée mais non prévue).
Lisez la conclusion automatique en bas : test conforme, régression potentielle, ou cascades convergentes attendues.
⚠ Important : les XML produits par cet onglet sont volontairement invalides. Le BT-1 est préfixé TEST-ANOM-, le nom de fichier commence par KaoraTest_, et un commentaire d'avertissement est ajouté en tête. Ne jamais transmettre à un destinataire en production.
Foire aux questions
Comment fonctionne le verdict de conformité ?
FE Factory rend un verdict 3 états adossé à la réalité des règles déclenchées (et non à un score arbitraire pondéré) :
✓ Conforme — aucune règle bloquante, aucune recommandation "réelle" déclenchée. La facture peut être émise telle quelle.
⚠ Valide avec réserves — aucun bloquant, mais une ou plusieurs recommandations et/ou bonnes pratiques sont déclenchées. La facture passera les contrôles obligatoires, mais des points d'amélioration sont signalés.
✗ Non conforme bloquant — au moins une règle bloquante est déclenchée. La facture sera rejetée par le PPF / la PA / le destinataire. Correction obligatoire avant émission.
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.
Pourquoi certains avertissements (UBL-CR-195, UBL-CR-197, UBL-CR-528…) n'affectent pas le verdict ?
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 :
UBL-CR-195 / UBL-CR-197 — bloc <cac:ServiceProviderParty> dans Party du vendeur ou acheteur. Légitime pour les cas 4 / 19a (tiers facturant — EXT-FR-FE-BG-04/05).
UBL-CR-528 — bloc <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 23 fixers qui couvrent ~94 % des erreurs XSD courantes et un large périmètre des règles CEN/CGI :
Structure : injection des namespaces UBL manquants (xmlns/cbc/cac), réordonnancement des éléments (Invoice, Party, PostalAddress, LegalMonetaryTotal, InvoiceLine), suppression des doublons 1..1.
Types simples : formats décimal (préfixe 0, précision), date YYYY-MM-DD, devise ISO 4217, pays ISO 3166, booléen true/false, ajout des attributs currencyID / unitCode.
Profil & mentions : injection du CustomizationID, du UBLVersionID, du ProfileID adapté, et des notes obligatoires Socle CGI : #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é.
Sécurité : injection d'éléments obligatoires manquants (BT-1, BT-2, BT-3, BT-5) avec valeurs par défaut signalées par une alerte « À valider manuellement ».
Chaque correctif peut être désactivé individuellement avant application. Les commentaires <!-- FIX KAORA --> dans le XML corrigé tracent chaque modification.
À quoi sert le Générateur d'anomalies ?
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.
Mes XML AFNOR officiels ont aussi des erreurs CEN EN 16931 dans FE Factory. Bug ?
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.
Mes données sont-elles envoyées sur Internet ?
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) :
Authentification : email / mot de passe vérifiés par Supabase Auth (invitations gérées par l'admin de l'organisation).
Référentiels partagés : entités (vendeurs / acheteurs / tiers) et commandes (BdC) stockées dans Supabase, scopées par organisation via Row Level Security Postgres. Un utilisateur de l'org A ne peut techniquement accéder ni aux entités ni aux commandes de l'org B (politique RLS imposée côté base, pas seulement côté UI).
Aucune autre donnée (XML, brouillons, anomalies générées) n'est transmise.
Quelles couches de validation sont embarquées ?
Cinq couches cumulatives, exécutées en cascade sur chaque XML :
Structure XSD UBL 2.1 — 30 contrôles structurels (racine, namespaces, cardinalité, types simples, ordre des éléments, vocabulaire fermé OASIS). Détecte les XML mal formés ou non conformes au schéma OASIS, là où les schématrons ne peuvent rien voir.
CEN EN 16931 — 979 règles, norme européenne de facturation électronique.
EXTENDED-CTC-FR — 51 règles d'extension française (tiers, multi-vendeurs, agents, mandataires).
Socle CGI — 26 contrôles natifs spécifiques au CGI français (SIREN/SIRET avec Luhn, N° TVA avec mod-97, IBAN, mentions légales PMT / PMD / AAB / BAR, TXD conditionnel pour les membres d'un assujetti unique, références BG-3, profil S2 « déjà payée »).
Total : 1 254 contrôles exécutés sur chaque facture.
Pourquoi une couche Structure XSD en plus des schématrons ?
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.
Comment FE Factory se compare aux autres validateurs en ligne (ecosio, PEPPOL, etc.) ?
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 :
ecosio / PPF-like — approche fail-fast strict : dès qu'une erreur XSD est trouvée, le validateur s'arrête. Les couches schématron (CEN, BR-FR) ne sont jamais exécutées. Vous obtenez 1 erreur claire — mais vous ne savez pas ce qui se cache derrière.
FE Factory — approche best-effort exhaustive : les 5 couches s'exécutent indépendamment sur l'XML, même si la couche XSD a déjà émis une erreur. Vous obtenez la liste complète de tout ce qui ne va pas, en un seul passage.
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.
Administration — Audit qualité
Modules de test de non-régression du Générateur. Pour usage administrateur/développeur — utiliser après modification d'un preset, du randomizer ou de la matrice du composeur.
Audit de robustesse des presets
Lance N variantes randomisées de chaque preset (33) et valide chacune. Détecte les combinaisons aléatoires problématiques et les régressions après modification du randomizer, d'un preset ou d'un fixer.
—
Progression
L'audit n'a pas encore été lancé.
Résultats par preset
—
Audit du composeur libre
Détecte les combinaisons d'axes du composeur qui produisent un XML invalide. Couvre la matrice de compatibilité ET la cohérence inter-axes.
—
Progression
L'audit composeur libre n'a pas encore été lancé.
Résultats détaillés
—
ZONE DE TEST KAORA — Les XML produits ici contiennent des anomalies volontaires destinées à la calibration et à la formation. Ne jamais transmettre à un destinataire en production.
Générateur d'anomalies UBL
Choisissez les parties (vendeur / acheteur) et cochez les anomalies à injecter — atomiques ou cumulées librement. FE Factory produit un XML UBL conforme au schéma OASIS mais contenant les erreurs ciblées, pour tester votre validateur, former vos utilisateurs ou faire un audit de couverture. Chaque XML est marqué KaoraTest_*.xml et porte un commentaire d'avertissement de tête.
Configuration de l'XML de test
Cas d'anomalies—
Chargement…
0 anomalie(s) sélectionnée(s)Aucune
Détail & XML généré
Cochez une ou plusieurs anomalies à gauche, ou utilisez un scénario rapide, puis cliquez sur « Générer l'XML ».
Cas types pré-configurés
Détail du preset
Sélectionnez un cas type à gauche pour voir son détail et générer la facture.
Axe A — Type de facture
Type d'avoir
Commercial (défaut) : #BAR#B2B — transmis au client. Technique : #BAR#ARCHIVEONLY + note #DCL# — archivage seul (AFNOR Z12-012).
Axe B — Régime TVA
Axe D — Tiers (multi-sélection)
Axe E — Modalités (multi-sélection)
Axe C — Parties
Vendeur verrouillé — défini par la commande sélectionnée (Axe H). Désélectionnez la commande pour reprendre la main.
Aucune commande enregistrée. Allez dans Référentiels → Mes commandes pour en ajouter.
Axe F — Lignes
Mode SOLDE — gestion de l'acompte versé
Mode ACOMPTE — ratio appliqué au prix HT typique
Cas 20 AFNOR — réduit le prix HT typique des lignes au prorata (BT-3 = 386).
↩ Référence facture antérieure (BG-3) — pour AVOIR / RECTIFICATIVE / SOLDE
Valeurs « auto » : le générateur génère un numéro cohérent et une date antérieure.
Axe G — Remise & frais (optionnel)
Profil B & moyen de paiement
CIUS-FR(déduit des tiers sélectionnés)
Les cartes grisées sont incompatibles avec votre sélection actuelle.
1. Charger l'XML source (acompte ou facture commerciale)
Déposez votre XML source iciou cliquez pour parcourir
2. Détection automatique
3. Action à générer
Le XML cible reprend automatiquement vendeur, acheteur et lignes de l'XML source. Référence à la facture source en BG-3.
1. Composition du jeu de données
Sélectionnez les presets à inclure :
✓ Forcée (montants, dates, lignes randomisés)
2. Vendeurs & acheteurs
Le mode "rotation" tire aléatoirement à chaque facture parmi les entités de votre référentiel partagé. Le mode "fixe" reproduit le scénario d'un fournisseur unique (utile pour tester un flux spécifique).
3. Tiers (mandataires, agents, payeurs…)
Les tiers ne s'appliquent qu'aux presets qui les utilisent (cas 3, 8, 9, 11/12, 14, 15, 19a). Si le tirage ne porte pas sur un cas concerné, le tiers correspondant est ignoré. Le mode rotation tire un tiers ≠ vendeur ≠ acheteur ≠ autres tiers déjà affectés.
Raccourci — appliquer à tous les tiers
Configure les 6 tiers ci-dessous avec la même valeur. Utile si vous voulez que toutes les factures qui ont un tiers (peu importe le type) pointent vers une entité unique (ex. un mandataire central).
4. Convention de nommage
Convention par défaut
Numéro BT-1 : {vendor}-{YYYY}-Q{trimestre}-{XXXX} ex. KAORA-2026-Q2-7384 Nom de fichier : {preset}_{numero}.xml ex. FACT_COMM_STD_KAORA-2026-Q2-7384.xml
Convention identique au mode unitaire du Générateur. Le préfixe est l'ID de l'entité vendeur, le suffixe à 4 chiffres garantit l'unicité.
5. Génération
Génération en cours…0 / 0
Le ZIP contient : les N fichiers XML nommés selon votre convention + un manifest.csv récapitulatif (numéro, type, vendeur, acheteur, montants, dates) prêt pour Excel/SI Achats.