Bibliotheek met voorbeeldbestanden
Kant-en-klare SEPA-, camt.053-, UBL-, MT940- en Factur-X-bestanden — geldige om mee te beginnen, opzettelijk kapotte om mee te testen. Elk bestand wordt gecontroleerd door de validator waar het bij hoort.
SEPA- en e-factuur-voorbeeldbestanden
Kant-en-klare SEPA-, camt.053-, UBL-, MT940- en Factur-X-bestanden — geldige om mee te beginnen, opzettelijk kapotte om mee te testen. Elk bestand wordt gecontroleerd door de validator waar het bij hoort.
129
Voorbeeldbestanden
92
Geldig
37
Ongeldig
SEPA-overboeking (pain.001) (12)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| pain.001.001.03 — valid credit transferEen geldige SEPA-overboeking in pain.001.001.03: drie overboekingen van in totaal 1.580,00 EUR, kloppende controletotalen, IBAN's die de mod-97-controle doorstaan en namen binnen de SEPA-basistekenset. | Geldig | |
| pain.001.001.09 — valid, hybrid addressEen geldige pain.001.001.09-overboeking met BICFI en het hybride postadres dat EPC153-22 v2.1 toestaat: TwnNm plus Ctry, plus maximaal twee AdrLine van 70 tekens of minder. | Geldig | |
| pain.001.001.03 — CtrlSum mismatchEen pain.001 met een onjuist controletotaal: CtrlSum vermeldt 1.000,00 EUR terwijl de transacties optellen tot 1.500,00 EUR. Het verschil wordt tweemaal gemeld: op de betaalbatch en op de bestandsheader. | Ongeldig | |
| pain.001.001.03 — invalid IBANEen pain.001 met een crediteur-IBAN waarvan de twee controlecijfers de mod-97-toets (ISO 7064) niet doorstaan. De rest van het bestand klopt, dus meldt de validator precies één fout. | Ongeldig | |
| pain.001.001.03 — NbOfTxs mismatchEen pain.001 die zichzelf verkeerd telt: NbOfTxs vermeldt één transactie terwijl het bestand er twee bevat. Net als CtrlSum wordt het aantal zowel op de betaalbatch als op de header gecontroleerd. | Ongeldig | |
| pain.001.001.03 — unstructured address after 2026-11-15Het referentiegeval voor de EPC-regel over gestructureerde adressen: de adressen bevatten alleen AdrLine, zonder TwnNm. Wat het tot een blokkerende fout maakt, is de uitvoeringsdatum in het bestand (ReqdExctnDt = 2026-11-20, na de grens van 15-11-2026) — met een eerdere datum levert hetzelfde bestand slechts een waarschuwing op. | Ongeldig | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15Het referentiebestand «klaar voor 2026»: een pain.001.001.11-overboeking waarvan de uitvoeringsdatum (ReqdExctnDt = 2026-11-20) na de EPC-grens voor gestructureerde adressen van 15-11-2026 valt. Elk adres van betaler en begunstigde is volledig gestructureerd — StrtNm, BldgNb, PstCd, TwnNm, Ctry en geen enkele AdrLine. Drie overboekingen, 4.320,00 EUR, nul fouten en nul waarschuwingen. | Geldig | |
| pain.001.001.09 — valid, two payment batches with different execution datesEén pain.001-bestand, twee PmtInf-blokken: batch A wordt uitgevoerd op 10-03-2026 met hybride adressen (TwnNm + Ctry + één AdrLine), batch B op 20-11-2026 met volledig gestructureerde adressen. Het toont beide lessen van een multibatch-bestand: de EPC-adresregel wordt per batch beoordeeld op de datum die de batch zelf draagt, en elke PmtInf heeft eigen NbOfTxs / CtrlSum bovenop de GrpHdr-totalen (4 overboekingen, 3.350,00 EUR). | Geldig | |
| pain.001.001.03 — nine-character BICEen pain.001 waarvan de BIC van de bank van de begunstigde negen tekens telt. ISO 9362 staat 8 toe (instelling + land + plaats) of 11 (plus een filiaalcode van 3 tekens) — nooit 9 of 10. "BNPAFRPPX" is het typische beeld van een afgekapte of met de hand aangevulde filiaalcode, en het is het ene gebrek in dit bestand dat beide lagen zien: het officiële XSD wijst het af op zijn BIC-patroon, de rulebook-laag op zijn lengte. | Ongeldig | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setEen pain.001 waarvan de begunstigde "Café Renard & Fils SARL" heet — een letter met accent en een ampersand, beide buiten de door het EPC goedgekeurde Latijnse basistekenset (a-z A-Z 0-9 en / - ? : ( ) . , ' + spatie). De XML is welgevormd en het officiële XSD accepteert het moeiteloos: Max70Text neemt elke tekenreeks. Dit gebrek zit volledig in de rulebook-laag, en juist daarom bereiken zulke bestanden de bank, die ze afwijst of stilzwijgend translitereert. | Ongeldig | |
| pain.001.001.03 — 250 transfers, high-volume payroll runEen realistische loonrun: 250 SEPA-overboekingen in één PmtInf, verspreid over vijf landen (DE, NL, BE, ES, FR), samen 442.028,75 EUR. Elke IBAN draagt correcte mod-97-controlecijfers (ISO 7064) en beide controletotalen komen tot op de cent overeen met de som. Gebruik het om te zien hoe je parser, je bankportaal of je eigen tooling zich gedraagt op een bestand dat noch speelgoed noch pathologisch is — en om te controleren dat één verkeerde cent in een batch van dit formaat nog steeds door CtrlSum alleen wordt gevonden. | Geldig | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)De tweeling van het blokkerende voorbeeld met ongestructureerd adres, met één verschil: de uitvoeringsdatum. Dezelfde adressen met alleen AdrLine, maar ReqdExctnDt is 30-09-2026, vóór de grens van EPC153-22 v2.1: hetzelfde gebrek komt terug als twee waarschuwingen in plaats van twee fouten — de betaling gaat vandaag nog gewoon door. Het laat ook zien wat "gestructureerd" echt betekent: het debiteuradres heeft noch TwnNm noch Ctry, het crediteuradres heeft een Ctry en nog steeds geen TwnNm. Ctry alleen volstaat niet; TwnNm is de doorslaggevende factor. | Geldig |
SEPA-incasso (pain.008) (8)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitEen geldige SEPA-incasso onder het CORE-schema: twee terugkerende incasso's van in totaal 175,00 EUR, een Incassant-ID (ICS) die de ISO 7064 MOD 97-10-controle doorstaat, en een getekend mandaat per debiteur. | Geldig | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15Zo ziet een conforme SEPA-incasso eruit na de grens van 15-11-2026: de incassodatum is 20-11-2026, dus elk crediteur- en debiteuradres is gestructureerd (TwnNm + Ctry). CORE-schema, drie incasso's van samen 228,80 EUR, nul waarschuwingen. | Geldig | |
| pain.008.001.02 — mandate signed after the collectionEen incasso op basis van een mandaat dat de debiteur nog niet had getekend: DtOfSgntr is 10-04-2026 terwijl de incassodatum 05-03-2026 is. Een veelvoorkomend, stilletjes fataal gebrek — het ICS, de IBAN's en de totalen kloppen allemaal. | Ongeldig | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceEen geldige SEPA B2B-incasso in pain.008.001.08: LclInstrm/Cd = B2B, sequentietype RCUR, twee terugkerende incasso's van samen 4.650,00 EUR. Het B2B-schema is de zakelijke variant — de debiteur mag geen consument zijn en heeft NA verrekening geen recht op terugboeking. Daarom controleert zijn bank het mandaat vóór de afschrijving en worden B2B-incasso's eerder aangeleverd dan CORE-incasso's. | Geldig | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceEen geldige SEPA CORE-incasso met sequentietype FRST: de eerste incasso onder een gloednieuw mandaat (DtOfSgntr is enkele dagen oud). Alles wat daarna op hetzelfde mandaat volgt, moet als RCUR de deur uit — een batch voor altijd op FRST laten staan is een van de meest gemaakte SDD-fouten, en de reden dat banken incasso's terugsturen met een reden "onjuist sequentietype". | Geldig | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceEen geldige eenmalige SEPA-incasso: sequentietype OOFF, één enkele incasso van 349,00 EUR. Het mandaat machtigt precies één afschrijving en is op zodra het gebruikt is — het mag nooit opnieuw worden aangeleverd, ook niet als RCUR. Dit is de sequentie voor een eenmalige aankoop, een aanbetaling of een eenmalige vergoeding; wie in plaats daarvan FRST gebruikt, laat stilzwijgend een lopend mandaat achter waarmee de debiteur nooit heeft ingestemd. | Geldig | |
| pain.008.001.02 — mandate identifier (MndtId) missingEen incasso zonder mandaatkenmerk: MndtRltdInf is aanwezig en draagt een ondertekeningsdatum, maar het element MndtId (AT-01 uit het rulebook) ontbreekt. Het officiële ISO 20022-XSD accepteert het bestand — MndtId is optioneel in het schema — dus een puur structurele controle laat het door en de bank wijst het af: zonder mandaatreferentie heeft de bank van de debiteur niets om de incasso aan te koppelen, en de debiteur niets om te betwisten. | Ongeldig | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsEen SEPA-incasso die zichzelf verkeerd telt én verkeerd optelt, op beide niveaus tegelijk: de batch bevat werkelijk 2 incasso's van samen 300,00 EUR, maar NbOfTxs zegt 3 en CtrlSum zegt 250,00 — in de PmtInf en nog eens in de GrpHdr. Dat zijn vier fouten, geen twee: controletotalen worden op de betaalbatch én op de bestandsheader gecontroleerd, want een multibatch-bestand kan een kloppend headertotaal tonen boven twee onjuiste batchtotalen. De XML is welgevormd en het officiële XSD accepteert het: voor een schema zijn NbOfTxs en CtrlSum gewoon getallen. | Ongeldig |
Bankafschrift (camt.052 / 053 / 054) (12)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| camt.053.001.02 — valid statementEen geldig camt.053.001.02-bankafschrift: vier boekingen, begin- en eindsaldo die aansluiten (OPBD ± mutaties = CLBD), en datums in Dt-formaat. | Geldig | |
| camt.053.001.08 — valid statementEen geldig camt.053.001.08-bankafschrift: drie boekingen, DtTm-tijdstempels en BICFI in plaats van BIC — precies de verschillen waarover men struikelt bij de overgang van versie 02 naar 08. | Geldig | |
| camt.053 — unsupported namespaceEen afschrift dat camt.053.001.99 declareert, een versie die niet in de ISO 20022-catalogus bestaat. Handig om te controleren of je eigen parser onbekende namespaces afwijst in plaats van te gokken. | Ongeldig | |
| camt.053.001.06 — missing Stmt elementEen afschrift met een correcte camt.053.001.06-namespace maar zonder enig <Stmt>-element: de envelop klopt, de inhoud ontbreekt. Zo ziet een afgekapte bankexport eruit. | Ongeldig | |
| camt.053.001.11 — valid statementEen geldig camt.053.001.11-bankafschrift — de huidige versie van het ISO 20022-afschriftbericht. Vier boekingen, OPBD 25.000,00 ± mutaties = CLBD 34.659,05. Let op wat versie 11 op elke boeking verplicht stelt: Sts en BkTxCd, die oudere versies nog lieten weglaten. | Geldig | |
| camt.053.001.08 — three accounts in one fileEén camt.053-bericht, drie <Stmt>-blokken: een rekening-courant, een spaarrekening en een USD-rekening. Het bestand voldoet aan het schema; de validator meldt uitdrukkelijk dat alleen het eerste afschrift wordt geanalyseerd. Dat is precies de les — een lezer die Stmt[0] pakt en stopt, verliest stilzwijgend twee rekeningen, en dit multi-rekeningbestand legt dat bloot. | Geldig | |
| camt.053.001.10 — fully detailed entriesAlles wat een bank onder een camt.053-boeking kan hangen, in één geldig bestand: NtryDtls/TxDtls met EndToEndId, InstrId, TxId en MndtId; RltdPties en RltdAgts; een gestructureerde ISO 11649-crediteurreferentie (RF) en een gerefereerde factuur (CINV); een verzamelboeking waarvan de twee TxDtls precies optellen tot het boekingsbedrag; en zowel een ISO-BkTxCd (PMNT/RCDT/ESCT) als een proprietaire Duitse GVC. Handig om te meten hoeveel uw reconciliatie werkelijk uitleest. | Geldig | |
| camt.053.001.08 — closing balance does not reconcileHet meest voorkomende gebrek in productie-camt.053-bestanden: beginsaldo 4.200,00 plus de geboekte mutaties geeft 5.194,70, terwijl het opgegeven CLBD 5.194,07 zegt — twee cijfers verwisseld. Het bestand voldoet feilloos aan het officiële ISO 20022-XSD, want een schema zegt niets over rekenkunde. Alleen een saldocontrole vangt een niet-aansluitend eindsaldo. | Geldig | |
| camt.052.001.08 — valid intraday reportEen geldig camt.052 intraday-rapport — en het is geen kleine camt.053: de root is BkToCstmrAcctRpt, de container is <Rpt>, en de saldi zijn TUSSENSALDI (ITBD geboekt, ITAV beschikbaar) in plaats van het OPBD/CLBD-paar van een dagafschrift. Het bevat ook een boeking in behandeling (Sts=PDNG) die bewust buiten het tussensaldo blijft: geld in behandeling is geen geboekt geld. | Geldig | |
| camt.054.001.08 — valid debit/credit notificationEen geldige camt.054 debet-/creditmelding: één inkomende SEPA-bijschrijving en één uitgaande incasso, elk met volledige TxDtls en end-to-end-referentie. De structurele verrassing is wat er NIET staat: een camt.054 heeft helemaal geen <Bal>-element — het ISO 20022-schema definieert er geen. Een melding kondigt mutaties aan, zij noemt nooit een saldo: er valt niets aan te sluiten. | Geldig | |
| camt.053.001.08 — entry with no CdtDbtIndDe tweede boeking draagt een bedrag van 1.200,00 en geen <CdtDbtInd>. Bedragen in camt.053 zijn altijd tekenloos: zonder richtingsindicator zegt het bedrag niets. Er breken twee dingen tegelijk — het officiële XSD wijst het bestand af (CdtDbtInd is verplicht 1..1 op een boeking), en een parser die stilzwijgend terugvalt op CRDT boekt +1.200,00 in plaats van −1.200,00 en zit er 2.400,00 naast, wat de saldocontrole vervolgens blootlegt. | Ongeldig | |
| camt.053.001.08 — 220 entries, validEen zakelijk maandeindafschrift met 220 geboekte mutaties, die allemaal aansluiten: OPBD 125.000,00 ± mutaties = CLBD 209.081,69. Elke boeking draagt NtryDtls/TxDtls, een EndToEndId en een tegenpartij, zodat een camt.053-lezer op realistisch volume wordt beproefd in plaats van op een speelbestand van drie regels — parseersnelheid, tabelweergave en reconciliatie over honderden regels. | Geldig |
UBL-factuur (Peppol BIS 3.0) (12)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Een geldige Peppol BIS Billing 3.0-factuur: drie regels, 2.596,00 EUR inclusief btw, kloppende totalen, een Frans btw-nummer en een IBAN voor betaling. | Geldig | |
| UBL Credit Note — valid Peppol BIS 3.0Een geldige Peppol BIS Billing 3.0-creditnota: één regel, 1.770,00 EUR inclusief btw, met verwijzing naar de oorspronkelijke factuur die zij crediteert. De creditnota is een eigen UBL-documenttype, geen factuur met negatieve bedragen. | Geldig | |
| UBL Invoice — BR-CO-10 violationEen factuur die EN 16931-regel BR-CO-10 schendt: de som van de netto regelbedragen (1.000,00) is niet gelijk aan het documenttotaal BT-106 (2.000,00). Een van de vaakst voorkomende afwijzingen op het Peppol-netwerk. | Ongeldig | |
| UBL Invoice — malformed seller VAT identifierEen factuur waarvan het btw-nummer van de verkoper, "FR1234", te kort is: een Frans nummer is FR gevolgd door een sleutel van twee tekens en negen cijfers. Formaatfouten op BT-31 worden opgevangen lang voordat de factuur de belastingdienst bereikt. | Ongeldig | |
| UBL Invoice — allowances and charges, line and document levelEen geldige UBL-factuur volgens Peppol BIS 3.0 met kortingen en toeslagen op BEIDE niveaus: een regelkorting (BG-27), een regeltoeslag (BG-28), een documentkorting (BG-20) en vrachtkosten (BG-21). Het draait om de keten van totalen: BT-106 = 1.520,00 is de som van de NETTO regelbedragen, en BT-109 = 1.530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13) — de 19 % btw wordt dus over 1.530,00 berekend, niet over 1.520,00. | Geldig | |
| UBL Invoice — reverse charge (VAT category AE)Een geldige factuur met btw-verlegging in UBL: een Franse dienstverlener factureert aan een Duitse onderneming, de btw wordt verlegd naar de afnemer, dus 0 % en geen btw in rekening gebracht. Categorie AE brengt vier regels mee: beide btw-nummers (BR-AE-02, BR-AE-03), het 0 %-tarief (BR-AE-05), een btw-bedrag van 0,00 (BR-AE-09) en een vrijstellingsreden (BR-AE-10), hier VATEX-EU-AE plus de tekst "Reverse charge". | Geldig | |
| UBL Invoice — VAT exempt (category E) with exemption reasonEen geldige btw-vrijgestelde factuur (categorie E): beroepsopleiding, vrijgesteld op grond van artikel 132, lid 1, onder i) van Richtlijn 2006/112/EG. Een vrijgestelde factuur moet zeggen WAAROM: BR-E-10 eist een vrijstellingsredencode (BT-121) of -tekst (BT-120); dit bestand bevat beide: VATEX-EU-132 en de formulering uit de officiële codelijst. | Geldig | |
| UBL Invoice — intra-Community supply (VAT category K)Een geldige intracommunautaire levering (btw-categorie K): goederen verzonden vanuit Duitsland naar een btw-geregistreerde afnemer in Frankrijk, nultarief op grond van artikel 138 van Richtlijn 2006/112/EG. Categorie K vraagt om twee dingen die men vergeet: BR-IC-11, een werkelijke leverdatum (BT-72) of een factuurperiode, en BR-IC-12, het land van levering (BT-80). Zonder die bewijst de factuur niet dat de goederen het land hebben verlaten. | Geldig | |
| UBL Invoice — two VAT rates, one breakdown per rateEen geldige factuur met het Franse standaardtarief (20 %) en het verlaagde tarief (5,5 %). De regel die dit bestand toont is BR-S-08: de btw-specificatie (BG-23) bevat ÉÉN TaxSubtotal per paar (categorie, tarief), en elke maatstaf van heffing is de som van de regels met dat paar — 1.500,00 tegen 20 % (btw 300,00) en 400,00 tegen 5,5 % (btw 22,00). Twee tarieven samenvoegen tot één subtotaal doorstaat alle BR-CO-controles en is toch fout. | Geldig | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106De meest voorkomende afwijzing in productie, geïsoleerd: de twee regels tellen op tot 1.500,00 maar BT-106 (LineExtensionAmount) vermeldt 1.400,00 — BR-CO-10. De rest is consistent met het FOUTE bedrag, dus BR-CO-13, BR-CO-14, BR-CO-15 en BR-CO-16 slagen en er komt precies één fout terug. Zo ziet een regel eruit die na het berekenen van de totalen is verwijderd. | Ongeldig | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Een vrijgestelde factuur die twee keer misgaat. BR-E-10: de btw-specificatie voor categorie E bevat noch een vrijstellingsreden (BT-120) noch een redencode (BT-121) — een vrijgestelde factuur moet zeggen WAAROM. BR-E-08: de vrijgestelde maatstaf vermeldt 1.200,00 terwijl de vrijgestelde regels optellen tot 1.500,00, want de tweede regel is nooit in de specificatie beland. De geciteerde fout komt uit de bedrijfsregellaag; het officiële EN 16931-Schematron voegt daar BR-E-10 aan toe. | Ongeldig | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateEen btw-specificatie die niet klopt: 2.000,00 tegen 19 % is 380,00 btw, maar de factuur vermeldt 395,00. BR-CO-17 controleert btw-bedrag per categorie = maatstaf × tarief / 100, met de officiële marge van één munteenheid — een echte afrondingscent mag, dit gat van 15,00 niet. Alle andere totalen volgen het foute bedrag: zo overleeft een afrondingsbug tot in productie. | Ongeldig |
CII-factuur (XRechnung-/Factur-X-syntaxis) (4)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validEen geldige XRechnung 3.0-factuur in de CII-syntaxis (UN/CEFACT CrossIndustryInvoice) — de e-factuur van de Duitse overheid. Ze bevat wat de KoSIT BR-DE-regels bovenop EN 16931 eisen: de Leitweg-ID als kopersreferentie (BR-DE-15), een volledig verkopercontact — naam, telefoon en e-mail (BR-DE-2 t/m BR-DE-6), het elektronische adres van de verkoper, gestructureerde betalingsvoorwaarden en een SEPA-overboeking (betaalmiddel 58). | Geldig | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)De Factur-X-/ZUGFeRD-payload op zichzelf: de CII-XML die normaal ingebed in een PDF/A-3 reist, hier als losstaand bestand dat je direct kunt valideren. Het profiel BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) is een EN 16931-conforme CIUS — volledige factuurregels, een complete btw-specificatie en de zes documenttotalen. Handig om een extractor op de XML alleen te testen, zonder PDF eromheen. | Geldig | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 in de CII-syntaxis: de twee regels tellen op tot 2.000,00 maar LineTotalAmount (BT-106, in SpecifiedTradeSettlementHeaderMonetarySummation) vermeldt 1.900,00. Hetzelfde gebrek als in het UBL-voorbeeld, in de syntaxis waar het het minst opvalt — de documenttotalen staan in een andere tak van de boom dan de regels die ze samenvatten. | Ongeldig | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisEen documentkorting die maar half bestaat: de factuur geeft 200,00 (BT-107), berekent de btw over de gekorte grondslag (1.800,00 × 19 % = 342,00 — correct), maar BT-109 (TaxBasisTotalAmount) vermeldt nog steeds de ongekorte 2.000,00. BR-CO-13 eist BT-109 = BT-106 - BT-107 + BT-108, dus de koper betaalt 200,00 die de verkoper dacht te hebben weggegeven. | Ongeldig |
SWIFT MT940-afschrift (10)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectHet nominale MT940-geval: één afschrift, één credit en één debet, met het paar klant-/bankreferentie in de :61:-regel. Begin hier om de tagstructuur te zien vóór de dialecten. | Geldig | |
| MT940 — ING Belgium, structured :86:Het ING België-dialect: de informatieregel :86: is opgedeeld in subvelden ?00 ?20 ?30 in plaats van vrije tekst. Dit is veruit de grootste bron van MT940-parsefouten. | Geldig | |
| MT940 — Commerzbank, one-decimal amountHet Commerzbank-dialect: een bedrag met één decimaal (1234,5 voor 1.234,50), een NMSC-transactietype en een Duitse rekening als BLZ + rekeningnummer in plaats van een IBAN. | Geldig | |
| MT940 — two statements in one fileTwee afschriften in één MT940-bestand, plus de tag :64: voor het beschikbare saldo. Een bestand is niet één afschrift; een parser die dat aanneemt, laat het tweede stilzwijgend vallen. | Geldig | |
| MT940 — reversal (RC) and intermediate balancesDe ABN AMRO-casus: een RC-storno (een credit die weer debet wordt), tussentijdse saldi 60M/62M in plaats van F, en een :86: over twee regels. Storno's draaien het teken om — mis dit en het saldo sluit nooit aan. | Geldig | |
| MT940 — overdrawn account (debit balances)Een debetstand: zowel het begin- als het eindsaldo draagt de markering D (debet). Een negatief saldo is in MT940 geen negatief getal maar een tekenvlag; code die dat negeert, rapporteert het roodstaan als tegoed. | Geldig | |
| MT940 — closing balance does not reconcileEen afschrift waarvan het eindsaldo niet volgt uit begin ± mutaties. Bewust een waarschuwing en geen blokkerende fout: het bestand blijft leesbaar en een mens moet uitmaken of de bank of de export fout zit. | Geldig | |
| MT940 — 500 transactions (load test)Vijfhonderd transacties in één afschrift, sluitend tot op de cent. Gebruik het om te controleren of je parser exact — en snel — blijft bij productievolume, en niet alleen bij een speelbestandje van drie regels. | Geldig | |
| MT940 — statement split over two pages (62M / 60M)Eén afschrift, één dag, twee pagina’s: reeks 00147/00001 sluit af op een TUSSENTIJDS saldo :62M: en reeks 00147/00002 opent op :60M: met exact dat bedrag, om pas op de definitieve :62F: te sluiten. M is geen F — wie het tussentijdse eindsaldo voor het dagsaldo aanziet, rapporteert 37.500,00 terwijl de rekening op 44.249,25 eindigde. | Geldig | |
| MT940 — USD account with an RD reversalEen afschrift in Amerikaanse dollar — MT940 is geen euroformaat — waarin een uitgaande overboeking van 35.000,00 de volgende dag via een RD-storno terugkomt: een GESTORNEERDE DEBET is geld dat TERUGKOMT. De markeringen RC/RD draaien de economische richting van de :61:-regel om; een parser die alleen de D van "RD" leest, boekt de terugbetaling nogmaals als betaling en sluit nooit aan. | Geldig |
BAI2-afschrift (VS / Canada) (6)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)Het nominale BAI2-bestand: één rekening, een 010-beginsaldo en 015-eindsaldo, en tien boekingen waarvan de richting uitsluitend uit de type code volgt — 115 lockbox-storting, 165 ACH-credit, 195 inkomende overboeking, 475 betaalde cheque, 451 ACH-debet, 495 uitgaande overboeking, 698 kosten. BAI2 kent geen debet-/creditvlag: 100–399 is geld erin, 400–699 geld eruit. | Geldig | |
| BAI2 — several accounts in one groupTwee 03-rekeningrecords binnen één 02-groep — een lopende rekening en een salarisrekening, elk afgesloten met een eigen 49-trailer. BAI2 is hiërarchisch (01 bestand / 02 groep / 03 rekening / 16 boeking / trailers 49-98-99): wie één rekening per bestand aanneemt, laat de tweede stilzwijgend vallen. | Geldig | |
| BAI2 — 88 continuation recordsHet 88-vervolgrecord in zijn twee zeer verschillende rollen: het draagt extra saldo-tuples voor een 03-rekeningrecord (hier het 015-eindsaldo en het 045-beschikbare saldo) en afgebroken vrije tekst voor een 16-boeking (drie fysieke regels, één omschrijving). Voeg ze op dezelfde manier samen en je leest saldi als tekst — of tekst als saldi. | Geldig | |
| BAI2 — CAD and JPY: minor units scale with the currencyBAI2-bedragen hebben geen decimaalteken: het zijn minor units, en hoeveel decimalen ze impliceren hangt van de valuta af. Hier is "2500000" op de CAD-rekening CAD 25.000,00 (2 decimalen) en op de JPY-rekening ¥2.500.000 (0 decimalen). De CAD-rekening laat haar valutaveld bovendien leeg en erft het van de 02-groepskop. Een hardgecodeerde deling door 100 verminkt de yen-rekening met twee grootteordes — en het saldo klopt nog steeds, omdat alle drie de cijfers met dezelfde factor fout zijn. | Geldig | |
| BAI2 — closing balance does not reconcileHet 015-eindsaldo volgt niet uit het 010-beginsaldo plus de 16-mutaties: 50.000,00 + 10.000,00 − 2.500,00 is 57.500,00, maar het bestand claimt 59.000,00. De trailers kloppen nog wel; alleen de rekensom verraadt het. Bewust een waarschuwing en geen blokkerende fout: het bestand blijft leesbaar en een mens moet uitmaken of de bank of de export fout zit. | Geldig | |
| BAI2 — bad trailer totals and an out-of-range type codeDrie gebreken tegelijk. De 49-rekeningtrailer noemt een controletotaal en een recordaantal die geen van beide kloppen met de records erboven — de trailers zijn de eigen integriteitscontrole van het bestand, en wie ze overslaat ziet afkapping niet. En een 16-boeking draagt type code 720, uit het leningenbereik 700–799: geen credit (100–399) en geen debet (400–699), dus de richting is niet af te leiden en de boeking wordt weggelaten in plaats van geraden — waardoor ook het saldo niet meer sluit. | Geldig |
Factur-X / ZUGFeRD (PDF) (2)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceEen geldige Factur-X-factuur op het EN 16931-profiel: een PDF/A-3 met de CII-XML erin ingebed. Eén document dat een mens leest en een machine parseert — dat is de hele bedoeling van het hybride formaat. | Geldig | |
| Factur-X EN 16931 — BR-CO-15 violationEen Factur-X-factuur die EN 16931-regel BR-CO-15 schendt: het totaal inclusief btw is 130,00 terwijl exclusief btw plus btw 120,00 oplevert. De pdf opent en oogt volkomen normaal — alleen de ingebedde XML verraadt het. | Ongeldig |
KSeF-factuur (Polen, FA(3)) (7)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Een conforme gestructureerde FA(3)-factuur — voorbeeld nr. 4 van het Poolse ministerie van Financiën zelf, ongewijzigd overgenomen. Drie regels, 64.279,92 PLN inclusief 23% btw. Referentie voor wat KSeF accepteert. | Geldig | |
| KSeF — invoice still using the retired FA(2) schemaDe meest voorkomende KSeF-migratiefout: een volkomen correct gevormde factuur die nog de FA(2)-namespace opgeeft, ingetrokken op 1 februari 2026. Er lijkt niets mis — tot KSeF hem weigert. Let op wat FA(3) toevoegde en hier ontbreekt: Podmiot2 vereist nu JST en GV. | Ongeldig | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Structureel perfect volgens het officiële schema, en toch zakt het NIP van de verkoper voor het mod-11-controlecijfer en komt P_15 niet overeen met de som van de btw-uitsplitsing. ValidateFin meldt beide als waarschuwing, niet als fout: geen van beide regels is normatief, en voorbeeld 1 van het ministerie wijkt zelf een grosz af. | Geldig | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Een correctiefactuur (RodzajFaktury = KOR), het meest gezochte en vaakst verkeerd opgebouwde FA(3)-geval. De totalen dragen het VERSCHIL, niet de herziene factuur: P_13_1, P_14_1 en P_15 zijn negatief. Daarnaast verschijnen PrzyczynaKorekty, TypKorekty en DaneFaKorygowanej, die naar de gecorrigeerde factuur verwijzen. De regels komen per paar: die met StanPrzed is de toestand vóór. | Geldig | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Een voorschotfactuur (RodzajFaktury = ZAL): zij factureert een aanbetaling op een nog niet geleverde bestelling. Daarom bevat zij GEEN enkele FaWiersz-regel — de goederen staan in het blok Zamowienie (bestelling), met eigen tags P_7Z / P_11NettoZ / P_11VatZ — terwijl P_15 alleen het voorschot van 12.300,00 PLN toont op een bestelling van 61.500,00 PLN. | Geldig | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Een FA(3)-factuur waarin één verplicht element ontbreekt: P_2, het factuurnummer. Op het oog mankeert er niets — correct gevormde XML, juiste namespace, plausibele btw-uitsplitsing — en alleen de officiële XSD van het ministerie van Financiën ziet het: “Element P_6: this element is not expected. Expected is P_2.” KSeF weigert zo’n bestand zonder meer. | Ongeldig | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)Het NIP van de koper is 1111111112 — tien cijfers, dus het officiële schema, dat het NIP alleen met een patroon toetst, aanvaardt het zonder meer. Het mod-11-controlecijfer klopt niet: zo’n Pools belastingnummer kan niet bestaan en de factuur is aan niemand gericht. ValidateFin geeft een waarschuwing, nooit een fout — het ministerie publiceert geen dergelijke validatieregel. | Geldig |
FatturaPA-factuur (Italië, SdI) (4)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyEen FatturaPA die het SdI zou aanvaarden: correcte btw-rekenkunde (twee regels tegen 22 % voor 1.100 €, 242 € btw, 1.342 € totaal), fiscale identificatiegegevens met een geldig controlecijfer, en een CodiceDestinatario van 7 tekens, zoals een private ontvanger vereist. Dit is het ijkpunt: elk ander voorbeeld hier is dit bestand, op één specifieke manier stukgemaakt. | Geldig | |
| FatturaPA — signed CAdES (.p7m) envelopeDezelfde conforme factuur, verpakt in een CAdES-handtekeningenvelop (.p7m) — zo reizen de meeste echte Italiaanse facturen, en zo MOET elke factuur aan een overheid reizen. In een teksteditor zie je alleen binaire ruis. De validator opent de envelop en controleert de XML erin; de handtekening zelf verifieert hij niet, en dat zegt hij ook. | Geldig | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Deze factuur is GELDIG volgens het officiële XSD en het SdI zou ze toch weigeren — precies daarom volstaat een schemacontrole niet. Drie gebreken: de maatstaf van heffing geeft 1.150 € aan terwijl de regels 1.100 € opleveren (controle 00422, met een tolerantie van één EURO, niet één cent); de btw geeft 250 € aan waar 22 % van 1.150 € gelijk is aan 253 € (00421); en de Natura-code is de kale N3, op 1 januari 2021 ingetrokken ten gunste van zijn subcodes (00445) — hoewel hij nog in de schema-enumeratie staat. | Ongeldig | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)De meest voorkomende reden waarom een factuur aan een Italiaanse overheid terugkomt: de CodiceDestinatario. Voor een PA (FormatoTrasmissione = FPA12) moet het de ZES tekens lange IPA-kantoorcode zijn — de vorm met zeven tekens is voor private ontvangers. Het XSD staat 6 OF 7 toe voor beide, dus het schema ziet het niet; alleen SdI-controle 00427 ziet het. Het factuurnummer, «FATTURA», bevat bovendien geen enkel cijfer (00425). | Ongeldig |
RO e-Factura-factuur (Roemenië, ANAF) (6)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Een factuur die ANAF accepteert — haar eigen offline validator zegt « este valid ». Het is het door het ministerie gepubliceerde voorbeeld, hersteld op de twee punten waarop de gepubliceerde versie faalt: BT-24 op CIUS-RO:1.0.1 gezet, en twee CUI met een werkelijk correct controlecijfer. Dit is het referentiepunt: elk kapot voorbeeld hier is dit bestand, op één precieze manier beschadigd. | Geldig | |
| RO e-Factura — credit note in a foreign currency (FCN)Een creditnota (FCN) in SEK — en ANAF accepteert ze. Ze toont wat BR-RO-030 werkelijk eist: RON moet voorkomen als factuurvaluta (BT-5) OF als btw-boekingsvaluta (BT-6), niet noodzakelijk allebei. Hier is BT-5 SEK en BT-6 RON, wat de regel vervult. Ze draagt ook typecode 381, toegestaan op een creditnota en verboden op een factuur. | Geldig | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)De meest voorkomende Roemeense weigering, en het enige gebrek van dit bestand: BT-24 zegt nog CIUS-RO:1.0.0, een waarde die op 29 december 2022 werd ingetrokken (besluit OMF 4092/2022). De factuur is verder onberispelijk en doorstaat het XSD. Beide voorbeelden die het ministerie zelf nog publiceert dragen dit gebrek — en zijn eigen validator weigert ze. | Ongeldig | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Een verkoper in Boekarest wiens stad (BT-37) “Sector 1” luidt — precies de schrijfwijze van het ministerieel besluit zelf. Het Schematron dat ANAF werkelijk draait eist SECTOR1: hoofdletters, zonder spatie. Als wettekst en implementatie botsen, is het de implementatie die uw factuur weigert. | Ongeldig | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)Het voorbeeld dat de blinde vlek blootlegt van elke validator die enkel het Schematron draait. De CUI van de koper (RO987456123) heeft een fout controlecijfer — en GEEN enkele Schematron-regel kijkt ernaar. Dit bestand doorstaat het XSD, doorstaat het volledige CIUS-RO-regelboek, en ANAF weigert het toch, onder een eigen code: ERRIdentif, « CUI cumparator incorect ». | Ongeldig | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Een B2C-factuur waarvan de koper een particulier is, geïdentificeerd door het anonieme CNP van dertien nullen — in productie sinds 16 december 2024. Ze is geldig, en een validator die dit als een misvormd rijksregisternummer zou behandelen, breekt de volledige consumentenfacturatie in Roemenië: dit nummer doorstaat geen enkele vormregel van het CNP (het eerste cijfer, 0, wordt overal elders geweigerd), want het is een gereserveerde waarde, geen CNP. | Geldig |
Verifactu-factuurrecord (Spanje, AEAT) (3)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosEen indiening die de AEAT zou accepteren: twee correct geketende factuurrecords. Het eerste verklaart zich het begin van de keten en hasht een leeg voorgangerveld; het tweede ketent de vingerafdruk van het eerste. Beide vingerafdrukken zijn echte SHA-256-waarden over exact de door de AEAT voorgeschreven tekenreeks — niet verzonnen. | Geldig | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)Het tweede record declareert een vingerafdruk die NIET bij zijn inhoud past: de keten is verbroken. Het bestand is GELDIG volgens het officiële AEAT-XSD — een validator die alleen het schema bekijkt, keurt het goed. Alleen het herberekenen van de geketende SHA-256 ontdekt het. Let op: de AEAT wijst het NIET af, maar markeert het als “Aceptado con errores” (code 2000) en registreert het toch. | Geldig | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Een vereenvoudigde factuur (F2) met een Destinatarios-blok — verboden, code 1190 — en waarvan de CuotaRepercutida (€ 100) niet klopt met grondslag × tarief (€ 1.000 × 21 % = € 210), ver buiten de ±€ 10-tolerantie van controle 1142. Het bestand DOORSTAAT het officiële XSD zonder één klacht: het schema kan dit niet zien, de AEAT wijst het af. | Ongeldig |
Facturae-factuur (Spanje, FACe) (2)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaEen Facturae 3.2.2-factuur gericht aan een overheidsdienst (met haar DIR3-administratieve centra, zoals FACe vereist) die het officiële XSD van facturae.gob.es zonder één klacht doorstaat, met alle totalen kloppend volgens de formules van het schema zelf en een aanwezige XAdES-handtekening. Het referentiepunt: het andere voorbeeld is hetzelfde bestand, op één bepaalde manier kapot. De handtekening is een voorbeeld — de cryptografische geldigheid wordt offline niet gecontroleerd. | Geldig | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)Hetzelfde bestand, met één wijziging: InvoiceTotal declareert € 1.200,00 waar de formule van het schema € 1.210,00 geeft (grondslag 1.000 + btw 210). Het bestand is GELDIG volgens het officiële facturae.gob.es-XSD — een validator die alleen het schema bekijkt keurt het goed. Alleen de coherentielaag ontdekt het, en meldt bovendien dat het lottotaal niet meer klopt. Geen “officiële” weigering: Facturae/FACe publiceert geen offline te controleren weigeringscodes, dus een waarschuwing, geen fout. | Geldig |
CODA-afschrift (België) (6)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationEen gewoon Belgisch afschrift: een SEPA-overschrijving met een geldige gestructureerde mededeling (+++090/9337/55493+++), een kaartbetaling en een ontvangen overschrijving met tegenpartij. Beginsaldo 1.000,00 − 250,00 − 89,90 + 1.500,00 = eindsaldo 2.160,10, en de trailertotalen kloppen. | Geldig | |
| CODA — globalised salary run (booked total + its details)Een globalisatie: één geboekt salaristotaal van 3.000,00 (detailnummer 0000), gevolgd door de twee individuele salarissen erachter (0001, 0002). Alleen het totaal is geboekt — een parser die de details meetelt, telt het bestand dubbel en het afschrift klopt niet meer. Sluit af met een debetsaldo van 2.000,00. | Geldig | |
| CODA — wrong mod-97 check digits and a statement that does not balanceOpzettelijk kapot. De gestructureerde mededeling eindigt op 94 waar mod 97 een 93 vereist — de belangrijkste reden waarom een Belgische betaling nooit aan haar factuur wordt gekoppeld — en het eindsaldo volgt niet uit de bewegingen. Geen enkele andere gratis CODA-tool controleert deze controlecijfers. | Geldig | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedEen CODA-afschrift met de twee gestructureerde referenties die het formaat kent, elk met een eigen controlecijfer: een uitgaande overschrijving met Belgische gestructureerde mededeling +++090/9337/55493+++ (type 101, mod 97 — een rest van 0 wordt als 97 geschreven, niet als 00) en een ontvangen overschrijving met ISO 11649-schuldeisersreferentie RF73INV20260042 (type 100, mod 97-10). Beide kloppen en het afschrift sluit: 1.000,00 − 250,00 + 1.500,00 = 2.250,00. | Geldig | |
| CODA — separate application: balances zeroed by design (§7.2.1)Een CODA-«separate application» (header, posities 84-88 = 00001): een kaartacceptatie-afrekening die buiten het rekeningafschrift wordt geleverd. Febelfin §7.2.1 zet begin- en eindsaldo per constructie op nul, dus de identiteit beginsaldo ± mutaties = eindsaldo kán niet kloppen — en mag niet worden gecontroleerd. ValidateFin slaat de controle hier over en meldt het bestand schoon; een validator die dat niet doet, bestempelt elk zo’n bestand als kapot. | Geldig | |
| CODA — old balance ± movements ≠ new balanceEen gewoon Belgisch afschrift — één mutatie te weinig. De 2.1-records geven 1.000,00 − 250,00 + 1.500,00 = 2.250,00, maar het «8»-record met het eindsaldo meldt 2.200,00: 50,00 aan geboekte mutatie heeft het bestand nooit gehaald. Dit is de controle die een afgekapt CODA-bestand, een verdwenen record of een verkeerd gelezen debet/credit-teken vangt — en precies waarom het vorige voorbeeld NIET zo gecontroleerd mag worden. | Geldig |
CFONB 120-afschrift (Frankrijk) (5)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsEen Frans afschrift met al zijn SEPA-gegevens: een incasso met mandaatreferentie en sequentietype RCUR, de naam van de schuldeiser, een kaartbetaling en een ontvangen overschrijving met de naam van de betaler, de end-to-end-referentie, het doel en de omschrijving — alles in «05»-aanvullingsrecords. Beginsaldo 1.000,00 − 250,00 − 89,90 + 1.500,00 = eindsaldo 2.160,10. | Geldig | |
| CFONB 120 — amount without its overpunched signOpzettelijk kapot, en de klassieke manier om een CFONB-bestand te verpesten: het bedrag van de debitering eindigt op een gewoon cijfer in plaats van een overponst tekenkarakter, dus het bestand zegt nooit dat het een debet is. Het wordt als credit gelezen — en de door het CFONB vereiste boekhoudkundige identiteit is wat dat betrapt. | Geldig | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYDe SEPA-gegevens van een CFONB 120-afschrift zitten in de «05»-aanvullingsrecords, en elke qualifier knipt dezelfde zone van 70 tekens (posities 49-118) anders op: RUM draagt een mandaatreferentie ÉN het sequentietype (RCUR), REF een batchreferentie ÉN een transactiereferentie, RCN een end-to-end-id ÉN een purpose, terwijl NBE, NPY en LIB de hele zone innemen. Plat gelezen plakt de zone het mandaat aan zijn sequentietype. Dit bestand bevat een SEPA-incasso (operatie B1) en een ontvangen overschrijving, met tien verschillende qualifiers samen. | Geldig | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileEén fysiek CFONB 120-bestand, twee rekeningen: elk vormt zijn eigen blok 01 (beginsaldo) … 07 (eindsaldo) en sluit op zichzelf. De tweede opent ROOD — het beginsaldo draagt een overponsteken uit de «}»-familie, dus een debet — en klimt terug naar een creditsaldo van 179,60. Een parser die één doorlopend saldo over het hele bestand bijhoudt, of het tekenkarakter als cijfer leest, zit er bij beide rekeningen naast. | Geldig | |
| CFONB 120 — the new balance does not equal old balance ± movementsElk bedrag draagt hier een correct overponsteken — en tóch klopt het afschrift niet: 1.000,00 − 89,90 + 500,00 = 1.410,10, terwijl het «07»-record 1.310,10 meldt. Regel 2 van §1 van de CFONB-specificatie stelt die identiteit als de DEFINITIE van een conform afschrift: dit is dus geen heuristiek, er ontbreekt 100,00 aan mutatie in het bestand. | Geldig |
Fedwire ISO 20022-bericht (VS) (6)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferEen klantoverboeking met BAH-header en hybride postadressen — voldoet al aan het formaat dat vanaf 16 november 2026 vereist is. | Geldig | |
| Fedwire pacs.009 — conformant bank-to-bank transferEen overboeking tussen financiële instellingen: het interbancaire deel, waarbij debiteur en crediteur banken zijn. | Geldig | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026Het adres van de crediteur bestaat uit drie vrije tekstregels, zonder plaats of land. Geldig volgens het XSD, maar afgewezen door de regel: vanaf 16 november 2026 schrapt Fedwire het volledig ongestructureerde adres. | Ongeldig | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overHet tegenvoorbeeld: precies hetzelfde ongestructureerde adres, maar met afwikkeling op 30-06-2026. Dat is toegestaan, dus volgt alleen een waarschuwing. De trigger is de afwikkeldatum in het bericht, nooit de datum van vandaag. | Geldig | |
| Fedwire pacs.008 — routing number that cannot existHet routingnummer van de bank van de crediteur is 021000088 — één cijfer verkeerd. Het faalt op het ABA 3-7-1-controlecijfer en kan dus niet bestaan. Het XSD ziet negen keurige cijfers. | Ongeldig | |
| Fedwire — header announces a different message than it carriesDe BAH-header noemt <MsgDefIdr>pacs.009.001.08</MsgDefIdr>, terwijl het bijbehorende document een pacs.008 is. Beide helften zijn schemaconform — alleen de vergelijking legt het bloot. | Ongeldig |
SWIFT MT103-overboeking (2)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| MT103 — cross-currency customer credit transferEen volledig MT103: alle vijf SWIFT-blokken, een UETR, een opdrachtgever in optie K, agenten in optie A en een IBAN-begunstigde. Afgewikkeld in USD, opgedragen in EUR — veld :36: (wisselkoers) is dus vereist en aanwezig. | Geldig | |
| MT103 — three defects a plain text viewer would missStructureel een prima leesbaar MT103 — en drie keer fout: de UETR is geen UUID v4, de betaling is meervalutair zonder wisselkoers in :36:, en de IBAN van de begunstigde faalt op mod-97. | Geldig |
CPA-005-/AFT-betaalbestand (Canada) (6)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Een gewoon Canadees loonbestand: één «C»-record met twee directe stortingen (transactietype 200) in twee van zijn zes segmenten. De Z-trailer geeft 2 crediteringen van in totaal 3.750,50 aan en geen debiteringen, en het klopt. Let op: de recordteller telt FYSIEKE records terwijl de trailer TRANSACTIES telt — drie records en twee transacties. | Geldig | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Een «D»-incasso van 899,00, gevolgd door het «J»-record dat hem retourneert. De retour draagt reden 901 (ontoereikend saldo) in het veld TRANSACTIETYPE — waar een betaling haar type zou dragen — terwijl het oorspronkelijke type 700 bewaard blijft in het stored transaction type. Beide worden als debet geboekt, vandaar de 2 debiteringen van 1.798,00 in de trailer. | Geldig | |
| CPA-005 — the error correction folded into the debit totalOpzettelijk kapot, en kapot zoals echte generatoren het kapotmaken: het bestand draait een creditering terug met een «E»-record, en de trailer telt die terugdraaiing als een debitering. Dat is het niet. Standaard 005 geeft de correcties E en F hun EIGEN paar totalen, los van de debet- en creditparen — voeg je ze samen, dan klopt het bestand niet meer. Dit is de meest voorkomende reden waarom een zelfgebouwde CPA-005-generator wordt geweigerd. | Ongeldig | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedEen AFT-bestand van 1464 tekens met beide richtingen: een «C»-record met twee salarisstortingen (3.750,50) en een «D»-record met twee incasso’s (1.349,25). C is de CREDITERING en D de DEBITERING — meerdere gepubliceerde samenvattingen draaien dat om. De Z-trailer klopt op de vier paren totalen die standaard 005 definieert (D+J, C+I, E apart, F apart), hier met de E- en F-tellers op nul. | Geldig | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Een Canadese Notice of Change: de ontvangende instelling laat de opdrachtgever weten dat een rekening is gewijzigd. Het is een APART BESTAND — records zijn 208 tekens lang, niet 1464, en standaard 005 verbiedt om de U- (header), S- (wijziging) en V-records (trailer) te mengen met AFT-records. Elk S-record draagt het nieuwe routingnummer en de nieuwe rekening naast de oorspronkelijke, en de V-trailer geeft aan hoeveel S-records het bestand bevat. | Geldig | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaEen klant-naar-bank loonbestand dat een op Amerikaanse regels getrainde validator twee keer ten onrechte zou afwijzen. De eerste creditering loopt via transit 099999999, dat géén rekenkundig controlecijfer draagt — het Canadese DPRN heeft er domweg geen: standaard 005 valideert het door opzoeking in het Financial Institutions File, en standaard 006 definieert geen enkele checksum. Wie hier de Amerikaanse 3-7-1-regel op plakt, wijst volkomen geldige bestanden af. De Item Trace Numbers staan bovendien op nul, normaal voor een bestand dat een klant bij zijn bank indient (de Direct Clearer kent ze toe) — vandaar twee waarschuwingen en nul fouten. | Geldig |
ACH-/NACHA-bestand (VS) (10)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Een WEB-incasso van 123,54 die terugkomt. Bij een retour veranderen precies drie dingen: de transactiecode wordt 26 (de retourcode van een betaalrekening-debitering — NIET de oorspronkelijke 27), de ontvangende bank wordt de ODFI van het origineel, en er wordt een nieuw tracenummer toegekend. Het bedrag blijft ongewijzigd — ACH kent geen gedeeltelijke retour. De addenda 99 draagt R01 en verwijst naar het tracenummer van de oorspronkelijke post. De batch blijft WEB en blijft TRANSFER: er bestaat geen «RETURN»-omschrijving en geen SEC-code «RET», hoe vaak het web ook iets anders beweert. | Geldig | |
| ACH — a notification of change (C01, corrected account number)Een notification of change — en het punt is dat het GEEN afwijzing is. De betaling is doorgegaan. De ontvangende bank vraagt om de opgeslagen gegevens te corrigeren vóór de VOLGENDE betaling: deze opnieuw sturen zou de begunstigde dubbel betalen. Daarom draagt de post het bedrag NUL, en daarom is de SEC-code van de batch COR. De addenda 98 draagt C01 met het gecorrigeerde rekeningnummer op posities 36-52 van het record. | Geldig | |
| ACH — an international entry (IAT) with its seven mandatory addendaEen USD-naar-MXN-betaling naar Mexico. Een IAT-record is niet het binnenlandse record met andere labels: het rekeningnummer verhuist naar posities 40-74 (35 tekens, om een buitenlandse rekening te bevatten), posities 13-16 geven aan hoeveel addenda volgen, en de naam van de begunstigde staat helemaal niet in het record — die leeft in addenda 10. Zeven addenda (10 tot en met 16) zijn verplicht bij elke internationale post, want een record van 94 tekens kan naam, adres en bankidentificatie van beide partijen niet bevatten. Dit bestand met de binnenlandse offsets lezen levert een stuk van het rekeningnummer op alsof het een persoonsnaam was. | Geldig | |
| ACH — PPD payroll credits, balanced with an offset debitHet referentiebestand: hoe een correct NACHA-bestand eruitziet. Vier PPD-salariscrediteringen (drie op een betaalrekening, code 22, één op een spaarrekening, code 32) en een vijfde post — de offset-debitering, code 27, op de eigen rekening van het bedrijf voor precies het totaal. Dat maakt het bestand «balanced», en daarom is de service class code 200 (gemengd) en niet 220. Entry hash, Batch Control-totalen, File Control-totalen en block count kloppen allemaal, en elk routingnummer voldoet aan het ABA 3-7-1-controlecijfer. | Geldig | |
| ACH — CCD corporate debits with an addenda 05 remittanceEen B2B-incasso: twee CCD-debiteringen (service class 225, alleen debiteringen), elk met één addenda 05 met de factuur die ermee wordt voldaan — RMR- en REF-segmenten, de ASC X12-remittance waarmee een zakelijke ontvanger afletter. CCD staat precies ÉÉN addenda per post toe: 80 tekens betalingsinformatie, geen teken meer. Heeft de betaler meer ruimte nodig, dan wordt de SEC-code CTX. Let op de addenda record indicator op positie 79 van de post: die staat op 1, en er volgt daadwerkelijk een addenda. | Geldig | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Vier WEB-debiteringen — de SEC-code van een betaling die een consument online heeft geautoriseerd. Drie gaan van betaalrekeningen af (code 27) en één van een spaarrekening (code 37): de transactiecode zegt welke, en die als iets anders dan een tabel lezen is precies hoe parsers de fout in gaan. Posities 77-78 dragen de payment type indicator, R voor terugkerend en S voor eenmalig. WEB-posten dragen geen addenda, dus de addenda record indicator blijft 0. | Geldig | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Eén CTX-debitering van 28.750,00 die drie facturen tegelijk voldoet, met het ASC X12 820-remittance-advies verdeeld over zeven addenda 05-records. CTX is de SEC-code die parsers het vaakst verkeerd lezen, want het entry-record betekent hier niet wat het overal elders betekent: posities 55-58 zijn NIET het begin van een naam, ze zijn het AANTAL addenda dat volgt (hier 0007), en de naam van het ontvangende bedrijf begint pas op 59. Met de PPD-offsets gelezen komt de naam terug als «0007GLOBEX CORP» — precies wat onze eigen validator toont, want die past de binnenlandse indeling toe. | Geldig | |
| ACH — entry hash mismatch (truncated or tampered file)Een PPD-crediteringsbestand met een verkeerde entry hash. De entry hash is de som van de 8-cijferige routingnummers van alle posten, afgekapt op de laatste tien cijfers — een controlegetal met als enige taak een bestand te betrappen dat onderweg een post verloor, erbij kreeg of gewijzigd zag. Hier verklaren zowel de Batch Control als de File Control 28905251, terwijl de vier posten optellen tot 27905251. De bedragen kloppen nog steeds, en dat is precies het punt: de hash is de controle die aanslaat wanneer geen enkele andere dat doet. | Ongeldig | |
| ACH — batch control debit total ≠ the sum of its entriesEen CCD-debetbatch waarvan de Batch Control 18.450,00 verklaart terwijl de twee posten optellen tot 28.075,00 — de klassieke fout van een generator die zijn trailer schrijft voordat hij de laatste post heeft opgeteld. Al het overige in het bestand klopt, ook de File Control-totalen, dus de validator meldt precies één fout en noemt beide bedragen. Dit is de meest voorkomende reden waarom een bank een handgemaakt ACH-bestand weigert. | Ongeldig | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberEen WEB-debetbestand waarin één ontvangende bank 026009594 draagt — een routingnummer dat zakt voor het ABA 3-7-1-controlecijfer (het echte is 026009593). Alleen positie 12 van de post is fout, dus de entry hash en alle controletotalen kloppen nog steeds: het controlecijfer is de enige controle die één verkeerd getypt cijfer betrapt, en dit bestand bewijst dat de totalen alleen dat niet doen. De andere twee posten en alle trailers zijn correct, dus de validator meldt precies één fout. | Ongeldig |
Betaal-QR-code (EPC / Zwitserse QR-factuur) (6)
| Voorbeeldbestanden | Verwacht resultaat | Bestand downloaden |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Een conforme EPC-QR-code (SCT QR), versie 002 — die waarin de BIC optioneel is en hier wordt weggelaten. De mededeling is een gestructureerde ISO 11649-crediteurreferentie, RF6518539007547034, met kloppende mod-97-controlecijfers: 94 van de toegestane 331 bytes. | Geldig | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageDe andere helft van EPC069-12: versie 001, waarin de BIC van de begunstigde verplicht is (het enige verschil tussen 001 en 002), met een vrije mededeling in plaats van een referentie. Gestructureerde referentie en vrije tekst sluiten elkaar uit — een QR-code draagt het een of het ander, nooit beide. | Geldig | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capDe valkuil die de specificatie met zoveel woorden benoemt en waar implementaties toch in trappen: EPC069-12 begrenst de payload op 331 BYTES, niet tekens. Deze Poolse payload telt 312 tekens — ruim onder elke tekengrens — maar elke letter met diakriet kost twee bytes in UTF-8: 338 bytes, dus afgewezen. | Ongeldig | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)De canonieke Zwitserse QR-factuur: een QR-IBAN (institutie-ID 31999, binnen het bereik 30000-31999) gekoppeld aan de QRR-referentie die hij vereist — 26 cijfers plus een controlecijfer in recursief modulo 10, niet de mod-97 uit de IBAN-wereld. Let op het blok “ultimate creditor”: zeven regels, aanwezig en volledig leeg, precies zoals de richtlijnen eisen. | Geldig | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceDe andere helft van de koppelingsregel: een gewone IBAN (institutie-ID 00791, buiten het QR-IID-bereik) VERBIEDT een QRR-referentie en neemt een ISO 11649-crediteurreferentie (SCOR) — RF6518539007547034 — of helemaal geen. Zelfde factuur, ander rekeningtype, andere referentie: dit onderscheid bepaalt of een Zwitserse betaling geboekt kan worden. | Geldig | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)De fout met de zwaarste gevolgen in het Zwitserse formaat: een QR-IBAN met een ISO 11649-referentie (SCOR). De referentie zelf is volkomen geldig — dat is de valkuil — maar een QR-IBAN eist een QRR-referentie en niets anders. De bank kan de betaling niet boeken, en het oordeel is hetzelfde onder richtlijnen 2.3 en 2.4. | Ongeldig |
Hoe we weten dat deze resultaten kloppen
Elk bestand in deze bibliotheek gaat bij elke build door de eigen validator van de site. Het hierboven vermelde verwachte resultaat wordt door een geautomatiseerde test bevestigd: zou een bestand niet meer overeenkomen met wat deze pagina beweert, dan faalt de build. Twee overgeërfde fixtures zijn zo vóór publicatie hersteld: drie IBAN's zakten voor de mod-97-controle en meerdere namen gebruikten tekens buiten de SEPA-basistekenset.