# ValidateFin

> Free, privacy-first online tools for SEPA, UBL/Peppol, IBAN, camt.053 and e-invoicing validation. All processing is done client-side — no data is ever uploaded to a server.

ValidateFin is a free web application for finance professionals, developers, and businesses across Europe who work with ISO 20022, SEPA, and e-invoicing (EN 16931 / Peppol) standards. It also ships an MCP server so AI assistants can run the validators directly.

## Tools

- [SEPA Validator](/en/tools/sepa): Validate SEPA pain.001 (Credit Transfer) and pain.008 (Direct Debit) files against the official ISO 20022 XSD schemas and the EPC Rulebook business rules — IBAN (mod-97), BIC, SEPA character set, mandate data, Creditor Scheme Identifier (ICS) and control sums. Runs in the browser.
- [pain.002 Status Report Reader](/en/tools/pain002): Read a SEPA payment status report (pain.002) and get every rejection reason code (AC04, AM04, MD01…) explained in plain language, with the status of the group, each payment and each transaction. 100% client-side.
- [UBL / Peppol Invoice Validator](/en/tools/ubl): Validate UBL 2.1 invoices and credit notes by running the official EN 16931 Schematron — the same rule set used by the official European e-invoicing validators — plus the ISO 20022 UBL XSD schema. The Peppol-specific rules (PEPPOL-EN16931-*) are not run: OpenPeppol publishes no licence for its validation artefacts, so they are not redistributed here (permission requested) — a passing file is EN 16931-conformant, which is necessary but not sufficient for Peppol BIS conformance. ~200 business rules (VAT consistency, mandatory fields, totals). Accepts both UBL and CII (UN/CEFACT) syntaxes, entirely in the browser.
- [XRechnung Validator](/en/tools/xrechnung): Validate a German XRechnung e-invoice against the official EN 16931 core Schematron plus the KoSIT XRechnung BR-DE rules — the same rule sets used by the official German validator. XRechnung is the German CIUS of EN 16931, mandatory for B2G. Accepts UBL and CII syntaxes. 100% client-side.
- [KSeF FA(3) Validator (Poland)](/en/tools/ksef): Validate a Polish KSeF FA(3) structured invoice (Krajowy System e-Faktur) against the official Polish Ministry of Finance XSD published on crd.gov.pl (namespace http://crd.gov.pl/wzor/2025/06/25/13775/). FA(3) has been the only schema KSeF accepts since 1 February 2026 (sales over PLN 200m) and 1 April 2026 (all other businesses); it replaced FA(2), whose files this tool recognises and explains. Checks structure, data types, cardinalities and closed code lists (RodzajFaktury: VAT/KOR/ZAL/ROZ/UPR/KOR_ZAL/KOR_ROZ, VAT rates), plus the NIP mod-11 check digit and VAT-total coherence as non-blocking warnings. 100% client-side.
- [RO e-Factura Validator (Romania)](/en/tools/efactura): Validate a Romanian electronic invoice (RO e-Factura / RO_CIUS) and find out whether ANAF would REJECT it, with the exact rule it would quote. Three layers, in the order ANAF runs them: (1) the OASIS UBL 2.1 XSD — Invoice (FACT1) or CreditNote (FCN); (2) the OFFICIAL CIUS-RO Schematron published by the Romanian Ministry of Finance (ro16931-ubl-1.0.9, in force since 05/06/2024), executed as published — it carries the EN 16931 core rules (BR-*, BR-CO-*, BR-CL-*) AND the Romanian ones (BR-RO-001: BT-24 must be urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1, the value 1.0.0 having been retired on 29/12/2022; BR-RO-020: invoice type code 380/384/389/751 on an Invoice, 381 only on a CreditNote; BR-RO-100/101/160/202: in Bucharest the city must read SECTOR1-SECTOR6, NOT "Sector 1" as the ministerial order itself spells it; BR-RO-030: RON must appear in BT-5 or BT-6; the BR-RO-L* length limits), with their verbatim Romanian messages; (3) the fiscal-identity check that is NOT part of the Schematron and that Schematron-only validators miss entirely — the CUI check digit and the CNP/NIF, which ANAF rejects under its own code ERRIdentif ("CUI cumparator incorect", "CNP sau NIF vanzator incorect"). The CNP check verifies the check digit AND that the encoded date of birth exists (a 31 April is refused although its checksum is correct), while a NIF (leading 9) encodes no date and is exempt; the anonymous B2C identifier 0000000000000 is valid. Mandatory: B2B since 01/07/2024, B2C since 01/01/2025 — a rejected invoice is legally not issued. 100% client-side.
- [Verifactu Validator (Spain)](/en/tools/verifactu): Validate a Spanish Verifactu / SIF billing-record submission (RegFactuSistemaFacturacion) and find out whether the AEAT would REJECT it, with the exact official code it would return. Two layers: (1) the OFFICIAL AEAT XSD (SuministroLR.xsd + SuministroInformacion.xsd) — structure, closed enumerations (TipoFactura F1/F2/F3/R1-R5, CalificacionOperacion S1/S2/N1/N2, ClaveRegimen, TipoHuella) and the DD-MM-AAAA date format; (2) the controls the AEAT publishes in 'Validaciones y errores' v1.2.2 (08/04/2026), quoted with their verbatim Spanish label and code — 1108 (IDEmisorFactura must equal ObligadoEmision), 1114/1115 (TipoRectificativa), 1116/1117/1118/1119, 1130 (forbidden characters in NumSerieFactura), 1138/1139 (Macrodato above 100,000,000 EUR), 1142 (CuotaRepercutida vs base x rate, tolerance +/-10 EUR), 1152 (no invoice dated before 28 October 2024), 1177, 1189/1190 (Destinatarios vs invoice type), 1195/1196 (CalificacionOperacion and OperacionExenta are mutually exclusive), 1223. THE DIFFERENTIATOR: it RECOMPUTES THE HUELLA — the chained SHA-256 fingerprint that makes the Spanish invoice chain tamper-evident, each record hashing the previous record's fingerprint — reproducing the three official test vectors of the AEAT hash specification (v0.1.2, 27/08/2024). A wrong huella is NOT a rejection: it is code 2000, series 2xxx = 'Aceptado con errores', and the AEAT records the entry anyway. The tool follows the AEAT's taxonomy, not intuition, and states what it cannot check offline (the NIF against the AEAT censo, duplicates, the signing certificate). Independent tool, not certified or endorsed by the Agencia Tributaria. 100% client-side.
- [Facturae Validator (Spain)](/en/tools/facturae): Validate a Spanish Facturae electronic invoice — the official B2G format required to invoice Spanish public administrations through FACe (law 25/2013), and one of the accepted B2B formats. Two layers: (1) the OFFICIAL XSD published by facturae.gob.es (Ministerio de Hacienda / Ministerio de Asuntos Económicos), chosen from the root namespace — version 3.2 (2009), 3.2.1 (2014) or 3.2.2 (current) — covering structure, data types, cardinalities and closed code lists; (2) COHERENCE controls derived from the schema's OWN official formulas, reported as warnings because Facturae/FACe (unlike Italy's SdI) publishes no numbered offline rejection list: line TotalCost = Quantity x UnitPriceWithoutTax, GrossAmount = TotalCost - discounts + charges, TotalGrossAmountBeforeTaxes, per-tax TaxAmount = TaxableBase x TaxRate, TotalTaxOutputs, InvoiceTotal = before-tax + tax outputs - taxes withheld, and the batch InvoicesCount and TotalInvoicesAmount. It also checks the FORM of the seller/buyer NIF/CIF/NIE (only to flag an impossible form, never a checksum, which no Spanish authority publishes) and whether a XAdES ds:Signature is PRESENT. Honest scope, listed on screen: the cryptographic validity of the XAdES signature (certificate chain to a trusted CA, OCSP/CRL revocation, the Facturae signature policy) is NOT verified offline, nor is the NIF against the AEAT censo, the DIR3 codes (oficina contable / órgano gestor / unidad tramitadora) or the FACe registration status. Independent tool, not certified or endorsed by the Ministerio de Hacienda; official XSD schemas retrieved from facturae.gob.es on 13 July 2026. 100% client-side — validating here does not submit the file to FACe.
- [FatturaPA Validator (Italy)](/en/tools/fatturapa): Validate an Italian electronic invoice against the official Agenzia delle Entrate XSD (schema v1.2.3, namespace http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2) AND the rejection controls of the Sistema di Interscambio (SdI), returning the exact code the SdI would quote in its notifica di scarto — 00301/00306 (fiscal identifier), 00421 (Imposta), 00422 (ImponibileImporto), 00423 (PrezzoTotale), 00424, 00425, 00427 (CodiceDestinatario length vs FormatoTrasmissione), 00428, 00400/00401/00429/00430 (Natura vs AliquotaIVA), 00445 (the generic N2/N3/N6 withdrawn on 01/01/2021), 00471-00476 (TipoDocumento constraints), 00409 (duplicate inside a lotto), and more. Sourced from the "Elenco dei controlli effettuati sul file fattura del SdI" v2.0 (31/01/2025). Handles FPR12 (private), FPA12 (public administration) and FSM10 (simplified), invoice batches (lotti), and opens signed CAdES .p7m envelopes (the signature itself is NOT verified). Partita IVA and codice fiscale check digits per the Ministerial Decree of 23/12/1976, omocodia included. 100% client-side.
- [IBAN Validator](/en/tools/iban): Validate any IBAN using the mod-97 checksum algorithm (ISO 13616). Supports all 36 SEPA countries.
- [Camt.053 Validator](/en/tools/camt): Validate ISO 20022 camt.053 bank statements against the official ISO 20022 XSD schema; view balances and entries, export to CSV. Also validates camt.052 (account report) and camt.054 (debit/credit notification). Versions .02, .06, .08, .10, .11.
- [Fedwire ISO 20022 Validator](/en/tools/fedwire): Validate a Fedwire Funds Service ISO 20022 message (the USD real-time gross settlement system of the Federal Reserve, on ISO 20022 since 14 July 2025). Checks the business application header (head.001.001.03) and the payment document (pacs.008.001.08, pacs.009.001.08, pacs.004.001.10, pacs.028.001.03, camt.056.001.08, camt.029.001.09) against the official ISO 20022 XSDs, then applies the hybrid postal address the Federal Reserve requires from 16 November 2026 (town name + country, at most two free-text lines, for all parties AND agents), the ABA 3-7-1 check digit, and header/document coherence. It does not predict a Fedwire rejection: the Usage Guidelines are on Swift MyStandards behind a login, and the tool says which controls it skipped. 100% client-side.
- [MT103 Viewer](/en/tools/mt103): Decode a SWIFT MT103 (Single Customer Credit Transfer) field by field — the five SWIFT blocks, the UETR, the parties (ordering customer, agents, beneficiary), the charges (OUR/SHA/BEN) and the remittance information. Field specifications sourced from the European Central Bank TARGET2 UDFS (public and free). The SWIFT Network Validated Rules are in the paid User Handbook and are not checked. MT103 was retired from cross-border interbank traffic when CBPR+ coexistence ended on 22 November 2025 (replaced by pacs.008) but remains widely used domestically and bank-to-corporate. 100% client-side.
- [MT940 Viewer & Converter](/en/tools/mt940): Read a legacy SWIFT MT940 bank statement (Customer Statement Message; tags :20:, :25:, :60F:, :61:, :86:, :62F:) and convert it to ISO 20022 camt.053. Parses opening/closing balances and transactions, reconciles opening ± turnover = closing, handles RC/RD reversals. MT940 was retired by SWIFT in November 2025 and is being replaced by camt.053. 100% client-side.
- [BAI2 Viewer & Converter](/en/tools/bai2): Read a BAI2 (Bank Administration Institute, version 2) bank statement — the dominant US/Canada cash-management format, the North-American counterpart of SWIFT MT940 — and convert it to ISO 20022 camt.053. Parses the 01/02/03/16/88 record hierarchy, infers debit/credit direction from the numeric type code (100–399 credit, 400–699 debit), scales integer minor-unit amounts by currency, and reconciles opening ledger (010) + turnover = closing ledger (015). 100% client-side.
- [CODA Validator & Converter (Belgium)](/en/tools/coda): Read and validate a Belgian CODA bank statement ("Coded statement of account", the Febelfin standard, version 2.8, updated November 2025) and convert it to ISO 20022 camt.053. Parses the fixed-width 128-character record hierarchy (0 header, 1 old balance, 2 movement with articles 2.1/2.2/2.3, 3 information with 3.1/3.2/3.3, 8 new balance, 4 free communication, 9 trailer), the 15-digit amounts (12 integer positions + 3 decimals), the explicit debit/credit sign (0 = credit, 1 = debit) and the 8-character transaction codes. Checks the trailer control totals and record count (record 9), the accounting identity (old balance ± movements = new balance) and — the differentiator — the CHECK DIGITS of the Belgian structured communication (+++123/4567/89012+++, mod 97, communication types 101 and 102) and of the ISO 11649 "RF" structured creditor reference (mod 97-10, type 100). A wrong structured reference is the most common reason a Belgian payment is never matched to its invoice; no other free online tool verifies it. 100% client-side.
- [CFONB 120 Validator & Converter (France)](/en/tools/cfonb): Read and validate a French CFONB 120-character bank statement ("Relevé de compte sur support informatique", also called AFB120) and convert it to ISO 20022 camt.053. Parses the fixed-width 120-character records (01 old balance, 04 movement, 05 supplement, 07 new balance) and correctly decodes the two traps of the format: the sign of the amount is OVERPUNCHED on its last character (COBOL zoned decimal — credit "{" and A-I, debit "}" and J-R), and the number of decimals is a field of the file itself (position 20), not a property of the currency. Decodes the SEPA data carried by the 05 records through their 3-letter qualifiers (LIB, MMO, NPY, IPY, NBE, IBE, LCC, LC2, LCS, RCN, REF, CBE, CPY, RUM…) and checks the accounting identity the CFONB spec itself requires (§1 rule 2: the new balance equals the algebraic sum of the old balance and of every movement in the statement). Specs: CFONB, "Relevé de compte sur support informatique" (July 2004) and "Evolutions du Relevé de Compte 120 caractères pour les opérations de virements et de prélèvements SEPA" (v2.0, March 2010). 100% client-side.
- [camt.053 to MT940 & CSV Converter](/en/tools/camt-converter): Convert an ISO 20022 camt.053 bank statement back to SWIFT MT940, or flatten any camt.052/053/054 to CSV. This is the REVERSE of the usual direction and the gap nobody else fills for free: banks now deliver camt.053, while a long tail of ERP, accounting and treasury systems still only reads MT940. Emits :20:/:25:/:28C:/:60F:/:61:/:86:/:62F: (plus :64: when the statement carries a closing available balance), one block per statement, preserving the balances with their sign, the value and booking dates, the customer reference (from EndToEndId) and the bank reference (from AcctSvcrRef), and marking reversals with the MT940 RC/RD marks rather than flattening them into an ordinary movement of the opposite sign. The limits are reported rather than hidden: only BOOKed entries are emitted, because MT940 has no way to express a pending entry and including one would claim money moved (the CSV has a status column and keeps them); text is folded into the SWIFT character set, so accents are stripped ("Société Générale" becomes "Societe Generale") and letters Unicode NFD cannot decompose (Ł, Ø, ß, Þ, Đ, Ħ, Œ) are transliterated rather than dropped; references are cut to MT940's 16 characters where camt.053 allows 35. Only camt.053 converts to MT940 — camt.052 (intraday report) and camt.054 (notification) carry no opening/closing balance pair and are refused rather than given invented balances. CSV amounts follow the currency's own minor unit (JPY none, KWD three) and cells are guarded against spreadsheet formula injection. Writing software that emits MT940 is expressly licensed by the SWIFT Standards IPR Policy; no SWIFT prose is republished. 100% client-side.
- [SEPA Date Calculator & TARGET Closing-Day Calendar](/en/tools/sepa-dates): Work out what actually happens to a SEPA payment, and when. For a direct debit Due Date: the settlement date, the D-1 presentation deadline, the earliest presentation and latest pre-notification (both 14 CALENDAR days before the due date), the latest return settlement (5 Inter-PSP Business Days for CORE, 3 for B2B), and for CORE the refund window (8 weeks no-questions-asked, 13 months for an unauthorised transaction under PSD article 71 — the B2B scheme gives NO refund right for an authorised collection at all). A Due Date that falls on a closed day is NOT an error: the rulebook states that settlement moves to the next Inter-PSP Business Day, so the tool reports the shift instead of rejecting the file. D-1 applies to EVERY sequence type — the rulebook says the deadline holds "irrespective of whether the Collection is presented as an one-off or a recurrent Collection" and that using FRST at all "is no longer mandatory"; the D-5 (FRST) / D-2 (RCUR) split was retired in November 2016 and survives only in stale third-party guides. Also says whether TARGET is open on any date and lists a year's six closing days: 1 January, Good Friday, Easter Monday, 1 May, 25 December and 26 December, plus every Saturday and Sunday. TARGET is a European system and is OPEN on national bank holidays (15 August, 1 November, 3 October in Germany, 14 July in France); Easter is the Gregorian ("Catholic/Protestant") one, which the ECB states explicitly — not the Orthodox one. Sources: ECB, "Long-term calendar for TARGET closing days" (14 December 2000), applying from 2002 until further notice, still in force per the EPC 2025 rulebooks; EPC016-06 SDD Core Rulebook 2025 v1.1 (5 Oct 2025), EPC222-07 SDD B2B 2025 v1.0, EPC125-05 SCT Rulebook 2025 v1.1. What it deliberately will NOT tell you: a credit transfer's settlement date (the SCT rulebook counts in Banking Business Days — days a PSP in the relevant jurisdiction is open for customers — not on the TARGET calendar), national bank holidays, or your bank's cut-off time; none is in any free authoritative source, so none is asserted. Open dataset: /data/target-days/index.json (CC-BY-4.0). 100% client-side.
- [ACH / NACHA File Validator](/en/tools/ach): Validate a US ACH file in the fixed-width Nacha format (94-character records, types 1/5/6/7/8/9). Checks record structure, the ABA routing-number check digit (3-7-1), the entry hash, and all batch and file control totals (debits, credits, entry/addenda count, block count). ALSO DECODES THE ADDENDA, which is where an ACH file stops being a list of payments and starts carrying meaning: RETURNS (addenda 99 — the return reason code R01-R85, the original entry trace number, the date of death that only R14 and R15 may carry, plus the dishonored R61-R70 and contested R71-R77 families), NOTIFICATIONS OF CHANGE (addenda 98 — the change code C01-C14 and the corrected data, split according to the layout its change code prescribes, with the corrected routing number re-checked against the 3-7-1 rule), and INTERNATIONAL ENTRIES (IAT — the batch's foreign exchange indicator, destination country and the two currency codes, and the SEVEN MANDATORY ADDENDA 10 to 16). Two things it enforces that most tools miss: a returned or corrected entry must carry one of the eight return transaction codes (21/26 checking, 31/36 savings, 41/46 general ledger, 51/56 loan) and NOT the transaction code of the original payment; and a notification of change is a ZERO-DOLLAR entry — the payment already went through, so re-sending it would pay the receiver twice. Two myths it deliberately does NOT enforce, because Nacha's own free guide contradicts them: a return batch does NOT carry a "RETURN" company entry description, and a notification of change does NOT carry "SOFTWARE" — every field of a return or NOC stays unchanged from the original entry unless the rules say otherwise. 100% client-side.
- [ABA Routing Number Validator](/en/tools/aba): Validate a US ABA routing number (routing transit number, RTN): checks the 9-digit structure, verifies the ABA 3-7-1 check digit (mod 10), and decodes the Federal Reserve routing symbol and district. The US counterpart of IBAN validation. 100% client-side.
- [LEI Validator (ISO 17442)](/en/tools/lei): Validate a Legal Entity Identifier: 20-character structure and check digits (ISO/IEC 7064 MOD 97-10 - the same algorithm as the IBAN), with the expected check digits suggested when a LEI is mistyped. The LEI identifies the PARTY where an IBAN identifies the ACCOUNT; it is carried by ISO 20022 payments and is scheme 0199 of the EN 16931 ICD and EAS code lists. Two things most LEI checkers get wrong, and this one states plainly: (1) a valid checksum proves only the absence of a typo - it does NOT prove the entity exists, nor which entity it is, nor that the LEI is still active (a LEI must be renewed yearly and can be LAPSED, RETIRED or ANNULLED; only the GLEIF Global LEI Repository can say, and that is an online lookup); (2) characters 5-6 are described by the standard as reserved "00", but measured against GLEIF's own public data 8% of real LEIs do not carry "00" there and are perfectly valid - enforcing that rule would reject roughly one entity in twelve. 100% client-side.
- [CPA-005 / AFT File Validator (Canada)](/en/tools/cpa005): Validate a Canadian bulk-payment file in the CPA Standard 005 AFT format (also called EFT 1464) — the format Canadian banks use for direct deposits and pre-authorised debits. Records are 1,464 characters: a 24-character prefix plus SIX 240-character segments, so a single record carries up to six transactions. Parses every record type (A header, C credit/deposit, D debit/PAD, E and F error corrections, I and J returns, Z trailer, plus the U/S/V records of a Notice of Change file), checks the logical record count, the origination control data repeated on every record, and the FOUR SEPARATE PAIRS of control totals in the Z trailer — the error corrections E and F have their own counters and are NEVER folded into the debit and credit totals, which is the single most common way a hand-written CPA-005 generator gets rejected. Decodes the 0YYDDD Julian date (a constant zero, a two-digit year, then the day of the YEAR, not the day of the month) and labels the transaction codes and 900-series return reason codes of CPA Standard 007 (901 NSF, 902 account not found, 905 account closed, 915-921 customer-initiated returns; 900 is reserved for edit rejects and 906 was retired in October 2007). IMPORTANT: a Canadian routing number has NO CHECK DIGIT — unlike the US ABA number and its 3-7-1 rule. Standard 005 validates it against the Payments Canada Financial Institutions File and Standard 006 defines no checksum at all, so only the shape is checked (a constant leading zero, a 3-digit institution number, a 5-digit branch). Sources: Payments Canada Standard 005 (2024) and Standard 007 (2026). 100% client-side.
- [Payment QR codes — SEPA (EPC) generator & Swiss QR-bill validator](/en/tools/qr-code): Generate an EPC QR code for a SEPA credit transfer (EPC069-12 v3.1, error correction level M), or decode and validate any payment QR code — EPC or Swiss QR-bill — from a pasted payload or from a picture of the QR code, scanned in the browser canvas. The EPC payload is twelve lines (BCD service tag, version, character set, SCT, beneficiary BIC, name and IBAN, the euro amount, a purpose code, then EITHER a structured creditor reference OR an unstructured message — never both) and is capped at 331 BYTES of the declared character set, not 331 characters: in UTF-8 an accented letter costs two. Version 001 makes the BIC mandatory; version 002 only requires it when the beneficiary's bank is a SEPA participant outside the EEA — that is the ONLY difference between the two. For a Swiss QR-bill (SIX Implementation Guidelines 2.3, in force, and 2.4, applicable from 14 November 2026), performs the check the guidelines explicitly ask a decoder to make: the ACCOUNT/REFERENCE PAIRING. A QR-IBAN — an IBAN whose institution identification (positions 5-9) falls between 30000 and 31999 — REQUIRES a QRR reference; a standard IBAN forbids one and takes an ISO 11649 SCOR reference or none. Verifies the QR reference's RECURSIVE MODULO-10 check digit (not the modulo 97 of the IBAN world — they give different answers) and the mod-97 check digits of an RF creditor reference. Also knows that a Swiss bill of exactly 0.00 carrying a "do not use for payment" message is a legitimate NOTIFICATION, not a broken document. 100% client-side — a payment QR code carries an IBAN, and it never leaves the browser.
- [Factur-X / ZUGFeRD Validator](/en/tools/facturx): Extract and validate embedded XML from Factur-X (France/EU) and ZUGFeRD (Germany) hybrid PDF invoices. Supports all profiles including EN 16931.
- [SEPA & camt.053 Test File Generator](/en/tools/test-generator): Generate a valid camt.053 test bank statement from a pain.008 or pain.001 file — test data for reconciliation and ERP integration.
- [CSV to SEPA Converter](/en/tools/sepa-converter): Convert any CSV spreadsheet to a valid SEPA pain.001 or pain.008 XML file using a visual column mapping interface.
- [XML Comparator](/en/tools/xml-comparator): Compare two XML files side by side with line-by-line diff highlighting.
- [Universal Viewer](/en/tools/viewer): Drop any SEPA (pain.001/pain.008), camt.052/053/054, UBL/Peppol or Factur-X/ZUGFeRD file — the type is auto-detected and its key facts (type, parties, totals, entries) shown read-only. 100% client-side.

## IBAN by country

Each country has a dedicated page with its IBAN format, length, structure, a validated example and an FAQ (how many characters, how to check validity, where to find your IBAN). All run the mod-97 checksum (ISO 13616) 100% client-side.

- [Germany IBAN](/en/tools/iban/germany) (DE, 22 chars), [France IBAN](/en/tools/iban/france) (FR, 27), [Spain IBAN](/en/tools/iban/spain) (ES, 24), [Italy IBAN](/en/tools/iban/italy) (IT, 27), [Belgium IBAN](/en/tools/iban/belgium) (BE, 16), [Netherlands IBAN](/en/tools/iban/netherlands) (NL, 18), [Austria IBAN](/en/tools/iban/austria) (AT, 20), [Portugal IBAN](/en/tools/iban/portugal) (PT, 25), [Ireland IBAN](/en/tools/iban/ireland) (IE, 22), [Luxembourg IBAN](/en/tools/iban/luxembourg) (LU, 20), [Finland IBAN](/en/tools/iban/finland) (FI, 18), [Poland IBAN](/en/tools/iban/poland) (PL, 28), [Switzerland IBAN](/en/tools/iban/switzerland) (CH, 21), [Sweden IBAN](/en/tools/iban/sweden) (SE, 24), [Denmark IBAN](/en/tools/iban/denmark) (DK, 18), [Norway IBAN](/en/tools/iban/norway) (NO, 15), [Greece IBAN](/en/tools/iban/greece) (GR, 27), [Croatia IBAN](/en/tools/iban/croatia) (HR, 21), [Romania IBAN](/en/tools/iban/romania) (RO, 24), [Czech Republic IBAN](/en/tools/iban/czech-republic) (CZ, 24), [Slovakia IBAN](/en/tools/iban/slovakia) (SK, 24), [Slovenia IBAN](/en/tools/iban/slovenia) (SI, 19), [Estonia IBAN](/en/tools/iban/estonia) (EE, 20), [Latvia IBAN](/en/tools/iban/latvia) (LV, 21), [Lithuania IBAN](/en/tools/iban/lithuania) (LT, 20), [Bulgaria IBAN](/en/tools/iban/bulgaria) (BG, 22), [Hungary IBAN](/en/tools/iban/hungary) (HU, 28), [Malta IBAN](/en/tools/iban/malta) (MT, 31), [Cyprus IBAN](/en/tools/iban/cyprus) (CY, 28), [Iceland IBAN](/en/tools/iban/iceland) (IS, 26), [Liechtenstein IBAN](/en/tools/iban/liechtenstein) (LI, 21), [Monaco IBAN](/en/tools/iban/monaco) (MC, 27), [San Marino IBAN](/en/tools/iban/san-marino) (SM, 27), [Andorra IBAN](/en/tools/iban/andorra) (AD, 24), [United Kingdom IBAN](/en/tools/iban/united-kingdom) (GB, 22), [Gibraltar IBAN](/en/tools/iban/gibraltar) (GI, 23), [Vatican City IBAN](/en/tools/iban/vatican-city) (VA, 22), [Turkey IBAN](/en/tools/iban/turkey) (TR, 26), [Brazil IBAN](/en/tools/iban/brazil) (BR, 29), [Israel IBAN](/en/tools/iban/israel) (IL, 23), [United Arab Emirates IBAN](/en/tools/iban/united-arab-emirates) (AE, 23), [Saudi Arabia IBAN](/en/tools/iban/saudi-arabia) (SA, 24).

## Reference hub

- [Financial standards reference](/en/resources): Hub linking every reference section - 313 e-invoice validation rules across EN 16931, Peppol BIS 3.0 and XRechnung, 163 EN 16931 business terms (BT-*) with their UBL/CII/Factur-X mapping, 5 ISO 20022 schema families, 15 financial code lists totalling 3695 codes (VATEX, UNCL 5305, UNTDID 1001/2005/1153/7143, pain.002, GVC, ISO 4217, ISO 20022 Purpose / Category Purpose / Status Reason, camt Bank Transaction Codes, ACH/NACHA notification-of-change and Standard Entry Class codes), the 36 SEPA payment rejection codes each marked recoverable or final, a sourced e-invoicing mandate matrix covering 32 European jurisdictions (B2G/B2B/e-reporting, every row backed by a government or EU source), a directory of 1228 banks across 37 countries, and a 91-term glossary. All free, no signup, every validator runs client-side.

## Validation rules reference

- [EN 16931, Peppol & XRechnung Validation Rules](/en/rules): Reference of 313 business rules checked on e-invoices across three stacked layers: 224 EN 16931 rules (BR-*, BR-CO-*, VAT category rules), 46 Peppol BIS 3.0 rules (PEPPOL-EN16931-*), and 43 XRechnung rules (BR-DE-*, BR-DEX-*). Each rule page explains what it checks and how to fix a file that fails it, in 8 languages. Examples: [BR-CO-10](/en/rules/br-co-10), [PEPPOL-EN16931-R001](/en/rules/peppol-en16931-r001), [BR-DE-10](/en/rules/br-de-10).

## Business terms reference (EN 16931 semantic model)

- [EN 16931 Business Terms (BT & BG)](/en/terms): Reference of every EN 16931 business term (BT-1 … BT-161) and business group (BG-1 … BG-32) - the semantic content model of a European e-invoice. Each term page gives its cardinality, data type, the exact mapping into the three EN 16931 syntaxes (UBL 2.1, UN/CEFACT CII, Factur-X/ZUGFeRD profile) and the BR-* rules that reference it, in 8 languages. The full dataset is downloadable as JSON: /data/en16931/business-terms.json. CC-BY-4.0 covers our compilation, translations and verification metadata only: the EN 16931 semantic model itself remains CEN's, reproduced cost-free under the European Commission/CEN agreement of 18 December 2018, and the payload carries the notice that permission is conditional on — carry it if you reuse the data. The ubl/cii/facturx mapping columns are our own reading, checked against the free official artefacts; the authoritative bindings (CEN/TS 16931-3-2 and -3-3) are paid specifications we have not consulted. Examples: [BT-1 Invoice number](/en/terms/bt-1), [BT-27 Seller name](/en/terms/bt-27), [BT-112 Invoice total with VAT](/en/terms/bt-112), [BG-25 Invoice line](/en/terms/bg-25).

## ISO 20022 schemas

- [ISO 20022 Schema Reference](/en/schemas): Factual reference for the SEPA payment (pain) and cash-management (camt) ISO 20022 message schemas: namespace, root element, versions and which validate against the official XSD. Each links to a free validator.
- [pain.001](/en/schemas/pain.001) - CustomerCreditTransferInitiation (SEPA credit transfer). Root element CstmrCdtTrfInitn. Versions .03, .09, .11.
- [pain.008](/en/schemas/pain.008) - CustomerDirectDebitInitiation (SEPA direct debit). Root element CstmrDrctDbtInitn. Versions .02, .08.
- [camt.053](/en/schemas/camt.053) - BankToCustomerStatement (end-of-day statement). Root element BkToCstmrStmt.
- [camt.052](/en/schemas/camt.052) - BankToCustomerAccountReport (intraday report).
- [camt.054](/en/schemas/camt.054) - BankToCustomerDebitCreditNotification.

## Code lists

- [Financial code lists & code lookup](/en/resources/codelists): Paste any code met on an invoice, a payment or a bank statement (AC04, 380, SRV, EN) and get its official meaning. Searches 6886 codes across 22 official lists at once (VATEX, UNCL 5305, UNTDID 1001/2005/1153/4451/4461/5189/7143/7161, UN/ECE Rec 20 unit codes, ISO 6523 ICD, EAS, pain.002, GVC, ISO 4217, ISO 20022 Purpose/Category Purpose/Status Reason, camt BTC, ACH/NACHA NOC and SEC codes) - by code or by meaning - and warns when the same code exists in several lists with different meanings (EN is "Embargo number" in UNTDID 1153 but the EAN article number in UNTDID 7143). Each list also has its own page with the official source and a CC-BY-4.0 JSON download (e.g. /data/codelists/vatex.json). 100% client-side.
- [VATEX - VAT exemption reason codes](/en/resources/codelists/vatex): The 88 EN 16931 VAT exemption reason codes (BT-121) from the CEF/DG DIGITAL list as published in Peppol BIS Billing 3.0 - EU VAT Directive 2006/112/EC articles, scheme codes (reverse charge VATEX-EU-AE, intra-Community supply VATEX-EU-IC, export VATEX-EU-G, not subject VATEX-EU-O), and French national CGI exemptions. JSON: /data/codelists/vatex.json.
- [UNCL 5305 - VAT category codes](/en/resources/codelists/uncl5305): The 10 EN 16931 VAT category codes (BT-118, BT-151) from the UN/CEFACT UNCL 5305 subset - S (standard), Z (zero-rated), E (exempt), AE (reverse charge), K (intra-community), G (export), O (out of scope), L/M (Canary Islands / Ceuta-Melilla), B (transferred, Italy). Each links to its BR-* rule family. JSON: /data/codelists/uncl5305.json.
- [UNTDID 1001 - Document type codes](/en/resources/codelists/untdid-1001): The 32 invoice and credit-note document type codes (EN 16931 BT-3) from the UN/CEFACT UNTDID 1001 subset used by Peppol BIS 3.0 - commercial invoice (380), corrected invoice (384), self-billed invoice (389), prepayment invoice (386), credit note (381) and more. JSON: /data/codelists/untdid-1001.json.
- [pain.002 reason codes](/en/resources/codelists/pain002): The 36 ISO 20022 SEPA payment rejection reason codes (ExternalStatusReason1Code) carried by a pain.002 status report - AC04 (closed account), AM04 (insufficient funds), MD01 (no valid mandate) and more - each decoded with whether the payment is recoverable or final, translated in 8 languages. JSON: /data/codelists/pain002.json.
- [GVC - German business transaction codes](/en/resources/codelists/gvc): The 49 three-digit Geschaftsvorfallcodes (DK Anlage 3 DFU-Abkommen) that a German bank puts in a camt.053 BkTxCd/Prtry/Cd to say what each booking is (SEPA credit transfer 166, direct debit 105, fee 808), with official German labels and booking direction. JSON: /data/codelists/gvc.json.
- [UNTDID 2005 - VAT date code](/en/resources/codelists/untdid-2005): The 3 EN 16931 VAT date codes (BT-8) from the UN/CEFACT UNCL 2005 subset - 3 (invoice issue date), 35 (actual delivery date), 432 (payment date) - stating which event fixes the VAT tax point. JSON: /data/codelists/untdid-2005.json.
- [ISO 4217 - Currency codes](/en/resources/codelists/iso4217): All 178 active ISO 4217 currencies parsed from the official SIX Financial Information list (list-one.xml) - three-letter code, numeric code and minor units (decimals) for each (EUR 978/2, JPY 392/0, BHD 048/3). Used for the EN 16931 invoice currency (BT-5) and every ISO 20022 amount. JSON: /data/codelists/iso4217.json.
- [UNTDID 1153 - Reference code qualifier](/en/resources/codelists/untdid-1153): All 817 UN/EDIFACT reference code qualifiers, parsed from the official UNECE directory D24A - the code that says what a reference number IS (CT contract, ON buyer's order, AAK despatch advice). Used as the scheme of the EN 16931 invoiced object identifier (BT-18-1, rule BR-CL-07) and on every EDIFACT RFF segment. JSON: /data/codelists/untdid-1153.json.
- [ExternalPurpose - Purpose of the payment (ISO 20022)](/en/resources/codelists/iso20022-purpose): All 342 ISO 20022 purpose codes from the official External Code Sets (publication 1Q2026) - the 4-letter code in the Purp element of a pain.001/pain.008 that says what a payment IS (SALA salary, SUPP supplier, TAXS taxes, PENS pension) and is passed on to the creditor. JSON: /data/codelists/iso20022-purpose.json.
- [ExternalCategoryPurpose - Category purpose (ISO 20022)](/en/resources/codelists/iso20022-category-purpose): All 49 ISO 20022 category purpose codes from the official External Code Sets (publication 1Q2026) - the code in CtgyPurp that tells the DEBTOR's bank how to process a payment or batch (SALA payroll, TAXS tax, TREA treasury, URGP urgent, SEPA credit transfer). Not to be confused with Purpose (Purp), which informs the creditor. JSON: /data/codelists/iso20022-category-purpose.json.
- [ExternalStatusReason - Payment rejection reason codes (ISO 20022)](/en/resources/codelists/iso20022-status-reason): The complete list of 302 ISO 20022 status reason codes from the official External Code Sets (publication 1Q2026) - every reason a payment can be rejected, returned or held, as reported in a pain.002 (AC04 account closed, AM04 insufficient funds, MD01 no mandate). This is the exhaustive raw reference; the pain.002 list is its curated companion, covering the 36 reasons actually met in SEPA, translated into 8 languages and each marked recoverable or final. JSON: /data/codelists/iso20022-status-reason.json.
- [BTC - Bank Transaction Code (camt)](/en/resources/codelists/btc): All 1563 ISO 20022 bank transaction sub-families across 11 domains, parsed from the official codification workbook (published 31 May 2025) - the three-level Domain/Family/SubFamily code in BkTxCd of a camt.052/053/054 entry that says what each booking is (a received SEPA credit transfer is PMNT/RCDT/ESCT, the issued one PMNT/ICDT/ESCT). The international counterpart of the German GVC codes. JSON: /data/codelists/btc.json.
- [UNTDID 7143 - Item type identification code](/en/resources/codelists/untdid-7143): All 184 UN/EDIFACT item type identification codes, parsed from the official UNECE directory D24A - the code that says which catalogue an item code comes from (SRV GS1 GTIN, HS Harmonised System, UP UPC). Used as the scheme of the EN 16931 item classification identifier (BT-158-1, rule BR-CL-13), carried in Peppol as cbc:ItemClassificationCode/@listID. JSON: /data/codelists/untdid-7143.json.
- [UN/ECE Rec 20 - Unit of measure codes](/en/resources/codelists/unit): All 2162 unit of measure codes of European e-invoicing, from the European Commission's genericode package - Recommendation 20 merged with the Rec 21 extension (packaging units, prefixed X), exactly as EN 16931 rule BR-CL-23 requires them for the invoiced quantity (BT-130) and the item base quantity (BT-150). A quantity without a unit is not an amount, it is a number: "10" is ten pieces, ten kilos or ten hours depending on this code. This is the single most common cause of a rejected invoice line - "EA" and "PCE" look like the obvious codes for a piece, and neither exists: the code is C62 (KGM kilogram, LTR litre, HUR hour, MTR metre). JSON: /data/codelists/unit.json.
- [UNTDID 4461 - Payment means codes](/en/resources/codelists/untdid-4461): All 84 UN/EDIFACT payment means codes (EN 16931 BT-81, rule BR-CL-16) saying how an invoice is to be paid - 30 credit transfer, 58 SEPA credit transfer, 59 SEPA direct debit, 48 bank card, 49 direct debit, 10 in cash, 20 cheque. The code decides which payment details the invoice must carry: a credit transfer needs an IBAN, a direct debit a mandate reference, a card neither. Careful: 42 is "Payment to bank account", NOT an ACH code - the directory intercalates it in the middle of the ACH CCD+ savings family, so the debit counterpart of 41 is 43, not 42. JSON: /data/codelists/untdid-4461.json.
- [UNTDID 7161 - Charge reason codes](/en/resources/codelists/untdid-7161): All 178 UN/EDIFACT charge reason codes (EN 16931 BT-105 at document level, BT-145 per line, rule BR-CL-20) stating in coded form why an amount is ADDED to an invoice - freight, packaging, insurance, handling, environmental levy. The mirror image of UNTDID 5189, which codes deductions. Charges are where invoices quietly diverge from purchase orders: a coded reason lets the buyer reconcile "+ 45 EUR freight" against what was agreed. JSON: /data/codelists/untdid-7161.json.
- [UNTDID 5189 - Allowance reason codes](/en/resources/codelists/untdid-5189): The 19 UN/EDIFACT allowance reason codes of the EN 16931 subset (BT-98 at document level, BT-140 per line, rule BR-CL-19) stating in coded form why an amount is DEDUCTED - volume discount, early-payment discount, promotion, damaged goods. An allowance without a reason is a number the buyer's system cannot post. JSON: /data/codelists/untdid-5189.json.
- [UNTDID 4451 - Text subject qualifier (invoice note subject)](/en/resources/codelists/untdid-4451): All 401 UN/EDIFACT text subject qualifiers (EN 16931 BT-21, rule BR-CL-08) saying what a free-text note on an invoice is ABOUT - AAB payment terms, AAI general information, a regulatory statement, a delivery instruction. Free text is where machine-readable invoicing gives up; this code is the compromise: the note stays human prose, but its subject is coded, so a payment-term note routes to accounts payable and a customs note to logistics - without reading the sentence. JSON: /data/codelists/untdid-4451.json.
- [ISO 6523 ICD - Organisation identifier schemes](/en/resources/codelists/iso6523-icd): All 243 ISO 6523 International Code Designators (EN 16931 BT-29-1 and siblings, rule BR-CL-10) saying which registry an organisation identifier comes from - 0088 GS1 GLN, 0199 LEI, 0106 Dutch KvK, 0009 French SIRET. An organisation number is meaningless without its registry: "12345678" is a company number in a dozen countries at once. NOT the same list as EAS: 46 EAS codes (the whole 99xx range) are absent from ICD, and 8 shared codes carry different official designations in each. JSON: /data/codelists/iso6523-icd.json.
- [EAS - Electronic Address Scheme codes](/en/resources/codelists/eas): All 102 EN 16931 electronic address scheme codes (BT-34-1 for the seller, BT-49-1 for the buyer, rule BR-CL-25) saying what KIND of address an invoice routes to - 0088 GS1 GLN, 9925 Belgian VAT number, 0192 Norwegian organisation number, 0199 LEI. This is the code that actually delivers the invoice: on Peppol, the endpoint identifier plus its EAS scheme is the postal address of the recipient, and a wrong scheme routes a perfectly valid invoice to nobody. JSON: /data/codelists/eas.json.
- [NOC - ACH Notification of Change codes (US)](/en/resources/codelists/nacha-noc): The 10 NACHA change codes (C01 incorrect account number, C02 incorrect routing number, C05 incorrect transaction code, C08 IAT only, C13 addenda format error, C14 outbound payment must be IAT) plus the 9 refused-NOC codes C61-C69 sent back by the ODFI. A NOC is NOT a rejection: the ACH payment was posted, and the Originator must correct its data within six banking days or before the next entry, whichever is later - re-sending the payment would pay twice. Verified against the appendixes Nacha publishes free, the US Treasury Green Book and the Federal Register, because the Nacha Rules book is sold. There is no C04 (removed from the Rules in 2015) and no C10/C11/C12 (they never existed - the table goes C09 to C13 - yet processors and bank PDFs publish them widely; the likely confusion is with the refused-NOC code C63 "Incorrect Company Identification Number"). JSON: /data/codelists/nacha-noc.json.
- [SEC - ACH Standard Entry Class codes (US)](/en/resources/codelists/nacha-sec): All 23 NACHA Standard Entry Class codes - the three letters at positions 51-53 of an ACH batch header saying what kind of entry it is: PPD (consumer payroll or preauthorized debit), CCD (business payment), CTX (business payment with EDI remittance, up to 9999 addenda), WEB (authorized online), TEL (authorized by phone, debits only), ARC/BOC/POP (cheque conversion), RCK, IAT (international), and the 6 non-monetary zero-dollar codes COR, ACK, ATX, ADV, DNE, ENR. The code decides the authorization you must hold and the return window: 60 calendar days for a consumer disputing an unauthorized PPD/WEB/TEL debit, against the opening of the second banking day for a business under CCD/CTX. There are 23 codes, not 13 (a widely-copied error); CBR and PBR no longer exist (replaced by IAT); TRC is "Check Truncation Entry" and ACK is "ACH Payment Acknowledgment" - both routinely mis-titled elsewhere. JSON: /data/codelists/nacha-sec.json.

## Compliance deadlines (countdown + checklist + validator)

- [Compliance deadlines](/en/deadlines): The regulatory dates that change what a financial file must contain. Each page gives a live countdown, exactly who is affected, the phase-by-phase timeline, what happens if you are not ready, an actionable checklist, and the free browser-based validator that proves a real file passes.
- [France - the 1 September 2026 e-invoicing deadline](/en/deadlines/france-2026): On 1 September 2026, RECEIVING a structured e-invoice becomes mandatory for EVERY VAT-registered business in France, whatever its size - there is no threshold. On the SAME date, large enterprises AND mid-sized companies (ETI) must also ISSUE e-invoices and transmit e-reporting. SMEs and micro-enterprises follow on 1 September 2027. A widespread misreading puts ETI issuing in 2027: it does not. B2B invoices are exchanged through an approved platform (PDP); the 2026 Finance Act dropped the public portal (PPF) as an exchange platform, and Chorus Pro remains the B2G portal. The DGFiP denied any postponement on 12 June 2026. Penalties: 50 EUR per invoice not issued electronically, 500 EUR per missing e-reporting transmission, each capped at 15,000 EUR a year. Formats: Factur-X, UBL 2.1 or CII, all carrying EN 16931. Source: DGFiP (impots.gouv.fr).
- [SEPA - the 15 November 2026 structured-address deadline](/en/deadlines/sepa-structured-address-2026): From 15 November 2026 (EPC153-22 v2.1), an address carried on a SEPA payment must be structured (town name + country, no free-text address lines) or hybrid (town name + country + at most two address lines of 70 characters). The trigger is the execution date INSIDE the file (ReqdExctnDt / ReqdColltnDt), never today's date - so a file dated after the cut-off is already rejected today, and one dated before it only warns. The rule covers the payer (Dbtr) and the payee (Cdtr); an absent address is fine. Not to be confused with the SWIFT CBPR+ migration, which concerns interbank pacs.* messages on a different rail. ValidateFin's SEPA validator already enforces this rule against your file's own execution date.

## Payment rejection codes — SEPA (pain.002) and ACH/NACHA (US)

- [Payment rejection codes](/en/errors): 109 codes across BOTH sides of the Atlantic, one page each, in 8 languages: 36 SEPA reason codes (ISO 20022 ExternalStatusReason1Code, carried by a pain.002 status report) and 73 US ACH return codes (NACHA, carried by an Addenda 99 record). Every page states what the code means, its typical causes, a worked example of the code inside the real file it arrives in, how to fix it — and, above all, whether the rejection is RECOVERABLE (fix the cause and the same payment can be re-sent) or FINAL (re-sending will fail again). That verdict is the part no official source publishes. SEPA: 21 recoverable / 15 final. ACH: 23 recoverable / 50 final. Machine-readable index with all 8 languages: /data/errors/index.json (CC-BY-4.0). No other free tool covers European AND US rejection codes together.

### SEPA — pain.002 reason codes (36)
- Met most often: [AC04 account closed](/en/errors/ac04) (final - get a new IBAN from the beneficiary), [AM04 insufficient funds](/en/errors/am04) (recoverable - top up and resubmit unchanged), [MD01 no valid mandate](/en/errors/md01) (final - a SEPA mandate lapses after 36 months without a collection), [AC01 incorrect account number](/en/errors/ac01) (recoverable - the IBAN is malformed), [MS03 reason not specified by bank](/en/errors/ms03) (final - the bank gave no reason; ask it), [AG01 transaction forbidden](/en/errors/ag01) (final).
- Grouped by cause: account (AC01, AC02, AC03, AC04, AC06, AC13, AC14, AC16), amount (AM04, AM05, AM09, AM18), mandate - direct debits only (MD01, MD02, MD06, MD07), references and identifiers (RC01, RC03, RC04, BE04, BE05), regulatory (AG01, AG02, RR01, RR02, RR03, RR04), technical and format (FF01, FF05, DT01, DU01, NARR), other (CUST, MS02, MS03, SL01).
- The exhaustive raw ISO 20022 list (302 codes, English labels only, no advice) is published separately as a table at /en/resources/codelists/iso20022-status-reason - deliberately NOT as 302 thin pages.
- Related tool: paste a real pain.002 into the [pain.002 reader](/en/tools/pain002) and every reason code it decodes links straight to its page. 100% client-side, nothing uploaded.

### United States — ACH / NACHA return codes (73)
- Met most often: [R01 insufficient funds](/en/errors/r01) (recoverable - may be reinitiated up to 2 times within 180 days, with 'RETRY PYMT' in the Company Entry Description), [R02 account closed](/en/errors/r02) (final), [R03 no account / unable to locate account](/en/errors/r03) (final as sent), [R10 customer advises originator not known / not authorized](/en/errors/r10) (final - needs a Written Statement of Unauthorized Debit; 60 calendar days), [R07 authorization revoked by customer](/en/errors/r07) (final), [R29 corporate customer advises not authorized](/en/errors/r29) (final - 2 banking days, the corporate analogue of R10).
- **R11 is the trap**: several public sources — Stripe's included — describe it as a "Checksum Abbreviation Error". That is flatly wrong. [R11](/en/errors/r11) is "customer advises entry not in accordance with the terms of the authorization", and since 2020 the Originator MAY send a corrected entry within 60 days WITHOUT a new authorization. It is the one unauthorized-family code that is recoverable. Getting it wrong inverts the advice.
- Every ACH page also states the RETURN WINDOW the RDFI had (2 banking days for the administrative returns, 60 calendar days for the consumer-dispute ones, 5 banking days for a dishonored return) and the exact reinitiation rule.
- Grouped by cause: funds, account, authorization and disputes, administrative, routing, data and format, other.
- **Provenance**: the official NACHA Operating Rules book is a paid publication and was never consulted. This reference was assembled from public documentation (Dwolla, Modern Treasury, Increase, Federal Reserve and bank/credit-union operations manuals), and EVERY code lists the sources it was checked against. R44 was sourced but deliberately left unpublished: sources disagreed on its title and the corroborating one proved unreliable — better 73 solid codes than 74 with a guess. R48-R49, R54-R60 and R78-R79 do not exist.
- Related tool: the [ACH / NACHA file validator](/en/tools/ach) checks a 94-character fixed-width ACH file (record structure, ABA check digit, entry hash, batch and file control totals) entirely in the browser.

## Sample files (SEPA / camt / UBL / MT940 / Factur-X test files)

- [Sample file library](/en/resources/samples): 106 downloadable example files (CC-BY-4.0) for every format ValidateFin validates - valid ones to start from, deliberately broken ones to test against. Each page states the exact verdict the matching validator returns, and that verdict is asserted by an automated test on every build, so a file that stopped matching its page would fail the build. Machine-readable index: /data/samples/index.json.
- [E-invoicing mandate matrix](/en/e-invoicing/mandates): B2G, B2B and e-reporting obligations across 32 European jurisdictions (the EU-27 plus the UK, Norway, Switzerland, Iceland and Liechtenstein), each row backed by a government or EU source - never a vendor blog. Corrects the dates the vendor maps get wrong (Slovenia is 1 January 2028, not June 2026; Hungary has NO B2B mandate, only RTIR data reporting; Spain has no legally fixed B2B date yet). Where no official source could be found, the status is "unverified" rather than a guess. Machine-readable, CC-BY-4.0: /data/e-invoicing/mandates.json.
- [pain.001 credit transfer samples](/en/resources/samples): pain.001.001.03 valid (3 transfers, 1580.00 EUR), pain.001.001.09 valid with the hybrid postal address allowed by EPC153-22 v2.1, plus deliberate defects: CtrlSum mismatch, IBAN failing mod-97, NbOfTxs mismatch, and an unstructured address with ReqdExctnDt after the 2026-11-15 EPC cut-off (a blocking error; move the date earlier and the same file downgrades to a warning).
- [pain.008 direct debit samples](/en/resources/samples/sepa-pain008-v02-valid): pain.008.001.02 valid CORE (2 collections, 175.00 EUR, ICS passing ISO 7064 MOD 97-10), pain.008.001.08 valid CORE collected on 2026-11-20 - i.e. after the EPC structured-address cut-off, so every creditor and debtor address is structured - and a mandate signed after the collection date (DtOfSgntr 2026-04-10 > ReqdColltnDt 2026-03-05). Every pain.* and camt.* sample is validated against the official ISO 20022 XSD, not only the business rules.
- [camt.053 statement samples](/en/resources/samples/camt053-v02-valid): camt.053.001.02 and camt.053.001.08 valid statements with reconciling balances, plus an unsupported namespace (camt.053.001.99) and a file whose mandatory Stmt element is missing.
- [UBL / Peppol invoice samples](/en/resources/samples/ubl-invoice-valid): valid Peppol BIS Billing 3.0 invoice and credit note, plus a BR-CO-10 violation (sum of line net amounts != BT-106) and a malformed seller VAT identifier.
- [MT940 samples](/en/resources/samples/mt940-rabobank-deutsche): 8 SWIFT MT940 files covering the bank dialects that break parsers - ING Belgium structured :86: subfields, Commerzbank one-decimal amounts, ABN AMRO RC reversals, two statements in one file, overdrawn account with D balances, a non-reconciling closing balance (a warning, not an error), and a 500-transaction load test.
- [Factur-X / ZUGFeRD samples](/en/resources/samples/facturx-en16931-valid): PDF/A-3 invoices with embedded CII XML at the EN 16931 profile - one conformant, one violating BR-CO-15 (total with VAT 130.00 while net + VAT = 120.00).

## Bank directory

- [Bank directory](/en/banks): Directory of 1228 banks across 37 IBAN countries, with their BIC/SWIFT codes and national bank identifiers, searchable and grouped by country. Each country page lists the banks whose codes appear in that country's IBAN structure.

## Glossary

- [Financial format glossary](/en/glossary): 91 defined terms across SEPA, ISO 20022, UBL/Peppol, EN 16931, IBAN and US/Canada formats (e.g. BAI2, BBAN, BIC, camt.053, EndToEndId, Leitweg-ID, mandate, PDF/A-3, remittance information, reverse charge, Peppol access point). Each term is a citable DefinedTerm.

## E-invoicing mandates by country

- [E-invoicing mandates in Europe](/en/e-invoicing): Country-by-country guide to B2B e-invoicing obligations (dates, formats, platforms). Covers [Belgium](/en/e-invoicing/belgium), [France](/en/e-invoicing/france), [Germany](/en/e-invoicing/germany), [Italy](/en/e-invoicing/italy), [Spain](/en/e-invoicing/spain), [Poland](/en/e-invoicing/poland), [Romania](/en/e-invoicing/romania).

## MCP server (use ValidateFin from an AI assistant)

- [ValidateFin MCP server](/en/mcp): A free, open-source Model Context Protocol server that lets AI assistants (Claude, Copilot, Cursor…) run the validators directly, 100% locally.
- npm package: `@validatefin/mcp` — install with `npx -y @validatefin/mcp`.
- Tools exposed (28): `validate_sepa`, `validate_ubl`, `validate_xrechnung`, `validate_ksef` (Polish KSeF FA(3)), `validate_efactura` (Romanian RO e-Factura — the official CIUS-RO Schematron of the Ministry of Finance, the OASIS UBL 2.1 XSD, and the CUI/CNP check ANAF runs outside the Schematron), `validate_verifactu` (Spanish Verifactu / SIF — the official AEAT XSD plus the published AEAT rejection controls, and the chained SHA-256 *huella* recomputed against the AEAT's own test vectors), `validate_facturae` (Spanish Facturae — the official facturae.gob.es XSD for versions 3.2/3.2.1/3.2.2, plus coherence controls derived from the schema's own formulas, the NIF form and the presence of the XAdES signature; the B2G format used with FACe), `validate_fatturapa` (Italian FatturaPA — official AdE XSD plus the SdI rejection controls, signed .p7m envelopes supported), `validate_camt`, `validate_fedwire` (Fedwire Funds Service ISO 20022 — official XSDs plus the hybrid-address rule of 16 Nov 2026), `read_mt103` (SWIFT MT103 → structured JSON, field specs from the ECB TARGET2 UDFS), `validate_ach` (US ACH/NACHA, including returns, notifications of change and IAT), `validate_cpa005` (Canadian CPA-005 / AFT, 1464-character records), `validate_iban`, `validate_aba` (US routing number), `validate_coda` (Belgian CODA, Febelfin), `validate_cfonb` (French CFONB 120 / AFB120), `validate_epc_qr` and `generate_epc_qr` (EPC QR code for a SEPA credit transfer, EPC069-12), `validate_swiss_qr` (Swiss QR-bill), `generate_camt_test`, `convert_mt940` (MT940 → camt.053), `convert_bai2` (BAI2 → camt.053), `convert_coda` (CODA → camt.053), `convert_cfonb` (CFONB 120 → camt.053), `convert_camt_to_mt940` (camt.053 → SWIFT MT940 — the reverse direction, booked entries only, SWIFT charset folding and reference truncation reported as warnings), `convert_camt_to_csv` (camt.052/053/054 → CSV, one row per entry, currency-correct decimals), `sepa_dates` (SEPA settlement date, D-1 presentation deadline, return and refund windows, TARGET closing days — sourced from the ECB calendar and the 2025 EPC rulebooks).

## Blog

- [SEPA Direct Debit timings: D-1, pre-notification, returns and refunds](/en/blog/sepa-direct-debit-timings): The presentation and settlement deadlines of the SDD Core and B2B schemes, quoted from the 2025 EPC rulebooks (EPC016-06 v1.1 and EPC222-07 v1.1, both issued 5 October 2025). D-1 applies to one-off, first and recurrent collections alike — the FRST/RCUR split stopped applying in November 2016 with rulebook version 9.0. Explains the difference between the Inter-PSP Business Day (the TARGET calendar, computable) and the Banking Business Day (per country and per bank, not computable), why a due date on a closed day is not an error, and the three things no calculator can answer: bank cut-offs, national bank holidays and post-dating limits.
- [ACH return codes: the complete R01-R85 reference](/en/blog/ach-return-codes): The 70 ACH return codes that officially exist, checked against Nacha's ISO 20022 mapping guide, the Federal Reserve's ACH Return Reason Report and the US Treasury Green Book. Debunks R63-R66 (not return codes at all: they are R69 addenda sub-codes) and the widespread mislabelling of R11.
- [Fedwire and ISO 20022, one year on](/en/blog/fedwire-iso20022-one-year-later): The 14 July 2025 single-day migration, what changed in the message (mandatory BAH, mandatory UETR, camt.052 only), what the Federal Reserve reports breaking in production, and the second mandatory cutover on 16 November 2026.
- [Validate your Factur-X before 1 September 2026: the checklist](/en/blog/facturx-checklist-september-2026)
- [SEPA structured addresses: the 15 November 2026 deadline for pain.001 and pain.008](/en/blog/sepa-structured-address-2026)
- [SEPA Instant (SCT Inst): the 2025 instant credit transfer explained](/en/blog/sepa-instant-credit-transfer)
- [Verification of Payee (VoP): the 2025 SEPA name check explained](/en/blog/verification-of-payee-sepa)
- [BAI2 to camt.053: how to read and convert US & Canadian bank statements in 2026](/en/blog/bai2-to-camt053)
- [MT940 to camt.053: how to read and convert SWIFT bank statements in 2026](/en/blog/mt940-to-camt053)
- [ACH file format explained: NACHA records, routing check digit and control totals](/en/blog/ach-nacha-file-format)
- [Validate invoices from your AI assistant — the ValidateFin MCP server](/en/blog/mcp-server-einvoicing)
- [Guide to the SEPA pain.001 format](/en/blog/sepa-pain001-guide)
- [Electronic invoicing with UBL 2.1 and Peppol BIS 3.0](/en/blog/ubl-peppol-invoicing)
- [E-invoicing in Europe 2026](/en/blog/e-invoicing-europe-2026)
- [EN 16931 complete guide](/en/blog/en16931-complete-guide)
- [IBAN validation: mod-97 checksum explained](/en/blog/iban-validation-guide)
- [Understanding camt.053 bank statements](/en/blog/camt053-bank-statement)
- [Factur-X and ZUGFeRD hybrid PDF invoices explained](/en/blog/facturx-zugferd-explained)

- [EN 16931 Mandatory Fields: Required Invoice Fields and Their Formats](/en/blog/en16931-mandatory-fields)
- [Peppol BIS Billing 3.0 Business Rules: The Complete Reference](/en/blog/peppol-bis-billing-rules)
- [8 Common IBAN Errors That Cause Payment Rejection - and How to Fix Them](/en/blog/common-iban-errors)
- [10 Common Factur-X / ZUGFeRD Errors and How to Fix Them](/en/blog/common-facturx-errors)
- [SEPA Direct Debit Guide 2026: pain.008, Mandates & Validation](/en/blog/sepa-direct-debit-guide)
- [IBAN Format by Country: Complete Reference Guide for All 36 SEPA Countries](/en/blog/iban-format-by-country)
- [Camt.052 vs Camt.053 vs Camt.054: What's the Difference?](/en/blog/camt-052-vs-053-vs-054)
- [E-invoicing in Belgium: The Complete Guide to the 2026 B2B Mandate](/en/blog/e-invoicing-belgium-guide)
- [ISO 20022 Migration Guide: Everything You Need to Know](/en/blog/iso20022-migration-guide)
- [XRechnung - Complete Guide to German E-Invoicing](/en/blog/xrechnung-guide)
- [Chorus Pro - Complete Guide to French E-Invoicing Platform](/en/blog/chorus-pro-guide)
- [Factur-X Profiles Explained - From MINIMUM to EXTENDED](/en/blog/facturx-profiles-explained)
- [The Peppol Network - A Complete Guide to European E-Invoicing Infrastructure](/en/blog/peppol-network-complete-guide)
- [Fix Common UBL & Peppol BIS 3.0 Errors: Causes & Examples](/en/blog/common-ubl-peppol-errors)
- [UBL vs CII vs Factur-X - Comparing European E-Invoice Formats](/en/blog/ubl-vs-cii-vs-facturx)
- [pain.001 vs pain.008 - SEPA Credit Transfer vs Direct Debit Explained](/en/blog/pain-001-vs-pain-008)
- [15 Common SEPA XML Errors and How to Fix Them](/en/blog/common-sepa-xml-errors)
- [CSV to SEPA XML Converter: generate pain.001 from a spreadsheet](/en/blog/csv-sepa-converter-guide)
- [XML validation: 5 common mistakes and how to fix them](/en/blog/xml-validation-best-practices)
## Key facts

- 100% free, no registration required
- GDPR compliant — all processing is done locally in the browser; no data stored or transmitted
- Open-source MCP server available on npm (`@validatefin/mcp`)
- Supports 8 languages: English, French, Dutch, German, Spanish, Italian, Portuguese, Polish
- Standards supported: EPC SEPA schemas, ISO 20022 (camt.053), UBL 2.1, UN/CEFACT CII, Peppol BIS 3.0, EN 16931, XRechnung (KoSIT BR-DE), KSeF FA(3) (Poland), ISO 13616, ISO 11649 (RF creditor reference), Factur-X / ZUGFeRD, ACH / NACHA (US), ABA routing number (US), SWIFT MT940, BAI2 (Bank Administration Institute, US/Canada), CODA (Febelfin, Belgium), CFONB 120 / AFB120 (France)

## Optional

- Full content: /llms-full.txt