Sample file library
Ready-made SEPA, camt.053, UBL, MT940 and Factur-X files — valid ones to start from, deliberately broken ones to test against. Every file is checked by the validator it belongs to.
SEPA and e-invoicing sample files
Ready-made SEPA, camt.053, UBL, MT940 and Factur-X files — valid ones to start from, deliberately broken ones to test against. Every file is checked by the validator it belongs to.
129
Sample files
92
Valid
37
Invalid
SEPA Credit Transfer (pain.001) (12)
| Sample files | Expected result | Download the file |
|---|---|---|
| pain.001.001.03 — valid credit transferA valid SEPA credit transfer in pain.001.001.03: three transfers totalling 1 580.00 EUR, matching control totals, IBANs that pass the mod-97 check and names inside the basic SEPA character set. | Valid | |
| pain.001.001.09 — valid, hybrid addressA valid pain.001.001.09 credit transfer using BICFI and the hybrid postal address allowed by EPC153-22 v2.1: TwnNm plus Ctry, plus at most two AdrLine of 70 characters or less. | Valid | |
| pain.001.001.03 — CtrlSum mismatchA pain.001 whose control sum lies: CtrlSum declares 1 000.00 EUR while the transactions add up to 1 500.00 EUR. The mismatch is reported twice, once for the payment batch and once for the file header. | Invalid | |
| pain.001.001.03 — invalid IBANA pain.001 carrying a creditor IBAN whose two check digits fail the ISO 7064 mod-97 test. Everything else in the file is correct, so the validator reports exactly one error. | Invalid | |
| pain.001.001.03 — NbOfTxs mismatchA pain.001 that miscounts itself: NbOfTxs declares one transaction while the file actually carries two. Like CtrlSum, the count is checked both on the payment batch and on the file header. | Invalid | |
| pain.001.001.03 — unstructured address after 2026-11-15The reference case for the EPC structured-address rule: addresses carry AdrLine only, with no TwnNm. What makes it a blocking error is the execution date inside the file (ReqdExctnDt = 2026-11-20, after the 2026-11-15 cut-off) — move that date earlier and the very same file downgrades to a warning. | Invalid | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15The reference "ready for 2026" file: a pain.001.001.11 credit transfer whose execution date (ReqdExctnDt = 2026-11-20) falls after the EPC structured-address cut-off of 2026-11-15. Every payer and payee address is fully structured — StrtNm, BldgNb, PstCd, TwnNm, Ctry and not a single AdrLine. Three transfers, 4 320.00 EUR, zero errors and zero warnings. | Valid | |
| pain.001.001.09 — valid, two payment batches with different execution datesOne pain.001 file, two PmtInf blocks: batch A is executed on 2026-03-10 with hybrid addresses (TwnNm + Ctry + one AdrLine), batch B on 2026-11-20 with fully structured ones. It shows the two things a multi-batch file teaches: the EPC address rule is evaluated per batch against the date that batch carries, and each PmtInf has its own NbOfTxs / CtrlSum on top of the GrpHdr totals (4 transfers, 3 350.00 EUR). | Valid | |
| pain.001.001.03 — nine-character BICA pain.001 whose creditor agent BIC is nine characters long. ISO 9362 allows 8 (institution + country + location) or 11 (plus a 3-character branch code) — never 9 or 10. "BNPAFRPPX" is what a truncated or hand-padded branch code looks like, and it is the one defect in this file that both layers catch: the official XSD rejects it on its BIC pattern, and the rulebook layer rejects it on its length. | Invalid | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setA pain.001 whose creditor is named "Café Renard & Fils SARL" — an accented letter and an ampersand, both outside the EPC-approved basic Latin character set (a-z A-Z 0-9 and / - ? : ( ) . , ' + space). The XML is well-formed and the official XSD accepts it happily: Max70Text takes any string. This defect lives purely in the rulebook layer, which is precisely why files like it reach the bank and are rejected or silently transliterated there. | Invalid | |
| pain.001.001.03 — 250 transfers, high-volume payroll runA realistic payroll run: 250 SEPA credit transfers in a single PmtInf, spread over five countries (DE, NL, BE, ES, FR), totalling 442 028.75 EUR. Every IBAN carries correct ISO 7064 mod-97 check digits and both control totals match the exact sum to the cent. Use it to see how your parser, your bank portal or your own tooling behaves on a file that is neither a toy nor pathological — and to check that a single wrong cent in a batch this size is still caught by CtrlSum alone. | Valid | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)The twin of the blocking unstructured-address sample, with one thing changed: the execution date. Same AdrLine-only addresses, but ReqdExctnDt is 2026-09-30, before the EPC153-22 v2.1 cut-off, so the very same defect comes back as two warnings instead of two errors — the payment still goes through today. It also shows what "structured" really means: the debtor address has neither TwnNm nor Ctry, the creditor address has a Ctry and still no TwnNm. Ctry alone is not enough; TwnNm is the discriminator. | Valid |
SEPA Direct Debit (pain.008) (8)
| Sample files | Expected result | Download the file |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitA valid SEPA Direct Debit under the CORE scheme: two recurrent collections totalling 175.00 EUR, a Creditor Scheme Identifier (ICS) that passes the ISO 7064 MOD 97-10 check, and a signed mandate behind each debtor. | Valid | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15What a compliant SEPA Direct Debit looks like after the 2026-11-15 cut-off: the collection date is 2026-11-20, so every creditor and debtor address is structured (TwnNm + Ctry). CORE scheme, three collections totalling 228.80 EUR, zero warnings. | Valid | |
| pain.008.001.02 — mandate signed after the collectionA direct debit collected under a mandate the debtor had not yet signed: DtOfSgntr is 2026-04-10 but the collection date is 2026-03-05. A common, quietly fatal defect — the ICS, the IBANs and the totals are all correct. | Invalid | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceA valid SEPA B2B direct debit in pain.008.001.08: LclInstrm/Cd = B2B, sequence type RCUR, two recurring collections totalling 4 650.00 EUR. The B2B scheme is the business-to-business variant — the debtor must be a non-consumer and has NO right to a refund after settlement, which is why the debtor bank checks the mandate before debiting and why B2B collections are presented earlier than CORE ones. | Valid | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceA valid SEPA CORE direct debit with sequence type FRST: the first collection presented under a brand-new mandate (DtOfSgntr is days old). Everything that follows on the same mandate must go out as RCUR — leaving a batch on FRST for ever is one of the most common SDD mistakes, and the reason banks return collections with an incorrect-sequence reason code. | Valid | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceA valid one-off SEPA direct debit: sequence type OOFF, a single collection of 349.00 EUR. The mandate authorises exactly one debit and is spent the moment it is used — it can never be presented again, not even as RCUR. This is the sequence for a single purchase, a deposit or a one-time fee; using FRST instead quietly leaves an open mandate the debtor never agreed to. | Valid | |
| pain.008.001.02 — mandate identifier (MndtId) missingA direct debit with no mandate identifier: MndtRltdInf is there and carries a signature date, but the MndtId element (rulebook AT-01) is absent. The official ISO 20022 XSD accepts the file — MndtId is optional in the schema — so a purely structural check passes it and the bank rejects it: without a mandate reference the debtor's bank has nothing to match the collection against, and the debtor has nothing to dispute. | Invalid | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsA SEPA direct debit that miscounts and mis-sums itself, at both levels at once: the batch really holds 2 collections worth 300.00 EUR, but NbOfTxs says 3 and CtrlSum says 250.00 — in the PmtInf and again in the GrpHdr. That is four errors, not two: control totals are checked on the payment batch and on the file header, because a multi-batch file can carry a correct header total sitting on top of two wrong batch totals. The XML is well-formed and the official XSD accepts it: NbOfTxs and CtrlSum are just numbers to a schema. | Invalid |
Bank statement (camt.052 / 053 / 054) (12)
| Sample files | Expected result | Download the file |
|---|---|---|
| camt.053.001.02 — valid statementA valid camt.053.001.02 bank statement: four entries, opening and closing balances that reconcile (OPBD ± movements = CLBD), and plain Dt dates. | Valid | |
| camt.053.001.08 — valid statementA valid camt.053.001.08 bank statement: three entries, DtTm timestamps and BICFI instead of BIC — the differences that trip people up when they move from version 02 to version 08. | Valid | |
| camt.053 — unsupported namespaceA statement declaring camt.053.001.99, a version that does not exist in the ISO 20022 catalogue. Useful for checking that your own parser rejects unknown namespaces instead of guessing. | Invalid | |
| camt.053.001.06 — missing Stmt elementA statement with a correct camt.053.001.06 namespace but no <Stmt> element at all: the envelope is right, the content is missing. This is what a truncated bank export looks like. | Invalid | |
| camt.053.001.11 — valid statementA valid camt.053.001.11 bank statement — the current version of the ISO 20022 statement message. Four entries, OPBD 25 000.00 ± movements = CLBD 34 659.05. Note what version 11 makes mandatory on every entry: Sts and BkTxCd, which earlier versions let you leave out. | Valid | |
| camt.053.001.08 — three accounts in one fileOne camt.053 message, three <Stmt> blocks: a current account, a savings account and a USD account. The file is schema-valid; the validator explicitly says it analyses only the first statement. That is the point — a reader that takes Stmt[0] and stops silently loses two accounts, and this is how a multi-account camt.053 file catches it out. | Valid | |
| camt.053.001.10 — fully detailed entriesEverything a bank can hang under a camt.053 entry, in one valid file: NtryDtls/TxDtls with EndToEndId, InstrId, TxId and MndtId; RltdPties and RltdAgts; an ISO 11649 structured creditor reference (RF) and a referred invoice (CINV); a batched entry whose two TxDtls add up to the entry amount; and both an ISO BkTxCd (PMNT/RCDT/ESCT) and a proprietary German GVC. Use it to test how much of an entry your reconciliation actually reads. | Valid | |
| camt.053.001.08 — closing balance does not reconcileThe most common defect in production camt.053 files: opening 4 200.00 plus the booked entries gives 5 194.70, while the declared CLBD says 5 194.07 — two digits transposed. The file satisfies the official ISO 20022 XSD perfectly, because a schema has nothing to say about arithmetic. Only a balance reconciliation catches a closing balance mismatch. | Valid | |
| camt.052.001.08 — valid intraday reportA valid camt.052 intraday account report — and it is not a small camt.053: the root is BkToCstmrAcctRpt, the container is <Rpt>, and the balances are INTERIM (ITBD booked, ITAV available) rather than the OPBD/CLBD pair of an end-of-day statement. It also carries a pending entry (Sts=PDNG) that is deliberately excluded from the interim balance — pending money is not booked money. | Valid | |
| camt.054.001.08 — valid debit/credit notificationA valid camt.054 debit/credit notification: one incoming SEPA credit and one outgoing direct debit, each with full TxDtls and end-to-end references. The structural surprise is what is NOT there: a camt.054 has no <Bal> element at all — the ISO 20022 schema does not define one. A notification announces movements, it never states a balance, so there is nothing to reconcile against. | Valid | |
| camt.053.001.08 — entry with no CdtDbtIndThe second entry carries an amount of 1 200.00 and no <CdtDbtInd>. Amounts in camt.053 are always unsigned: without the direction indicator the amount means nothing. Two things break at once — the official XSD rejects the file (CdtDbtInd is mandatory 1..1 on an entry), and a parser that quietly defaults to CRDT books +1 200.00 instead of −1 200.00 and lands 2 400.00 away from the truth, which the balance check then exposes. | Invalid | |
| camt.053.001.08 — 220 entries, validA month-end corporate statement with 220 booked entries, all reconciling: OPBD 125 000.00 ± movements = CLBD 209 081.69. Every entry carries NtryDtls/TxDtls, an EndToEndId and a counterparty, so it exercises a camt.053 reader at realistic volume rather than on a three-line toy file — parsing throughput, table rendering, and a reconciliation over hundreds of lines. | Valid |
UBL invoice (Peppol BIS 3.0) (12)
| Sample files | Expected result | Download the file |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0A valid Peppol BIS Billing 3.0 invoice: three lines, 2 596.00 EUR including VAT, coherent totals, a French VAT identifier and an IBAN for payment. | Valid | |
| UBL Credit Note — valid Peppol BIS 3.0A valid Peppol BIS Billing 3.0 credit note: one line, 1 770.00 EUR including VAT, referencing the original invoice it cancels. The credit note is a distinct UBL document type, not an invoice with negative amounts. | Valid | |
| UBL Invoice — BR-CO-10 violationAn invoice that breaks EN 16931 rule BR-CO-10: the sum of the line net amounts (1 000.00) does not equal the document total BT-106 (2 000.00). One of the most frequent rejections on the Peppol network. | Invalid | |
| UBL Invoice — malformed seller VAT identifierAn invoice whose seller VAT identifier, "FR1234", is too short: a French VAT number is FR followed by a two-character key and nine digits. Format errors on BT-31 are caught before the invoice ever reaches the tax authority. | Invalid | |
| UBL Invoice — allowances and charges, line and document levelA valid Peppol BIS 3.0 UBL invoice carrying discounts and charges at BOTH levels: a line allowance (BG-27), a line charge (BG-28), a document-level discount (BG-20) and a freight charge (BG-21). The chain the totals must satisfy is the whole point — BT-106 = 1 520.00 is the sum of the NET line amounts, and BT-109 = 1 530.00 = BT-106 - BT-107 + BT-108 (BR-CO-13), so 19 % VAT is charged on 1 530.00, not on 1 520.00. | Valid | |
| UBL Invoice — reverse charge (VAT category AE)A valid reverse charge invoice in UBL: a French supplier bills services to a German business, VAT is accounted for by the customer, so the rate is 0 % and no VAT is charged. Category AE brings four rules with it — both VAT identifiers (BR-AE-02, BR-AE-03), a 0 % rate (BR-AE-05), a VAT category tax amount of 0.00 (BR-AE-09) and an exemption reason (BR-AE-10), here VATEX-EU-AE plus the text "Reverse charge". | Valid | |
| UBL Invoice — VAT exempt (category E) with exemption reasonA valid VAT-exempt invoice (category E): vocational training exempted under Article 132(1)(i) of Council Directive 2006/112/EC. An exempt invoice must say WHY it is exempt — BR-E-10 demands a VAT exemption reason code (BT-121) or text (BT-120), and this file carries both: VATEX-EU-132 and the wording from the official code list. | Valid | |
| UBL Invoice — intra-Community supply (VAT category K)A valid intra-Community supply (VAT category K): goods dispatched from Germany to a VAT-registered buyer in France, zero-rated under Article 138 of Council Directive 2006/112/EC. Category K asks for two things people forget — BR-IC-11: an actual delivery date (BT-72) or an invoicing period, and BR-IC-12: the deliver-to country (BT-80). Without them, the invoice cannot prove the goods left the country. | Valid | |
| UBL Invoice — two VAT rates, one breakdown per rateA valid invoice mixing the French standard rate (20 %) and reduced rate (5.5 %). The rule this file exists for is BR-S-08: the VAT breakdown (BG-23) carries ONE TaxSubtotal per (category, rate) pair, and each taxable amount equals the sum of the lines carrying that pair — 1 500.00 at 20 % (VAT 300.00) and 400.00 at 5.5 % (VAT 22.00). Merging two rates into one subtotal passes every BR-CO total check and is still wrong. | Valid | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106The most common rejection in production, isolated: the two lines add up to 1 500.00 but BT-106 (LineExtensionAmount) declares 1 400.00 — BR-CO-10. Everything else is internally consistent with the WRONG figure, so BR-CO-13, BR-CO-14, BR-CO-15 and BR-CO-16 all pass and exactly one error comes back. That is what a line dropped after the totals were computed looks like. | Invalid | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)An exempt invoice done wrong, twice over. BR-E-10: the VAT breakdown for category E carries neither an exemption reason text (BT-120) nor a reason code (BT-121) — an exempt invoice must say WHY. BR-E-08: the exempt taxable amount declares 1 200.00 while the exempt lines add up to 1 500.00, because the second line never made it into the breakdown. The quoted error is the one the business-rule layer reports; the official EN 16931 Schematron adds BR-E-10 on top. | Invalid | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateA VAT breakdown that does not add up: a base of 2 000.00 at 19 % is 380.00 of VAT, but the invoice declares 395.00. BR-CO-17 checks VAT category tax amount = taxable amount x rate / 100 with the official margin of 1.00 currency unit — so a genuine cent of rounding is tolerated and this 15.00 gap is not. Every other total agrees with the wrong figure, which is exactly how a rounding bug survives to production. | Invalid |
CII invoice (XRechnung / Factur-X syntax) (4)
| Sample files | Expected result | Download the file |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validA valid XRechnung 3.0 invoice in the CII (UN/CEFACT CrossIndustryInvoice) syntax — the German public-sector e-invoice. It carries what the KoSIT BR-DE rules add on top of EN 16931: the Leitweg-ID as buyer reference (BR-DE-15), a complete seller contact point — name, telephone and e-mail (BR-DE-2 to BR-DE-6), the seller electronic address, structured payment terms and a SEPA credit transfer (payment means 58). | Valid | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)The Factur-X / ZUGFeRD payload on its own: the CII XML that normally travels embedded in a PDF/A-3, here as a standalone file you can validate directly. Profile BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) is an EN 16931-compliant CIUS — full invoice lines, a complete VAT breakdown and the six document totals. Useful for testing an extractor against the XML alone, without a PDF in the way. | Valid | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 in the CII syntax: the two lines add up to 2 000.00 but LineTotalAmount (BT-106, inside SpecifiedTradeSettlementHeaderMonetarySummation) declares 1 900.00. The same defect as the UBL sample, in the syntax where it is harder to spot — the document totals live in a different branch of the tree from the lines they are supposed to summarise. | Invalid | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisA document-level discount that only half exists: the invoice grants 200.00 (BT-107), computes VAT on the discounted base (1 800.00 x 19 % = 342.00 — correct), but BT-109 (TaxBasisTotalAmount) still declares the undiscounted 2 000.00. BR-CO-13 says BT-109 = BT-106 - BT-107 + BT-108, so the buyer is billed for 200.00 the seller believed they had given away. | Invalid |
SWIFT MT940 statement (10)
| Sample files | Expected result | Download the file |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectThe nominal MT940 case: one statement, one credit and one debit, with the customer/bank reference pair in the :61: line. Start here to see the tag structure before the dialects. | Valid | |
| MT940 — ING Belgium, structured :86:The ING Belgium dialect: the :86: information line is structured into ?00 ?20 ?30 subfields rather than free text. This is the single biggest source of MT940 parsing bugs. | Valid | |
| MT940 — Commerzbank, one-decimal amountThe Commerzbank dialect: an amount written with a single decimal (1234,5 meaning 1 234.50), an NMSC transaction type and a German account given as BLZ + account number rather than an IBAN. | Valid | |
| MT940 — two statements in one fileTwo statements inside a single MT940 file, plus the available-balance tag :64:. A file is not one statement, and a parser that assumes it is will silently drop the second. | Valid | |
| MT940 — reversal (RC) and intermediate balancesThe ABN AMRO case: an RC reversal (a credit turned back into a debit), intermediate balances 60M/62M rather than F, and an :86: spread over two lines. Reversals invert the sign — get this wrong and the balance never reconciles. | Valid | |
| MT940 — overdrawn account (debit balances)An overdrawn account: both the opening and the closing balance carry the D (debit) marker. A negative balance is not a negative number in MT940 — it is a sign flag, and code that ignores it reports the overdraft as a credit. | Valid | |
| MT940 — closing balance does not reconcileA statement whose closing balance does not follow from opening ± movements. This is deliberately a warning, not a blocking error: the file is still readable and a human must decide whether the bank or the export is at fault. | Valid | |
| MT940 — 500 transactions (load test)Five hundred transactions in one statement, balancing to the cent. Use it to check that your parser stays exact — and fast — at production volume rather than on a three-line toy file. | Valid | |
| MT940 — statement split over two pages (62M / 60M)One statement, one day, two pages: sequence 00147/00001 closes on an INTERMEDIATE balance :62M: and sequence 00147/00002 reopens on :60M: with exactly that figure before closing on the final :62F:. M is not F — treat the intermediate closing balance as the day’s final one and you report the account as 37,500.00 when it actually ended at 44,249.25. | Valid | |
| MT940 — USD account with an RD reversalA US dollar statement — MT940 is not a euro format — in which an outgoing wire of 35,000.00 is returned the next day by an RD reversal: a REVERSED DEBIT is money coming back IN. The RC/RD marks flip the economic direction of the :61: line, and a parser that reads only the D of "RD" books the refund twice as a payment and never reconciles. | Valid |
BAI2 statement (US / Canada) (6)
| Sample files | Expected result | Download the file |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)The nominal BAI2 file example: one account, an 010 opening and 015 closing ledger balance, and ten transactions whose direction comes solely from the type code — 115 lockbox deposit, 165 ACH credit, 195 incoming wire, 475 check paid, 451 ACH debit, 495 outgoing wire, 698 fees. BAI2 has no debit/credit flag: 100–399 is money in, 400–699 is money out. | Valid | |
| BAI2 — several accounts in one groupTwo 03 account records inside a single 02 group — an operating account and a payroll account, each closed by its own 49 trailer. BAI2 is hierarchical (01 file / 02 group / 03 account / 16 transaction / 49-98-99 trailers), and a reader that assumes one account per file silently drops the second. | Valid | |
| BAI2 — 88 continuation recordsThe 88 continuation record, in its two very different roles: it carries extra summary tuples for an 03 account record (here the 015 closing and 045 available balances) and wrapped free text for a 16 transaction (three physical lines, one remittance string). Merge them the same way and the balances get read as text — or the text as balances. | Valid | |
| BAI2 — CAD and JPY: minor units scale with the currencyBAI2 amounts carry no decimal point: they are minor units, and how many decimals they imply depends on the currency. In this file "2500000" is CAD 25,000.00 on the CAD account (2 decimals) and ¥2,500,000 on the JPY account (0 decimals). The CAD account also leaves its currency field empty and inherits it from the 02 group header. A hardcoded division by 100 corrupts the yen account by two orders of magnitude — and the balance still reconciles, because all three figures are wrong by the same factor. | Valid | |
| BAI2 — closing balance does not reconcileThe 015 closing ledger balance does not follow from the 010 opening balance plus the 16 movements — 50,000.00 + 10,000.00 − 2,500.00 is 57,500.00, but the file claims 59,000.00. The trailers still add up, so only the arithmetic betrays it. Deliberately a warning, not a blocking error: the file is readable and a human must decide whether the bank or the export is at fault. | Valid | |
| BAI2 — bad trailer totals and an out-of-range type codeThree defects at once. The 49 account trailer declares a control total and a record count neither of which matches the records above it — the trailers are the file’s own integrity check, so a reader that skips them cannot see truncation. And a 16 transaction carries type code 720, which sits in the 700–799 loan range: it is neither a credit (100–399) nor a debit (400–699), so its direction cannot be inferred and it is dropped rather than guessed at — which is why the balance no longer reconciles either. | Valid |
Factur-X / ZUGFeRD (PDF) (2)
| Sample files | Expected result | Download the file |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceA valid Factur-X invoice at the EN 16931 profile: a PDF/A-3 with the CII XML embedded inside it. One document that a human reads and a machine parses — that is the whole point of the hybrid format. | Valid | |
| Factur-X EN 16931 — BR-CO-15 violationA Factur-X invoice that breaks EN 16931 rule BR-CO-15: the total including VAT is 130.00 while the total excluding VAT plus the VAT amount is 120.00. The PDF still opens and looks perfectly normal — only the embedded XML gives it away. | Invalid |
KSeF invoice (Poland, FA(3)) (7)
| Sample files | Expected result | Download the file |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)A conformant FA(3) structured invoice — the Polish Ministry of Finance’s own example no. 4, reproduced unchanged. Three lines, PLN 64,279.92 including VAT at 23%. Use it as the reference of what KSeF accepts. | Valid | |
| KSeF — invoice still using the retired FA(2) schemaThe most common KSeF migration failure: a perfectly well-formed invoice that still declares the FA(2) namespace, retired on 1 February 2026. Nothing looks wrong until KSeF rejects it. Note what FA(3) added and this file lacks: Podmiot2 now requires JST and GV. | Invalid | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Structurally perfect against the official schema, yet the seller’s NIP fails its mod-11 check digit and P_15 does not match the sum of the VAT breakdown. ValidateFin reports both as warnings, not errors — neither is a normative KSeF rule, and the Ministry’s own example 1 is itself one grosz off. | Valid | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)A correcting invoice (RodzajFaktury = KOR), the FA(3) case people look for most and get wrong most. Its totals carry the DELTA, not the restated invoice — P_13_1, P_14_1 and P_15 are all negative — and PrzyczynaKorekty, TypKorekty and DaneFaKorygowanej appear, pointing back at the invoice being corrected. The lines come in pairs: the one with StanPrzed is the state before. | Valid | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)A prepayment invoice (RodzajFaktury = ZAL): it bills a deposit against an order that has not been delivered yet. It therefore carries NO FaWiersz lines at all — the goods live in the Zamowienie (order) block, with their own P_7Z / P_11NettoZ / P_11VatZ tags — while P_15 shows only the PLN 12,300.00 deposit against an order worth PLN 61,500.00. | Valid | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)A FA(3) invoice missing one mandatory element: P_2, the invoice number. Nothing about the XML looks wrong — it is well-formed, in the right namespace, with a plausible VAT breakdown — and only the Ministry of Finance’s own XSD catches it: “Element P_6: this element is not expected. Expected is P_2.” KSeF rejects such a file outright. | Invalid | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)The buyer’s NIP is 1111111112 — ten digits, so the official schema, which constrains the NIP by a pattern only, accepts it without a word. Its mod-11 check digit does not hold: no such Polish tax number can exist, and the invoice is addressed to nobody. ValidateFin reports a warning, never an error — the Ministry publishes no such validation rule. | Valid |
FatturaPA invoice (Italy, SdI) (4)
| Sample files | Expected result | Download the file |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyA FatturaPA that the SdI would accept: correct VAT arithmetic (two lines at 22 % summing to 1,100 €, 242 € of tax, 1,342 € total), fiscal identifiers that pass their check digit, and a 7-character CodiceDestinatario as a private recipient requires. Use it as the reference point — every other sample here is this file, broken in one specific way. | Valid | |
| FatturaPA — signed CAdES (.p7m) envelopeThe same conformant invoice, wrapped in a CAdES (.p7m) signature envelope — which is how most real Italian invoices travel, and how EVERY invoice to a public administration must. Open it in a text editor and you see binary noise. The validator unwraps it and checks the XML inside; it does not verify the signature itself, and says so. | Valid | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)This invoice is VALID against the official XSD and the SdI would still reject it — which is exactly why a schema-only check is not enough. Three defects: the taxable base declares 1,150 € against lines summing to 1,100 € (control 00422, whose tolerance is one EURO, not one cent); the tax declares 250 € where 22 % of 1,150 € is 253 € (00421); and the Natura code is the bare N3, withdrawn on 1 January 2021 in favour of its sub-codes (00445) — yet still listed in the schema enumeration. | Invalid | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)The commonest way an invoice to an Italian public administration gets bounced: the CodiceDestinatario. For a PA (FormatoTrasmissione = FPA12) it must be the SIX-character IPA office code — the seven-character form belongs to private recipients. The XSD permits 6 OR 7 for both, so the schema cannot see it; only SdI control 00427 does. The invoice number, "FATTURA", also contains no digit at all (00425). | Invalid |
RO e-Factura invoice (Romania, ANAF) (6)
| Sample files | Expected result | Download the file |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)An invoice ANAF accepts — its own offline validator says « este valid ». It is the Ministry’s published example, repaired on the two points that make the published version fail: BT-24 raised to CIUS-RO:1.0.1, and two CUI whose check digits are actually correct. Use it as the reference point — every broken sample here is this file, damaged in one precise way. | Valid | |
| RO e-Factura — credit note in a foreign currency (FCN)A credit note (FCN) billed in SEK — and ANAF accepts it. It shows what BR-RO-030 actually demands: RON has to appear as the invoice currency (BT-5) OR as the VAT accounting currency (BT-6), not necessarily both. Here BT-5 is SEK and BT-6 is RON, which satisfies the rule. It also carries type code 381, which is legal on a credit note and illegal on an invoice. | Valid | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)The single most common Romanian rejection, and the only thing wrong with this file: BT-24 still says CIUS-RO:1.0.0, a value retired on 29 December 2022 (order OMF 4092/2022). The invoice is impeccable in every other respect and passes the XSD. Both example invoices the Ministry itself still publishes carry this defect — and the Ministry’s own validator rejects them. | Invalid | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)A seller in Bucharest whose city (BT-37) reads “Sector 1” — the exact spelling the ministerial order itself uses. The Schematron ANAF actually runs demands SECTOR1: uppercase, no space. When the text of the law and the implementation disagree, it is the implementation that rejects your invoice. | Invalid | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)The sample that exposes the blind spot of every Schematron-only validator. The buyer’s CUI (RO987456123) has a wrong check digit — and NO Schematron rule looks at it. This file passes the XSD, passes the whole CIUS-RO rulebook, and ANAF still rejects it, under a code of its own: ERRIdentif, « CUI cumparator incorect ». | Invalid | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)A B2C invoice whose buyer is a private individual, identified by the anonymous CNP of thirteen zeros — in production since 16 December 2024. It is valid, and a validator that treated it as a malformed personal number would break every consumer invoice in Romania: it survives none of the CNP’s own structural rules (its leading digit, 0, is refused everywhere else), because it is a reserved value, not a CNP. | Valid |
Verifactu billing record (Spain, AEAT) (3)
| Sample files | Expected result | Download the file |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosA submission the AEAT would accept: two invoice records, correctly chained. The first declares PrimerRegistro=S and hashes an empty previous-fingerprint field; the second chains the first record’s huella. Both fingerprints are real SHA-256 values over the exact string the AEAT specifies — not invented. Use it as the reference point: every other sample here is this file, broken in one specific way. | Valid | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)The second record declares a fingerprint that does NOT match its content: the chain is broken. The file is VALID against the official AEAT XSD — a schema-only validator passes it. Only recomputing the chained SHA-256 catches it. And note: the AEAT does NOT reject it — it marks it “Aceptado con errores” (code 2000) and records it anyway, to be corrected. | Valid | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)A simplified invoice (F2) that carries a Destinatarios block — forbidden, code 1190 — and whose CuotaRepercutida (€100) does not match base × rate (€1,000 × 21 % = €210), far beyond control 1142’s ±€10 tolerance. The file PASSES the official XSD without a single complaint: the schema cannot see this; the AEAT rejects it. | Invalid |
Facturae invoice (Spain, FACe) (2)
| Sample files | Expected result | Download the file |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaA Facturae 3.2.2 invoice addressed to a public administration (with its DIR3 administrative centres — fiscal office, managing body, processing unit — as FACe requires) that passes the official facturae.gob.es XSD without a single complaint, with every total reconciling under the schema’s own formulas and a XAdES signature present. Use it as the reference point: the other sample is this same file, broken in one specific way. The signature is a sample — its cryptographic validity is not checked offline. | Valid | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)The same file, with one change: InvoiceTotal declares €1,200.00 where the schema’s own formula gives €1,210.00 (base 1,000 + VAT 210). The file is VALID against the official facturae.gob.es XSD — a schema-only validator passes it. Only the coherence layer catches it, and it also flags that the batch total no longer reconciles. This is not an “official” rejection: Facturae/FACe publishes no offline-verifiable rejection codes, so it is a warning, not an error. | Valid |
CODA statement (Belgium) (6)
| Sample files | Expected result | Download the file |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationAn ordinary Belgian statement: a SEPA credit transfer carrying a valid structured communication (+++090/9337/55493+++), a card payment, and an incoming transfer with its counterparty. Opening 1 000.00 − 250.00 − 89.90 + 1 500.00 = closing 2 160.10, and the trailer totals agree. | Valid | |
| CODA — globalised salary run (booked total + its details)A globalisation: one booked salary total of 3 000.00 (detail number 0000) followed by the two individual salaries behind it (0001, 0002). Only the total is booked — a parser that sums the details too double-counts the file, and the statement stops balancing. Closes on a debit balance of 2 000.00. | Valid | |
| CODA — wrong mod-97 check digits and a statement that does not balanceBroken on purpose. The structured communication ends in 94 where mod 97 requires 93 — the single most common reason a Belgian payment is never matched to its invoice — and the new balance does not follow from the movements. No other free CODA tool checks these check digits. | Valid | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedA CODA statement carrying the two structured references the format allows, each with its own checksum: an outgoing transfer with a Belgian structured communication +++090/9337/55493+++ (type 101, mod 97 — where a remainder of 0 is written 97, not 00) and an incoming transfer with an ISO 11649 creditor reference RF73INV20260042 (type 100, mod 97-10). Both check out, and the statement balances: 1 000.00 − 250.00 + 1 500.00 = 2 250.00. | Valid | |
| CODA — separate application: balances zeroed by design (§7.2.1)A CODA "separate application" (header positions 84-88 = 00001): a card-acceptance settlement delivered outside the account statement. Febelfin §7.2.1 zeroes its old and new balances by construction, so the accounting identity old ± movements = new cannot hold — and must not be checked. ValidateFin skips it here and reports the file clean; a validator that does not skip it flags every such file as broken. | Valid | |
| CODA — old balance ± movements ≠ new balanceAn ordinary Belgian statement — one movement short. The 2.1 records add up to 1 000.00 − 250.00 + 1 500.00 = 2 250.00, but the "8" new-balance record declares 2 200.00: 50.00 of booked movement never made it into the file. This is the check that catches a truncated CODA, a dropped record or a mis-read debit/credit sign, and it is the reason the previous sample must NOT be checked the same way. | Valid |
CFONB 120 statement (France) (5)
| Sample files | Expected result | Download the file |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsA French statement carrying its full SEPA data: a direct debit with its mandate reference and RCUR sequence type, the creditor’s name, a card payment, and an incoming transfer with the payer’s name, the end-to-end reference, the purpose and the remittance information — all in "05" supplement records. Opening 1 000.00 − 250.00 − 89.90 + 1 500.00 = closing 2 160.10. | Valid | |
| CFONB 120 — amount without its overpunched signBroken on purpose, and the classic way to corrupt a CFONB file: the debit’s amount ends in a plain digit instead of an overpunched sign character, so the file never says it is a debit. It is read as a credit — and the accounting identity the CFONB requires is what catches it. | Valid | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYThe SEPA data of a CFONB 120 statement lives in "05" supplement records, and each one cuts the same 70-character zone (positions 49-118) differently: RUM is a mandate reference AND its sequence type (RCUR), REF is a batch reference AND a transaction reference, RCN is an end-to-end id AND a purpose, while NBE, NPY and LIB take the whole zone. Read flat, the zone glues a mandate to its sequence type. This file carries a SEPA direct debit (operation B1) and an incoming credit transfer with ten different qualifiers between them. | Valid | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileOne physical CFONB 120 file, two accounts: each is its own 01 (old balance) … 07 (new balance) block, and each balances on its own. The second one opens OVERDRAWN — the old balance carries an overpunched "}" family sign, a debit — and climbs back to a credit of 179.60. A parser that keeps a single running balance across the file, or that reads the sign character as a digit, gets both accounts wrong. | Valid | |
| CFONB 120 — the new balance does not equal old balance ± movementsEvery amount here carries a correct overpunched sign — and the statement still does not add up: 1 000.00 − 89.90 + 500.00 = 1 410.10, while the "07" record declares 1 310.10. Rule 2 of §1 of the CFONB spec states the identity as the DEFINITION of a conforming statement, so this is not a heuristic: 100.00 of movement is missing from the file. | Valid |
Fedwire ISO 20022 message (US) (6)
| Sample files | Expected result | Download the file |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferA customer wire with a Business Application Header and hybrid postal addresses — it already meets the format required from 16 November 2026. | Valid | |
| Fedwire pacs.009 — conformant bank-to-bank transferA financial institution credit transfer: the bank-to-bank leg, where both debtor and creditor are banks rather than customers. | Valid | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026The creditor address is three free-text lines with no town and no country. Valid against the XSD, rejected by the rule: from 16 November 2026 Fedwire removes the fully unstructured address. | Invalid | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overThe counter-example, and the point of the pair: byte-for-byte the same unstructured address, but settling on 30/06/2026. It is legal, so it warns — it does not fail. The trigger is the settlement date carried by the message, never today’s date. | Valid | |
| Fedwire pacs.008 — routing number that cannot existThe creditor agent’s routing number is 021000088 — one digit off. It fails the ABA 3-7-1 check digit, so it is not a number that can exist. The XSD sees nine perfectly good digits. | Invalid | |
| Fedwire — header announces a different message than it carriesThe Business Application Header says <MsgDefIdr>pacs.009.001.08</MsgDefIdr> while the document it heads is a pacs.008. Both halves validate against their own schema; only comparing them catches it. | Invalid |
SWIFT MT103 credit transfer (2)
| Sample files | Expected result | Download the file |
|---|---|---|
| MT103 — cross-currency customer credit transferA complete MT103: all five SWIFT blocks, a UETR, an option-K ordering customer, option-A agents and an IBAN beneficiary. Settled in USD, instructed in EUR — so field :36: (exchange rate) is required, and present. | Valid | |
| MT103 — three defects a plain text viewer would missStructurally a perfectly readable MT103 — and wrong three times over: the UETR is not a version-4 UUID, the payment is cross-currency with no exchange rate in :36:, and the beneficiary IBAN fails its mod-97 check digits. | Valid |
CPA-005 / AFT payment file (Canada) (6)
| Sample files | Expected result | Download the file |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)An ordinary Canadian payroll file: a single "C" record carrying two direct deposits (transaction type 200) in two of its six segments. The Z trailer declares 2 credits totalling 3,750.50 and no debits, and it reconciles. Note that the record counts PHYSICAL records while the trailer counts TRANSACTIONS — there are three records and two transactions. | Valid | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)A "D" pre-authorised debit of 899.00 followed by the "J" record that returns it. The return carries reason code 901 (insufficient funds) in the TRANSACTION TYPE field — where the payment would carry its payment type — while the original type 700 survives in the stored transaction type. Both are booked as debits, which is why the trailer declares 2 debits for 1,798.00. | Valid | |
| CPA-005 — the error correction folded into the debit totalBroken on purpose, and broken the way real generators break: the file reverses a credit with an "E" record, and the trailer counts that reversal as a debit. It is not one. Standard 005 gives the E and F error corrections their OWN pair of totals, separate from the debit and credit pairs — fold them together and the file no longer balances. This is the single most common way a hand-written CPA-005 generator gets rejected. | Invalid | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedA 1464-character AFT file mixing both directions: a "C" record with two payroll deposits (3 750.50) and a "D" record with two pre-authorised debits (1 349.25). C is the CREDIT and D the DEBIT — several published summaries have them the other way round. The Z trailer balances on the four pairs of totals Standard 005 defines (D+J, C+I, E on its own, F on its own), here with the E and F counters at zero. | Valid | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)A Canadian Notice of Change: the receiving institution tells the originator that an account has moved. It is a FILE OF ITS OWN — records are 208 characters, not 1464, and Standard 005 forbids intermixing its U (header), S (change) and V (trailer) records with AFT records. Each S record carries the new routing number and account beside the original ones, and the V trailer declares how many S records it holds. | Valid | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaA customer-to-bank payroll file that a US-trained validator would wrongly reject twice over. Its first credit routes to transit 099999999, which carries no arithmetic check digit — the Canadian DPRN has none at all: Standard 005 validates it by lookup against the Financial Institutions File, and Standard 006 defines no checksum. Transposing the US ABA 3-7-1 rule here rejects perfectly valid files. Its item trace numbers are also left at zero, which is normal on a file a customer sends its bank (the Direct Clearer assigns them) — hence two warnings and zero errors. | Valid |
ACH / NACHA file (US) (10)
| Sample files | Expected result | Download the file |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)A WEB debit of 123.54 coming back. Three things change on a return and nothing else: the transaction code becomes 26 (the return code of a checking debit — NOT the original 27), the receiving bank becomes the ODFI of the original, and a new trace number is assigned. The amount is unchanged — ACH has no partial return. The addenda 99 carries R01 and points back to the original entry trace number. The batch still says WEB and still says TRANSFER: there is no "RETURN" description and no "RET" SEC code, however often the web says otherwise. | Valid | |
| ACH — a notification of change (C01, corrected account number)A notification of change — and the thing to understand is that it is NOT a rejection. The payment went through. The receiving bank is asking for the stored data to be corrected before the NEXT payment: re-sending this one would pay the receiver twice. That is why the entry carries an amount of ZERO, and why the batch SEC code is COR. The addenda 98 carries C01 with the corrected account number in positions 36-52 of the record. | Valid | |
| ACH — an international entry (IAT) with its seven mandatory addendaA USD-to-MXN payment to Mexico. An IAT entry record is not the domestic one relabelled: the account number moves to positions 40-74 (35 characters, to hold a foreign account), positions 13-16 declare how many addenda follow, and the receiver's name is not in the record at all — it lives in addenda 10. Seven addenda (10 to 16) are mandatory on every international entry, because a 94-character record cannot hold the name, address and bank identification of both parties. Reading this file with the domestic offsets returns a fragment of the account number as if it were a person's name. | Valid | |
| ACH — PPD payroll credits, balanced with an offset debitThe reference file: what a correct NACHA file looks like. Four PPD payroll credits (three checking, code 22, one savings, code 32) and a fifth entry — the offset debit, code 27, on the company's own account for the exact total, which is what makes the file "balanced" and why the service class code is 200 (mixed) rather than 220. Entry hash, batch control totals, file control totals and the block count all reconcile, and every routing number satisfies the ABA 3-7-1 check digit. | Valid | |
| ACH — CCD corporate debits with an addenda 05 remittanceA B2B collection: two CCD debits (service class 225, debits only), each carrying one addenda 05 with the invoice it settles — RMR and REF segments, the ASC X12 remittance a corporate receiver reconciles against. CCD allows exactly ONE addenda per entry: 80 characters of payment-related information, no more. When a payer needs more room than that, the SEC code becomes CTX. Note the addenda record indicator in position 79 of the entry: it says 1, and an addenda actually follows. | Valid | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Four WEB debits — the SEC code of a payment a consumer authorised online. Three come off checking accounts (code 27) and one off a savings account (code 37): the transaction code is what says which, and reading it as anything but a table is how parsers get it wrong. Position 77-78 carries the payment type indicator, R for recurring and S for single-entry. WEB entries carry no addenda, so the addenda record indicator stays at 0. | Valid | |
| ACH — CTX with seven addenda 05 carrying an EDI 820One CTX debit of 28,750.00 settling three invoices at once, with the ASC X12 820 remittance advice split across seven addenda 05 records. CTX is the SEC code parsers get wrong most often, because the entry record does not mean what it means everywhere else: positions 55-58 are NOT the start of a name, they are the NUMBER of addenda that follow (0007 here), and the receiving company name only starts at 59. Read it with the PPD offsets and the name comes back as "0007GLOBEX CORP" — which is exactly what our own validator shows, because it applies the domestic layout. | Valid | |
| ACH — entry hash mismatch (truncated or tampered file)A PPD credit file whose entry hash is wrong. The entry hash is the sum of the 8-digit routing numbers of every entry, truncated to its last ten digits — a checksum whose only job is to catch a file that lost, gained or had an entry altered in transit. Here the batch control and the file control both declare 28905251 while the four entries add up to 27905251. The amounts still balance, which is the point: the hash is the control that fires when nothing else does. | Invalid | |
| ACH — batch control debit total ≠ the sum of its entriesA CCD debit batch whose Batch Control declares 18,450.00 while its two entries add up to 28,075.00 — the classic bug of a generator that writes the trailer before it has added the last entry. Everything else in the file is right, including the file control totals, so the validator reports exactly one error and names both figures. This is the single most common reason a bank rejects a hand-built ACH file. | Invalid | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberA WEB debit file in which one receiving bank is 026009594 — a routing number that fails the ABA 3-7-1 check digit (the real one is 026009593). Only position 12 of the entry is wrong, so the entry hash and every control total still reconcile: the check digit is the one control that catches a single mistyped digit, and this file is the proof that the totals alone will not. The other two entries and all the trailers are correct, so the validator reports exactly one error. | Invalid |
Payment QR code (EPC / Swiss QR-bill) (6)
| Sample files | Expected result | Download the file |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)A conformant EPC QR code payload (SCT QR), version 002 — the version in which the BIC is optional, and it is omitted here. Remittance is a structured ISO 11649 creditor reference, RF6518539007547034, whose mod-97 check digits hold: 94 bytes of the 331 allowed. | Valid | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageThe other half of EPC069-12: version 001, where the beneficiary BIC is mandatory (it is the only difference between 001 and 002), and a free-text message instead of a reference. Structured reference and free text are mutually exclusive — a QR code carries one or the other, never both. | Valid | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capThe trap the spec spells out and implementations still fall into: EPC069-12 caps the payload at 331 BYTES, not characters. This Polish payload is 312 characters — comfortably under any character count — but the accented letters cost two bytes each in UTF-8, so it weighs 338 bytes and is rejected. | Invalid | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)The canonical Swiss QR-bill: a QR-IBAN (institution ID 31999, inside the 30000-31999 range) paired with the QR reference it requires — 26 digits plus a recursive-modulo-10 check digit, not the mod-97 of the IBAN world. Note the “ultimate creditor” block: seven lines, present and entirely empty, exactly as the Guidelines demand. | Valid | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceThe other half of the pairing rule: a normal IBAN (institution ID 00791, outside the QR-IID range) FORBIDS a QR reference and takes an ISO 11649 creditor reference (SCOR) — RF6518539007547034 — or none at all. Same bill, other account type, other reference: this is the distinction that decides whether a Swiss payment can be booked. | Valid | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)The single most consequential error in the Swiss format: a QR-IBAN carrying an ISO 11649 (SCOR) reference. The reference itself is perfectly valid — that is the trap — but a QR-IBAN demands a QRR reference and nothing else. The bank cannot book the payment, and the same verdict holds under Implementation Guidelines 2.3 and 2.4. | Invalid |
How we know these results hold
Every file in this library is run through the site's own validator on each build. The expected result stated above is asserted by an automated test — if a file stopped matching what this page claims, the build would fail. Two inherited fixtures were repaired this way before publication: three IBANs failed the mod-97 check and several names used characters outside the basic SEPA character set.