Bibliothèque de fichiers d’exemple
Des fichiers SEPA, camt.053, UBL, MT940 et Factur-X prêts à l’emploi — des valides pour partir sur de bonnes bases, des cassés à dessein pour tester. Chaque fichier est contrôlé par le validateur dont il relève.
Fichiers d’exemple SEPA et facturation électronique
Des fichiers SEPA, camt.053, UBL, MT940 et Factur-X prêts à l’emploi — des valides pour partir sur de bonnes bases, des cassés à dessein pour tester. Chaque fichier est contrôlé par le validateur dont il relève.
129
Fichiers d’exemple
92
Valide
37
Invalide
Virement SEPA (pain.001) (12)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| pain.001.001.03 — valid credit transferUn virement SEPA valide en pain.001.001.03 : trois virements pour 1 580,00 EUR, totaux de contrôle cohérents, IBAN qui passent le mod-97 et libellés dans le jeu de caractères SEPA de base. | Valide | |
| pain.001.001.09 — valid, hybrid addressUn virement pain.001.001.09 valide, avec BICFI et l’adresse postale hybride autorisée par EPC153-22 v2.1 : TwnNm et Ctry, plus au maximum deux AdrLine de 70 caractères ou moins. | Valide | |
| pain.001.001.03 — CtrlSum mismatchUn pain.001 dont le total de contrôle ment : CtrlSum déclare 1 000,00 EUR alors que les transactions totalisent 1 500,00 EUR. L’écart est signalé deux fois, au niveau du lot de paiement puis de l’en-tête du fichier. | Invalide | |
| pain.001.001.03 — invalid IBANUn pain.001 portant un IBAN de créancier dont les deux chiffres de contrôle échouent au test mod-97 (ISO 7064). Tout le reste du fichier est correct : le validateur ne signale qu’une seule erreur. | Invalide | |
| pain.001.001.03 — NbOfTxs mismatchUn pain.001 qui se compte mal : NbOfTxs déclare une transaction alors que le fichier en contient deux. Comme CtrlSum, le compte est contrôlé sur le lot de paiement et sur l’en-tête du fichier. | Invalide | |
| pain.001.001.03 — unstructured address after 2026-11-15Le cas de référence de la règle d’adresse structurée EPC : les adresses ne portent que des AdrLine, sans TwnNm. Ce qui en fait une erreur bloquante, c’est la date d’exécution contenue dans le fichier (ReqdExctnDt = 2026-11-20, après le seuil du 15/11/2026) — avancez cette date et le même fichier ne produit plus qu’un avertissement. | Invalide | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15Le fichier de référence « prêt pour 2026 » : un virement pain.001.001.11 dont la date d’exécution (ReqdExctnDt = 2026-11-20) tombe après le seuil EPC d’adresse structurée du 15/11/2026. Chaque adresse de payeur et de bénéficiaire est entièrement structurée — StrtNm, BldgNb, PstCd, TwnNm, Ctry et pas une seule AdrLine. Trois virements, 4 320,00 EUR, zéro erreur et zéro avertissement. | Valide | |
| pain.001.001.09 — valid, two payment batches with different execution datesUn seul fichier pain.001, deux blocs PmtInf : le lot A s’exécute le 10/03/2026 avec des adresses hybrides (TwnNm + Ctry + une AdrLine), le lot B le 20/11/2026 avec des adresses entièrement structurées. Il démontre les deux leçons du fichier multi-lots : la règle d’adresse EPC s’évalue lot par lot, sur la date que porte le lot, et chaque PmtInf a ses propres NbOfTxs / CtrlSum en plus des totaux du GrpHdr (4 virements, 3 350,00 EUR). | Valide | |
| pain.001.001.03 — nine-character BICUn pain.001 dont le BIC de la banque du bénéficiaire fait neuf caractères. L’ISO 9362 en autorise 8 (établissement + pays + localité) ou 11 (plus un code guichet de 3 caractères) — jamais 9 ni 10. « BNPAFRPPX » est l’allure typique d’un code guichet tronqué ou complété à la main, et c’est le seul défaut du fichier que les deux couches attrapent : le XSD officiel le rejette sur son motif BIC, la couche métier sur sa longueur. | Invalide | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setUn pain.001 dont le bénéficiaire s’appelle « Café Renard & Fils SARL » — une lettre accentuée et une esperluette, toutes deux hors du jeu de caractères latin de base approuvé par l’EPC (a-z A-Z 0-9 et / - ? : ( ) . , ' + espace). Le XML est bien formé et le XSD officiel l’accepte sans broncher : Max70Text prend n’importe quelle chaîne. Ce défaut vit entièrement dans la couche métier — d’où le fait que ces fichiers arrivent jusqu’à la banque, qui les rejette ou les translittère en silence. | Invalide | |
| pain.001.001.03 — 250 transfers, high-volume payroll runUne paie réaliste : 250 virements SEPA dans un seul PmtInf, répartis sur cinq pays (DE, NL, BE, ES, FR), pour 442 028,75 EUR. Chaque IBAN porte des chiffres de contrôle mod-97 (ISO 7064) corrects et les deux totaux de contrôle égalent la somme exacte, au centime. À utiliser pour voir comment votre parseur, votre portail bancaire ou vos propres outils se comportent sur un fichier ni jouet ni pathologique — et pour vérifier qu’un seul centime faux dans un lot de cette taille reste attrapé par le seul CtrlSum. | Valide | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)Le jumeau de l’échantillon d’adresse non structurée bloquant, à une chose près : la date d’exécution. Mêmes adresses réduites à des AdrLine, mais ReqdExctnDt est au 30/09/2026, avant le seuil EPC153-22 v2.1 : le même défaut ressort en deux avertissements et non deux erreurs — le paiement passe encore aujourd’hui. Il montre aussi ce que « structuré » veut dire : l’adresse du débiteur n’a ni TwnNm ni Ctry, celle du créancier a un Ctry mais toujours pas de TwnNm. Ctry seul ne suffit pas : TwnNm est le discriminant. | Valide |
Prélèvement SEPA (pain.008) (8)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitUn prélèvement SEPA valide sous le schéma CORE : deux prélèvements récurrents pour 175,00 EUR, un Identifiant Créancier SEPA (ICS) qui passe le contrôle ISO 7064 MOD 97-10, et un mandat signé derrière chaque débiteur. | Valide | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15À quoi ressemble un prélèvement SEPA conforme après le seuil du 15/11/2026 : la date de prélèvement est le 20/11/2026, donc chaque adresse de créancier et de débiteur est structurée (TwnNm + Ctry). Schéma CORE, trois prélèvements pour 228,80 EUR, aucun avertissement. | Valide | |
| pain.008.001.02 — mandate signed after the collectionUn prélèvement exécuté sous un mandat que le débiteur n’avait pas encore signé : DtOfSgntr est au 10/04/2026 alors que le prélèvement est daté du 05/03/2026. Un défaut courant et silencieusement fatal — l’ICS, les IBAN et les totaux sont tous corrects. | Invalide | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceUn prélèvement SEPA B2B valide en pain.008.001.08 : LclInstrm/Cd = B2B, séquence RCUR, deux prélèvements récurrents pour 4 650,00 EUR. Le schéma B2B est la variante entre entreprises — le débiteur doit être un non-consommateur et n’a AUCUN droit au remboursement après règlement, d’où la vérification du mandat par sa banque avant le débit et une présentation plus précoce que le CORE. | Valide | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceUn prélèvement SEPA CORE valide en séquence FRST : la première présentation sous un mandat tout neuf (DtOfSgntr date de quelques jours). Tout ce qui suivra sur le même mandat doit partir en RCUR — laisser un lot en FRST indéfiniment est l’une des erreurs SDD les plus répandues, et la raison pour laquelle les banques retournent des prélèvements avec un motif de séquence incorrecte. | Valide | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceUn prélèvement SEPA ponctuel valide : séquence OOFF, un unique prélèvement de 349,00 EUR. Le mandat n’autorise qu’un seul débit et est consommé dès qu’il sert — il ne pourra plus jamais être présenté, pas même en RCUR. C’est la séquence de l’achat unique, de l’acompte ou du frais ponctuel ; utiliser FRST à sa place laisse ouvert, en silence, un mandat que le débiteur n’a jamais accepté. | Valide | |
| pain.008.001.02 — mandate identifier (MndtId) missingUn prélèvement sans identifiant de mandat : MndtRltdInf est bien là et porte une date de signature, mais l’élément MndtId (AT-01 du rulebook) est absent. Le XSD officiel ISO 20022 accepte le fichier — MndtId y est optionnel — si bien qu’un contrôle purement structurel le laisse passer et que la banque le rejette : sans référence de mandat, la banque du débiteur n’a rien à quoi rattacher le prélèvement, et le débiteur n’a rien à contester. | Invalide | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsUn prélèvement SEPA qui se compte et s’additionne mal, aux deux niveaux à la fois : le lot contient réellement 2 prélèvements pour 300,00 EUR, mais NbOfTxs annonce 3 et CtrlSum 250,00 — dans le PmtInf puis dans le GrpHdr. Cela fait quatre erreurs, pas deux : les totaux de contrôle sont vérifiés sur le lot de paiement ET sur l’en-tête, car un fichier multi-lots peut afficher un total d’en-tête correct posé sur deux totaux de lots faux. Le XML est bien formé et le XSD officiel l’accepte : pour un schéma, NbOfTxs et CtrlSum ne sont que des nombres. | Invalide |
Relevé bancaire (camt.052 / 053 / 054) (12)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| camt.053.001.02 — valid statementUn relevé bancaire camt.053.001.02 valide : quatre écritures, soldes d’ouverture et de clôture qui se réconcilient (OPBD ± mouvements = CLBD), et des dates au format Dt. | Valide | |
| camt.053.001.08 — valid statementUn relevé camt.053.001.08 valide : trois écritures, horodatages DtTm et BICFI à la place de BIC — les différences qui font trébucher au passage de la version 02 à la version 08. | Valide | |
| camt.053 — unsupported namespaceUn relevé déclarant camt.053.001.99, une version qui n’existe pas au catalogue ISO 20022. Utile pour vérifier que votre parseur rejette les namespaces inconnus au lieu de deviner. | Invalide | |
| camt.053.001.06 — missing Stmt elementUn relevé au namespace camt.053.001.06 correct mais sans aucun élément <Stmt> : l’enveloppe est bonne, le contenu manque. C’est l’allure qu’a un export bancaire tronqué. | Invalide | |
| camt.053.001.11 — valid statementUn relevé bancaire camt.053.001.11 valide — la version courante du message de relevé ISO 20022. Quatre écritures, OPBD 25 000,00 ± mouvements = CLBD 34 659,05. À noter, ce que la version 11 rend obligatoire sur chaque écriture : Sts et BkTxCd, que les versions antérieures laissaient omettre. | Valide | |
| camt.053.001.08 — three accounts in one fileUn seul message camt.053, trois blocs <Stmt> : un compte courant, un compte d’épargne et un compte en USD. Le fichier est conforme au schéma ; le validateur annonce explicitement qu’il n’analyse que le premier relevé. C’est tout l’intérêt : un lecteur qui prend Stmt[0] et s’arrête perd deux comptes en silence, et c’est ce fichier multi-comptes qui le démasque. | Valide | |
| camt.053.001.10 — fully detailed entriesTout ce qu’une banque peut accrocher sous une écriture camt.053, dans un seul fichier valide : NtryDtls/TxDtls avec EndToEndId, InstrId, TxId et MndtId ; RltdPties et RltdAgts ; une référence créancier structurée ISO 11649 (RF) et une facture référencée (CINV) ; une écriture groupée dont les deux TxDtls totalisent bien le montant de l’écriture ; et un BkTxCd ISO (PMNT/RCDT/ESCT) doublé d’un GVC propriétaire allemand. À utiliser pour mesurer ce que votre rapprochement lit vraiment d’une écriture. | Valide | |
| camt.053.001.08 — closing balance does not reconcileLe défaut le plus fréquent des camt.053 de production : l’ouverture à 4 200,00 plus les écritures comptabilisées donne 5 194,70, alors que le CLBD annonce 5 194,07 — deux chiffres transposés. Le fichier satisfait parfaitement le XSD officiel ISO 20022, car un schéma n’a rien à dire de l’arithmétique. Seul un contrôle de solde attrape une incohérence de solde de clôture. | Valide | |
| camt.052.001.08 — valid intraday reportUn rapport intraday camt.052 valide — et ce n’est pas un camt.053 en plus petit : la racine est BkToCstmrAcctRpt, le conteneur est <Rpt>, et les soldes sont INTERMÉDIAIRES (ITBD comptabilisé, ITAV disponible) au lieu du couple OPBD/CLBD d’un relevé de fin de journée. Il porte aussi une écriture en attente (Sts=PDNG) volontairement exclue du solde intermédiaire : l’argent en attente n’est pas de l’argent comptabilisé. | Valide | |
| camt.054.001.08 — valid debit/credit notificationUn avis de débit/crédit camt.054 valide : un crédit SEPA entrant et un prélèvement sortant, chacun avec ses TxDtls complets et sa référence de bout en bout. La surprise structurelle est ce qui n’y est PAS : un camt.054 n’a aucun élément <Bal> — le schéma ISO 20022 n’en définit pas. Un avis annonce des mouvements, il n’énonce jamais de solde : il n’y a rien à rapprocher. | Valide | |
| camt.053.001.08 — entry with no CdtDbtIndLa deuxième écriture porte un montant de 1 200,00 et aucun <CdtDbtInd>. En camt.053, les montants sont toujours non signés : sans l’indicateur de sens, le montant ne veut rien dire. Deux choses cassent d’un coup — le XSD officiel rejette le fichier (CdtDbtInd est obligatoire 1..1 sur une écriture), et un parseur qui bascule silencieusement sur CRDT comptabilise +1 200,00 au lieu de −1 200,00 et se retrouve à 2 400,00 de la vérité, ce que le contrôle de solde met alors au jour. | Invalide | |
| camt.053.001.08 — 220 entries, validUn relevé d’entreprise de fin de mois avec 220 écritures comptabilisées, toutes réconciliées : OPBD 125 000,00 ± mouvements = CLBD 209 081,69. Chaque écriture porte ses NtryDtls/TxDtls, un EndToEndId et une contrepartie : de quoi éprouver un lecteur camt.053 à volume réaliste plutôt que sur un fichier jouet de trois lignes — débit de parsing, rendu du tableau, rapprochement sur des centaines de lignes. | Valide |
Facture UBL (Peppol BIS 3.0) (12)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Une facture Peppol BIS Billing 3.0 valide : trois lignes, 2 596,00 EUR TTC, totaux cohérents, numéro de TVA français et IBAN de paiement. | Valide | |
| UBL Credit Note — valid Peppol BIS 3.0Un avoir Peppol BIS Billing 3.0 valide : une ligne, 1 770,00 EUR TTC, référençant la facture d’origine qu’il annule. L’avoir est un type de document UBL distinct, pas une facture à montants négatifs. | Valide | |
| UBL Invoice — BR-CO-10 violationUne facture qui viole la règle EN 16931 BR-CO-10 : la somme des montants nets de lignes (1 000,00) ne vaut pas le total du document BT-106 (2 000,00). L’un des rejets les plus fréquents sur le réseau Peppol. | Invalide | |
| UBL Invoice — malformed seller VAT identifierUne facture dont le numéro de TVA du vendeur, « FR1234 », est trop court : un numéro français, c’est FR suivi d’une clé de deux caractères et de neuf chiffres. Les erreurs de format sur BT-31 sont attrapées bien avant l’administration fiscale. | Invalide | |
| UBL Invoice — allowances and charges, line and document levelUne facture UBL Peppol BIS 3.0 valide portant remises et frais aux DEUX niveaux : une remise de ligne (BG-27), une majoration de ligne (BG-28), une remise au niveau document (BG-20) et des frais de port (BG-21). Tout l’intérêt est l’enchaînement des totaux : BT-106 = 1 520,00 est la somme des montants de ligne NETS, et BT-109 = 1 530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13) — la TVA à 19 % porte donc sur 1 530,00, pas sur 1 520,00. | Valide | |
| UBL Invoice — reverse charge (VAT category AE)Une facture d’autoliquidation valide en UBL : un prestataire français facture des services à une entreprise allemande, la TVA est due par le preneur, donc taux à 0 % et aucune TVA facturée. La catégorie AE apporte quatre règles : les deux numéros de TVA (BR-AE-02, BR-AE-03), le taux à 0 % (BR-AE-05), un montant de TVA de 0,00 (BR-AE-09) et un motif d’exonération (BR-AE-10), ici VATEX-EU-AE et la mention « Reverse charge ». | Valide | |
| UBL Invoice — VAT exempt (category E) with exemption reasonUne facture exonérée de TVA valide (catégorie E) : formation professionnelle exonérée au titre de l’article 132, §1, point i) de la directive 2006/112/CE. Une facture exonérée doit dire POURQUOI elle l’est — BR-E-10 exige un code de motif d’exonération (BT-121) ou un texte (BT-120) ; ce fichier porte les deux : VATEX-EU-132 et le libellé de la liste de codes officielle. | Valide | |
| UBL Invoice — intra-Community supply (VAT category K)Une livraison intracommunautaire valide (catégorie de TVA K) : marchandises expédiées d’Allemagne vers un acheteur assujetti en France, exonérées au titre de l’article 138 de la directive 2006/112/CE. La catégorie K réclame deux éléments qu’on oublie : BR-IC-11, une date de livraison effective (BT-72) ou une période de facturation, et BR-IC-12, le pays de livraison (BT-80). Sans eux, la facture ne prouve pas que les biens ont quitté le pays. | Valide | |
| UBL Invoice — two VAT rates, one breakdown per rateUne facture valide mêlant taux normal français (20 %) et taux réduit (5,5 %). La règle que ce fichier illustre est BR-S-08 : la ventilation de TVA (BG-23) porte UN TaxSubtotal par couple (catégorie, taux), et chaque base imposable est la somme des lignes de ce couple — 1 500,00 à 20 % (TVA 300,00) et 400,00 à 5,5 % (TVA 22,00). Fondre deux taux en un seul sous-total passe tous les contrôles BR-CO et reste faux. | Valide | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106Le rejet le plus fréquent en production, isolé : les deux lignes totalisent 1 500,00 alors que BT-106 (LineExtensionAmount) déclare 1 400,00 — BR-CO-10. Tout le reste est cohérent avec le chiffre FAUX, donc BR-CO-13, BR-CO-14, BR-CO-15 et BR-CO-16 passent et une seule erreur remonte. C’est l’allure exacte d’une ligne supprimée après le calcul des totaux. | Invalide | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Une facture exonérée ratée, deux fois. BR-E-10 : la ventilation de TVA de la catégorie E ne porte ni motif d’exonération (BT-120) ni code de motif (BT-121) — une facture exonérée doit dire POURQUOI. BR-E-08 : la base exonérée déclare 1 200,00 alors que les lignes exonérées totalisent 1 500,00, la seconde ligne n’ayant jamais rejoint la ventilation. L’erreur citée est celle que remonte la couche métier ; le Schematron officiel EN 16931 y ajoute BR-E-10. | Invalide | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateUne ventilation de TVA qui ne tombe pas juste : une base de 2 000,00 à 19 % fait 380,00 de TVA, mais la facture déclare 395,00. BR-CO-17 vérifie que le montant de TVA de la catégorie = base × taux / 100, avec la marge officielle d’une unité monétaire — un vrai centime d’arrondi est donc toléré, cet écart de 15,00 non. Tous les autres totaux collent au chiffre faux : c’est ainsi qu’un bug d’arrondi survit jusqu’en production. | Invalide |
Facture CII (syntaxe XRechnung / Factur-X) (4)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validUne facture XRechnung 3.0 valide en syntaxe CII (UN/CEFACT CrossIndustryInvoice) — la facture électronique du secteur public allemand. Elle porte ce que les règles BR-DE de la KoSIT ajoutent à EN 16931 : le Leitweg-ID comme référence acheteur (BR-DE-15), un point de contact vendeur complet — nom, téléphone et e-mail (BR-DE-2 à BR-DE-6), l’adresse électronique du vendeur, des conditions de paiement structurées et un virement SEPA (moyen de paiement 58). | Valide | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)La charge utile Factur-X / ZUGFeRD toute seule : le XML CII qui voyage normalement à l’intérieur d’un PDF/A-3, ici en fichier autonome directement validable. Le profil BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) est un CIUS conforme EN 16931 — lignes de facture complètes, ventilation de TVA et les six totaux du document. Utile pour tester un extracteur sur le XML seul, sans le PDF autour. | Valide | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 en syntaxe CII : les deux lignes totalisent 2 000,00 mais LineTotalAmount (BT-106, dans SpecifiedTradeSettlementHeaderMonetarySummation) déclare 1 900,00. Le même défaut que l’échantillon UBL, dans la syntaxe où il se voit le moins — les totaux du document vivent dans une branche de l’arbre différente de celle des lignes qu’ils résument. | Invalide | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisUne remise au niveau document qui n’existe qu’à moitié : la facture accorde 200,00 (BT-107), calcule la TVA sur la base remisée (1 800,00 × 19 % = 342,00 — correct), mais BT-109 (TaxBasisTotalAmount) déclare toujours 2 000,00 sans remise. BR-CO-13 impose BT-109 = BT-106 - BT-107 + BT-108 : l’acheteur est donc facturé de 200,00 que le vendeur croyait avoir offerts. | Invalide |
Relevé SWIFT MT940 (10)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectLe cas nominal MT940 : un relevé, un crédit et un débit, avec le couple référence client / référence banque dans la ligne :61:. Commencez par celui-ci pour voir la structure des tags avant les dialectes. | Valide | |
| MT940 — ING Belgium, structured :86:Le dialecte ING Belgique : la ligne d’information :86: est structurée en sous-champs ?00 ?20 ?30 plutôt qu’en texte libre. C’est la première source de bugs de parsing MT940. | Valide | |
| MT940 — Commerzbank, one-decimal amountLe dialecte Commerzbank : un montant écrit avec une seule décimale (1234,5 pour 1 234,50), un type de transaction NMSC et un compte allemand donné en BLZ + numéro plutôt qu’en IBAN. | Valide | |
| MT940 — two statements in one fileDeux relevés dans un même fichier MT940, plus le tag de solde disponible :64:. Un fichier n’est pas un relevé, et un parseur qui le suppose perdra le second en silence. | Valide | |
| MT940 — reversal (RC) and intermediate balancesLe cas ABN AMRO : une contre-passation RC (un crédit rebasculé en débit), des soldes intermédiaires 60M/62M au lieu de F, et un :86: sur deux lignes. Les contre-passations inversent le sens — se tromper ici, c’est un solde qui ne se réconcilie jamais. | Valide | |
| MT940 — overdrawn account (debit balances)Un compte à découvert : les soldes d’ouverture et de clôture portent tous deux le marqueur D (débiteur). En MT940, un solde négatif n’est pas un nombre négatif : c’est un drapeau de signe, et le code qui l’ignore présente le découvert comme un avoir. | Valide | |
| MT940 — closing balance does not reconcileUn relevé dont le solde de clôture ne découle pas de l’ouverture ± les mouvements. C’est volontairement un avertissement et non une erreur bloquante : le fichier reste lisible et c’est à un humain de trancher entre la banque et l’export. | Valide | |
| MT940 — 500 transactions (load test)Cinq cents transactions dans un seul relevé, équilibrées au centime. À utiliser pour vérifier que votre parseur reste exact — et rapide — à volume réel, et pas seulement sur un fichier jouet de trois lignes. | Valide | |
| MT940 — statement split over two pages (62M / 60M)Un relevé, une journée, deux pages : la séquence 00147/00001 se clôt sur un solde INTERMÉDIAIRE :62M: et la séquence 00147/00002 rouvre sur :60M: avec exactement ce montant, avant de se clore sur le :62F: final. M n’est pas F : prendre le solde intermédiaire pour le solde final du jour, c’est annoncer 37 500,00 alors que le compte a terminé à 44 249,25. | Valide | |
| MT940 — USD account with an RD reversalUn relevé en dollars — MT940 n’est pas un format euro — où un virement sortant de 35 000,00 est retourné le lendemain par une contre-passation RD : un DÉBIT CONTRE-PASSÉ, c’est de l’argent qui REVIENT. Les marqueurs RC/RD inversent le sens économique de la ligne :61:, et un parseur qui ne lit que le D de « RD » comptabilise le remboursement une seconde fois en paiement et ne réconcilie jamais. | Valide |
Relevé BAI2 (US / Canada) (6)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)Le fichier BAI2 nominal : un compte, un solde d’ouverture 010 et de clôture 015, et dix transactions dont le sens ne vient que du type code — 115 dépôt lockbox, 165 crédit ACH, 195 virement entrant, 475 chèque payé, 451 débit ACH, 495 virement sortant, 698 frais. BAI2 n’a aucun indicateur débit/crédit : 100–399 = entrée, 400–699 = sortie. | Valide | |
| BAI2 — several accounts in one groupDeux enregistrements de compte 03 dans un même groupe 02 — un compte d’exploitation et un compte de paie, chacun clos par son propre trailer 49. BAI2 est hiérarchique (01 fichier / 02 groupe / 03 compte / 16 transaction / trailers 49-98-99) : un lecteur qui suppose un compte par fichier perd le second en silence. | Valide | |
| BAI2 — 88 continuation recordsL’enregistrement de continuation 88, dans ses deux rôles très différents : il porte des tuples de solde supplémentaires pour un enregistrement de compte 03 (ici la clôture 015 et le disponible 045) et du texte libre replié pour une transaction 16 (trois lignes physiques, une seule chaîne de communication). Les fusionner de la même façon, c’est lire les soldes comme du texte — ou le texte comme des soldes. | Valide | |
| BAI2 — CAD and JPY: minor units scale with the currencyLes montants BAI2 n’ont pas de séparateur décimal : ce sont des unités mineures, et le nombre de décimales implicites dépend de la devise. Ici « 2500000 » vaut 25 000,00 CAD sur le compte CAD (2 décimales) et 2 500 000 ¥ sur le compte JPY (0 décimale). Le compte CAD laisse en plus sa zone devise vide et l’hérite de l’en-tête de groupe 02. Une division par 100 en dur corrompt le compte en yens de deux ordres de grandeur — et le solde se réconcilie quand même, puisque les trois chiffres sont faux du même facteur. | Valide | |
| BAI2 — closing balance does not reconcileLe solde de clôture 015 ne découle pas du solde d’ouverture 010 plus les mouvements 16 — 50 000,00 + 10 000,00 − 2 500,00 font 57 500,00, mais le fichier annonce 59 000,00. Les trailers, eux, tombent juste : seule l’arithmétique le trahit. Volontairement un avertissement et non une erreur bloquante : le fichier reste lisible et c’est à un humain de trancher entre la banque et l’export. | Valide | |
| BAI2 — bad trailer totals and an out-of-range type codeTrois défauts d’un coup. Le trailer de compte 49 annonce un total de contrôle et un nombre d’enregistrements qui ne correspondent ni l’un ni l’autre aux enregistrements qui le précèdent — les trailers sont le contrôle d’intégrité propre au fichier, et qui les ignore ne voit pas une troncature. Et une transaction 16 porte le type code 720, qui tombe dans la plage prêts 700–799 : ce n’est ni un crédit (100–399) ni un débit (400–699), son sens ne peut pas être déduit et elle est écartée plutôt que devinée — d’où le solde qui ne se réconcilie plus non plus. | Valide |
Factur-X / ZUGFeRD (PDF) (2)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceUne facture Factur-X valide au profil EN 16931 : un PDF/A-3 avec le XML CII embarqué à l’intérieur. Un seul document qu’un humain lit et qu’une machine parse — c’est tout l’intérêt du format hybride. | Valide | |
| Factur-X EN 16931 — BR-CO-15 violationUne facture Factur-X qui viole la règle EN 16931 BR-CO-15 : le TTC vaut 130,00 alors que HT + TVA font 120,00. Le PDF s’ouvre et paraît parfaitement normal — seul le XML embarqué le trahit. | Invalide |
Facture KSeF (Pologne, FA(3)) (7)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Une facture structurée FA(3) conforme — l’exemple n° 4 publié par le ministère des Finances polonais, reproduit tel quel. Trois lignes, 64 279,92 PLN TTC à 23 %. À utiliser comme référence de ce que KSeF accepte. | Valide | |
| KSeF — invoice still using the retired FA(2) schemaL’échec de migration KSeF le plus fréquent : une facture parfaitement bien formée, mais qui déclare encore l’espace de noms FA(2), retiré le 1er février 2026. Rien ne semble anormal jusqu’au rejet par KSeF. À noter, ce que FA(3) a ajouté et qui manque ici : Podmiot2 exige désormais JST et GV. | Invalide | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Structurellement parfaite au regard du schéma officiel, et pourtant le NIP du vendeur échoue à sa clé mod-11 et P_15 ne correspond pas à la somme de la ventilation de TVA. ValidateFin signale les deux en avertissement, pas en erreur : aucune de ces règles n’est normative, et l’exemple n° 1 du ministère lui-même est décalé d’un grosz. | Valide | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Une facture correctrice (RodzajFaktury = KOR), le cas FA(3) le plus recherché et le plus souvent mal construit. Ses totaux portent l’ÉCART, pas la facture rectifiée : P_13_1, P_14_1 et P_15 sont négatifs. Apparaissent aussi PrzyczynaKorekty, TypKorekty et DaneFaKorygowanej, qui renvoient à la facture corrigée. Les lignes vont par paires : celle qui porte StanPrzed est l’état avant. | Valide | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Une facture d’acompte (RodzajFaktury = ZAL) : elle facture un acompte sur une commande non encore livrée. Elle ne porte donc AUCUNE ligne FaWiersz — les biens figurent dans le bloc Zamowienie (commande), avec ses propres balises P_7Z / P_11NettoZ / P_11VatZ — tandis que P_15 n’affiche que l’acompte de 12 300,00 PLN sur une commande de 61 500,00 PLN. | Valide | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Une facture FA(3) à laquelle il manque un élément obligatoire : P_2, le numéro de facture. Rien ne cloche à l’œil — XML bien formé, bon espace de noms, ventilation de TVA plausible — et seul le XSD officiel du ministère des Finances l’attrape : « Element P_6: this element is not expected. Expected is P_2. » KSeF rejette purement et simplement un tel fichier. | Invalide | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)Le NIP de l’acheteur est 1111111112 — dix chiffres, donc le schéma officiel, qui ne contraint le NIP que par un motif, l’accepte sans broncher. Sa clé mod-11 est fausse : aucun numéro fiscal polonais de ce type ne peut exister, et la facture n’est adressée à personne. ValidateFin émet un avertissement, jamais une erreur — le ministère ne publie aucune règle de validation de ce genre. | Valide |
Facture FatturaPA (Italie, SdI) (4)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyUne FatturaPA que le SdI accepterait : arithmétique de TVA juste (deux lignes à 22 % pour 1 100 €, 242 € de taxe, 1 342 € au total), identifiants fiscaux dont le chiffre de contrôle est correct, et un CodiceDestinatario de 7 caractères comme l’exige un destinataire privé. C’est le point de référence : les autres échantillons sont ce fichier, cassé d’une manière précise. | Valide | |
| FatturaPA — signed CAdES (.p7m) envelopeLa même facture conforme, enveloppée dans une signature CAdES (.p7m) — la forme sous laquelle circulent la plupart des factures italiennes réelles, et la forme OBLIGATOIRE vers l’administration publique. Ouvert dans un éditeur de texte, le fichier n’est que du binaire. Le validateur ouvre l’enveloppe et contrôle le XML qu’elle contient ; il ne vérifie pas la signature elle-même, et le dit. | Valide | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Cette facture est VALIDE au sens du XSD officiel et le SdI la rejetterait quand même — c’est précisément pourquoi un contrôle de schéma ne suffit pas. Trois défauts : la base imposable déclare 1 150 € pour des lignes qui somment à 1 100 € (contrôle 00422, dont la tolérance est de un EURO, pas un centime) ; la taxe déclare 250 € là où 22 % de 1 150 € font 253 € (00421) ; et le code Natura est le N3 nu, retiré le 1er janvier 2021 au profit de ses sous-codes (00445) — alors qu’il figure toujours dans l’énumération du schéma. | Invalide | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)La façon la plus courante de faire rejeter une facture adressée à une administration italienne : le CodiceDestinatario. Pour une PA (FormatoTrasmissione = FPA12), ce doit être le code bureau IPA sur SIX caractères — la forme à sept caractères est réservée aux destinataires privés. Le XSD autorise 6 OU 7 pour les deux : le schéma ne peut pas le voir, seul le contrôle SdI 00427 le voit. Le numéro de facture, « FATTURA », ne contient par ailleurs aucun chiffre (00425). | Invalide |
Facture RO e-Factura (Roumanie, ANAF) (6)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Une facture que l’ANAF accepte — son propre validateur hors ligne répond « este valid ». C’est l’exemple publié par le ministère, réparé sur les deux points qui font échouer la version publiée : BT-24 remis à CIUS-RO:1.0.1, et deux CUI dont le chiffre de contrôle est réellement juste. C’est le point de référence : chaque échantillon cassé est ce fichier, abîmé d’une manière précise. | Valide | |
| RO e-Factura — credit note in a foreign currency (FCN)Une note de crédit (FCN) libellée en SEK — et l’ANAF l’accepte. Elle montre ce qu’exige réellement BR-RO-030 : RON doit apparaître comme devise de la facture (BT-5) OU comme devise de comptabilisation de la TVA (BT-6), pas forcément les deux. Ici BT-5 vaut SEK et BT-6 vaut RON, ce qui satisfait la règle. Elle porte aussi le code de type 381, licite sur une note de crédit et interdit sur une facture. | Valide | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)Le rejet roumain le plus fréquent, et le seul défaut de ce fichier : BT-24 dit encore CIUS-RO:1.0.0, une valeur morte depuis le 29 décembre 2022 (ordre OMF 4092/2022). La facture est irréprochable par ailleurs et passe le XSD. Les deux exemples que le ministère publie encore portent ce défaut — et son propre validateur les rejette. | Invalide | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Un vendeur à Bucarest dont la ville (BT-37) est écrite « Sector 1 » — l’orthographe exacte qu’emploie l’ordre du ministre lui-même. Le Schematron que l’ANAF exécute réellement exige SECTOR1 : majuscules, sans espace. Quand le texte de loi et l’implémentation divergent, c’est l’implémentation qui rejette votre facture. | Invalide | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)L’échantillon qui révèle l’angle mort de tout validateur qui n’exécute que le Schematron. Le CUI de l’acheteur (RO987456123) a un chiffre de contrôle faux — et AUCUNE règle du Schematron ne le regarde. Ce fichier passe le XSD, passe tout le corpus CIUS-RO, et l’ANAF le rejette quand même, sous un code à elle : ERRIdentif, « CUI cumparator incorect ». | Invalide | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Une facture B2C dont l’acheteur est un particulier, identifié par le CNP anonyme de treize zéros — en production depuis le 16 décembre 2024. Elle est valide, et un validateur qui y verrait un numéro personnel mal formé casserait toute la facturation aux consommateurs roumains : ce numéro ne survit à aucune règle de forme du CNP (son premier chiffre, 0, est refusé partout ailleurs), parce que c’est une valeur réservée, pas un CNP. | Valide |
Registre de facturation Verifactu (Espagne, AEAT) (3)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosUn envoi que l’AEAT accepterait : deux registres d’enregistrement correctement chaînés. Le premier se déclare premier de la chaîne et hache une empreinte précédente vide ; le second chaîne la huella du premier. Les deux empreintes sont réelles (SHA-256 sur la chaîne exacte spécifiée par l’AEAT), pas inventées. C’est le point de référence : les autres échantillons sont ce fichier, cassé d’une manière précise. | Valide | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)Le second registre déclare une empreinte qui ne correspond PAS à son contenu : la chaîne est rompue. Le fichier est VALIDE contre le XSD officiel de l’AEAT — un validateur qui ne regarde que le schéma le déclare bon. Seul le recalcul du SHA-256 chaîné le détecte. Et attention : l’AEAT ne le rejette PAS, elle le marque « Aceptado con errores » (code 2000) et l’enregistre quand même, à corriger. | Valide | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Une facture simplifiée (F2) qui porte un bloc Destinatarios — interdit, code 1190 — et dont la CuotaRepercutida (100 €) ne correspond pas à la base × le taux (1 000 € × 21 % = 210 €), bien au-delà de la tolérance de ±10 € du contrôle 1142. Le fichier PASSE le XSD officiel sans une plainte : le schéma ne peut pas le voir, l’AEAT le rejette. | Invalide |
Facture Facturae (Espagne, FACe) (2)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaUne facture Facturae 3.2.2 adressée à une administration publique (avec ses centres administratifs DIR3 — oficina contable, órgano gestor, unidad tramitadora — comme l’exige FACe) qui passe le XSD officiel de facturae.gob.es sans une plainte, tous les totaux cohérents selon les formules du schéma lui-même et une signature XAdES présente. C’est le point de référence : l’autre échantillon est ce même fichier, cassé d’une manière précise. La signature est un échantillon : sa validité cryptographique n’est pas vérifiée hors ligne. | Valide | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)Le même fichier, à un changement près : InvoiceTotal déclare 1200,00 € là où la formule du schéma donne 1210,00 € (base 1000 + TVA 210). Le fichier est VALIDE contre le XSD officiel de facturae.gob.es — un validateur qui ne regarde que le schéma le déclare bon. Seule la couche de cohérence le détecte, et signale aussi que le total du lot ne cadre plus. Ce n’est pas un rejet « officiel » : Facturae/FACe ne publie aucun code de rejet vérifiable hors ligne, c’est donc un avertissement, pas une erreur. | Valide |
Relevé CODA (Belgique) (6)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationUn relevé belge ordinaire : un virement SEPA portant une communication structurée valide (+++090/9337/55493+++), un paiement par carte et un virement reçu avec sa contrepartie. Ancien solde 1 000,00 − 250,00 − 89,90 + 1 500,00 = nouveau solde 2 160,10, et les totaux du trailer concordent. | Valide | |
| CODA — globalised salary run (booked total + its details)Une globalisation : un total de salaires comptabilisé de 3 000,00 (numéro de détail 0000) suivi des deux salaires individuels qui le composent (0001, 0002). Seul le total est comptabilisé — un parseur qui somme aussi les détails double-compte le fichier et le relevé cesse d’équilibrer. Se clôt sur un solde débiteur de 2 000,00. | Valide | |
| CODA — wrong mod-97 check digits and a statement that does not balanceCassé à dessein. La communication structurée finit par 94 là où le mod 97 exige 93 — la première cause de non-rapprochement d’un paiement belge avec sa facture — et le nouveau solde ne découle pas des mouvements. Aucun autre outil CODA gratuit ne contrôle ces chiffres de contrôle. | Valide | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedUn relevé CODA portant les deux références structurées que le format autorise, chacune avec sa clé : un virement émis avec une communication structurée belge +++090/9337/55493+++ (type 101, mod 97 — où un reste de 0 s’écrit 97 et non 00) et un virement reçu avec une référence créancier ISO 11649 RF73INV20260042 (type 100, mod 97-10). Les deux sont valides, et le relevé équilibre : 1 000,00 − 250,00 + 1 500,00 = 2 250,00. | Valide | |
| CODA — separate application: balances zeroed by design (§7.2.1)Une « separate application » CODA (positions 84-88 de l’en-tête = 00001) : une remise d’acceptation carte livrée en dehors du relevé de compte. Le §7.2.1 de Febelfin met ses anciens et nouveaux soldes à zéro par construction : l’identité ancien solde ± mouvements = nouveau solde ne peut donc pas tenir — et ne doit pas être contrôlée. ValidateFin la neutralise ici et déclare le fichier propre ; un validateur qui ne le fait pas signale tout fichier de ce type comme cassé. | Valide | |
| CODA — old balance ± movements ≠ new balanceUn relevé belge ordinaire — à un mouvement près. Les enregistrements 2.1 donnent 1 000,00 − 250,00 + 1 500,00 = 2 250,00, mais l’enregistrement « 8 » de nouveau solde déclare 2 200,00 : 50,00 de mouvement comptabilisé n’ont jamais atteint le fichier. C’est ce contrôle qui attrape un CODA tronqué, un enregistrement perdu ou un sens débit/crédit mal lu — et c’est pour cela que l’échantillon précédent ne doit PAS être contrôlé de la même façon. | Valide |
Relevé CFONB 120 (France) (5)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsUn relevé français portant toutes ses données SEPA : un prélèvement avec sa référence de mandat et sa séquence RCUR, le nom du créancier, un paiement par carte, et un virement reçu avec le nom du payeur, la référence de bout en bout, le motif et le libellé — le tout dans des enregistrements « 05 ». Ancien solde 1 000,00 − 250,00 − 89,90 + 1 500,00 = nouveau solde 2 160,10. | Valide | |
| CFONB 120 — amount without its overpunched signCassé à dessein, et c’est la façon classique de corrompre un fichier CFONB : le montant du débit finit par un chiffre nu au lieu d’un caractère de signe surimprimé, donc le fichier ne dit jamais qu’il s’agit d’un débit. Il est lu comme un crédit — et c’est l’identité comptable exigée par le CFONB qui le rattrape. | Valide | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYLes données SEPA d’un relevé CFONB 120 vivent dans les enregistrements « 05 », et chacun découpe autrement la même zone de 70 caractères (positions 49-118) : RUM porte une référence de mandat ET son type de séquence (RCUR), REF une référence de lot ET une référence d’opération, RCN un identifiant de bout en bout ET un motif, tandis que NBE, NPY et LIB occupent toute la zone. Lue à plat, la zone colle le mandat à son type de séquence. Ce fichier porte un prélèvement SEPA (opération B1) et un virement reçu, avec dix qualifiants différents entre les deux. | Valide | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileUn seul fichier CFONB 120, deux comptes : chacun forme son propre bloc 01 (ancien solde) … 07 (nouveau solde), et chacun équilibre séparément. Le second ouvre à DÉCOUVERT — l’ancien solde porte un signe surimprimé de la famille « } », donc un débit — et remonte à un solde créditeur de 179,60. Un parseur qui tient un solde unique pour tout le fichier, ou qui lit le caractère de signe comme un chiffre, se trompe sur les deux comptes. | Valide | |
| CFONB 120 — the new balance does not equal old balance ± movementsTous les montants portent ici un signe surimprimé correct — et le relevé n’équilibre pourtant pas : 1 000,00 − 89,90 + 500,00 = 1 410,10, alors que l’enregistrement « 07 » déclare 1 310,10. La règle 2 du §1 de la spec CFONB pose cette identité comme la DÉFINITION d’un relevé conforme : ce n’est donc pas une heuristique, il manque 100,00 de mouvement dans le fichier. | Valide |
Message Fedwire ISO 20022 (États-Unis) (6)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferUn virement client avec en-tête BAH et adresses postales hybrides — il respecte déjà le format exigé à partir du 16 novembre 2026. | Valide | |
| Fedwire pacs.009 — conformant bank-to-bank transferUn virement entre institutions financières : le segment interbancaire, où débiteur et créancier sont des banques et non des clients. | Valide | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026L’adresse du créancier tient en trois lignes libres, sans ville ni pays. Valide au regard du XSD, rejetée par la règle : à partir du 16 novembre 2026, Fedwire supprime l’adresse entièrement non structurée. | Invalide | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overLe contre-exemple, et toute la raison d’être de la paire : exactement la même adresse non structurée, mais un règlement au 30/06/2026. Elle est légale, donc elle produit un avertissement — pas une erreur. Le déclencheur est la date de règlement portée par le message, jamais la date du jour. | Valide | |
| Fedwire pacs.008 — routing number that cannot existLe routing number de la banque du bénéficiaire est 021000088 — un chiffre de travers. Il échoue au chiffre de contrôle ABA 3-7-1 : ce numéro ne peut pas exister. Le XSD, lui, voit neuf chiffres parfaitement valides. | Invalide | |
| Fedwire — header announces a different message than it carriesL’en-tête BAH déclare <MsgDefIdr>pacs.009.001.08</MsgDefIdr> alors que le document qu’il coiffe est un pacs.008. Chaque moitié est valide contre son propre schéma : seule la confrontation des deux le détecte. | Invalide |
Virement SWIFT MT103 (2)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| MT103 — cross-currency customer credit transferUn MT103 complet : les cinq blocs SWIFT, un UETR, un donneur d’ordre en option K, des agents en option A et un bénéficiaire IBAN. Réglé en USD, instruit en EUR — le champ :36: (taux de change) est donc requis, et il est présent. | Valide | |
| MT103 — three defects a plain text viewer would missStructurellement, un MT103 parfaitement lisible — et faux trois fois : l’UETR n’est pas un UUID v4, le paiement est multidevise sans taux de change en :36:, et l’IBAN du bénéficiaire échoue à la clé mod-97. | Valide |
Fichier de paiements CPA-005 / AFT (Canada) (6)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Un fichier de paie canadien ordinaire : un seul enregistrement « C » portant deux dépôts directs (type d’opération 200) dans deux de ses six segments. Le trailer Z déclare 2 crédits pour 3 750,50 et aucun débit, et il concorde. À noter : le compteur d’enregistrements compte des enregistrements PHYSIQUES quand le trailer compte des TRANSACTIONS — il y a trois enregistrements et deux transactions. | Valide | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Un prélèvement préautorisé « D » de 899,00 suivi de l’enregistrement « J » qui le retourne. Le retour porte le code 901 (provision insuffisante) dans le champ TYPE D’OPÉRATION — là où le paiement porterait son type — tandis que le type d’origine 700 survit dans le stored transaction type. Les deux sont comptés en débits, d’où les 2 débits pour 1 798,00 déclarés au trailer. | Valide | |
| CPA-005 — the error correction folded into the debit totalCassé à dessein, et cassé comme le cassent les vrais générateurs : le fichier annule un crédit par un enregistrement « E », et le trailer compte cette annulation comme un débit. Elle n’en est pas un. La norme 005 donne aux corrections E et F leur PROPRE paire de totaux, distincte des paires débit et crédit — les fondre ensemble déséquilibre le fichier. C’est la première cause de rejet d’un générateur CPA-005 écrit à la main. | Invalide | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedUn fichier AFT de 1464 caractères mêlant les deux sens : un enregistrement « C » portant deux dépôts de paie (3 750,50) et un enregistrement « D » portant deux prélèvements préautorisés (1 349,25). C est le CRÉDIT et D le DÉBIT — plusieurs résumés publiés les inversent. Le trailer Z équilibre sur les quatre paires de totaux que définit la norme 005 (D+J, C+I, E à part, F à part), ici avec les compteurs E et F à zéro. | Valide | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Une Notice of Change canadienne : l’institution destinataire signale à l’émetteur qu’un compte a changé. C’est un FICHIER À PART — les enregistrements font 208 caractères et non 1464, et la norme 005 interdit de mêler ses enregistrements U (en-tête), S (changement) et V (trailer) aux enregistrements AFT. Chaque S porte le nouveau numéro d’acheminement et le nouveau compte à côté des anciens, et le trailer V déclare combien de S le fichier contient. | Valide | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaUn fichier de paie client→banque qu’un validateur formé aux règles américaines rejetterait deux fois à tort. Son premier crédit part sur le transit 099999999, qui ne porte aucun chiffre de contrôle arithmétique — le transit canadien n’en a tout simplement pas : la norme 005 le valide par consultation du Financial Institutions File, et la norme 006 ne définit aucune formule. Transposer ici le 3-7-1 américain rejette des fichiers parfaitement valides. Ses Item Trace Numbers sont par ailleurs laissés à zéro, ce qui est normal sur un fichier envoyé par un client à sa banque (c’est le Direct Clearer qui les attribue) — d’où deux avertissements et zéro erreur. | Valide |
Fichier ACH / NACHA (US) (10)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Un débit WEB de 123,54 qui revient. Trois choses changent sur un retour, et rien d’autre : le transaction code devient 26 (le code de retour d’un débit sur compte courant — PAS le 27 d’origine), la banque réceptrice devient l’ODFI de l’origine, et un nouveau trace number est attribué. Le montant est inchangé — l’ACH ne connaît pas le retour partiel. L’addenda 99 porte R01 et pointe vers le trace de l’entrée d’origine. Le batch reste WEB et reste TRANSFER : il n’existe ni description « RETURN » ni code SEC « RET », quoi qu’en dise le web. | Valide | |
| ACH — a notification of change (C01, corrected account number)Une notification de changement — et ce qu’il faut comprendre, c’est que ce n’est PAS un rejet. Le paiement est passé. La banque réceptrice demande la correction de la donnée stockée avant le PROCHAIN paiement : renvoyer celui-ci paierait le bénéficiaire deux fois. D’où le montant à ZÉRO de l’entrée, et le code SEC COR du batch. L’addenda 98 porte C01 avec le numéro de compte corrigé en positions 36-52 de l’enregistrement. | Valide | |
| ACH — an international entry (IAT) with its seven mandatory addendaUn paiement USD → MXN vers le Mexique. Un enregistrement IAT n’est pas l’enregistrement domestique avec d’autres étiquettes : le numéro de compte passe en positions 40-74 (35 caractères, pour loger un compte étranger), les positions 13-16 déclarent le nombre d’addenda qui suivent, et le nom du bénéficiaire n’est pas dans l’enregistrement du tout — il vit dans l’addenda 10. Sept addenda (10 à 16) sont obligatoires sur toute entrée internationale, parce qu’un enregistrement de 94 caractères ne peut pas contenir le nom, l’adresse et l’identification bancaire des deux parties. Lire ce fichier avec les décalages domestiques renvoie un fragment du numéro de compte comme s’il s’agissait d’un nom de personne. | Valide | |
| ACH — PPD payroll credits, balanced with an offset debitLe fichier de référence : à quoi ressemble un fichier NACHA correct. Quatre crédits de paie PPD (trois sur compte courant, code 22, un sur compte d'épargne, code 32) et une cinquième entrée — le débit d'équilibrage (offset), code 27, sur le compte de l'entreprise pour le total exact : c'est ce qui rend le fichier « équilibré », et c'est pourquoi le service class code est 200 (mixte) et non 220. Entry hash, totaux du Batch Control, totaux du File Control et block count tombent tous juste, et chaque routing number satisfait le check digit ABA 3-7-1. | Valide | |
| ACH — CCD corporate debits with an addenda 05 remittanceUn encaissement B2B : deux débits CCD (service class 225, débits seuls), chacun portant un addenda 05 avec la facture qu'il règle — segments RMR et REF, la remittance ASC X12 que le client corporate rapproche de sa comptabilité. Le CCD n'autorise qu'UN SEUL addenda par entrée : 80 caractères d'information de paiement, pas un de plus. Quand le payeur a besoin de plus de place, le code SEC devient CTX. Noter l'addenda record indicator en position 79 de l'entrée : il vaut 1, et un addenda suit effectivement. | Valide | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Quatre débits WEB — le code SEC d'un paiement autorisé en ligne par un consommateur. Trois tombent sur des comptes courants (code 27) et un sur un compte d'épargne (code 37) : c'est le transaction code qui le dit, et le lire autrement que comme une table est exactement la façon dont les parseurs se trompent. Les positions 77-78 portent le payment type indicator, R pour un prélèvement récurrent et S pour un paiement unique. Une entrée WEB ne porte pas d'addenda : l'addenda record indicator reste à 0. | Valide | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Un débit CTX de 28 750,00 réglant trois factures d'un coup, avec l'avis de remittance ASC X12 820 réparti sur sept addenda 05. Le CTX est le code SEC que les parseurs manquent le plus souvent, parce que l'enregistrement d'entrée ne veut pas dire la même chose qu'ailleurs : les positions 55-58 ne sont PAS le début d'un nom, ce sont le NOMBRE d'addenda qui suivent (0007 ici), et le nom de l'entreprise réceptrice ne commence qu'en 59. Lu avec les décalages PPD, le nom ressort en « 0007GLOBEX CORP » — ce qu'affiche d'ailleurs notre propre validateur, qui applique la découpe domestique. | Valide | |
| ACH — entry hash mismatch (truncated or tampered file)Un fichier de crédits PPD dont l'entry hash est faux. L'entry hash est la somme des routing numbers à 8 chiffres de toutes les entrées, tronquée à ses dix derniers chiffres — une somme de contrôle dont l'unique rôle est d'attraper un fichier qui a perdu, gagné ou vu modifier une entrée en route. Ici, le Batch Control et le File Control déclarent tous deux 28905251 alors que les quatre entrées totalisent 27905251. Les montants, eux, tombent toujours juste : c'est tout l'intérêt, le hash est le contrôle qui se déclenche quand aucun autre ne le fait. | Invalide | |
| ACH — batch control debit total ≠ the sum of its entriesUn batch de débits CCD dont le Batch Control déclare 18 450,00 alors que ses deux entrées totalisent 28 075,00 — le bug classique du générateur qui écrit son trailer avant d'avoir ajouté la dernière entrée. Tout le reste du fichier est juste, y compris les totaux du File Control : le validateur signale donc exactement une erreur, en nommant les deux chiffres. C'est la première cause de rejet d'un fichier ACH écrit à la main. | Invalide | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberUn fichier de débits WEB dans lequel une banque réceptrice porte 026009594 — un routing number qui échoue au check digit ABA 3-7-1 (le vrai est 026009593). Seule la position 12 de l'entrée est fausse : l'entry hash et tous les totaux de contrôle tombent donc encore juste. Le check digit est le seul contrôle qui attrape un chiffre mal saisi, et ce fichier en est la preuve — les totaux, à eux seuls, ne le verront pas. Les deux autres entrées et tous les trailers sont corrects : le validateur signale exactement une erreur. | Invalide |
QR code de paiement (EPC / QR-facture suisse) (6)
| Fichiers d’exemple | Résultat attendu | Télécharger le fichier |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Un payload de QR code EPC (SCT QR) conforme, version 002 — celle où le BIC est facultatif, et il est ici omis. La communication est une référence créancier structurée ISO 11649, RF6518539007547034, dont la clé mod-97 est correcte : 94 octets sur les 331 autorisés. | Valide | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageL’autre moitié d’EPC069-12 : la version 001, où le BIC du bénéficiaire est obligatoire (c’est la seule différence entre 001 et 002), et une communication libre au lieu d’une référence. Référence structurée et texte libre sont exclusifs : un QR code porte l’un ou l’autre, jamais les deux. | Valide | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capLe piège que la spec écrit noir sur blanc et dans lequel les implémentations tombent quand même : EPC069-12 plafonne le payload à 331 OCTETS, pas caractères. Ce payload polonais fait 312 caractères — largement sous n’importe quel décompte — mais chaque lettre accentuée coûte deux octets en UTF-8 : il pèse 338 octets et se fait rejeter. | Invalide | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)La QR-facture suisse canonique : une QR-IBAN (identifiant d’institut 31999, dans la plage 30000-31999) appariée à la référence QRR qu’elle exige — 26 chiffres plus une clé en modulo 10 récursif, et non le mod-97 du monde IBAN. Notez le bloc « ultimate creditor » : sept lignes, présentes et entièrement vides, exactement comme l’exigent les guidelines. | Valide | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceL’autre moitié de la règle d’appariement : un IBAN normal (identifiant d’institut 00791, hors plage QR-IID) INTERDIT une référence QRR et prend une référence créancier ISO 11649 (SCOR) — RF6518539007547034 — ou aucune. Même facture, autre type de compte, autre référence : c’est cette distinction qui décide si un paiement suisse peut être lettré. | Valide | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)L’erreur la plus lourde de conséquences du format suisse : une QR-IBAN porteuse d’une référence ISO 11649 (SCOR). La référence est elle-même parfaitement valide — c’est là le piège — mais une QR-IBAN exige une référence QRR et rien d’autre. La banque ne peut pas lettrer le paiement, et le verdict est le même sous les guidelines 2.3 et 2.4. | Invalide |
Comment nous savons que ces résultats tiennent
Chaque fichier de cette bibliothèque passe dans le validateur du site à chaque build. Le résultat attendu annoncé ci-dessus est vérifié par un test automatisé : si un fichier cessait de correspondre à ce que cette page affirme, le build échouerait. Deux fixtures héritées ont été réparées ainsi avant publication : trois IBAN échouaient au mod-97 et plusieurs libellés utilisaient des caractères hors du jeu SEPA de base.