Bibliothek der Beispieldateien
Fertige SEPA-, camt.053-, UBL-, MT940- und Factur-X-Dateien — gültige zum Starten, absichtlich fehlerhafte zum Testen. Jede Datei wird von dem Validator geprüft, zu dem sie gehört.
SEPA- und E-Rechnungs-Beispieldateien
Fertige SEPA-, camt.053-, UBL-, MT940- und Factur-X-Dateien — gültige zum Starten, absichtlich fehlerhafte zum Testen. Jede Datei wird von dem Validator geprüft, zu dem sie gehört.
129
Beispieldateien
92
Gültig
37
Ungültig
SEPA-Überweisung (pain.001) (12)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| pain.001.001.03 — valid credit transferEine gültige SEPA-Überweisung in pain.001.001.03: drei Zahlungen über 1.580,00 EUR, stimmige Kontrollsummen, IBANs mit korrekter Mod-97-Prüfziffer und Namen im SEPA-Basiszeichensatz. | Gültig | |
| pain.001.001.09 — valid, hybrid addressEine gültige pain.001.001.09-Überweisung mit BICFI und der von EPC153-22 v2.1 erlaubten hybriden Adresse: TwnNm und Ctry sowie höchstens zwei AdrLine mit maximal 70 Zeichen. | Gültig | |
| pain.001.001.03 — CtrlSum mismatchEine pain.001 mit falscher Kontrollsumme: CtrlSum nennt 1.000,00 EUR, die Zahlungen ergeben aber 1.500,00 EUR. Die Abweichung wird zweimal gemeldet — für den Zahlungsstapel und für den Datei-Header. | Ungültig | |
| pain.001.001.03 — invalid IBANEine pain.001 mit einer Gläubiger-IBAN, deren zwei Prüfziffern die Mod-97-Prüfung (ISO 7064) nicht bestehen. Alles andere ist korrekt, daher meldet der Validator genau einen Fehler. | Ungültig | |
| pain.001.001.03 — NbOfTxs mismatchEine pain.001, die sich verzählt: NbOfTxs nennt eine Transaktion, die Datei enthält aber zwei. Wie bei CtrlSum wird die Anzahl sowohl im Zahlungsstapel als auch im Datei-Header geprüft. | Ungültig | |
| pain.001.001.03 — unstructured address after 2026-11-15Der Referenzfall für die EPC-Regel zur strukturierten Adresse: Die Adressen enthalten nur AdrLine, kein TwnNm. Zum blockierenden Fehler wird das durch das Ausführungsdatum in der Datei (ReqdExctnDt = 2026-11-20, nach dem Stichtag 15.11.2026) — mit einem früheren Datum bleibt bei derselben Datei nur eine Warnung. | Ungültig | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15Die Referenzdatei „bereit für 2026“: eine pain.001.001.11-Überweisung, deren Ausführungsdatum (ReqdExctnDt = 2026-11-20) nach dem EPC-Stichtag für strukturierte Adressen (15.11.2026) liegt. Jede Zahler- und Empfängeradresse ist vollständig strukturiert — StrtNm, BldgNb, PstCd, TwnNm, Ctry und keine einzige AdrLine. Drei Zahlungen, 4.320,00 EUR, null Fehler und null Warnungen. | Gültig | |
| pain.001.001.09 — valid, two payment batches with different execution datesEine pain.001-Datei, zwei PmtInf-Blöcke: Stapel A wird am 10.03.2026 mit hybriden Adressen (TwnNm + Ctry + eine AdrLine) ausgeführt, Stapel B am 20.11.2026 mit vollständig strukturierten. Sie zeigt beides, was eine Mehrstapel-Datei lehrt: Die EPC-Adressregel wird je Stapel anhand dessen eigenem Datum geprüft, und jeder PmtInf trägt eigene NbOfTxs / CtrlSum zusätzlich zu den GrpHdr-Summen (4 Zahlungen, 3.350,00 EUR). | Gültig | |
| pain.001.001.03 — nine-character BICEine pain.001, deren BIC der Empfängerbank neun Zeichen lang ist. ISO 9362 erlaubt 8 (Institut + Land + Ort) oder 11 (plus dreistellige Filialkennung) — niemals 9 oder 10. „BNPAFRPPX“ ist das typische Bild einer abgeschnittenen oder von Hand aufgefüllten Filialkennung, und es ist der eine Fehler dieser Datei, den beide Schichten sehen: Das offizielle XSD lehnt ihn wegen seines BIC-Musters ab, die Regelwerkschicht wegen seiner Länge. | Ungültig | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setEine pain.001, deren Empfänger „Café Renard & Fils SARL“ heißt — ein akzentuierter Buchstabe und ein kaufmännisches Und, beide außerhalb des vom EPC zugelassenen lateinischen Basiszeichensatzes (a-z A-Z 0-9 sowie / - ? : ( ) . , ' + Leerzeichen). Das XML ist wohlgeformt und das offizielle XSD akzeptiert es anstandslos: Max70Text nimmt jede Zeichenkette. Dieser Fehler lebt allein in der Regelwerkschicht — genau deshalb erreichen solche Dateien die Bank, die sie ablehnt oder stillschweigend transliteriert. | Ungültig | |
| pain.001.001.03 — 250 transfers, high-volume payroll runEin realistischer Gehaltslauf: 250 SEPA-Überweisungen in einer einzigen PmtInf, verteilt auf fünf Länder (DE, NL, BE, ES, FR), insgesamt 442.028,75 EUR. Jede IBAN trägt korrekte Mod-97-Prüfziffern (ISO 7064), und beide Kontrollsummen entsprechen der Summe auf den Cent genau. Damit lässt sich prüfen, wie der eigene Parser, das Bankportal oder die eigene Software auf eine Datei reagiert, die weder Spielzeug noch pathologisch ist — und dass ein einziger falscher Cent in einem Stapel dieser Größe allein von CtrlSum gefunden wird. | Gültig | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)Der Zwilling des blockierenden Beispiels mit unstrukturierter Adresse — geändert wurde nur eines: das Ausführungsdatum. Dieselben reinen AdrLine-Adressen, aber ReqdExctnDt ist der 30.09.2026, vor dem Stichtag von EPC153-22 v2.1: Derselbe Mangel erscheint als zwei Warnungen statt zweier Fehler — die Zahlung geht heute noch durch. Zugleich zeigt die Datei, was „strukturiert“ wirklich heißt: Die Zahleradresse hat weder TwnNm noch Ctry, die Empfängeradresse hat ein Ctry und immer noch kein TwnNm. Ctry allein genügt nicht; TwnNm ist das Unterscheidungsmerkmal. | Gültig |
SEPA-Lastschrift (pain.008) (8)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitEine gültige SEPA-Lastschrift im CORE-Verfahren: zwei wiederkehrende Einzüge über 175,00 EUR, eine Gläubiger-Identifikationsnummer (ICS), die die ISO-7064-MOD-97-10-Prüfung besteht, und ein unterzeichnetes Mandat je Zahlungspflichtigem. | Gültig | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15So sieht eine konforme SEPA-Lastschrift nach dem Stichtag 15.11.2026 aus: Das Einzugsdatum ist der 20.11.2026, daher ist jede Gläubiger- und Zahlungspflichtigen-Adresse strukturiert (TwnNm + Ctry). CORE-Verfahren, drei Einzüge über 228,80 EUR, keine Warnung. | Gültig | |
| pain.008.001.02 — mandate signed after the collectionEin Einzug auf Basis eines Mandats, das der Zahlungspflichtige noch gar nicht unterschrieben hatte: DtOfSgntr ist der 10.04.2026, das Einzugsdatum aber der 05.03.2026. Ein häufiger, still tödlicher Fehler — ICS, IBANs und Summen stimmen alle. | Ungültig | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceEine gültige SEPA-Firmenlastschrift (B2B) in pain.008.001.08: LclInstrm/Cd = B2B, Sequenztyp RCUR, zwei wiederkehrende Einzüge über 4.650,00 EUR. Das B2B-Verfahren ist die Variante zwischen Unternehmen — der Zahlungspflichtige darf kein Verbraucher sein und hat nach der Verrechnung KEIN Erstattungsrecht. Deshalb prüft seine Bank das Mandat vor der Belastung, und deshalb werden B2B-Einzüge früher eingereicht als CORE-Einzüge. | Gültig | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceEine gültige SEPA-Basislastschrift (CORE) mit Sequenztyp FRST: der erste Einzug unter einem brandneuen Mandat (DtOfSgntr liegt wenige Tage zurück). Alles Weitere auf demselben Mandat muss als RCUR laufen — einen Stapel dauerhaft auf FRST stehen zu lassen, gehört zu den häufigsten SDD-Fehlern und ist der Grund, warum Banken Einzüge mit dem Rückgabegrund „falscher Sequenztyp“ zurückgeben. | Gültig | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceEine gültige einmalige SEPA-Lastschrift: Sequenztyp OOFF, ein einziger Einzug über 349,00 EUR. Das Mandat erlaubt genau eine Belastung und ist mit ihrer Nutzung verbraucht — es darf nie wieder eingereicht werden, auch nicht als RCUR. Das ist die Sequenz für den Einzelkauf, die Anzahlung oder die einmalige Gebühr; wer stattdessen FRST verwendet, hinterlässt stillschweigend ein offenes Mandat, dem der Zahlungspflichtige nie zugestimmt hat. | Gültig | |
| pain.008.001.02 — mandate identifier (MndtId) missingEine Lastschrift ohne Mandatsreferenz: MndtRltdInf ist vorhanden und trägt ein Unterschriftsdatum, doch das Element MndtId (AT-01 des Rulebooks) fehlt. Das offizielle ISO-20022-XSD akzeptiert die Datei — MndtId ist dort optional —, eine rein strukturelle Prüfung lässt sie also durch, und die Bank weist sie ab: Ohne Mandatsreferenz hat die Bank des Zahlungspflichtigen nichts, woran sie den Einzug knüpfen könnte, und der Zahlungspflichtige nichts, wogegen er widersprechen könnte. | Ungültig | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsEine SEPA-Lastschrift, die sich verzählt und verrechnet — und zwar auf beiden Ebenen zugleich: Der Stapel enthält tatsächlich 2 Einzüge über 300,00 EUR, doch NbOfTxs nennt 3 und CtrlSum 250,00 — im PmtInf und noch einmal im GrpHdr. Das sind vier Fehler, nicht zwei: Kontrollsummen werden im Zahlungsstapel UND im Datei-Header geprüft, denn eine Mehrstapel-Datei kann einen korrekten Header-Wert über zwei falschen Stapelsummen tragen. Das XML ist wohlgeformt und das offizielle XSD akzeptiert es: Für ein Schema sind NbOfTxs und CtrlSum bloß Zahlen. | Ungültig |
Kontoauszug (camt.052 / 053 / 054) (12)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| camt.053.001.02 — valid statementEin gültiger camt.053.001.02-Kontoauszug: vier Buchungen, Anfangs- und Schlusssaldo stimmen überein (OPBD ± Bewegungen = CLBD), Datumsangaben im Dt-Format. | Gültig | |
| camt.053.001.08 — valid statementEin gültiger camt.053.001.08-Kontoauszug: drei Buchungen, DtTm-Zeitstempel und BICFI statt BIC — genau die Unterschiede, über die man beim Wechsel von Version 02 auf 08 stolpert. | Gültig | |
| camt.053 — unsupported namespaceEin Auszug, der camt.053.001.99 deklariert — eine Version, die es im ISO-20022-Katalog nicht gibt. Nützlich, um zu prüfen, ob der eigene Parser unbekannte Namespaces ablehnt, statt zu raten. | Ungültig | |
| camt.053.001.06 — missing Stmt elementEin Auszug mit korrektem camt.053.001.06-Namespace, aber ganz ohne <Stmt>-Element: Der Umschlag stimmt, der Inhalt fehlt. Genau so sieht ein abgeschnittener Bankexport aus. | Ungültig | |
| camt.053.001.11 — valid statementEin gültiger camt.053.001.11-Kontoauszug — die aktuelle Version der ISO-20022-Auszugsnachricht. Vier Buchungen, OPBD 25.000,00 ± Bewegungen = CLBD 34.659,05. Beachtenswert: Version 11 macht Sts und BkTxCd bei jeder Buchung zur Pflicht, die frühere Versionen weglassen ließen. | Gültig | |
| camt.053.001.08 — three accounts in one fileEine camt.053-Nachricht, drei <Stmt>-Blöcke: Girokonto, Sparkonto und USD-Konto. Die Datei ist schemakonform; der Validator sagt ausdrücklich, dass er nur den ersten Auszug auswertet. Genau darum geht es — ein Parser, der Stmt[0] nimmt und aufhört, verliert stillschweigend zwei Konten; diese Mehrkonten-Datei entlarvt ihn. | Gültig | |
| camt.053.001.10 — fully detailed entriesAlles, was eine Bank unter eine camt.053-Buchung hängen kann, in einer einzigen gültigen Datei: NtryDtls/TxDtls mit EndToEndId, InstrId, TxId und MndtId; RltdPties und RltdAgts; eine strukturierte Gläubigerreferenz nach ISO 11649 (RF) und eine referenzierte Rechnung (CINV); eine Sammelbuchung, deren zwei TxDtls exakt den Buchungsbetrag ergeben; sowie ein ISO-BkTxCd (PMNT/RCDT/ESCT) samt proprietärem deutschem GVC. Ideal, um zu prüfen, wie viel Ihr Abgleich von einer Buchung wirklich liest. | Gültig | |
| camt.053.001.08 — closing balance does not reconcileDer häufigste Fehler in produktiven camt.053-Dateien: Anfangssaldo 4.200,00 plus die gebuchten Posten ergeben 5.194,70, während der deklarierte CLBD 5.194,07 nennt — zwei Ziffern vertauscht. Die Datei erfüllt das offizielle ISO-20022-XSD tadellos, denn ein Schema sagt nichts über Arithmetik. Nur eine Saldenabstimmung findet einen falschen Schlusssaldo. | Gültig | |
| camt.052.001.08 — valid intraday reportEin gültiger camt.052-Intraday-Kontobericht — und kein kleiner camt.053: Die Wurzel heißt BkToCstmrAcctRpt, der Container <Rpt>, und die Salden sind ZWISCHENSALDEN (ITBD gebucht, ITAV verfügbar) statt des OPBD/CLBD-Paars eines Tagesendauszugs. Enthalten ist außerdem eine vorgemerkte Buchung (Sts=PDNG), die bewusst nicht im Zwischensaldo steckt: vorgemerktes Geld ist kein gebuchtes Geld. | Gültig | |
| camt.054.001.08 — valid debit/credit notificationEine gültige camt.054-Soll-/Haben-Anzeige: eine eingehende SEPA-Gutschrift und eine ausgehende Lastschrift, jeweils mit vollständigen TxDtls und Ende-zu-Ende-Referenz. Die strukturelle Überraschung ist das, was FEHLT: Eine camt.054 hat überhaupt kein <Bal>-Element — das ISO-20022-Schema definiert keines. Eine Anzeige meldet Bewegungen, sie nennt nie einen Saldo; es gibt also nichts abzustimmen. | Gültig | |
| camt.053.001.08 — entry with no CdtDbtIndDie zweite Buchung trägt einen Betrag von 1.200,00 und kein <CdtDbtInd>. Beträge in camt.053 sind stets vorzeichenlos: Ohne Richtungsindikator sagt der Betrag nichts aus. Zwei Dinge brechen zugleich — das offizielle XSD weist die Datei ab (CdtDbtInd ist an einer Buchung Pflicht, 1..1), und ein Parser, der stillschweigend auf CRDT zurückfällt, bucht +1.200,00 statt −1.200,00 und liegt 2.400,00 daneben, was die Saldenprüfung sofort aufdeckt. | Ungültig | |
| camt.053.001.08 — 220 entries, validEin Monatsend-Firmenauszug mit 220 gebuchten Posten, allesamt stimmig: OPBD 125.000,00 ± Bewegungen = CLBD 209.081,69. Jede Buchung trägt NtryDtls/TxDtls, eine EndToEndId und eine Gegenpartei — damit lässt sich ein camt.053-Reader unter realistischem Volumen prüfen statt an einer Drei-Zeilen-Spieldatei: Parsing-Durchsatz, Tabellenrendering und Abstimmung über Hunderte Zeilen. | Gültig |
UBL-Rechnung (Peppol BIS 3.0) (12)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Eine gültige Peppol-BIS-Billing-3.0-Rechnung: drei Positionen, 2.596,00 EUR brutto, stimmige Summen, französische USt-IdNr. und IBAN für die Zahlung. | Gültig | |
| UBL Credit Note — valid Peppol BIS 3.0Eine gültige Peppol-BIS-Billing-3.0-Gutschrift: eine Position, 1.770,00 EUR brutto, mit Bezug auf die stornierte Ursprungsrechnung. Die Gutschrift ist ein eigener UBL-Dokumenttyp, keine Rechnung mit negativen Beträgen. | Gültig | |
| UBL Invoice — BR-CO-10 violationEine Rechnung, die die EN-16931-Regel BR-CO-10 verletzt: Die Summe der Positionsnettobeträge (1.000,00) entspricht nicht dem Dokumentsumme BT-106 (2.000,00). Eine der häufigsten Ablehnungen im Peppol-Netz. | Ungültig | |
| UBL Invoice — malformed seller VAT identifierEine Rechnung, deren Verkäufer-USt-IdNr. „FR1234“ zu kurz ist: Eine französische Nummer besteht aus FR, einem zweistelligen Schlüssel und neun Ziffern. Formatfehler bei BT-31 werden abgefangen, lange bevor die Rechnung die Steuerbehörde erreicht. | Ungültig | |
| UBL Invoice — allowances and charges, line and document levelEine gültige UBL-Rechnung nach Peppol BIS 3.0 mit Nachlässen und Zuschlägen auf BEIDEN Ebenen: Positionsrabatt (BG-27), Positionszuschlag (BG-28), Rabatt auf Dokumentebene (BG-20) und Frachtkosten (BG-21). Entscheidend ist die Kette der Summen: BT-106 = 1.520,00 ist die Summe der NETTO-Positionsbeträge, und BT-109 = 1.530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13) — die 19 % USt. werden also auf 1.530,00 berechnet, nicht auf 1.520,00. | Gültig | |
| UBL Invoice — reverse charge (VAT category AE)Eine gültige Rechnung mit Umkehrung der Steuerschuldnerschaft in UBL: Ein französischer Dienstleister stellt einem deutschen Unternehmen Leistungen in Rechnung, die USt. schuldet der Leistungsempfänger — also 0 % und keine ausgewiesene Steuer. Kategorie AE bringt vier Regeln mit: beide USt-IdNr. (BR-AE-02, BR-AE-03), den Satz 0 % (BR-AE-05), einen Steuerbetrag von 0,00 (BR-AE-09) und einen Befreiungsgrund (BR-AE-10), hier VATEX-EU-AE und der Text „Reverse charge“. | Gültig | |
| UBL Invoice — VAT exempt (category E) with exemption reasonEine gültige umsatzsteuerfreie Rechnung (Kategorie E): berufliche Bildung, befreit nach Artikel 132 Abs. 1 Buchst. i der Richtlinie 2006/112/EG. Eine steuerfreie Rechnung muss sagen, WARUM sie steuerfrei ist — BR-E-10 verlangt einen Befreiungsgrund als Code (BT-121) oder als Text (BT-120); diese Datei enthält beides: VATEX-EU-132 und den Wortlaut aus der offiziellen Codeliste. | Gültig | |
| UBL Invoice — intra-Community supply (VAT category K)Eine gültige innergemeinschaftliche Lieferung (USt-Kategorie K): Waren aus Deutschland an einen umsatzsteuerregistrierten Käufer in Frankreich, steuerfrei nach Artikel 138 der Richtlinie 2006/112/EG. Kategorie K verlangt zwei gern vergessene Angaben: BR-IC-11 — ein tatsächliches Lieferdatum (BT-72) oder einen Abrechnungszeitraum — und BR-IC-12 — das Lieferland (BT-80). Ohne sie belegt die Rechnung nicht, dass die Ware das Land verlassen hat. | Gültig | |
| UBL Invoice — two VAT rates, one breakdown per rateEine gültige Rechnung mit französischem Regelsteuersatz (20 %) und ermäßigtem Satz (5,5 %). Die Regel dahinter ist BR-S-08: Die USt-Aufschlüsselung (BG-23) enthält EIN TaxSubtotal je Paar (Kategorie, Satz), und jede Bemessungsgrundlage ist die Summe der Positionen mit diesem Paar — 1.500,00 zu 20 % (USt. 300,00) und 400,00 zu 5,5 % (USt. 22,00). Zwei Sätze in einem Untertotal zu verschmelzen besteht alle BR-CO-Prüfungen und ist trotzdem falsch. | Gültig | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106Die häufigste Ablehnung in der Praxis, isoliert: Die beiden Positionen ergeben 1.500,00, BT-106 (LineExtensionAmount) nennt aber 1.400,00 — BR-CO-10. Alles andere ist mit der FALSCHEN Zahl konsistent, daher bestehen BR-CO-13, BR-CO-14, BR-CO-15 und BR-CO-16, und es kommt genau ein Fehler zurück. Genau so sieht eine Position aus, die nach der Summenbildung entfernt wurde. | Ungültig | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Eine steuerfreie Rechnung, gleich doppelt falsch. BR-E-10: Die USt-Aufschlüsselung der Kategorie E enthält weder einen Befreiungsgrund (BT-120) noch einen Grundcode (BT-121) — eine steuerfreie Rechnung muss sagen, WARUM. BR-E-08: Die steuerfreie Bemessungsgrundlage nennt 1.200,00, während die steuerfreien Positionen 1.500,00 ergeben — die zweite Position kam nie in der Aufschlüsselung an. Zitiert ist der Fehler der Geschäftsregel-Ebene; das offizielle EN-16931-Schematron ergänzt BR-E-10. | Ungültig | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateEine USt-Aufschlüsselung, die nicht aufgeht: 2.000,00 zu 19 % ergibt 380,00 USt., die Rechnung nennt aber 395,00. BR-CO-17 prüft Steuerbetrag der Kategorie = Bemessungsgrundlage × Satz / 100 mit der offiziellen Toleranz von einer Währungseinheit — ein echter Rundungscent ist erlaubt, diese Lücke von 15,00 nicht. Alle übrigen Summen passen zur falschen Zahl: genau so überlebt ein Rundungsfehler bis in die Produktion. | Ungültig |
CII-Rechnung (XRechnung-/Factur-X-Syntax) (4)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validEine gültige XRechnung 3.0 in der CII-Syntax (UN/CEFACT CrossIndustryInvoice) — die E-Rechnung der deutschen öffentlichen Verwaltung. Sie enthält genau das, was die KoSIT-Regeln BR-DE über EN 16931 hinaus verlangen: die Leitweg-ID als Käuferreferenz (BR-DE-15), einen vollständigen Verkäuferkontakt — Name, Telefon und E-Mail (BR-DE-2 bis BR-DE-6), die elektronische Adresse des Verkäufers, strukturierte Zahlungsbedingungen und eine SEPA-Überweisung (Zahlungsmittel 58). | Gültig | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)Die Factur-X-/ZUGFeRD-Nutzlast für sich: das CII-XML, das sonst in einem PDF/A-3 eingebettet reist, hier als eigenständige, direkt prüfbare Datei. Das Profil BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) ist ein EN-16931-konformer CIUS — vollständige Rechnungspositionen, komplette USt-Aufschlüsselung und die sechs Dokumentsummen. Ideal, um einen Extraktor allein am XML zu testen, ohne PDF drumherum. | Gültig | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 in der CII-Syntax: Die beiden Positionen ergeben 2.000,00, LineTotalAmount (BT-106, in SpecifiedTradeSettlementHeaderMonetarySummation) nennt aber 1.900,00. Derselbe Fehler wie im UBL-Beispiel, nur in der Syntax, in der man ihn am schlechtesten sieht — die Dokumentsummen stehen in einem anderen Ast des Baums als die Positionen, die sie zusammenfassen. | Ungültig | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisEin Rabatt auf Dokumentebene, den es nur halb gibt: Die Rechnung gewährt 200,00 (BT-107), berechnet die USt. auf die rabattierte Basis (1.800,00 × 19 % = 342,00 — korrekt), doch BT-109 (TaxBasisTotalAmount) nennt weiterhin die unrabattierten 2.000,00. BR-CO-13 verlangt BT-109 = BT-106 - BT-107 + BT-108 — dem Käufer werden also 200,00 berechnet, die der Verkäufer verschenkt zu haben glaubte. | Ungültig |
SWIFT-MT940-Auszug (10)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectDer Normalfall MT940: ein Auszug, eine Gutschrift und eine Belastung, mit dem Referenzpaar Kunde/Bank in der :61:-Zeile. Der beste Einstieg, um die Tag-Struktur vor den Dialekten zu sehen. | Gültig | |
| MT940 — ING Belgium, structured :86:Der ING-Belgien-Dialekt: Die Informationszeile :86: ist in Unterfelder ?00 ?20 ?30 gegliedert statt als Freitext. Das ist die häufigste Ursache von MT940-Parsing-Fehlern. | Gültig | |
| MT940 — Commerzbank, one-decimal amountDer Commerzbank-Dialekt: ein Betrag mit nur einer Nachkommastelle (1234,5 für 1.234,50), ein NMSC-Transaktionstyp und ein deutsches Konto als BLZ + Kontonummer statt IBAN. | Gültig | |
| MT940 — two statements in one fileZwei Auszüge in einer einzigen MT940-Datei, dazu das Tag :64: für den verfügbaren Saldo. Eine Datei ist nicht ein Auszug — ein Parser, der das annimmt, verliert den zweiten stillschweigend. | Gültig | |
| MT940 — reversal (RC) and intermediate balancesDer ABN-AMRO-Fall: eine RC-Stornierung (eine Gutschrift, die zur Belastung wird), Zwischensalden 60M/62M statt F und ein :86: über zwei Zeilen. Stornierungen kehren das Vorzeichen um — wer das falsch macht, bekommt den Saldo nie ausgeglichen. | Gültig | |
| MT940 — overdrawn account (debit balances)Ein überzogenes Konto: Anfangs- und Schlusssaldo tragen beide die Kennung D (Soll). Ein negativer Saldo ist in MT940 keine negative Zahl, sondern ein Vorzeichen-Flag — Code, der es ignoriert, meldet die Überziehung als Guthaben. | Gültig | |
| MT940 — closing balance does not reconcileEin Auszug, dessen Schlusssaldo sich nicht aus Anfangssaldo ± Bewegungen ergibt. Bewusst nur eine Warnung, kein blockierender Fehler: Die Datei bleibt lesbar, und ein Mensch muss entscheiden, ob die Bank oder der Export schuld ist. | Gültig | |
| MT940 — 500 transactions (load test)Fünfhundert Transaktionen in einem Auszug, auf den Cent genau ausgeglichen. Damit prüfen Sie, ob Ihr Parser auch bei Produktionsvolumen exakt und schnell bleibt — nicht nur bei einer Dreizeilen-Spieldatei. | Gültig | |
| MT940 — statement split over two pages (62M / 60M)Ein Auszug, ein Tag, zwei Seiten: Sequenz 00147/00001 schließt mit einem ZWISCHENSALDO :62M:, Sequenz 00147/00002 eröffnet mit :60M: über genau diesen Betrag und schließt erst mit dem finalen :62F:. M ist nicht F — wer den Zwischensaldo für den Tagesendsaldo hält, meldet 37.500,00, obwohl das Konto bei 44.249,25 endete. | Gültig | |
| MT940 — USD account with an RD reversalEin Auszug in US-Dollar — MT940 ist kein Euro-Format —, in dem eine ausgehende Überweisung von 35.000,00 am Folgetag per RD-Storno zurückkommt: eine STORNIERTE BELASTUNG ist Geld, das ZURÜCKFLIESST. Die Marken RC/RD kehren die wirtschaftliche Richtung der :61:-Zeile um; wer nur das D in „RD“ liest, bucht die Rückerstattung erneut als Zahlung und gleicht nie ab. | Gültig |
BAI2-Kontoauszug (USA / Kanada) (6)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)Die BAI2-Beispieldatei im Normalfall: ein Konto, ein Eröffnungssaldo 010 und ein Schlusssaldo 015 sowie zehn Buchungen, deren Richtung allein aus dem Type Code stammt — 115 Lockbox-Einzahlung, 165 ACH-Gutschrift, 195 Zahlungseingang, 475 eingelöster Scheck, 451 ACH-Belastung, 495 Zahlungsausgang, 698 Gebühren. BAI2 kennt kein Soll-/Haben-Kennzeichen: 100–399 ist Zufluss, 400–699 Abfluss. | Gültig | |
| BAI2 — several accounts in one groupZwei 03-Kontosätze in einer einzigen 02-Gruppe — ein Geschäftskonto und ein Lohnkonto, jedes mit eigenem 49-Trailer. BAI2 ist hierarchisch (01 Datei / 02 Gruppe / 03 Konto / 16 Buchung / Trailer 49-98-99): Wer ein Konto pro Datei annimmt, verliert das zweite stillschweigend. | Gültig | |
| BAI2 — 88 continuation recordsDer 88-Fortsetzungssatz in seinen zwei völlig verschiedenen Rollen: Er trägt zusätzliche Saldo-Tupel für einen 03-Kontosatz (hier Schlusssaldo 015 und verfügbarer Saldo 045) und umgebrochenen Freitext für eine 16-Buchung (drei physische Zeilen, ein Verwendungszweck). Wer beide gleich zusammenführt, liest Salden als Text — oder Text als Salden. | Gültig | |
| BAI2 — CAD and JPY: minor units scale with the currencyBAI2-Beträge haben kein Dezimaltrennzeichen: Es sind Minor Units, und wie viele Nachkommastellen sie bedeuten, hängt von der Währung ab. Hier ist „2500000“ auf dem CAD-Konto 25.000,00 CAD (2 Stellen) und auf dem JPY-Konto ¥2.500.000 (0 Stellen). Das CAD-Konto lässt sein Währungsfeld zudem leer und erbt es aus dem 02-Gruppenkopf. Eine fest verdrahtete Division durch 100 verfälscht das Yen-Konto um zwei Zehnerpotenzen — und der Saldo stimmt trotzdem, weil alle drei Zahlen um denselben Faktor falsch sind. | Gültig | |
| BAI2 — closing balance does not reconcileDer Schlusssaldo 015 ergibt sich nicht aus dem Eröffnungssaldo 010 plus den 16-Bewegungen — 50.000,00 + 10.000,00 − 2.500,00 sind 57.500,00, die Datei behauptet aber 59.000,00. Die Trailer stimmen weiterhin, nur die Arithmetik verrät es. Bewusst eine Warnung, kein blockierender Fehler: Die Datei bleibt lesbar, und ein Mensch muss entscheiden, ob Bank oder Export schuld ist. | Gültig | |
| BAI2 — bad trailer totals and an out-of-range type codeDrei Fehler auf einmal. Der 49-Kontotrailer nennt eine Kontrollsumme und eine Satzanzahl, die beide nicht zu den vorangehenden Sätzen passen — die Trailer sind die Integritätsprüfung der Datei selbst, wer sie überspringt, sieht eine Kürzung nicht. Und eine 16-Buchung trägt Type Code 720 aus dem Darlehensbereich 700–799: weder Gutschrift (100–399) noch Belastung (400–699), also ist die Richtung nicht ableitbar und der Satz wird verworfen statt geraten — weshalb auch der Saldo nicht mehr aufgeht. | Gültig |
Factur-X / ZUGFeRD (PDF) (2)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceEine gültige Factur-X-Rechnung im Profil EN 16931: ein PDF/A-3 mit eingebettetem CII-XML. Ein Dokument, das ein Mensch liest und eine Maschine parst — genau darum geht es beim hybriden Format. | Gültig | |
| Factur-X EN 16931 — BR-CO-15 violationEine Factur-X-Rechnung, die die EN-16931-Regel BR-CO-15 verletzt: Der Bruttobetrag beträgt 130,00, während Netto plus Steuer 120,00 ergeben. Das PDF öffnet sich und sieht völlig normal aus — nur das eingebettete XML verrät den Fehler. | Ungültig |
KSeF-Rechnung (Polen, FA(3)) (7)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Eine konforme strukturierte FA(3)-Rechnung — das Beispiel Nr. 4 des polnischen Finanzministeriums, unverändert übernommen. Drei Positionen, 64.279,92 PLN brutto bei 23 % USt. Referenz dafür, was KSeF akzeptiert. | Gültig | |
| KSeF — invoice still using the retired FA(2) schemaDer häufigste KSeF-Migrationsfehler: eine formal einwandfreie Rechnung, die weiterhin den am 1. Februar 2026 abgeschafften FA(2)-Namensraum angibt. Nichts wirkt falsch — bis KSeF sie zurückweist. Beachten Sie, was FA(3) ergänzt hat und hier fehlt: Podmiot2 verlangt nun JST und GV. | Ungültig | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Strukturell einwandfrei gegenüber dem offiziellen Schema — dennoch scheitert die NIP des Verkäufers an der Mod-11-Prüfziffer und P_15 passt nicht zur Summe der Steueraufteilung. ValidateFin meldet beides als Warnung, nicht als Fehler: keine der Regeln ist normativ, und das Beispiel 1 des Ministeriums weicht selbst um einen Grosz ab. | Gültig | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Eine Korrekturrechnung (RodzajFaktury = KOR) — der meistgesuchte und am häufigsten falsch gebaute FA(3)-Fall. Die Summen tragen die DIFFERENZ, nicht die berichtigte Rechnung: P_13_1, P_14_1 und P_15 sind negativ. Hinzu kommen PrzyczynaKorekty, TypKorekty und DaneFaKorygowanej mit dem Verweis auf die korrigierte Rechnung. Die Positionen stehen paarweise: die mit StanPrzed ist der Zustand davor. | Gültig | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Eine Anzahlungsrechnung (RodzajFaktury = ZAL): Sie stellt eine Anzahlung auf eine noch nicht gelieferte Bestellung in Rechnung. Sie enthält daher KEINE FaWiersz-Positionen — die Ware steht im Block Zamowienie (Bestellung) mit den eigenen Tags P_7Z / P_11NettoZ / P_11VatZ —, während P_15 nur die Anzahlung von 12.300,00 PLN auf eine Bestellung über 61.500,00 PLN ausweist. | Gültig | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Eine FA(3)-Rechnung, der ein Pflichtelement fehlt: P_2, die Rechnungsnummer. Auf den ersten Blick stimmt alles — wohlgeformtes XML, richtiger Namensraum, plausible Steueraufteilung —, und nur die offizielle XSD des Finanzministeriums entdeckt es: „Element P_6: this element is not expected. Expected is P_2.“ KSeF weist eine solche Datei rundweg zurück. | Ungültig | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)Die NIP des Käufers lautet 1111111112 — zehn Ziffern, also nimmt das offizielle Schema, das die NIP nur über ein Muster prüft, sie wortlos an. Die Mod-11-Prüfziffer stimmt jedoch nicht: eine solche polnische Steuernummer kann es nicht geben, die Rechnung geht an niemanden. ValidateFin meldet eine Warnung, nie einen Fehler — das Ministerium veröffentlicht keine solche Validierungsregel. | Gültig |
FatturaPA-Rechnung (Italien, SdI) (4)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyEine FatturaPA, die das SdI annehmen würde: korrekte USt.-Arithmetik (zwei Positionen zu 22 % ergeben 1.100 €, 242 € Steuer, 1.342 € gesamt), Steuer-IDs mit gültiger Prüfziffer und ein 7-stelliger CodiceDestinatario, wie ihn ein privater Empfänger verlangt. Der Bezugspunkt: Jedes andere Beispiel hier ist diese Datei, auf eine bestimmte Weise beschädigt. | Gültig | |
| FatturaPA — signed CAdES (.p7m) envelopeDieselbe konforme Rechnung, verpackt in einen CAdES-Signaturumschlag (.p7m) — so reisen die meisten echten italienischen Rechnungen, und so MUSS jede Rechnung an eine öffentliche Verwaltung reisen. Im Texteditor sieht man nur Binärrauschen. Der Validator öffnet den Umschlag und prüft das XML darin; die Signatur selbst prüft er nicht, und er sagt es. | Gültig | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Diese Rechnung ist gegen das offizielle XSD GÜLTIG, und das SdI würde sie trotzdem ablehnen — genau deshalb reicht eine reine Schemaprüfung nicht. Drei Mängel: Die Bemessungsgrundlage weist 1.150 € aus, während die Positionen 1.100 € ergeben (Prüfung 00422, deren Toleranz ein EURO beträgt, nicht ein Cent); die Steuer weist 250 € aus, wo 22 % von 1.150 € = 253 € sind (00421); und der Natura-Code ist das nackte N3, das am 1. Januar 2021 zugunsten seiner Untercodes zurückgezogen wurde (00445) — im Schema steht es weiterhin. | Ungültig | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)Der häufigste Grund, warum eine Rechnung an eine italienische Behörde zurückkommt: der CodiceDestinatario. Für eine PA (FormatoTrasmissione = FPA12) muss es der SECHSSTELLIGE IPA-Amtscode sein — die siebenstellige Form gehört privaten Empfängern. Das XSD erlaubt 6 ODER 7 für beide, das Schema sieht es also nicht; nur SdI-Prüfung 00427 sieht es. Die Rechnungsnummer „FATTURA“ enthält zudem gar keine Ziffer (00425). | Ungültig |
RO e-Factura-Rechnung (Rumänien, ANAF) (6)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Eine Rechnung, die ANAF annimmt — ihr eigener Offline-Validator sagt « este valid ». Es ist das veröffentlichte Beispiel des Ministeriums, repariert an den zwei Stellen, an denen die veröffentlichte Fassung scheitert: BT-24 auf CIUS-RO:1.0.1 gesetzt und zwei CUI mit tatsächlich korrekter Prüfziffer. Der Bezugspunkt: Jedes fehlerhafte Beispiel hier ist diese Datei, gezielt beschädigt. | Gültig | |
| RO e-Factura — credit note in a foreign currency (FCN)Eine Gutschrift (FCN) in SEK — und ANAF akzeptiert sie. Sie zeigt, was BR-RO-030 wirklich verlangt: RON muss als Rechnungswährung (BT-5) ODER als USt.-Buchungswährung (BT-6) auftreten, nicht zwingend beides. Hier ist BT-5 SEK und BT-6 RON, was die Regel erfüllt. Sie trägt außerdem den Typcode 381, der auf einer Gutschrift zulässig und auf einer Rechnung unzulässig ist. | Gültig | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)Die häufigste rumänische Ablehnung und der einzige Fehler dieser Datei: BT-24 nennt weiterhin CIUS-RO:1.0.0, einen am 29. Dezember 2022 zurückgezogenen Wert (Erlass OMF 4092/2022). Die Rechnung ist sonst tadellos und besteht das XSD. Beide vom Ministerium selbst veröffentlichten Beispiele tragen diesen Fehler — und sein eigener Validator lehnt sie ab. | Ungültig | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Ein Verkäufer in Bukarest, dessen Stadt (BT-37) „Sector 1“ lautet — genau die Schreibweise des Ministerialerlasses selbst. Das Schematron, das ANAF tatsächlich ausführt, verlangt SECTOR1: Großbuchstaben, ohne Leerzeichen. Wenn Gesetzestext und Implementierung auseinandergehen, lehnt die Implementierung Ihre Rechnung ab. | Ungültig | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)Das Beispiel, das den blinden Fleck jedes reinen Schematron-Validators offenlegt. Die CUI des Käufers (RO987456123) hat eine falsche Prüfziffer — und KEINE Schematron-Regel sieht sie an. Diese Datei besteht das XSD, besteht das gesamte CIUS-RO-Regelwerk, und ANAF lehnt sie dennoch ab, unter einem eigenen Code: ERRIdentif, « CUI cumparator incorect ». | Ungültig | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Eine B2C-Rechnung, deren Käufer eine Privatperson ist, identifiziert durch die anonyme CNP aus dreizehn Nullen — seit 16. Dezember 2024 im Einsatz. Sie ist gültig, und ein Validator, der darin eine fehlerhafte Personennummer sähe, würde die gesamte Verbraucherfakturierung in Rumänien lahmlegen: Diese Nummer besteht keine der CNP-Formregeln (ihre führende 0 wird überall sonst abgelehnt), denn sie ist ein reservierter Wert, keine CNP. | Gültig |
Verifactu-Rechnungsdatensatz (Spanien, AEAT) (3)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosEine Übermittlung, die die AEAT annehmen würde: zwei korrekt verkettete Rechnungsdatensätze. Der erste deklariert sich als Kettenanfang und hasht ein leeres Vorgänger-Feld; der zweite verkettet den Hash des ersten. Beide Fingerabdrücke sind echte SHA-256-Werte über genau die von der AEAT vorgegebene Zeichenkette — nicht erfunden. Der Bezugspunkt für die übrigen Beispiele. | Gültig | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)Der zweite Datensatz nennt einen Fingerabdruck, der NICHT zu seinem Inhalt passt: die Kette ist gebrochen. Die Datei ist gegen das offizielle AEAT-XSD GÜLTIG — ein reiner Schema-Validator lässt sie durch. Nur das Neuberechnen des verketteten SHA-256 findet den Fehler. Und: die AEAT lehnt sie NICHT ab, sie markiert sie als „Aceptado con errores“ (Code 2000) und speichert sie dennoch. | Gültig | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Eine vereinfachte Rechnung (F2) mit einem Destinatarios-Block — verboten, Code 1190 — und einer CuotaRepercutida (100 €), die nicht zu Bemessungsgrundlage × Satz passt (1.000 € × 21 % = 210 €), weit jenseits der ±10-€-Toleranz von Kontrolle 1142. Die Datei BESTEHT das offizielle XSD ohne Beanstandung: Das Schema kann das nicht sehen — die AEAT weist sie zurück. | Ungültig |
Facturae-Rechnung (Spanien, FACe) (2)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaEine an eine öffentliche Verwaltung gerichtete Facturae-3.2.2-Rechnung (mit ihren DIR3-Verwaltungsstellen, wie FACe es verlangt), die das offizielle XSD von facturae.gob.es ohne Beanstandung besteht, mit nach den Formeln des Schemas stimmigen Summen und vorhandener XAdES-Signatur. Der Bezugspunkt: das andere Beispiel ist dieselbe Datei, auf eine bestimmte Weise beschädigt. Die Signatur ist ein Muster — ihre kryptografische Gültigkeit wird offline nicht geprüft. | Gültig | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)Dieselbe Datei mit einer Änderung: InvoiceTotal deklariert 1.200,00 €, wo die Formel des Schemas 1.210,00 € ergibt (Basis 1.000 + USt 210). Die Datei ist gegen das offizielle facturae.gob.es-XSD GÜLTIG — ein reiner Schema-Validator lässt sie durch. Nur die Kohärenzschicht findet den Fehler und meldet zudem, dass die Losumme nicht mehr stimmt. Kein „offizieller“ Ablehnungscode: Facturae/FACe veröffentlicht keine offline prüfbaren Ablehnungscodes — daher eine Warnung, kein Fehler. | Gültig |
CODA-Kontoauszug (Belgien) (6)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationEin gewöhnlicher belgischer Kontoauszug: eine SEPA-Überweisung mit gültiger strukturierter Mitteilung (+++090/9337/55493+++), eine Kartenzahlung und ein Zahlungseingang mit Gegenpartei. Anfangssaldo 1.000,00 − 250,00 − 89,90 + 1.500,00 = Endsaldo 2.160,10; die Trailer-Summen stimmen. | Gültig | |
| CODA — globalised salary run (booked total + its details)Eine Globalisierung: eine gebuchte Gehaltssumme von 3.000,00 (Detailnummer 0000), gefolgt von den beiden Einzelgehältern dahinter (0001, 0002). Nur die Summe ist gebucht — ein Parser, der die Details mitzählt, verdoppelt die Datei, und der Auszug geht nicht mehr auf. Endet mit einem Sollsaldo von 2.000,00. | Gültig | |
| CODA — wrong mod-97 check digits and a statement that does not balanceAbsichtlich fehlerhaft. Die strukturierte Mitteilung endet auf 94, wo Mod 97 eine 93 verlangt — der häufigste Grund, warum eine belgische Zahlung nie ihrer Rechnung zugeordnet wird — und der Endsaldo folgt nicht aus den Bewegungen. Kein anderes kostenloses CODA-Tool prüft diese Prüfziffern. | Gültig | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedEin CODA-Kontoauszug mit den beiden strukturierten Referenzen, die das Format kennt — jede mit eigener Prüfziffer: eine ausgehende Überweisung mit belgischer strukturierter Mitteilung +++090/9337/55493+++ (Typ 101, Mod 97 — ein Rest von 0 wird als 97 geschrieben, nicht als 00) und ein Zahlungseingang mit ISO-11649-Kreditorenreferenz RF73INV20260042 (Typ 100, Mod 97-10). Beide sind korrekt, und der Auszug geht auf: 1.000,00 − 250,00 + 1.500,00 = 2.250,00. | Gültig | |
| CODA — separate application: balances zeroed by design (§7.2.1)Eine CODA-„separate application“ (Kopfsatz, Positionen 84-88 = 00001): eine Kartenakzeptanz-Abrechnung, die außerhalb des Kontoauszugs geliefert wird. Febelfin §7.2.1 setzt Anfangs- und Endsaldo konstruktionsbedingt auf null, also kann die Identität Anfangssaldo ± Bewegungen = Endsaldo gar nicht aufgehen — und darf nicht geprüft werden. ValidateFin überspringt die Prüfung und meldet die Datei sauber; ein Validator, der das nicht tut, erklärt jede solche Datei für fehlerhaft. | Gültig | |
| CODA — old balance ± movements ≠ new balanceEin gewöhnlicher belgischer Auszug — dem eine Bewegung fehlt. Die 2.1-Sätze ergeben 1.000,00 − 250,00 + 1.500,00 = 2.250,00, der „8“-Satz mit dem Endsaldo nennt aber 2.200,00: 50,00 gebuchter Umsatz sind nie in der Datei angekommen. Genau diese Prüfung entlarvt eine abgeschnittene CODA-Datei, einen verlorenen Satz oder ein falsch gelesenes Soll/Haben-Zeichen — und genau deshalb darf das vorige Beispiel NICHT so geprüft werden. | Gültig |
CFONB-120-Kontoauszug (Frankreich) (5)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsEin französischer Kontoauszug mit seinen vollständigen SEPA-Daten: eine Lastschrift mit Mandatsreferenz und Sequenztyp RCUR, der Name des Gläubigers, eine Kartenzahlung und ein Zahlungseingang mit Zahlername, Ende-zu-Ende-Referenz, Verwendungszweck und Verwendungstext — alles in „05“-Zusatzsätzen. Anfangssaldo 1.000,00 − 250,00 − 89,90 + 1.500,00 = Endsaldo 2.160,10. | Gültig | |
| CFONB 120 — amount without its overpunched signAbsichtlich fehlerhaft — und die klassische Art, eine CFONB-Datei zu zerstören: Der Betrag der Belastung endet auf einer bloßen Ziffer statt auf einem überstanzten Vorzeichenzeichen, die Datei sagt also nie, dass es eine Belastung ist. Sie wird als Gutschrift gelesen — und die vom CFONB geforderte Saldenidentität fängt das ab. | Gültig | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYDie SEPA-Daten eines CFONB-120-Auszugs stecken in den „05“-Zusatzsätzen — und jeder Qualifier schneidet dieselbe 70-Zeichen-Zone (Positionen 49-118) anders: RUM trägt eine Mandatsreferenz UND deren Sequenztyp (RCUR), REF eine Sammler- UND eine Transaktionsreferenz, RCN eine Ende-zu-Ende-ID UND einen Purpose, während NBE, NPY und LIB die ganze Zone belegen. Flach gelesen klebt die Zone das Mandat an seinen Sequenztyp. Diese Datei enthält eine SEPA-Lastschrift (Operation B1) und einen Zahlungseingang mit zusammen zehn verschiedenen Qualifiern. | Gültig | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileEine einzige physische CFONB-120-Datei, zwei Konten: jedes bildet seinen eigenen Block 01 (Anfangssaldo) … 07 (Endsaldo) und geht für sich allein auf. Das zweite startet im SOLL — der Anfangssaldo trägt ein überdrucktes Vorzeichen aus der „}“-Familie, also eine Lastschrift — und erholt sich auf ein Guthaben von 179,60. Ein Parser, der einen einzigen laufenden Saldo über die Datei führt oder das Vorzeichenzeichen als Ziffer liest, liegt bei beiden Konten falsch. | Gültig | |
| CFONB 120 — the new balance does not equal old balance ± movementsJeder Betrag trägt hier ein korrektes überdrucktes Vorzeichen — und der Auszug geht trotzdem nicht auf: 1.000,00 − 89,90 + 500,00 = 1.410,10, während der „07“-Satz 1.310,10 nennt. Regel 2 aus §1 der CFONB-Spezifikation formuliert diese Identität als DEFINITION eines konformen Auszugs; das ist also keine Heuristik: In der Datei fehlen 100,00 an Umsatz. | Gültig |
Fedwire-ISO-20022-Nachricht (USA) (6)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferEine Kundenüberweisung mit BAH-Header und hybriden Postanschriften — sie erfüllt bereits das ab 16. November 2026 geforderte Format. | Gültig | |
| Fedwire pacs.009 — conformant bank-to-bank transferEine Überweisung zwischen Finanzinstituten: der Interbanken-Teil, bei dem Zahler und Zahlungsempfänger Banken sind. | Gültig | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026Die Empfängeradresse besteht aus drei Freitextzeilen ohne Ort und Land. XSD-konform, aber regelwidrig: Ab dem 16. November 2026 entfällt bei Fedwire die vollständig unstrukturierte Adresse. | Ungültig | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overDas Gegenbeispiel: dieselbe unstrukturierte Adresse, aber Abwicklung am 30.06.2026. Sie ist zulässig, also gibt es nur eine Warnung. Auslöser ist das Abwicklungsdatum der Nachricht, nie das heutige Datum. | Gültig | |
| Fedwire pacs.008 — routing number that cannot existDie Routing-Nummer der Empfängerbank lautet 021000088 — eine Ziffer daneben. Sie scheitert an der ABA-3-7-1-Prüfziffer und kann daher nicht existieren. Das XSD sieht nur neun einwandfreie Ziffern. | Ungültig | |
| Fedwire — header announces a different message than it carriesDer BAH-Header nennt <MsgDefIdr>pacs.009.001.08</MsgDefIdr>, während das zugehörige Dokument ein pacs.008 ist. Beide Hälften sind schemakonform — nur ihr Abgleich deckt den Fehler auf. | Ungültig |
SWIFT-MT103-Überweisung (2)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| MT103 — cross-currency customer credit transferEin vollständiges MT103: alle fünf SWIFT-Blöcke, ein UETR, ein Auftraggeber in Option K, Agenten in Option A und ein IBAN-Begünstigter. Abwicklung in USD, Auftrag in EUR — Feld :36: (Wechselkurs) ist daher erforderlich und vorhanden. | Gültig | |
| MT103 — three defects a plain text viewer would missStrukturell ein einwandfrei lesbares MT103 — und gleich dreifach falsch: der UETR ist keine UUID v4, die Zahlung ist mehrwährungsfähig ohne Wechselkurs in :36:, und die IBAN des Begünstigten scheitert an der Mod-97-Prüfziffer. | Gültig |
CPA-005-/AFT-Zahlungsdatei (Kanada) (6)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Eine gewöhnliche kanadische Lohndatei: ein einziger „C“-Satz mit zwei Direkteinzahlungen (Transaktionstyp 200) in zwei seiner sechs Segmente. Der Z-Trailer weist 2 Gutschriften über 3.750,50 und keine Lastschriften aus und stimmt überein. Beachten Sie: Der Satzzähler zählt PHYSISCHE Sätze, der Trailer dagegen TRANSAKTIONEN — drei Sätze, zwei Transaktionen. | Gültig | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Eine „D“-Lastschrift über 899,00, gefolgt vom „J“-Satz, der sie zurückgibt. Die Rückgabe trägt den Grund 901 (unzureichende Deckung) im Feld TRANSAKTIONSTYP — dort, wo eine Zahlung ihren Typ trägt — während der ursprüngliche Typ 700 im Stored Transaction Type erhalten bleibt. Beide zählen als Lastschriften, daher die 2 Lastschriften über 1.798,00 im Trailer. | Gültig | |
| CPA-005 — the error correction folded into the debit totalAbsichtlich fehlerhaft — und zwar so, wie es echte Generatoren falsch machen: Die Datei storniert eine Gutschrift mit einem „E“-Satz, und der Trailer zählt diese Stornierung als Lastschrift. Das ist sie nicht. Standard 005 gibt den Korrekturen E und F ein EIGENES Summenpaar, getrennt von den Lastschrift- und Gutschriftpaaren — vermischt man sie, geht die Datei nicht mehr auf. Der häufigste Grund, warum ein selbst gebauter CPA-005-Generator abgelehnt wird. | Ungültig | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedEine 1464-Zeichen-AFT-Datei mit beiden Richtungen: ein „C“-Satz mit zwei Gehaltsgutschriften (3.750,50) und ein „D“-Satz mit zwei Lastschriften (1.349,25). C ist die GUTSCHRIFT und D die LASTSCHRIFT — mehrere veröffentlichte Zusammenfassungen drehen das um. Der Z-Trailer geht auf den vier Summenpaaren auf, die Standard 005 definiert (D+J, C+I, E für sich, F für sich) — hier mit E- und F-Zählern auf null. | Gültig | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Eine kanadische Notice of Change: Die empfangende Bank teilt dem Absender mit, dass ein Konto gewechselt hat. Es ist eine EIGENE DATEI — die Sätze sind 208 Zeichen lang, nicht 1464, und Standard 005 verbietet, ihre U- (Kopf), S- (Änderung) und V-Sätze (Trailer) mit AFT-Sätzen zu mischen. Jeder S-Satz führt die neue Routingnummer und das neue Konto neben den alten, und der V-Trailer nennt die Anzahl der S-Sätze. | Gültig | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaEine Kunde-an-Bank-Lohndatei, die ein US-geschulter Validator gleich zweimal zu Unrecht ablehnen würde. Ihre erste Gutschrift läuft über die Transitnummer 099999999, die keine arithmetische Prüfziffer trägt — die kanadische DPRN hat schlicht keine: Standard 005 prüft sie per Nachschlag im Financial Institutions File, Standard 006 definiert keine Prüfsumme. Wer hier die US-Regel 3-7-1 überträgt, weist einwandfreie Dateien zurück. Die Item Trace Numbers stehen zudem auf null, was bei einer vom Kunden eingereichten Datei normal ist (der Direct Clearer vergibt sie) — daher zwei Warnungen und null Fehler. | Gültig |
ACH-/NACHA-Datei (USA) (10)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Eine WEB-Lastschrift über 123,54 kommt zurück. Bei einer Rückgabe ändern sich genau drei Dinge: Der Transaktionscode wird 26 (der Rückgabecode einer Girokonto-Lastschrift — NICHT die ursprüngliche 27), die empfangende Bank wird zum ODFI des Originals, und eine neue Trace-Nummer wird vergeben. Der Betrag bleibt unverändert — ACH kennt keine Teilrückgabe. Das Addenda 99 trägt R01 und verweist auf die Trace-Nummer der Originalbuchung. Der Batch bleibt WEB und bleibt TRANSFER: Es gibt weder eine „RETURN“-Beschreibung noch einen SEC-Code „RET“, was das Web auch behaupten mag. | Gültig | |
| ACH — a notification of change (C01, corrected account number)Eine Notification of Change — und entscheidend ist: Sie ist KEINE Rückgabe. Die Zahlung ist durchgegangen. Die empfangende Bank bittet darum, die gespeicherten Daten vor der NÄCHSTEN Zahlung zu korrigieren: Diese hier erneut zu senden, würde den Empfänger doppelt bezahlen. Deshalb trägt die Buchung den Betrag NULL, und deshalb lautet der SEC-Code des Batches COR. Das Addenda 98 trägt C01 mit der korrigierten Kontonummer in den Positionen 36-52 des Satzes. | Gültig | |
| ACH — an international entry (IAT) with its seven mandatory addendaEine USD-zu-MXN-Zahlung nach Mexiko. Ein IAT-Satz ist nicht der inländische Satz mit anderen Beschriftungen: Die Kontonummer wandert auf die Positionen 40-74 (35 Zeichen, um ein ausländisches Konto aufzunehmen), die Positionen 13-16 geben an, wie viele Addenda folgen, und der Name des Empfängers steht überhaupt nicht in diesem Satz — er lebt im Addenda 10. Sieben Addenda (10 bis 16) sind bei jeder internationalen Buchung Pflicht, denn ein 94-Zeichen-Satz kann Name, Adresse und Bankidentifikation beider Parteien nicht fassen. Liest man diese Datei mit den inländischen Offsets, erhält man ein Bruchstück der Kontonummer, als wäre es ein Personenname. | Gültig | |
| ACH — PPD payroll credits, balanced with an offset debitDie Referenzdatei: So sieht eine korrekte NACHA-Datei aus. Vier PPD-Lohngutschriften (drei aufs Girokonto, Code 22, eine aufs Sparkonto, Code 32) und ein fünfter Satz — die Offset-Lastschrift, Code 27, auf das eigene Firmenkonto über die exakte Summe. Genau das macht die Datei „balanced“, und deshalb lautet der Service Class Code 200 (gemischt) statt 220. Entry Hash, Batch-Control-Summen, File-Control-Summen und Block Count gehen alle auf, und jede Routing Number erfüllt die ABA-3-7-1-Prüfziffer. | Gültig | |
| ACH — CCD corporate debits with an addenda 05 remittanceEin B2B-Einzug: zwei CCD-Lastschriften (Service Class 225, nur Lastschriften), jede mit einem Addenda 05, das die beglichene Rechnung trägt — RMR- und REF-Segmente, die ASC-X12-Remittance, mit der ein Firmenempfänger abstimmt. CCD erlaubt genau EIN Addenda pro Buchung: 80 Zeichen zahlungsbezogene Information, kein Zeichen mehr. Braucht der Zahler mehr Platz, wird der SEC-Code zu CTX. Beachten Sie den Addenda Record Indicator auf Position 79 der Buchung: Er steht auf 1, und es folgt tatsächlich ein Addenda. | Gültig | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Vier WEB-Lastschriften — der SEC-Code einer Zahlung, die ein Verbraucher online autorisiert hat. Drei gehen von Girokonten ab (Code 27), eine von einem Sparkonto (Code 37): Der Transaktionscode sagt, welches — und ihn als etwas anderes denn als Tabelle zu lesen, ist genau der Fehler, den Parser machen. Die Positionen 77-78 tragen den Payment Type Indicator, R für wiederkehrend und S für Einzelbuchung. WEB-Buchungen tragen keine Addenda, der Addenda Record Indicator bleibt also auf 0. | Gültig | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Eine CTX-Lastschrift über 28.750,00, die drei Rechnungen auf einmal begleicht, mit dem ASC-X12-820-Remittance-Advice verteilt auf sieben Addenda-05-Sätze. CTX ist der SEC-Code, den Parser am häufigsten falsch lesen, denn der Entry-Satz bedeutet hier nicht, was er sonst überall bedeutet: Die Positionen 55-58 sind NICHT der Anfang eines Namens, sondern die ANZAHL der folgenden Addenda (hier 0007), und der Name des empfangenden Unternehmens beginnt erst bei 59. Mit den PPD-Offsets gelesen, kommt der Name als „0007GLOBEX CORP“ zurück — genau das zeigt auch unser eigener Validator, der das inländische Layout anwendet. | Gültig | |
| ACH — entry hash mismatch (truncated or tampered file)Eine PPD-Gutschriftdatei mit falschem Entry Hash. Der Entry Hash ist die Summe der 8-stelligen Routing Numbers aller Buchungen, auf die letzten zehn Stellen gekürzt — eine Prüfsumme, deren einzige Aufgabe es ist, eine Datei zu erwischen, die unterwegs eine Buchung verloren, dazubekommen oder verändert hat. Hier deklarieren Batch Control und File Control beide 28905251, während die vier Buchungen 27905251 ergeben. Die Beträge gehen weiterhin auf — und genau darin liegt der Sinn: Der Hash ist die Kontrolle, die anschlägt, wenn keine andere es tut. | Ungültig | |
| ACH — batch control debit total ≠ the sum of its entriesEin CCD-Lastschriftbatch, dessen Batch Control 18.450,00 deklariert, während seine beiden Buchungen 28.075,00 ergeben — der klassische Fehler eines Generators, der seinen Trailer schreibt, bevor er die letzte Buchung addiert hat. Alles andere in der Datei stimmt, auch die File-Control-Summen: Der Validator meldet daher genau einen Fehler und nennt beide Zahlen. Das ist der häufigste Grund, warum eine Bank eine handgebaute ACH-Datei zurückweist. | Ungültig | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberEine WEB-Lastschriftdatei, in der eine empfangende Bank 026009594 trägt — eine Routing Number, die an der ABA-3-7-1-Prüfziffer scheitert (richtig wäre 026009593). Falsch ist nur Position 12 der Buchung, daher gehen der Entry Hash und sämtliche Kontrollsummen weiterhin auf: Die Prüfziffer ist die einzige Kontrolle, die eine einzelne vertippte Ziffer erwischt, und diese Datei beweist, dass die Summen allein es nicht tun. Die beiden anderen Buchungen und alle Trailer sind korrekt — der Validator meldet genau einen Fehler. | Ungültig |
Zahlungs-QR-Code (EPC / Schweizer QR-Rechnung) (6)
| Beispieldateien | Erwartetes Ergebnis | Datei herunterladen |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Ein konformer EPC-QR-Code (SCT QR), Version 002 — jene, in der die BIC optional ist und hier fehlt. Der Verwendungszweck ist eine strukturierte ISO-11649-Kreditorenreferenz, RF6518539007547034, deren Mod-97-Prüfziffern stimmen: 94 von 331 erlaubten Bytes. | Gültig | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageDie andere Hälfte von EPC069-12: Version 001, in der die BIC des Begünstigten Pflicht ist (der einzige Unterschied zwischen 001 und 002), mit einem freien Verwendungszweck statt einer Referenz. Strukturierte Referenz und Freitext schließen einander aus — ein QR-Code trägt das eine oder das andere, nie beides. | Gültig | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capDie Falle, die die Spezifikation ausdrücklich benennt und in die Implementierungen trotzdem tappen: EPC069-12 begrenzt die Nutzlast auf 331 BYTES, nicht Zeichen. Dieses polnische Payload hat 312 Zeichen — mühelos unter jeder Zeichengrenze —, doch jeder Akzentbuchstabe kostet in UTF-8 zwei Bytes: 338 Bytes, also zurückgewiesen. | Ungültig | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)Die kanonische Schweizer QR-Rechnung: eine QR-IBAN (Institut-ID 31999, im Bereich 30000-31999), gepaart mit der QR-Referenz, die sie verlangt — 26 Ziffern plus eine Prüfziffer im rekursiven Modulo 10, nicht das Mod-97 der IBAN-Welt. Man beachte den Block „ultimate creditor“: sieben Zeilen, vorhanden und völlig leer, genau wie die Guidelines es fordern. | Gültig | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceDie andere Hälfte der Zuordnungsregel: Eine normale IBAN (Institut-ID 00791, außerhalb des QR-IID-Bereichs) VERBIETET eine QR-Referenz und nimmt eine ISO-11649-Kreditorenreferenz (SCOR) — RF6518539007547034 — oder gar keine. Dieselbe Rechnung, anderer Kontotyp, andere Referenz: Von dieser Unterscheidung hängt ab, ob eine Schweizer Zahlung verbucht werden kann. | Gültig | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)Der folgenschwerste Fehler des Schweizer Formats: eine QR-IBAN mit einer ISO-11649-Referenz (SCOR). Die Referenz selbst ist einwandfrei — das ist die Falle —, doch eine QR-IBAN verlangt eine QRR-Referenz und nichts anderes. Die Bank kann die Zahlung nicht verbuchen; das Urteil gilt unter Implementation Guidelines 2.3 wie 2.4. | Ungültig |
Woher wir wissen, dass diese Ergebnisse stimmen
Jede Datei dieser Bibliothek läuft bei jedem Build durch den eigenen Validator der Website. Das oben genannte erwartete Ergebnis wird von einem automatisierten Test geprüft: Passt eine Datei nicht mehr zu dem, was diese Seite behauptet, schlägt der Build fehl. Zwei geerbte Fixtures wurden so vor der Veröffentlichung repariert — drei IBANs scheiterten an der Mod-97-Prüfung, und mehrere Namen nutzten Zeichen außerhalb des SEPA-Basiszeichensatzes.