# ValidateFin — Full Content

> Free, privacy-first online tools to validate and convert financial files: SEPA (pain.001/pain.008/pain.002), UBL/Peppol & XRechnung e-invoices, ISO 20022 camt.053, IBAN, Factur-X/ZUGFeRD, the national bank-statement formats of Belgium (CODA, Febelfin) and France (CFONB 120 / AFB120), plus US & Canada formats (ACH/NACHA including returns, notifications of change and IAT; the Canadian CPA-005 / AFT payment file; ABA routing numbers; SWIFT MT940; BAI2), and the payment QR codes of Europe (EPC069-12) and Switzerland (Swiss QR-bill). All processing is done client-side — no data is ever uploaded to a server.

## About ValidateFin

ValidateFin is a free web application built by Elni Consulting, a Belgian digital agency founded in 2024 and based in Ramillies (Brabant Wallon, Belgium). The project was created to help finance professionals, developers, and businesses across Europe work more efficiently with ISO 20022, SEPA, and e-invoicing standards.

All processing is done locally in the user's browser. No financial data, XML files, or personal information is ever sent to a server. ValidateFin is fully GDPR compliant.

ValidateFin is available in 8 languages: English, French, Dutch, German, Spanish, Italian, Portuguese, and Polish.

## Tools — Detailed descriptions

### SEPA Validator
URL: /en/tools/sepa

Validates SEPA XML payment files against the official ISO 20022 XSD schemas and the EPC (European Payments Council) Rulebook business rules.

Supported formats:
- pain.001.001.03 — Customer Credit Transfer Initiation (bank transfers)
- pain.008.001.02 — Customer Direct Debit Initiation (direct debits)

What it checks:
- XSD schema compliance
- Mandatory field presence (e.g., MsgId, CreDtTm, PmtInfId, EndToEndId)
- IBAN format and check digit validity
- BIC/SWIFT format
- Payment amount consistency
- Payment information block integrity

Output: validation result (valid/invalid), list of errors with descriptions, extracted transaction list (creditor name, IBAN, amount, remittance info), PDF export.

### pain.002 Status Report Reader
URL: /en/tools/pain002

Reads a SEPA Payment Status Report (pain.002 — Customer Payment Status Report) returned by the bank in response to a pain.001 or pain.008 submission.

Supported formats:
- pain.002.001.03 and later — Customer Payment Status Report

What it does:
- Extracts the group status, and the status of each payment and each individual transaction (ACCP, RJCT, PDNG, ACSP…)
- Decodes every ISO 20022 reason code (AC04 closed account, AM04 insufficient funds, MD01 no mandate, etc.) into a plain-language explanation
- Localizes the code descriptions in all 8 site languages

Output: the parsed status tree (group / payment / transaction) with each rejection reason code explained. 100% client-side — the status report never leaves the browser.

### UBL / Peppol Invoice Validator
URL: /en/tools/ubl

Validates UBL 2.1 electronic invoices and credit notes against two layers of rules:
1. XSD schema validation (document structure and data types)
2. Peppol BIS Billing 3.0 business rules (EN 16931 standard)

Supported document types:
- UBL 2.1 Invoice
- UBL 2.1 Credit Note

Business rule checks include:
- VAT consistency (line items vs. document total)
- Mandatory supplier and buyer fields
- Line item subtotals and document total reconciliation
- Date validity
- Currency consistency

This tool is suitable for testing e-invoicing compliance in all EU member states under the EN 16931 European standard. It accepts both the UBL and the UN/CEFACT CII syntaxes (the syntax is detected automatically).

### XRechnung Validator
URL: /en/tools/xrechnung

Validates a German XRechnung e-invoice — the German CIUS (Core Invoice Usage Specification) of EN 16931, mandatory for invoicing public authorities (B2G) in Germany and increasingly used in B2B.

Runs two rule sets:
1. The official EN 16931 core Schematron
2. The official KoSIT XRechnung Schematron (BR-DE rules) — the same rule sets used by the official German validator

Supported syntaxes: UBL 2.1 and UN/CEFACT CII (Invoice and Credit Note).

Common German-specific rules checked: Buyer reference / Leitweg-ID (BR-DE-15), payment instructions (BR-DE-1), seller contact (BR-DE-2), specification identifier (BR-DE-21).

100% client-side — no invoice data is ever uploaded.

### Fedwire ISO 20022 Validator (United States)
URL: /en/tools/fedwire
The Fedwire Funds Service — the USD real-time gross settlement system operated by the Federal Reserve — migrated to ISO 20022 in a single big-bang on 14 July 2025. A Fedwire message is a PAIR: one Business Application Header (head.001.001.03) plus one payment document, drawn from six pinned versions: pacs.008.001.08 (customer credit transfer), pacs.009.001.08 (financial institution credit transfer), pacs.004.001.10 (payment return), pacs.028.001.03 (payment status request), camt.056.001.08 (cancellation request), camt.029.001.09 (resolution of investigation).

Validation layers:
1. The OFFICIAL ISO 20022 XSDs, from the iso20022.org catalogue. The header and the document are separate schemas in separate namespaces, so each is validated against its own.
2. The hybrid postal address the Federal Reserve requires from 16 NOVEMBER 2026. In its own words: "Remove the fully unstructured postal address option in favor of a single hybrid postal address format for all parties and agents across all message types (i.e., remove three free-text lines of 35 characters each, require town name and country, and allow the option to include other structured address elements such as two free-text lines of up to 70 characters each)." Note the scope — ALL PARTIES AND AGENTS — which is WIDER than the SEPA rule of 15 November 2026, which the EPC limits to the debtor and the creditor. The trigger is the settlement date carried by the message, never the current date: a message settling before the cut-over is warned about, not failed.
3. The ABA 3-7-1 check digit of every USABA routing number. A routing number that fails it cannot exist, so we speak only on failure.
4. Coherence between the header and the document it carries (MsgDefIdr vs the actual message).

WHAT IT DOES NOT DO, AND SAYS SO: it cannot tell you whether Fedwire would accept a message. The Fedwire Usage Guidelines (mandatory UETR, LclInstrm codes, settlement method) are published on Swift MyStandards behind a login, and the Fed's proprietary XSDs go only to FedLine customers. The participant directory, OFAC screening, duplicate detection and cut-off times all need live data. Every one of these is listed by name in the response and in the UI rather than hidden behind a green badge.

### MT103 Viewer (SWIFT)
URL: /en/tools/mt103
MT103 is the SWIFT Single Customer Credit Transfer — the most widely used customer payment order in the world. This tool decodes it locally: the five SWIFT blocks ({1:} basic header, {2:} application header, {3:} user header with the UETR in tag 121, {4:} the message, {5:} trailer), every field of the text block with a plain-language label, and the parsed parties with account and BIC kept apart.

Checks performed: the mandatory fields (:20: sender's reference, :23B: bank operation code, :32A: value date + currency + settled amount, :50a: ordering customer, :59a: beneficiary, :71A: details of charges), the format of :32A:, the closed OUR/SHA/BEN list of :71A:, the mod-97 check digits of an IBAN beneficiary, the format of option-A BICs, and the version-4 UUID form of the UETR.

SOURCE: the field specifications come from the European Central Bank, TARGET2 User Detailed Functional Specifications (UDFS), Book 1, v15.0 (26 March 2021), §9.1.2 — a public, free document. The SWIFT MT Message Reference Guide is copyrighted and licensed, and is not used.

WHAT IT DOES NOT DO, AND SAYS SO: the SWIFT Network Validated Rules (C1-C18 — how :71A: interacts with :71F:/:71G:, when :33B: becomes mandatory in the EEA, what :23B: codes permit) live in the SWIFT User Handbook, which is not freely available, and are NOT verified. TARGET2-specific restrictions are deliberately NOT applied: they would reject valid messages sent over other rails.

CONTEXT 2026: the MT / ISO 20022 coexistence on CBPR+ ended on 22 November 2025, so MT103 is retired for cross-border interbank traffic and replaced by pacs.008. It remains in wide use domestically, bank-to-corporate and host-to-host.

### RO e-Factura Validator (Romania)
URL: /en/tools/efactura

Validates a Romanian electronic invoice (RO e-Factura / RO_CIUS) and answers the only question that matters: WOULD ANAF REJECT THIS FILE, AND ON WHICH RULE?

Romania has run mandatory B2B e-invoicing through the ANAF clearing platform (the SPV) since 1 July 2024, and B2C since 1 January 2025. An invoice the platform rejects is legally not issued. The format is RO_CIUS, a national CIUS of the European standard EN 16931, carried in OASIS UBL 2.1 — Invoice (validated as FACT1) or CreditNote (FCN).

Validation layers, in the order ANAF itself applies them:
1. The OASIS UBL 2.1 XSD. Romania publishes NO schema of its own: its official validator validates against the standard OASIS schemas, which we embed from that very binary. This layer catches what no business rule can see — an element in the wrong order, a malformed date — and ANAF rejects on it before running anything else.
2. The OFFICIAL CIUS-RO Schematron published by the Romanian Ministry of Finance (ro16931-ubl-1.0.9, in force since 5 June 2024, https://mfinante.gov.ro/static/10/eFactura/ro16931-ubl-1.0.9.zip). Not a reimplementation: the ministry's own file, compiled and executed as published. It is self-contained — it carries the EN 16931 core rules (BR-*, BR-CO-*, BR-CL-*) as well as the Romanian ones — and its messages are the Romanian ones the SPV quotes back. Key BR-RO rules: BR-RO-001, the CustomizationID (BT-24) must be exactly urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1 (the value ending in 1.0.0 was retired on 29 December 2022 by order OMF 4092/2022 and is the single most common rejection); BR-RO-020, the invoice type code (BT-3) must be 380, 384, 389 or 751 on an Invoice — 381 is accepted only on a CreditNote, although the rule's own message lists all five together; BR-RO-030, RON must appear as the invoice currency (BT-5) or as the VAT accounting currency (BT-6); BR-RO-100/101/160/202, when the country is RO and the subdivision is RO-B (Bucharest) the city must be spelled SECTOR1…SECTOR6 — uppercase, no space — even though the ministerial order itself writes "Sector 1"; BR-RO-081/082/091/092, street and city are mandatory for both parties; BR-RO-110/111/170/212, the ISO 3166-2:RO subdivision is mandatory whenever the country is RO; and the BR-RO-L* maximum-length rules.
3. The fiscal-identity check — the layer almost every free tool misses. The check digit of the CUI (the Romanian tax number, BT-31/BT-30 for the seller, BT-48/BT-47 for the buyer) and the CNP/NIF are NOT part of the Schematron: ANAF verifies them separately and rejects the invoice under a code of its own, ERRIdentif, with the messages "CUI vanzator incorect", "CUI cumparator incorect", "CNP sau NIF vanzator incorect", "nu a fost identificat cui cumparator". A validator that runs only the Schematron therefore declares valid a file ANAF will refuse.

Three facts about the CUI and the CNP that are published nowhere and were established by running the Ministry's own offline validator (ROeFacturaValidator v1.3.0) as an oracle on ~80 purpose-built invoices:
- The CNP is not just a checksum: its encoded DATE OF BIRTH must exist. 1902030405064 has a perfectly correct check digit and ANAF rejects it — its month is 20. A 29 February is accepted only in a genuinely leap year, and the century is read from the leading digit (1/2 → 1900s, 3/4 → 1800s, 5/6 → 2000s, 7/8 → 1900s).
- A NIF (leading digit 9, the number issued to a non-resident) encodes NO date, and ANAF exempts it from that test entirely: 9801301221147, whose "month" is 13, is accepted. Applying the calendar to it would reject legitimate non-residents.
- The county code inside a CNP is NOT checked (00, 47, 53 and 99 are all accepted although none is a Romanian county), and the anonymous B2C identifier 0000000000000 — in production since 16 December 2024 — is valid and must never be rejected.
The CUI check is purely arithmetic: a well-formed but non-existent number is accepted at validation. Passing does not mean the company exists.

What this tool CANNOT check, and says so explicitly rather than implying a clean bill of health: everything that needs ANAF's own systems — the authentication of the depositor and the fact that the seller's CUI matches the certificate used to deposit; the actual registration of the parties in the taxpayer registry; the transmission deadline (5 working days since 1 January 2026, 5 calendar days before that), which is not a property of the file. Note also that BR-RO-230 (the 3 MB cap on attachments) appears in the ministerial order but NOT in Schematron 1.0.9, so the official validator does not enforce it.

CII is refused rather than simulated: RO_CIUS does cover the UN/CEFACT CII syntax, but the Ministry publishes neither a Schematron nor a validator for it — both of its official tools accept UBL only — so ANAF's verdict on a CII file cannot be faithfully reproduced.

Verified, not assumed: the compiled Schematron was confronted with the Ministry's official offline validator on 78 invoices and fired exactly the same rules on all 78. Both example invoices the Ministry publishes on mfinante.gov.ro (eInvoice_ex.xml, creditNote_ex.xml) are REJECTED by the Ministry's own validator: they still declare CIUS-RO:1.0.0.

100% client-side — no invoice data is ever uploaded.

### Verifactu Validator (Spain)
URL: /en/tools/verifactu

Validates a Spanish Verifactu / SIF billing-record submission (RegFactuSistemaFacturacion) and answers the only question that matters: WOULD THE AEAT REJECT THIS FILE, AND WITH WHICH CODE?

Verifactu is not an invoice format in the UBL sense. Under Real Decreto 1007/2023 and Orden HAC/1177/2024, a Spanish billing system (Sistema Informatico de Facturacion, SIF) produces immutable BILLING RECORDS — a RegistroAlta when an invoice is issued, a RegistroAnulacion when one is voided — and either transmits them to the Agencia Tributaria (a VERI*FACTU system) or holds them for inspection. What the AEAT receives is that record, not the invoice document.

Validation layers:

1. The OFFICIAL AEAT XSD (SuministroLR.xsd + SuministroInformacion.xsd). Structure, cardinalities and the closed enumerations that are easy to get wrong by hand: TipoFactura (F1, F2, F3, R1-R5 — there is no F4), CalificacionOperacion (S1, S2, N1, N2), OperacionExenta (E1-E8, not E1-E6), Impuesto (01, 02, 03, 05 — there is no 04), ClaveRegimen (01-11, 14, 15, 17-21 — 12, 13 and 16 do not exist), TipoHuella (01 only). Dates are DD-MM-AAAA, not ISO.

2. The controls the AEAT publishes in "Validaciones y errores" v1.2.2 (8 April 2026), each quoted with its verbatim Spanish label and its official code — because that code is what the emitter will see in the AEAT's reply. Among them: 1108 (IDEmisorFactura must equal ObligadoEmision), 1114/1115 (TipoRectificativa is required on a rectifying invoice and forbidden otherwise), 1116/1117/1118/1119 (the rectifying and substituting blocks), 1130 (the characters " ' < = > are forbidden in NumSerieFactura), 1138/1139 (Macrodato is mandatory above 100,000,000 EUR), 1142 (CuotaRepercutida must equal base x rate, tolerance +/-10 EUR), 1152 (no invoice may be dated before 28 October 2024), 1177 (IdSistemaInformatico is exactly 2 characters), 1189/1190 (Destinatarios is mandatory on F1/F3/R1-R4 and forbidden on the simplified F2/R5), 1195/1196 (CalificacionOperacion and OperacionExenta are mutually exclusive, and one is required), 1223 (SistemaInformatico carries a NIF or an IDOtro, never both).

WHAT MAKES THIS TOOL DIFFERENT: IT RECOMPUTES THE HUELLA.

Every billing record carries a SHA-256 fingerprint — the "huella" — computed over a string that INCLUDES THE FINGERPRINT OF THE PREVIOUS RECORD. That chaining is the whole point of the Spanish regime: altering an old invoice breaks every fingerprint after it, and the tampering becomes visible. No one can verify a chain without redoing the arithmetic, and a file whose chain is broken is perfectly valid XML against the official schema. A schema-only validator — which is what most free tools are — hands it a clean bill of health.

Our implementation reproduces, character for character, the three official test vectors published in the AEAT's hash specification ("Detalle de las especificaciones tecnicas para generacion de la huella o hash", v0.1.2, 27 August 2024): the field order, the & and = separators, the empty-value convention, UTF-8 encoding, and uppercase hexadecimal output. The fields of a RegistroAnulacion are NOT the fields of a RegistroAlta — their keys carry the "Anulada" suffix and no amounts appear at all.

A COUNTER-INTUITIVE RULE, AND IT IS SOURCED: a wrong huella is NOT a rejection. It is code 2000, and the 2xxx series means "Aceptado con errores" — the AEAT RECORDS the entry anyway, and the emitter must correct it. Treating it as an error would misstate what the tax agency will do with the file. The tool therefore follows the AEAT's own taxonomy: series 1xxx/3xxx/4xxx are rejections, series 2xxx are warnings.

WHAT IT CANNOT CHECK, AND SAYS SO. Roughly half of the AEAT's controls need a registry, a history or a certificate, and the tool lists them by code rather than hiding them behind a green badge: the NIF against the AEAT censo (1109/4107 — the AEAT does not verify a checksum, it queries its register, which is why no NIF check digit is computed here; no official Spanish text publishes that algorithm), duplicate records (3000), the history of previous submissions (2007), the registry of billing agreements (1128) and of declared systems (1242), the signing certificate (4112), and the clock tolerance on FechaHoraHusoGenRegistro (2004) — whose numeric threshold the AEAT publishes nowhere, its official label stopping literally at "admitiendose un margen de error de:".

100% client-side: the file never leaves the browser. Independent tool — not certified, approved or endorsed by the Agencia Tributaria. Schemas and control lists: Origen de los datos: Agencia Estatal de Administracion Tributaria, downloaded 13 July 2026.

### Facturae Validator (Spain)
URL: /en/tools/facturae

Validates a Spanish Facturae electronic invoice — the official format for invoicing public administrations (B2G), mandatory through FACe since law 25/2013, and one of the accepted formats for the B2B e-invoicing obligation now being phased in. A Facturae file is a single XML document, digitally signed with a recognised electronic certificate (XAdES), organised as FileHeader (SchemaVersion, Modality, InvoiceIssuerType, Batch) + Parties (SellerParty, BuyerParty) + Invoices (one or more Invoice) + an optional Extensions block + the ds:Signature.

The tool validates in two layers. LAYER 1 is the OFFICIAL XSD published by facturae.gob.es (Ministerio de Hacienda / Ministerio de Asuntos Económicos y Transformación Digital). Three versions coexist, each with its own namespace, and the validator picks the matching schema from the root element: 3.2 (http://www.facturae.es/Facturae/2009/v3.2/Facturae), 3.2.1 (http://www.facturae.es/Facturae/2014/v3.2.1/Facturae) and 3.2.2 (http://www.facturae.gob.es/formato/Versiones/Facturaev3_2_2.xml). The schema imports the W3C xmldsig schema by an http:// URL; it is supplied to the validator in memory, since nothing here ever touches the network — the file never leaves the browser.

LAYER 2 is a set of COHERENCE controls, reported as warnings, never as "official" rejections — because Facturae/FACe, unlike Italy's SdI, publishes no numbered offline rejection list, and inventing one would be dishonest. The controls are derived from the schema's OWN documented formulas: line TotalCost = Quantity × UnitPriceWithoutTax; GrossAmount = TotalCost − discounts + charges; TotalGrossAmount = sum of line GrossAmounts; TotalGrossAmountBeforeTaxes = TotalGrossAmount − TotalGeneralDiscounts + TotalGeneralSurcharges; per-tax TaxAmount = TaxableBase × TaxRate; TotalTaxOutputs = sum of tax amounts (plus equivalence surcharge); InvoiceTotal = TotalGrossAmountBeforeTaxes + TotalTaxOutputs − TotalTaxesWithheld; and, at file level, InvoicesCount = number of invoices and TotalInvoicesAmount = sum of the InvoiceTotals. It also checks the FORM of the seller/buyer NIF/CIF/NIE (RD 1065/2007, Orden EHA/451/2008) — only to flag a shape that cannot exist, never a check digit, which no Spanish authority publishes — and whether a XAdES ds:Signature is present (the schema makes it optional, but FACe requires it, so its absence is a warning).

WHAT IT CANNOT CHECK, AND SAYS SO. The cryptographic validity of the XAdES signature (the certificate chain to a trusted CA, OCSP/CRL revocation, the Facturae signature policy) is NOT verified — that needs online trust services. Nor is the existence of the NIF in the AEAT censo, the DIR3 codes (oficina contable / órgano gestor / unidad tramitadora) against the DIR3 directory, or the FACe/FACeB2B registration status. These are listed on screen rather than hidden behind a green badge.

100% client-side: the file never leaves the browser, and validating here does not submit it to FACe. Independent tool — not certified, approved or endorsed by the Ministerio de Hacienda or facturae.gob.es. Official XSD schemas: Origen de los datos: Ministerio de Hacienda / facturae.gob.es, downloaded 13 July 2026.

### FatturaPA Validator (Italy)
URL: /en/tools/fatturapa

Validates an Italian electronic invoice (FatturaPA) and answers the only question that matters: WOULD THE SISTEMA DI INTERSCAMBIO REJECT THIS FILE, AND WITH WHICH CODE?

Italy has had mandatory e-invoicing since 2019 — B2B, B2C and B2G alike. Every invoice passes through the Sistema di Interscambio (SdI), the Agenzia delle Entrate's clearing house, which either forwards it or returns a "notifica di scarto" quoting one of its 63 numbered rejection codes. A rejected invoice is legally not issued; the sender has 5 days to correct and resend.

Validation layers:
1. The official Agenzia delle Entrate XSD (schema v1.2.3, in force since 1 April 2025, namespace http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2) — this is SdI control 00200, "File non conforme al formato". Note that the two XSD files the AdE publishes (Schema_VFPA12 for public administrations, Schema_VFPR12 for private parties) are BYTE-IDENTICAL: they differ only by the FormatoTrasmissione value inside the file. The simplified invoice (FSM10, art. 21-bis) has its own schema, namespace .../fatture/v1.0.
2. The SdI's own substantive controls, each reported with its official code and its verbatim Italian label, sourced from "Elenco dei controlli effettuati sul file fattura del SdI" v2.0 (31 January 2025): 00301/00302/00305/00306 (fiscal identifiers), 00400/00401/00429/00430 (Natura required for a zero VAT rate, forbidden otherwise), 00403 (future-dated invoice), 00409 (duplicate inside a lotto), 00411/00415 (Ritenuta without DatiRitenuta), 00417 (customer with no fiscal ID), 00418 (credit note predating its invoice), 00419/00443/00444 (a rate or Natura that reaches no DatiRiepilogo), 00420 (reverse charge with split payment), 00421 (Imposta), 00422 (ImponibileImporto), 00423 (PrezzoTotale), 00424 (rate as a fraction rather than a percentage), 00425 (invoice number with no digit), 00427 (CodiceDestinatario length vs FormatoTrasmissione), 00428, 00437/00438 (discount with no amount), 00445 (the generic N2/N3/N6 codes, withdrawn on 1 January 2021), 00471-00476 (TipoDocumento constraints, including the TD29 rule that v2.0 inverted).
3. The check digits of the partita IVA and the codice fiscale, per the Ministerial Decree of 23 December 1976 — including omocodia codes (art. 6), which are legally assigned and must be accepted.

Signed invoices: most real Italian invoices, and every invoice to a public administration, travel as a .xml.p7m — the XML wrapped in a binary CAdES envelope. The tool opens the envelope and validates the XML inside. The signature itself is NOT verified: that needs the trusted-CA list and an online revocation check (SdI controls 00100-00107), which is impossible without uploading the file. The tool says so rather than implying otherwise.

Three tolerances that are commonly got wrong, and are NOT uniform: control 00421 (Imposta) tolerates 1 CENT, control 00423 (PrezzoTotale) tolerates 1 CENT, but control 00422 (ImponibileImporto) tolerates 1 EURO. And <ImportoTotaleDocumento> is checked by NO SdI control at all — the string does not appear once in the Elenco dei controlli — so a discrepancy there is reported as an advisory, never as a rejection.

What this tool CANNOT check, and says so explicitly rather than implying a clean bill of health: roughly half of the SdI's rulebook queries a live government registry — the existence of a fiscal identifier in the Anagrafe Tributaria (00300-00306, 00320-00324), the CodiceDestinatario in IndicePA (00311, 00312, 00398, 00399), duplicates across the SdI's entire history (00404), the signing certificate (00100-00107), and invalidated dichiarazioni d'intento (00477). A failed check digit is still conclusive, because a number with a wrong check digit cannot exist in the Anagrafe Tributaria.

Verified against the six example invoices published by the Agenzia delle Entrate — and those files are themselves non-conformant, which the tool reports rather than hides: all six carry a placeholder partita IVA (01234567890, whose check digit should be 7), two of them (FPR02, FPR03) declare an ImponibileImporto of EUR 27.00 against lines summing to EUR 25.00 (a EUR 2 gap, twice the tolerance of control 00422), and FPR02 does not even validate against the AdE's own XSD because it places <ContattiTrasmittente> after <PECDestinatario>, the reverse of the schema's ordered xs:sequence. Those files date from 2014 and predate the controls that now reject them.

100% client-side — the invoice is never uploaded, and validating here does NOT transmit it to the SdI.

### KSeF FA(3) Validator (Poland)
URL: /en/tools/ksef

Validates a Polish structured invoice for KSeF (Krajowy System e-Faktur), Poland's national e-invoicing system.

FA(3) has been the only schema KSeF accepts since 1 February 2026 (taxpayers with 2024 gross sales over PLN 200 million) and 1 April 2026 (all other businesses). It replaced FA(2). Penalties for KSeF errors apply only from 1 January 2027, so 2026 is a transition year.

Validation layers:
1. The official Ministry of Finance XSD schema, published on crd.gov.pl (namespace http://crd.gov.pl/wzor/2025/06/25/13775/) — document structure, data types, cardinalities, and closed code lists: RodzajFaktury (VAT, KOR, ZAL, ROZ, UPR, KOR_ZAL, KOR_ROZ) and the VAT rate codes (23, 22, 8, 7, 5, 4, 3, "0 KR", "0 WDT", "0 EX", "zw", "oo", "np I", "np II" — lowercase and case-sensitive).
2. Retired-schema detection: a file still declaring the FA(2) namespace is recognised and reported explicitly. This is the most common migration failure. Note that FA(3) added two mandatory fields to Podmiot2 (the buyer): JST and GV.
3. Rules the schema cannot express, reported as NON-BLOCKING WARNINGS: the NIP mod-11 check digit, and the coherence of the VAT totals (P_13_* net amounts + P_14_* VAT amounts vs P_15, and the invoice lines' P_11 vs the net totals on plain VAT invoices).

Why those last checks are warnings and not errors: they are not normative KSeF rules, and the Ministry's own example invoice no. 1 declares P_15 = 2051 while its parts sum to 2050.99. Treating the discrepancy as fatal would reject the Ministry's own reference files. Similarly, the CRC-8 check digit of the KSeF number is documented by the Ministry but does not hold for any of the KSeF numbers in its example files, so it is deliberately not enforced.

The validator is verified against all 26 official example invoices published by the Ministry of Finance: every one of them must come back with zero errors and zero warnings, or the build fails.

100% client-side — no invoice data is ever uploaded, and validating here does NOT submit the invoice to KSeF.

### IBAN Validator
URL: /en/tools/iban

Validates any IBAN (International Bank Account Number) using the mod-97 checksum algorithm defined in ISO 13616.

Validation steps:
1. Verify country code (2-letter ISO 3166-1 alpha-2)
2. Verify check digits (positions 3-4)
3. Verify BBAN (Basic Bank Account Number) length and format per country rules
4. Compute mod-97 checksum on the rearranged IBAN

Supported countries: all 36 SEPA countries including EU member states, UK, Norway, Switzerland, Iceland, Liechtenstein, and others.

Output: valid/invalid status, country detection, check digit value, BBAN breakdown.

Per-country IBAN pages: each country has a dedicated landing page at /en/tools/iban/{country} showing that country's IBAN format, total length, structure (country code + 2 check digits + BBAN), a validated example, and a country-specific FAQ (how many characters the IBAN has, how to check whether it is valid, and where to find your IBAN). Available countries: germany (DE, 22 chars), france (FR, 27), spain (ES, 24), italy (IT, 27), belgium (BE, 16), netherlands (NL, 18), austria (AT, 20), portugal (PT, 25), ireland (IE, 22), luxembourg (LU, 20), finland (FI, 18), poland (PL, 28), switzerland (CH, 21), sweden (SE, 24), denmark (DK, 18), norway (NO, 15), greece (GR, 27), croatia (HR, 21), romania (RO, 24), czech-republic (CZ, 24), slovakia (SK, 24), slovenia (SI, 19), estonia (EE, 20), latvia (LV, 21), lithuania (LT, 20), bulgaria (BG, 22), hungary (HU, 28), malta (MT, 31), cyprus (CY, 28), iceland (IS, 26), liechtenstein (LI, 21), monaco (MC, 27), san-marino (SM, 27), andorra (AD, 24), united-kingdom (GB, 22), gibraltar (GI, 23), vatican-city (VA, 22). All pages run the mod-97 checksum entirely in the browser.

Major banks and their national bank codes (bank code / BIC), by country — extracted from each /en/tools/iban/{country} page:
- germany: Deutsche Bank 50070010/DEUTDEFF; Commerzbank 50040000/COBADEFF; DZ Bank 50060400/GENODEFF; ING 50010517/INGDDEFF; UniCredit Bank (HypoVereinsbank) 70020270/HYVEDEMM; Postbank 10010010/PBNKDEFF; N26 Bank 10011001/NTSBDEB1; DKB (Deutsche Kreditbank) 12030000/BYLADEM1001; Berliner Sparkasse 10050000/BELADEBE.
- france: BNP Paribas 30004/BNPAFRPP; Société Générale 30003/SOGEFRPP; La Banque Postale 20041/PSSTFRPP; LCL (Le Crédit Lyonnais) 30002/CRLYFRPP; CIC 30066/CMCIFRPP; Crédit Agricole S.A. 30006/AGRIFRPP; Boursorama (BoursoBank) 40618/BOUSFRPP; Fortuneo 14518/FTNOFRP1.
- spain: Banco Santander 0049/BSCHESMM; BBVA 0182/BBVAESMM; CaixaBank 2100/CAIXESBB; Banco Sabadell 0081/BSABESBB; Bankinter 0128/BKBKESMM; ING España 1465/INGDESMM; Abanca 2080/CAGLESMM; Unicaja Banco 2103/UCJAES2M.
- italy: Intesa Sanpaolo 03069/BCITITMM; UniCredit 02008/UNCRITMM; Banco BPM 05034/BAPPIT22; BPER Banca 05387/BPMOIT22; Banca Monte dei Paschi di Siena 01030/PASCITMM; BancoPosta (Poste Italiane) 07601/BPPIITRR; FinecoBank 03015/FEBIITM2; Crédit Agricole Italia 06230/CRPPIT2P.
- netherlands: ABN AMRO ABNA/ABNANL2A; ING INGB/INGBNL2A; Rabobank RABO/RABONL2U; SNS Bank (de Volksbank) SNSB/SNSBNL2A; ASN Bank ASNB/ASNBNL21; RegioBank RBRB/RBRBNL21; Triodos Bank TRIO/TRIONL2U; Knab KNAB/KNABNL2H; bunq BUNQ/BUNQNL2A; Revolut (NL branch) REVO/REVONL22; Van Lanschot Kempen FVLB/FVLBNL22; NIBC Bank DNIB/DNIBNL2G; Nationale-Nederlanden Bank NNBA/NNBANL2G; Aegon Bank AEGO/AEGONL2U.
- belgium: BNP Paribas Fortis 001/GEBABEBB; Belfius 063/GKCCBEBB; Crelan 103/NICABEBB; Beobank 109/CTBKBEBX; Bank Nagelmackers 132/BNAGBEBB; CBC Banque 190/CREGBEBB; ING Belgium 310/BBRUBEBB; KBC Bank 400/KREDBEBB; Triodos Bank 523/TRIOBEBB; Bank J. Van Breda & C° 645/JVBABE22; Keytrade Bank 651/KEYTBEBB; vdk bank 890/VDSPBE91; Argenta 979/ARSPBE22.
- austria: Erste Bank / Sparkasse 20111/GIBAATWW; UniCredit Bank Austria 12000/BKAUATWW; Raiffeisen Bank International 31000/RZBAATWW; Raiffeisenlandesbank NÖ-Wien 32000/RLNWATWW; BAWAG P.S.K. 60000/BAWAATWW; Volksbank Wien 43000/VBOEATWW; Oberbank 15000/OBKLAT2L; BTV (Bank für Tirol und Vorarlberg) 16000/BTVAAT22; HYPO NOE Landesbank 53000/HYPNATWW; Hypo Vorarlberg Bank 58000/HYPVAT2B; easybank 14200/EASYATW1; ING (ING-DiBa Austria) 19210/INGBATWW; bank99 19120/SPBAATWW.
- portugal: Caixa Geral de Depósitos (CGD) 0035/CGDIPTPL; Millennium BCP 0033/BCOMPTPL; Novo Banco 0007/BESCPTPL; Banco Santander Totta 0018/TOTAPTPL; Banco BPI 0010/BBPIPTPL; Banco Montepio 0036/MPIOPTPL; Crédito Agrícola 0045/CCCMPTPL; Bankinter Portugal 0269/BKBKPTPL; ABANCA Portugal 0170/CAGLPTPL; Banco CTT 0193/CTTVPTPL; ActivoBank 0023/ACTVPTPL.
- ireland: Allied Irish Banks (AIB) AIBK/AIBKIE2D; Bank of Ireland BOFI/BOFIIE2D; Permanent TSB (PTSB) IPBS/IPBSIE2D; EBS EBSI/EBSIIE2D; An Post Money PSTS/PSTSIE21; Revolut Bank (Ireland) REVO/REVOIE23; Citibank Europe CITI/CITIIE2X; Barclays Bank Ireland BARC/BARCIE2D.
- luxembourg: Spuerkeess (BCEE) 001/BCEELULL; Banque Internationale à Luxembourg (BIL) 002/BILLLULL; BGL BNP Paribas 003/BGLLLULL; Banque de Luxembourg 008/BLUXLULL; Banque Raiffeisen 009/CCRALULL; ING Luxembourg 014/CELLLULL; Deutsche Bank Luxembourg 036/DEUTLULL; Société Générale Luxembourg 061/SGABLULL; POST Group (CCP Luxembourg) 111/CCPLLULL; Advanzia Bank 344/ADVZLULL; Keytrade Bank Luxembourg 359/KEYTLULL; Quintet Private Bank 705/KBLXLULL.
- finland: Nordea 182/NDEAFIHH; OP (Osuuspankki) 500/OKOYFIHH; Danske Bank 800/DABAFIHH; Aktia Bank 405/HELSFIHH; S-Pankki 390/SBANFIHH; POP Pankki 470/POPFFI22; Säästöpankki 715/ITELFIHH; Handelsbanken 313/HANDFIHH.
- poland: PKO Bank Polski 1020/BPKOPLPW; Bank Pekao 1240/PKOPPLPW; Santander Bank Polska 1090/WBKPPLPP; mBank 1140/BREXPLPW; ING Bank Śląski 1050/INGBPLPW; BNP Paribas Bank Polska 1600/PPABPLPK; Bank Millennium 1160/BIGBPLPW; Alior Bank 2490/ALBPPLPW; Citi Handlowy 1030/CITIPLPX; Credit Agricole Bank Polska 1940/AGRIPLPR; VeloBank 1560/GBGCPLPK; Bank Pocztowy 1320/POCZPLP4; Nest Bank 1870/NESBPLPW.
- switzerland: UBS Switzerland 200/UBSWCHZH80A; PostFinance 9000/POFICHBE; Raiffeisen Schweiz 80808/RAIFCH22; Zürcher Kantonalbank 700/ZKBKCHZZ80A; Migros Bank 8401/MIGRCHZZ80A; Banque Cantonale Vaudoise 767/BCVLCH2L.
- sweden: Nordea 3000/NDEASESS; Handelsbanken 6000/HANDSESS; SEB 5000/ESSESESS; Swedbank 7000/SWEDSESS; Danske Bank 1200/DABASESX; Länsförsäkringar Bank 9020/ELLFSESS; Skandiabanken 9150/SKIASESS; Nordnet Bank 9100/NNSESES1; Avanza Bank 9550/AVANSES1; SBAB Bank 9250/SBAVSESS.
- denmark: Danske Bank 3000/DABADKKK; Nordea Danmark 2000/NDEADKKK; Jyske Bank 5000/JYBADKKK.
- norway: DNB Bank 1200/DNBANOKK; Nordea Norge 6021/NDEANOKK; SpareBank 1 SR-Bank 3201/SPRKNO22; SpareBank 1 SMN 4200/SPTRNO22; Handelsbanken Norge 9042/HANDNOKK; Sparebanken Vest 3625/SPAVNO22.
- greece: National Bank of Greece (NBG) 011/ETHNGRAA; Alpha Bank 014/CRBAGRAA; CrediaBank (ex-Attica Bank) 016/ATTIGRAA; Piraeus Bank 017/PIRBGRAA; Eurobank 026/ERBKGRAA; Optima Bank 034/IBOGGRAA.
- croatia: Zagrebačka banka 2360000/ZABAHR2X; Privredna banka Zagreb (PBZ) 2340009/PBZGHR2X; Erste&Steiermärkische Bank 2402006/ESBCHR22; OTP banka 2407000/OTPVHR2X; Raiffeisenbank Austria (RBA) 2484008/RZBHHR2X; Hrvatska poštanska banka (HPB) 2390001/HPBZHR2X; Addiko Bank 2500009/HAABHR22; Agram banka 2481000/KREZHR2X; Istarska kreditna banka Umag 2380006/ISKBHR2X; Podravska banka 2386002/PDKCHR2X; Karlovačka banka 2400008/KALCHR2X; Croatia banka 2485003/CROAHR2X.
- romania: Banca Transilvania BTRL/BTRLRO22; BCR (Banca Comercială Română) RNCB/RNCBROBU; BRD - Groupe Société Générale BRDE/BRDEROBU; Raiffeisen Bank RZBR/RZBRROBU; ING Bank INGB/INGBROBU; UniCredit Bank BACX/BACXROBU; CEC Bank CECE/CECEROBU; Garanti Bank (BBVA) UGBI/UGBIROBU; Vista Bank EGNA/EGNAROBX; Salt Bank ROIN/ROINROBU; Libra Internet Bank BREL/BRELROBU; Patria Bank CARP/CARPRO22; Intesa Sanpaolo Bank România WBAN/WBANRO22.
- czech-republic: Komerční banka 0100/KOMBCZPP; ČSOB 0300/CEKOCZPP; MONETA Money Bank 0600/AGBACZPP; Česká spořitelna 0800/GIBACZPX; Fio banka 2010/FIOBCZPP; TRINITY BANK 2070/MPUBCZPP; Banka CREDITAS 2250/CTASCZ22; UniCredit Bank 2700/BACXCZPP; Air Bank 3030/AIRACZPP; Raiffeisenbank 5500/RZBCCZPP; J&T Banka 5800/JTBPCZPP; PPF banka 6000/PMBPCZPP; mBank 6210/BREXCZPP; Partners Banka 6363/PTBNCZPP.
- slovakia: Slovenská sporiteľňa 0900/GIBASKBX; Všeobecná úverová banka (VÚB) 0200/SUBASKBX; Tatra banka 1100/TATRSKBX; ČSOB 7500/CEKOSKBX; 365.bank 6500/POBNSKBA; Prima banka Slovensko 5600/KOMASK2X; UniCredit Bank 1111/UNCRSKBX; mBank 8360/BREXSKBX; Fio banka 8330/FIOZSKBA; J&T Banka 8320/JTBPSKBA.
- slovenia: Nova Ljubljanska Banka (NLB) 02/LJBASI2X; SKB Banka 03/SKBASI2X; OTP banka (ex-Nova KBM) 04/KBMASI2X; Gorenjska Banka 07/GORESI2X; Banka Intesa Sanpaolo 10/BAKOSI2X; Deželna Banka Slovenije 19/SZKBSI2X; UniCredit Banka Slovenija 29/BACXSI22; Addiko Bank 33/HAABSI22; Banka Sparkasse 34/KSPKSI22; Delavska Hranilnica 61/HDELSI22.
- estonia: SEB Pank 10/EEUHEE2X; Swedbank 22/HABAEE2X; Luminor Bank 96/RIKOEE22; LHV Pank 77/LHVBEE22; Coop Pank 42/EKRDEE22; Citadele banka (Eesti filiaal) 12/PARXEE22; Bigbank 75/BIGKEE2B.
- latvia: Swedbank HABA/HABALV22; SEB banka UNLA/UNLALV2X; Citadele banka PARX/PARXLV22; Luminor Bank RIKO/RIKOLV2X; Rietumu Banka RTMB/RTMBLV2X; BluOr Bank CBBR/CBBRLV22; Industra Bank MULT/MULTLV2X; Signet Bank LLBB/LLBBLV2X.
- lithuania: Swedbank 73000/HABALT22; SEB bankas 70440/CBVILT2X; Luminor Bank 40100/AGBLLT2X.
- bulgaria: UniCredit Bulbank UNCR/UNCRBGSF; DSK Bank STSA/STSABGSF; United Bulgarian Bank (UBB) UBBS/UBBSBGSF; Postbank (Eurobank Bulgaria) BPBI/BPBIBGSF; First Investment Bank (Fibank) FINV/FINVBGSF; Allianz Bank Bulgaria BUIN/BUINBGSF; Central Cooperative Bank CECB/CECBBGSF; ProCredit Bank PRCB/PRCBBGSF; TBI Bank TBIB/TBIBBGSF.
- hungary: OTP Bank 117/OTPVHUHB; K&H Bank 104/OKHBHUHB; Erste Bank Hungary 116/GIBAHUHB; Raiffeisen Bank 120/UBRTHUHB; UniCredit Bank Hungary 109/BACXHUHB; CIB Bank 107/CIBHHUHB; MBH Bank 504/MKKBHUHB; Gránit Bank 121/GNBAHUHB; MagNet Bank 162/HBWEHUHB.
- malta: Bank of Valletta VALL/VALLMTMT; HSBC Bank Malta MMEB/MMEBMTMT; APS Bank APSB/APSBMTMT; BNF Bank BNIF/BNIFMTMT; Lombard Bank Malta LBMA/LBMAMTMT; MeDirect Bank MBWM/MBWMMTMT; Sparkasse Bank Malta SBMT/SBMTMTMT; FIMBank FIMB/FIMBMTM3; Izola Bank IZOL/IZOLMTMT.
- iceland: Landsbankinn 0100/NBIIISRE; Arion banki 0300/ESJAISRE; Íslandsbanki 0500/GLITISRE; Kvika banki 0700/MPBAISRE.
- cyprus: Bank of Cyprus 002/BCYPCY2N; Hellenic Bank 005/HEBACY2N; AstroBank 008/PIRBCY2N; Alpha Bank Cyprus 009/ABKLCY2N; Cyprus Development Bank (cdbbank) 014/CYDBCY2N; Eurobank Cyprus 018/ERBKCY2N; Ancoria Bank 029/ANCOCY2N.
- united-kingdom: Barclays Bank UK BUKB/BUKBGB22; HSBC UK HBUK/HBUKGB4B; Lloyds Bank LOYD/LOYDGB2L; NatWest NWBK/NWBKGB2L; Royal Bank of Scotland RBOS/RBOSGB2L; Santander UK ABBY/ABBYGB2L; Halifax HLFX/HLFXGB22; Nationwide Building Society NAIA/NAIAGB21; TSB Bank TSBS/TSBSGB2A; The Co-operative Bank CPBK/CPBKGB22.
- liechtenstein: LGT Bank 08810/BLFLLI2X; Liechtensteinische Landesbank (LLB) 08800/LILALI2X; VP Bank 08805/VPBVLI2X; Neue Bank 08802/NBANLI22; Bank Frick 08811/BFRILI22; Bendura Bank 08803/HYIBLI22.
- monaco: CFM Indosuez Wealth Management 12739/CFMOMCMX; CMB Monaco (Compagnie Monégasque de Banque) 17569/CMBMMCMX; Crédit Agricole Monaco 19106/AGRIMCM1; Société Générale Private Banking (Monaco) 13368/SGBTMCMC; Barclays Bank PLC (Monaco) 12448/BARCMCMX; EFG Bank (Monaco) 18759/EFGBMCMC; Andbank Monaco 15638/BACAMCMC; UBS (Monaco) 11999/UBSWMCMX; Union Bancaire Privée (UBP) Monaco 16648/UBPGMCMX; Bank Julius Baer (Monaco) 14508/BAERMCMC.
- san-marino: Banca Agricola Commerciale (BAC) 03034/BASMSMSM; Banca Sammarinese di Investimento 03287/BSDISMSD; Cassa di Risparmio della Repubblica di San Marino 06067/CSSMSMSM; Banca di San Marino 08540/MAOISMSM.
- andorra: Andbank 0001/BACAADAD; Crèdit Andorrà (Creand) 0003/CRDAADAD; MoraBanc 0004/BINAADAD.
- gibraltar: NatWest International (Gibraltar) NWBK/RBOSGIGI; Trusted Novus Bank TNOV/TNOVGIGI.
- vatican-city: Istituto per le Opere di Religione (IOR) 001/IOPRVAVX.

### Camt.053 Viewer
URL: /en/tools/camt

Parses and visualizes ISO 20022 camt.053 (Bank-to-Customer Statement) XML files.

Supported versions:
- camt.053.001.02
- camt.053.001.06
- camt.053.001.08

Displays:
- Account IBAN and currency
- Opening and closing balances (OPBD, CLBD)
- All debit and credit entries with dates, amounts, and transaction details
- Remittance information per entry

Export: CSV download of all parsed entries, compatible with Excel and accounting software.

### MT940 Viewer & MT940-to-camt.053 Converter
URL: /en/tools/mt940

Reads a legacy SWIFT MT940 "Customer Statement Message" (the text-based, tag-delimited bank statement format used for decades) and converts it to an ISO 20022 camt.053 XML statement. MT940 was retired by SWIFT for cross-border messaging in November 2025 and is being replaced by camt.053; this tool bridges the two during the ISO 20022 migration.

MT940 tags parsed:
- :20: Transaction reference
- :25: Account identification
- :28C: Statement / sequence number
- :60F: / :60M: Opening balance (D/C, date, currency, amount)
- :61: Statement line — value date, entry date (MMDD), debit/credit mark (C, D, RC, RD reversals), amount (comma decimal), SWIFT transaction type (NTRF, NDDT, NMSC, …) and reference
- :86: Information to account owner (remittance / description), including wrapped continuation lines
- :62F: / :62M: Closing balance

Extraction and checks:
- Opening and closing balances with credit/debit sign and value date
- Per-transaction value date, entry date (year inferred from the value date, with year-boundary rollback), direction, amount, SWIFT type and description
- Reversals: a reversed credit (RC) is counted as a debit and a reversed debit (RD) as a credit; the transaction type is prefixed REV: so the reversal stays visible
- Balance reconciliation: opening balance ± net turnover must equal the stated closing balance; a mismatch is flagged as a warning
- Multiple statements in one file are supported

Conversion output: a valid camt.053.001.02 statement carrying the real opening/closing balances and the mixed debit/credit entries, ready to import into ERP and treasury systems that expect ISO 20022. Everything runs in the browser; no MT940 file is uploaded.

### BAI2 Viewer & BAI2-to-camt.053 Converter
URL: /en/tools/bai2

Reads a BAI2 (Bank Administration Institute, version 2 — "Cash Management Balance Reporting", published in 1987) bank statement and converts it to an ISO 20022 camt.053 XML statement. BAI2 is the dominant cash-management statement format in the United States and Canada — the North-American counterpart of the European SWIFT MT940 — and is increasingly converted to the richer ISO 20022 camt.053 as ERP and treasury systems (SAP, Kyriba) migrate.

BAI2 record hierarchy parsed (comma-delimited records, each ended by "/"):
- 01 File Header — sender, receiver, file creation date
- 02 Group Header — ultimate receiver / originator, as-of date
- 03 Account Identifier — customer account number, currency, and repeating balance/summary tuples (010 opening ledger, 015 closing ledger, 040/045 available balances)
- 16 Transaction Detail — numeric type code, amount, bank reference, customer reference, free text
- 88 Continuation — continues the preceding 03 (structured summary fields) or 16 (free-text remittance) record
- 49 / 98 / 99 — Account / Group / File trailers

Extraction and checks:
- Debit/credit direction inferred from the numeric type code range: 100–399 = credit, 400–699 = debit. Ambiguous ranges (700–799 loans, 900+ custom/bank-specific) are rejected rather than guessed, so a wrong assumption never silently flips a balance
- Amounts are integer minor units with no decimal point; they are scaled by the currency's implied decimals (USD/EUR = 2, JPY = 0, KWD/BHD = 3)
- Balance reconciliation: opening ledger balance (010) plus net turnover must equal the closing ledger balance (015); a mismatch is flagged as a warning
- Multiple groups and accounts in one file are supported

Conversion output: a valid camt.053.001.02 statement carrying the real opening/closing balances and the mixed debit/credit entries, ready to import into ERP and treasury systems that expect ISO 20022. Everything runs in the browser; no BAI2 file is uploaded.

### CODA Viewer & CODA-to-camt.053 Converter (Belgium)
URL: /en/tools/coda

Reads a Belgian CODA bank statement ("Coded statement of account") and converts it to an ISO 20022 camt.053 XML statement. CODA is the coded bank-statement standard published by Febelfin (the Belgian Financial Sector Federation) and delivered by every Belgian bank — the Belgian counterpart of the SWIFT MT940, the US BAI2 and the ISO 20022 camt.053. The layout implemented here is that of the official Febelfin specification "Coded statement of account (CODA)", version 2.8, updated November 2025; every field position comes from its Annex I.

CODA record hierarchy parsed (fixed-width, 128 characters, identified by the first character):
- 0 — Header: creation date, file reference, addressee, the BIC of the bank, the duplicate flag, and the "separate application" code
- 1 — Old balance: account structure (0 Belgian BBAN / 1 foreign / 2 Belgian IBAN / 3 foreign IBAN), account number and currency, opening balance with its explicit sign and date, account holder
- 2.1 / 2.2 / 2.3 — Movement: sequence and detail number, bank reference, amount, value date, entry date, the 8-character transaction code, the communication (structured or free), then the SEPA data block (customer reference, counterparty BIC, R-transaction type and ISO 20022 return reason code, category purpose, purpose) and the counterparty's account and name
- 3.1 / 3.2 / 3.3 — Information: free text attached to the movement above
- 8 — New balance: closing balance with its explicit sign and date
- 4 — Free communication: text not attached to any movement
- 9 — Trailer: record count and the debit / credit control totals

Format conventions handled (and the reason a naive parser gets them wrong):
- Amounts are 15 numeric positions = 12 integer positions + 3 DECIMALS — not cents, and not currency-dependent minor units as in BAI2. "000000000123456" is 123.456
- The direction is an explicit sign character (0 = credit, 1 = debit), never inferred from a type-code range
- The booked movements are the 2.1 records whose detail number is 0000. Records with a higher detail number are the breakdown of the movement above them (costs, VAT, exchange commission) or, under globalisation, the individual transactions behind a single booked total. Summing them all would double-count; Febelfin's own trailer defines its control totals as the sum of the type-2 records with detail number 0000, which is exactly the rule applied here
- A single physical file may contain several logical CODA files, one per account
- The account layout of the 37-character "account number and currency" zone depends on the account structure, so each structure is decoded explicitly rather than with one fixed layout

Checks performed:
- Trailer control totals (record 9): the declared debit and credit totals must equal the sum of the booked debit / credit movements
- Trailer record count (record 9): must equal the records 1, 2.x, 3.x and 8 actually present
- Accounting identity: old balance ± booked movements = new balance (skipped for a "separate application" file, whose balances are zeroed out by design)
- CHECK DIGITS OF THE BELGIAN STRUCTURED COMMUNICATION (communication types 101 and 102): the 12-digit +++123/4567/89012+++ reference every Belgian invoice carries — the last two digits are the first ten modulo 97, a remainder of 0 written as 97
- CHECK DIGITS OF THE ISO 11649 STRUCTURED CREDITOR REFERENCE (communication type 100): "RF" + 2 check digits + up to 21 alphanumerics, validated with the same mod-97-10 rule as an IBAN
- All arithmetic is done in integer thousandths, so comparing 3-decimal money never drifts

Those two check-digit rules are the differentiator: a wrong structured reference is the single most common reason a Belgian payment is never matched to its invoice, the file is the last place it can still be caught, and no other free online tool verifies it.

Conversion output: a valid camt.053.001.02 statement carrying the real opening/closing balances, the booked entries only (never the detail records, which would double-count), the counterparty names and accounts, the CODA transaction code as a proprietary bank transaction code, and the remittance information. An <IBAN> element is emitted only when the file actually carries a structurally valid IBAN — never a reconstructed one — everything else goes to <Othr>. Everything runs in the browser; no CODA file is uploaded.

### CFONB 120 Viewer & CFONB-to-camt.053 Converter (France)
URL: /en/tools/cfonb

Reads a French CFONB 120-character bank statement ("Relevé de compte sur support informatique", also known as AFB120) and converts it to an ISO 20022 camt.053 XML statement. CFONB 120 is the account-statement format published by the Comité Français d'Organisation et de Normalisation Bancaires and delivered by every French bank — the French counterpart of the Belgian CODA, the SWIFT MT940, the US BAI2 and the ISO 20022 camt.053. Two official specifications define it, and both are implemented here: "Relevé de compte sur support informatique" (July 2004) for the layout, and "Evolutions du Relevé de Compte 120 caractères pour les opérations de virements et de prélèvements SEPA", version 2.0 (March 2010), for the SEPA data carried by the "05" records.

CFONB record hierarchy parsed (fixed-width, 120 characters, identified by the first two):
- 01 — Old balance ("ancien solde"): bank code, branch code, account number, currency, number of decimals, opening balance and its date
- 04 — Movement ("mouvement"): interbank operation code, bank-internal operation code, accounting date, value date, the 31-character label shown on the paper statement, cheque / batch / voucher number, amount, reject reason code (only on an unpaid or rejected operation), the "funds not available" flag, and the free reference zone
- 05 — Supplement ("complément"): the SEPA and remittance data, attached to the movement above
- 07 — New balance ("nouveau solde"): closing balance and its date

The two traps of the format, both handled:
- THE SIGN IS OVERPUNCHED ON THE LAST CHARACTER OF THE AMOUNT. The amount field is 14 characters, but only the first 13 are plain digits: the spec says "le montant étant signé, le signe est superposé au dernier caractère à droite" — a COBOL zoned-decimal encoding where a credit ending in 0..9 is written "{" or "A".."I" and a debit "}" or "J".."R". So "0000000012345J" is −123451, not a parse error. Reading that last character as a digit — or dropping it — loses both the sign and one significant digit, and silently corrupts every debit
- THE NUMBER OF DECIMALS IS A FIELD OF THE FILE (position 20), not a property of the currency. A 0-decimal or a 3-decimal amount is declared by the record itself, and a currency-decimals table must not override it

SEPA data decoded from the "05" records, by their 3-letter qualifier (2010 addendum): LIB (free additional label), LCC and LC2 (unstructured remittance information), LCS (structured creditor reference), RCN (end-to-end reference + purpose), REF (batch reference + transaction reference), NPY / IPY (payer name and identifier), NBE / IBE (beneficiary name and identifier — for a SEPA direct debit the IBE carries the ICS), NPO / NBU (ultimate debtor / ultimate creditor), CBE / CPY (beneficiary and payer accounts), RUM (SEPA mandate reference + sequence type OOFF / FRST / RCUR / FNAL, which is validated), MMO (original amount and currency of a converted operation, plus the exchange rate). Each qualifier has its own layout, so the 70-character zone is split per qualifier rather than read as one flat string. Unknown, bank-specific qualifiers are reported rather than silently dropped.

Checks performed:
- THE ACCOUNTING IDENTITY THE CFONB ITSELF REQUIRES. Rule 2 of §1 of the spec is unusually explicit: "le nouveau solde est égal à la somme algébrique des montants de l'ancien solde et de tous les mouvements présents dans le relevé". This is not a heuristic, it is the definition of a conforming statement — and it is also what catches an amount whose overpunched sign was written as a plain digit
- An amount whose last character carries no overpunched sign is flagged: the file then does not say whether the movement is a credit or a debit
- The SEPA sequence type of an RUM qualifier must be one of OOFF, FRST, RCUR, FNAL
- The interbank operation codes of the SEPA direct-debit family (A1-A6 issued, B1-B6 received, including the rejected / unpaid and refund variants) are labelled; any other code is displayed raw, never guessed at
- All arithmetic is done in integer minor units, at the precision the file declares

Conversion output: a valid camt.053.001.02 statement carrying the real opening/closing balances, the movements with their direction, the counterparty lifted from the "05" records (the payer on a credit, the beneficiary on a debit), the end-to-end reference and the remittance information, and the CFONB operation code as a proprietary bank transaction code. The account is emitted as a domestic identifier under <Othr>, never as an IBAN: the CFONB 120 carries the bank code, the branch code and the account number but NOT the 2-digit RIB key, so an IBAN could only be produced by guessing a check digit the file never stated — and a reconstructed IBAN in a financial document is worse than none. Everything runs in the browser; no CFONB file is uploaded.

### camt.053 to MT940 & CSV Converter
URL: /en/tools/camt-converter

Converts an ISO 20022 camt.053 bank statement back to SWIFT MT940, and flattens any camt.052/053/054 to CSV. This is the REVERSE of the direction every other free converter offers, and it is the gap nobody fills: banks now deliver camt.053, while a long tail of ERP, accounting and treasury systems only reads MT940. Those teams are stuck between a bank that has moved on and software that has not.

MT940 output:
- :20: transaction reference, :25: account, :28C: statement number, :60F: opening balance, :61: one line per entry, :86: information, :62F: closing balance
- :64: (closing available balance) is emitted ONLY when the statement carries a CLAV balance — it is never derived from :62F:, because the two differ whenever funds are blocked
- Multi-statement camt.053 becomes multi-statement MT940, separated by the "-" end-of-statement marker
- References: EndToEndId becomes the customer reference, AcctSvcrRef the bank reference after "//". NONREF is written when the originator gave none
- Amounts use the SWIFT decimal comma, at the precision the currency actually has (JPY none, KWD three). The comma is mandatory in a 15d field even for a zero-decimal currency: a JPY amount is "100000," and not "100000"

What it deliberately does NOT do, and says so:
- ONLY BOOKED ENTRIES ARE EMITTED. camt can carry PDNG (pending) and INFO entries; MT940 has no way to say "not settled yet", so including them would state as settled money that has not moved, and would break the :60F: ± :61: = :62F: reconciliation every consumer runs. The CSV has a status column and keeps them.
- ACCENTS CANNOT SURVIVE. The MT940 character set is A-Z a-z 0-9 and / - ? : ( ) . , ' + space. "Société Générale" becomes "Societe Generale". Letters Unicode NFD cannot decompose — Ł (Poland), Ø/Æ (Denmark, Norway), ß (Germany), Þ/Ð (Iceland), Đ (Croatia), Ħ (Malta), Œ (France) — are transliterated rather than silently deleted: without that, "Łódź" would convert to "odz". The tool warns when it adapted anything.
- REFERENCES ARE CUT TO 16 CHARACTERS, the MT940 limit, where camt.053 allows 35. Warned, never silent.
- A REVERSAL IS NOT A MOVEMENT OF THE OPPOSITE SIGN. camt marks it <RvslInd>; MT940 has dedicated RC (reverses a credit) and RD (reverses a debit) marks, and they are used.
- ONLY camt.053 CONVERTS TO MT940. camt.052 (intraday account report) and camt.054 (debit/credit notification) carry no opening/closing balance pair; they are refused rather than given invented balances. The CSV accepts all three.

CSV output: one row per entry — statement, account, booking date, value date, direction, amount, currency, counterparty, counterparty IBAN, end-to-end ID, bank reference, status, reversal, bank transaction code, description. Every statement of a multi-statement file is included. Options: delimiter (";" or ","), decimal comma (ignored when the delimiter is itself a comma, which would split the amount across two columns), signed amounts. Cells are guarded against spreadsheet formula injection, while a genuine negative amount is left as a number.

Licence: writing software that emits MT940 is expressly licensed by the SWIFT Standards IPR Policy, which grants a royalty-free licence "to develop software, products or services which support transmission of information in accordance with SWIFTStandards". What is not licensed is republishing SWIFT prose — the MT Message Reference Guide is not used, quoted or hosted, and every field description is written from scratch. Context: SWIFT retired MT940 in November 2025 in favour of camt.053, but it remains in wide domestic and bank-to-corporate use — which is exactly the traffic this converter serves.

### SEPA Date Calculator & TARGET Closing-Day Calendar
URL: /en/tools/sepa-dates

Works out what actually happens to a SEPA payment, and when, from the scheme rulebooks in force and the ECB TARGET calendar. Every rule is quoted from a document anyone can download free; nothing is inferred from a vendor page.

TARGET closing days — the six days the system is shut, plus every Saturday and Sunday:
- 1 January, Good Friday, Easter Monday, 1 May (Labour Day), 25 December, 26 December
- Source: European Central Bank, press release of 14 December 2000, "Long-term calendar for TARGET closing days", applying "from 2002 until further notice". Still in force: the EPC 2025 SDD Core Rulebook v1.1 (5 October 2025) states "The TARGET Days Calendar is used to identify Inter-PSP Business Days" and "a long-term calendar for TARGET closing days has been established and applied since 2002. It is published by the European Central Bank."
- THERE IS NO OTHER HOLIDAY. TARGET is a European system and ignores national bank holidays entirely: it is OPEN on 15 August, 1 November, 31 December, 3 October (German Unity Day) and 14 July (Bastille Day). Completing the list from a country's holiday table is the most common way a TARGET calendar goes wrong.
- Easter is the GREGORIAN one. The ECB writes "Good Friday (Catholic/Protestant)" and "Easter Monday (Catholic/Protestant)" — the parenthesis excludes the Orthodox Easter, which falls on a different date most years. Greece and Cyprus are in the euro area and observe Orthodox Easter nationally; TARGET still closes on the Gregorian one.

SEPA Direct Debit (source: EPC016-06, 2025 SDD Core Rulebook v1.1, issued 5 October 2025, in force to 21 November 2027; EPC222-07, 2025 SDD B2B Rulebook v1.0):
- A DUE DATE ON A CLOSED DAY IS NOT AN ERROR. The rulebook does not forbid it, it defines what happens: "If the Due Date falls on a day which is not an Inter-PSP Business Day, then the Settlement Date will be the next Inter-PSP Business Day." A validator that rejected a Sunday due date would reject files the scheme accepts. The tool reports the shift; it never calls it a fault.
- D-1 APPLIES TO EVERY SEQUENCE TYPE. The Debtor PSP must receive the collection at the latest one Inter-PSP Business Day before the due date, "irrespective of whether the Collection is presented as an one-off or a recurrent Collection", and "The use of the sequence type 'First' in a first of a recurrent series of Collections is no longer mandatory". The old D-5 (FRST) / D-2 (RCUR) split was retired in November 2016 and survives only in stale third-party guides.
- Pre-notification: at the latest 14 CALENDAR days before the due date, unless another time-line is agreed between debtor and creditor.
- Earliest presentation: not earlier than 14 calendar days before the due date.
- Return settlement: at the latest 5 Inter-PSP Business Days after the settlement date for CORE, 3 for B2B. The two schemes genuinely differ.
- Refund (CORE only): 8 weeks from the debit date, "on a no-questions-asked basis"; 13 months for an unauthorised transaction, per article 71 of the Payment Services Directive. THE B2B SCHEME GIVES NO REFUND RIGHT for an authorised collection — that is the point of B2B, and showing an 8-week window there would describe a right that does not exist.

SEPA Credit Transfer (source: EPC125-05, 2025 SCT Rulebook v1.1, 5 October 2025) — and the limit this tool refuses to cross:
- The SCT execution cycle is counted in BANKING BUSINESS DAYS, "a day on which PSPs in the relevant jurisdiction are generally open for business with customers", NOT on the TARGET calendar. A bank in Frankfurt is shut on 3 October while TARGET is open. So the tool says whether TARGET is closed on a requested execution date and stops there: it never announces a credit transfer settlement date, because that would be inventing a fact.

What it will NOT tell you, stated out loud rather than hidden behind a green badge:
- YOUR BANK'S CUT-OFF TIME. Cut-offs are set by each PSP in its own terms and conditions — the rulebooks explicitly defer to them ("in accordance with its Terms and Conditions") and no public register lists them.
- NATIONAL BANKING HOLIDAYS. Needed for an SCT execution date; no free authoritative list covers the 36 SEPA countries.
- Whether your PSP accepts a future-dated instruction that far ahead — the ceiling is the bank's, not the scheme's.

Open dataset: /data/target-days/index.json and /data/target-days/{year}.json (2015-2035), CC-BY-4.0, with the ECB provenance embedded in every payload. The ECB publishes the RULE but not a machine-readable list of the resulting DATES, so every consumer recomputes Easter or copies a table that goes stale. Reused under the ECB terms: "users of this website may make free use of the information obtained directly from it" provided "it must appear accurately and the ECB must be cited as the source".
### ABA Routing Number Validator
URL: /en/tools/aba

Validates a US ABA routing number (also called a routing transit number, or RTN) — the 9-digit code that identifies a bank or credit union in the United States for ACH transfers, wire transfers and checks. It is the US counterpart of European IBAN validation (a routing number identifies the bank; a separate account number identifies the account).

Structure decoded:
- Digits 1-4 — Federal Reserve routing symbol (district and office)
- Digits 5-8 — institution identifier
- Digit 9 — check digit

Validation performed:
- Exactly 9 digits (spaces and dashes are ignored)
- Check digit using the ABA 3-7-1 weighting algorithm: the weighted sum of all nine digits must be a multiple of 10 (mod 10)
- Prefix decoding: the first two digits map to a Federal Reserve district (01-12), with thrift (21-32), electronic/ACH (61-72), US Government (00) and traveler's-cheque (80) ranges; an unassigned prefix is reported as invalid
- A valid check digit confirms the number is well-formed but does not prove the bank is currently active (which requires the official Federal Reserve / Accuity directory)

Everything runs in the browser; no routing number is uploaded.

### ACH / NACHA File Validator
URL: /en/tools/ach

Validates a US ACH (Automated Clearing House) file in the fixed-width Nacha format used for domestic US payments (payroll, vendor payments, consumer collections). Every record is exactly 94 characters, grouped in blocks of 10.

Record types checked:
- Type 1 — File Header
- Type 5 — Batch/Company Header (service class code, SEC code, company identification)
- Type 6 — Entry Detail (transaction code, RDFI routing number, account, amount, receiver)
- Type 7 — Addenda (optional)
- Type 8 — Batch/Company Control (control totals for the batch)
- Type 9 — File Control (control totals for the whole file)

Validation performed:
- Every record is exactly 94 characters
- Routing-number check digit using the ABA 3-7-1 weighting algorithm (mod 10)
- Entry hash = sum of the 8-digit RDFI routing numbers, truncated to the rightmost 10 digits, at both batch and file level
- Total debit and total credit dollar amounts match the detail entries (batch control record 8 and file control record 9)
- Entry/addenda count, batch count and block count (records ÷ 10) match
- Service class codes (200 mixed / 220 credits / 225 debits) and standard entry class (SEC) codes (PPD, CCD, CTX, WEB, TEL, IAT, …)
- Zero-dollar amount enforced for prenotification / administrative transaction codes

Transaction codes recognised: checking (22 credit, 27 debit), savings (32/37), general ledger (42/47) and loan (52/55) accounts, including prenote and zero-dollar variants.

Output: valid/invalid status with per-record error messages, warnings for unrecognised codes, plus a per-batch view of every entry (direction, routing, account, receiver, amount) and file totals.

100% client-side — no ACH file is ever uploaded to a server.

### CSV to SEPA Converter
URL: /en/tools/sepa-converter

Converts any CSV spreadsheet into a valid SEPA XML payment file.

Output formats:
- pain.001.001.03 (Credit Transfer) for bank transfers
- pain.008.001.02 (Direct Debit) for collections

Features:
- Visual column mapping interface — no predefined template required
- Supports any CSV delimiter and encoding
- Each CSV row becomes one payment transaction
- Generates EPC-compliant XML ready for bank submission
- No row count limit

Recommended workflow: convert CSV → validate with SEPA Validator → submit to bank.

### XML Comparator
URL: /en/tools/xml-comparator

Compares two XML files side by side with line-by-line diff highlighting.

How it works:
- Loads two XML files in the browser
- Computes a line-by-line diff
- Highlights added lines (green), removed lines (red), and unchanged lines

Compatible with any XML format: SEPA pain files, UBL invoices, camt.053 statements, configuration files, or any other XML document.

File size limit: 10 MB per file.

### SEPA & camt.053 Test File Generator
URL: /en/tools/test-generator

Generates a valid camt.053 test bank statement from an existing pain.001 (Credit Transfer) or pain.008 (Direct Debit) file — realistic test data for reconciliation, ERP integration and bank-statement processing without touching production data.

How it works:
- Reads the payments in the source pain.001 / pain.008 file
- Produces a matching camt.053.001.02 statement with one booked entry per payment, coherent opening/closing balances and amounts
- The generated statement is what a bank would return after the payments settle — ideal for testing a reconciliation or ERP import routine end to end

100% client-side — the source file never leaves the browser.

### Universal Viewer
URL: /en/tools/viewer

A single drop zone that auto-detects the financial file type and shows its key facts read-only, without validating. Useful for a quick look at an unknown file before deciding which validator to run.

Auto-detected formats:
- SEPA pain.001 / pain.008 (Credit Transfer / Direct Debit)
- ISO 20022 camt.052 / camt.053 / camt.054 bank statements
- UBL / Peppol invoices and credit notes
- Factur-X / ZUGFeRD hybrid PDF invoices (embedded XML)

For each file it surfaces the essentials (type and version, parties, totals, entries or line items). 100% client-side — the file is never uploaded.

### Factur-X / ZUGFeRD Viewer
URL: /en/tools/facturx

Extracts and displays the embedded XML data from Factur-X (France/EU) and ZUGFeRD (Germany) hybrid PDF invoices.

What is Factur-X / ZUGFeRD?
These are hybrid electronic invoice formats that embed a structured XML file inside a PDF/A-3 document. The PDF is human-readable; the embedded XML enables automated processing by ERP and accounting systems. Both conform to the EN 16931 European standard.

Supported profiles:
- MINIMUM
- BASIC WL
- BASIC
- EN 16931 (COMFORT)
- EXTENDED
- ZUGFeRD 2.x (all profiles)

Output: extracted XML displayed in a structured viewer, with option to copy the raw XML.

### CPA-005 / AFT File Validator (Canada)
URL: /en/tools/cpa005

Validates a Canadian bulk-payment file in the CPA Standard 005 AFT format — also called EFT 1464 — the format Canadian financial institutions use to exchange direct deposits and pre-authorised debits. It is the Canadian counterpart of the US ACH/NACHA file and of the European SEPA pain.001. Sources, both read in full and both public: Payments Canada Standard 005, "Standards for the Exchange of Financial Data on AFT Files" (2024 edition), and Standard 007, "Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files" (2026 edition).

Record structure (fixed width, 1,464 characters — a 24-character prefix plus SIX 240-character segments, so one record carries up to six transactions):
- A — file header. Exactly one, first. Carries the originator's ID, the file creation number, the creation date and the currency (CAD or USD only; a file never mixes the two).
- C — a deposit. This is the CREDIT.
- D — a pre-authorised debit. This is the DEBIT.
- E — an error correction that reverses a C (so it moves money like a debit).
- F — an error correction that reverses a D (so it moves money like a credit).
- I — the return of a C (or of an F).
- J — the return of a D (or of an E).
- Z — file trailer, carrying the control totals.
- U / S / V — the header, detail and trailer of a NOTICE OF CHANGE file (208-character records). Standard 005 requires these to be sent on a file of their own; they may never be intermixed with AFT records.

Several published summaries have C and D the wrong way round. Standard 005 is unambiguous: type C records "deposit" data.

What the validator checks:
- LOGICAL RECORD COUNT: the header must carry exactly 000000001, and every following record exactly one more. This counts PHYSICAL records, not transactions — a file of three records can carry twelve transactions.
- ORIGINATION CONTROL DATA: positions 11-24 of every record must repeat the header's originator ID and file creation number, byte for byte. Standard 005 rejects the whole file on a mismatch.
- THE FOUR SEPARATE PAIRS OF TRAILER TOTALS. This is the trap of the format. D and J go into the debit pair; C and I into the credit pair; and E and F have counters OF THEIR OWN. Folding the error corrections into the debit and credit totals breaks the balance of every file that carries a reversal, and it is the single most common reason a hand-written CPA-005 generator is rejected.
- THE SEGMENT RULE: once a segment of a record is left blank, every following segment must be blank too. A used segment after a blank one is a hole in the record.
- POSITIONS 230-251 ARE NOT THE SAME FIELD IN EVERY RECORD TYPE. On a C or a D they are a plain alphanumeric filler. On an E, F, I or J the very same bytes carry the numeric "Stored Item Trace No." — the pointer back to the transaction being reversed or returned. A parser that reads the layout flat loses the link to the original payment.
- THE DATE IS 0YYDDD: a constant zero, the two-digit year, then the day of the YEAR (1 to 366) — a Julian day, not a day of the month. Reading 026193 as "19 March" instead of "the 193rd day" moves the payment by months.
- AMOUNTS ARE CENTS WITH NO DECIMAL POINT: $4,456.00 is written 0000445600, right-justified and zero-filled, and must be greater than zero.
- TRANSACTION CODES and 900-SERIES RETURN REASON CODES of Standard 007. On an I or a J, the transaction-type field carries the RETURN REASON, not a payment type — the original payment type survives in the "stored transaction type" field. 901 is insufficient funds, 902 an account not found, 903 a stopped payment, 905 an account closed, 907 no debit allowed, 910 a deceased payor or payee, 911 a frozen account, 912 an invalid account number, 915 to 921 the customer-initiated returns of a pre-authorised debit, 922 a customer-initiated return of a credit, 990 an institution in default. Code 900 is reserved for edit rejects. Code 906 was RETIRED on 11 October 2007 and will never be reassigned — a file still using it is using a dead code.
- ITEM TRACE NUMBER: 22 digits — the destination data centre (with its last digit dropped), the originating data centre, the file creation number and a sequence number — cross-checked against the A header. An empty item trace is NOT an error: on a file a customer sends to its bank, the Direct Clearer assigns it.

WHAT THE VALIDATOR DELIBERATELY DOES NOT DO: invent a check digit. The US ABA routing number has the 3-7-1 modulo 10 check digit. The Canadian routing number has NOTHING OF THE SORT. Standard 005 prescribes a lookup against the Payments Canada Financial Institutions File instead, and Standard 006 (which defines the MICR encoding) contains no checksum whatsoever. So only the shape is validated: nine digits, a constant leading zero, a 3-digit institution number and a 5-digit branch number. Inventing an arithmetic check here would reject perfectly valid files.

Positioning: no other free online CPA-005 validator exists. The format is served only by paid desktop software and by developer libraries.

### Payment QR codes — EPC QR generator & Swiss QR-bill validator
URL: /en/tools/qr-code

Generates the EPC QR code of a SEPA credit transfer, and decodes and validates any payment QR code — European (EPC) or Swiss — from a pasted payload or from a picture of the code, scanned in the browser canvas. Sources, both official and read in full: European Payments Council, EPC069-12 v3.1 (issued and effective 19 March 2024), and SIX / paymentstandards.ch, "Swiss Implementation Guidelines QR-bill" version 2.4 (valid from 14 November 2026; version 2.3 remains valid until November 2027).

THE EPC QR CODE (EPC069-12) — the "scan to pay" square printed on European invoices. Its payload is twelve lines of plain text, separated by LF or CRLF, with no separator after the last populated line:
1. BCD — the service tag.
2. The version: 001 or 002.
3. The character set: 1 = UTF-8, 2 = ISO 8859-1, 3 = 8859-2, 4 = 8859-4, 5 = 8859-5, 6 = 8859-7, 7 = 8859-10, 8 = 8859-15. Note that the list SKIPS ISO 8859-3 and ISO 8859-9 — numbering them as consecutive 8859 parts is wrong.
4. SCT — the identification code. EPC069-12 covers SEPA Credit Transfers only.
5. The beneficiary's BIC.
6. The beneficiary's name (max 70).
7. The beneficiary's IBAN (max 34). Only an IBAN is allowed — never a national account number.
8. The amount, written as EUR followed by the value (for example EUR12.30), between 0.01 and 999999999.99. There is no currency field: the amount is in euro by definition.
9. A purpose code (max 4, an ISO 20022 ExternalPurpose1Code such as GDDS).
10. A structured creditor reference (max 35) — OR —
11. An unstructured message (max 140). The two are MUTUALLY EXCLUSIVE: a payment QR carries a creditor reference or free text, never both.
12. Beneficiary-to-originator information (max 70).

Two rules implementations get wrong:
- THE 331-BYTE CAP IS ON BYTES, NOT CHARACTERS — bytes of the declared character set. In UTF-8, an accented letter costs two, so a payload that fits in characters can still overflow. The specification spells the distinction out precisely because it is easy to miss.
- VERSION 001 VERSUS 002 DIFFERS IN EXACTLY ONE THING: whether the BIC is mandatory. In 001 it always is. In 002 it is only required when the beneficiary's payment service provider is a SEPA scheme participant outside the EEA. Nothing else about the structure changes.
The generator renders at error correction level M, as the guidelines prescribe. It also warns, rather than rejects, when an amount is written with one decimal — because EPC069-12's OWN published example writes "EUR12.3", and a validator that rejects the standard's example is wrong by definition.

THE SWISS QR-BILL (SIX Implementation Guidelines) — a different standard entirely. Its payload is 31 to 34 lines: the fixed QR type SPC, the version 0200 (there is no 0210), the coding type 1, the creditor's IBAN, the creditor's structured address, SEVEN EMPTY LINES for the reserved "ultimate creditor" block, the amount and currency (CHF or EUR only), the ultimate debtor, the reference type and reference, an unstructured message, the fixed EPD trailer, and optionally billing information and two alternative procedures.

The defining rule — and the check the guidelines explicitly ask a decoder to perform — is the ACCOUNT/REFERENCE PAIRING:
- A QR-IBAN is nothing more than an IBAN whose institution identification (positions 5 to 9) falls between 30000 and 31999. It REQUIRES a QRR reference.
- A standard IBAN FORBIDS a QR reference, and takes an ISO 11649 creditor reference (SCOR) or none at all (NON).
- A QR-IBAN with SCOR, a QR-IBAN with NON, or a standard IBAN with QRR cannot be booked. This is the single most common reason a Swiss payment is refused even though the IBAN is perfectly valid.

Other rules the validator enforces:
- THE QR REFERENCE CHECK DIGIT IS A RECURSIVE MODULO 10 (the Swiss ESR/BVR algorithm), not the modulo 97 of the IBAN world. The two give different answers, and only one is right. The reference is 26 digits plus its check digit, and may not consist exclusively of zeros.
- The SCOR creditor reference is checked against the ISO 11649 mod-97 check digits.
- Only a Swiss or Liechtenstein IBAN is allowed — but the creditor's ADDRESS may perfectly well be in another country.
- The seven "ultimate creditor" lines must be PRESENT and EMPTY. Filling them in is an error; omitting them shifts every following line and silently corrupts the whole payload.
- A BILL OF EXACTLY 0.00 CARRYING A "DO NOT USE FOR PAYMENT" MESSAGE IS LEGITIMATE. The guidelines define this notification bill (in German, French, Italian, English and Romansh). A validator that blindly enforces a 0.01 minimum rejects a document the standard itself defines.
- The unstructured message and the billing information share a COMBINED budget of 140 characters.
- Implementation Guidelines 2.4, applicable from 14 November 2026, restrict the QR-IBAN and the QR reference to Swiss francs, and limit a euro bill to a standard IBAN with SCOR or with an unstructured message. Version 2.3 stays valid until November 2027. A Swiss QR code carries NO DATE — unlike a SEPA file, nothing in the payload says which rule set applies — so the version is a choice the user makes, and the 2.4 restrictions are reported as warnings under 2.3 and as errors under 2.4. This is never inferred.

Everything, including the image scan, runs in the browser. A payment QR code contains an IBAN, an amount and often an invoice reference; it never leaves the machine.


## Blog articles

### SEPA Direct Debit timings: D-1, pre-notification, returns and refunds
URL: /en/blog/sepa-direct-debit-timings

Covers: the presentation and post-settlement deadlines of the two SEPA Direct Debit schemes, every figure read in the rulebook itself — EPC016-06 (2025 SDD Core Scheme Rulebook version 1.1) and EPC222-07 (2025 SDD B2B Scheme Rulebook version 1.1), both issued 5 October 2025. THE DISTINCTION THAT DECIDES EVERY DATE: the rulebooks count in two different units of time, and they are not interchangeable. An Inter-PSP Business Day is "a day on which PSPs generally are open for inter-PSP business", and the rulebook states that "the TARGET Days Calendar is used to identify Inter-PSP Business Days" — so it is computable offline for any date, because the ECB publishes the TARGET closing days. A Banking Business Day is "a day on which PSPs in the relevant jurisdiction are generally open for business with customers" — it varies by country and in practice by bank, and no public register lists it for the 36 SEPA countries. The direct debit schemes run on the first; the credit transfer scheme runs on the second, since the SCT rulebook defines its execution cycle "by reference to Banking Business Days, rather than to Calendar Days". Applying the TARGET calendar to a credit transfer to announce a settlement date is therefore wrong: a Frankfurt bank is closed on 3 October while TARGET is open. TARGET closes on weekends and exactly six days a year — 1 January, Good Friday, Easter Monday, 1 May, 25 December, 26 December — published by the ECB in December 2000 and applicable "from 2002 until further notice"; there is no 15 August, no All Saints' Day and no national holiday, and the ECB's own parenthesis "(Catholic/Protestant)" excludes Orthodox Easter even though Greece and Cyprus observe it nationally. THE DEADLINE DOES NOT DEPEND ON THE SEQUENCE TYPE: the Core rulebook requires the collection to reach the debtor PSP "at least 1 Inter-PSP Business Day (D-1) irrespective of whether the Collection is presented as an one-off or a recurrent Collection", and the B2B rulebook reaches the same result with "D-1 Inter-PSP Business Day at the latest for all Collections". The older FRST/RCUR split is dated by the rulebook's own change log: it stopped applying "as of the effective date in November 2016 of the Rulebook version 9.0", following EPC Plenary approval on 11 December 2014, and the same entry records that using sequence type 'First' for the first of a recurrent series is "no longer mandatory". CORE VERSUS B2B, the differences that are real: pre-notification at the latest 14 calendar days before the due date (both schemes, unless another timeline is agreed); presentation no earlier than 14 calendar days before the due date (both); receipt by the debtor PSP at D-1 (both); settlement of returns within FIVE Inter-PSP Business Days under Core but THREE under B2B; refund of an authorised transaction within eight weeks of the debit date on a no-questions-asked basis under Core, but NONE under B2B — "Refunds are not provided for under the B2B Scheme" and "The Debtor has no right to obtain a refund for an authorised transaction under the Scheme". What survives in B2B is the statutory route: 13 months after the debit date for a defective or fraudulent transaction under articles 73 or 89 of the Payment Services Directive — a different claim on different grounds, not the scheme's refund. A DUE DATE ON A CLOSED DAY IS NOT AN ERROR: the rulebook does not forbid it, it defines the outcome — "If the Due Date falls on a day which is not an Inter-PSP Business Day, then the Settlement Date will be the next Inter-PSP Business Day. If the Settlement Date falls on a day which is not a Banking Business Day for the Debtor PSP, then the debit date will be the next Banking Business Day." A validator that rejects such a file rejects something the scheme accepts; the useful output is the date the money will actually move. Note the chaining: the first shift is computable, the second is not. WHAT NO CALCULATOR CAN ANSWER, stated rather than papered over: bank cut-off times (the rulebooks defer to the contract — an originator submits "in accordance with its Terms and Conditions" — and cut-offs vary by bank, channel and customer, published nowhere); national bank holidays (needed for any SCT execution date, with no free official consolidated list for the 36 SEPA countries, and the TARGET calendar is not a substitute since it ignores national holidays by design); and the maximum post-dating a given PSP accepts. ValidateFin's SEPA date calculator applies the TARGET calendar to a due date and returns the settlement date, the D-1 presentation deadline, the pre-notification date and the refund window, and marks those three unanswerable items as not checked instead of producing a number. Everything runs in the browser, and the TARGET dataset is published at /data/target-days/{year}.json under CC-BY-4.0 with the ECB cited as source.

### ACH return codes: the complete R01-R85 reference, checked against the official sources
URL: /en/blog/ach-return-codes

Covers: the definitive list of ACH (NACHA) return reason codes and, crucially, which codes do NOT exist. Exactly 70 return codes officially exist: R01-R47, R50-R53, R61, R62, R67-R77 and R80-R85. This is established by two independent official sources that agree: Nacha's own free "ISO 20022 Guide to Mapping U.S. ACH Return and Notifications of Change", which carries the full code table with Nacha's official titles and the SEC scope of each code, and the Federal Reserve's "ACH Return Reason Report", which enumerates the codes FedACH processes with and without activity - which is what makes it decisive on existence. R63, R64, R65 and R66 are published as return codes across the web (including by large payment providers) but ARE NOT return codes: the official list goes from R62 straight to R67, and what is published as "R63 Incorrect Dollar Amount" is in fact sub-code 03 of the addenda attached to R69 "Field Error(s)", exactly as the US Treasury Green Book (public domain) prints it - the seven R69 sub-codes being 01 incorrect DFI account number, 02 incorrect original entry trace number, 03 incorrect dollar amount, 04 incorrect individual identification number, 05 incorrect transaction code, 06 incorrect company identification number, 07 invalid effective entry date. R44 ("Invalid Individual ID Number", ENR entries only) DOES exist and is missing from many published lists. R85 is NOT an IAT code: R80-R84 apply to outbound IAT entries while R85's SEC scope is "all except IAT" - it is a domestic-coded entry that the gateway identifies as an outbound international payment. R11 does NOT mean "Checksum Abbreviation Error" (Stripe's public page is wrong): it means the customer states the debit did not follow the terms of the authorization, and since 2020 it is the one unauthorized code an originator may correct and re-send within 60 days of the return's settlement date without obtaining a new authorization - unlike R05, R07, R10, R29 and R51, which may not be reinitiated at all. The return code lives at positions 4-6 of an addenda record of type 99 (94 characters); positions 22-27 carry a Date of Death, but only on R14 and R15. A Notification of Change (addenda type 98) is a ZERO-dollar entry: the payment succeeded and the bank is asking for corrected data, so re-sending it as a payment pays twice. Return timeframes: two banking days is the administrative norm (the Green Book states a return must be received by the opening of business on the second banking day following the settlement date), and consumer unauthorized debits carry an extended 60-calendar-day window; the dishonored (R61-R70) and contested (R71-R77) windows and the exact reinitiation limits are published ONLY in the paid Nacha Operating Rules, so this article states that the rules exist and refuses to quote figures it cannot source. Coming: R90 "Entry Returned Due to RDFI's Sanctions Compliance Obligations" takes effect 17 March 2028, and on the same day R16 loses its OFAC half and reverts to "Account Frozen" alone. ValidateFin validates NACHA files entirely in the browser (record structure, ABA check digits, entry hash, batch and file control totals, addenda 99/98/IAT decoded) and publishes one page per code at /en/errors/<code>.

### Fedwire and ISO 20022, one year on: what changed, and what breaks on 16 November 2026
URL: /en/blog/fedwire-iso20022-one-year-later

Covers: the state of the Fedwire Funds Service one year after its ISO 20022 migration. The Federal Reserve adopted ISO 20022 on a SINGLE DAY, 14 July 2025, with NO coexistence period: Friday 11 July 2025 was the last day the legacy FAIM 3.0.7 (Fedwire Application Interface Manual) tag-based format was supported, and FAIM-formatted messages sent after the cutoff were not accepted and were deleted during the migration weekend. The date 10 March 2025, still widely repeated, was the ORIGINAL plan and was postponed - it is not the migration date. Past messages remain retrievable for fifteen months, each in the format in which it was created. What changed inside the message: every message now travels with a mandatory head.001 Business Application Header, separate from the business document; the UETR became mandatory on the value messages (pacs.008, pacs.009, pacs.004) and the Fed validates its FORMAT but explicitly does NOT check uniqueness; the message set is narrower than assumed - pacs.008, pacs.009, pacs.004, pacs.002, camt.056 (return request) answered by camt.029, pain.013/pain.014 (drawdowns), admi.002 (technical reject) and camt.052 for reporting, with NO camt.053 on Fedwire at all; and date, time and amount formats are restricted beyond what the schema allows (UTC or UTC offset only, plain local time not supported; interbank settlement date as a bare YYYY-MM-DD local date; amounts carry no leading plus or minus sign). The Federal Reserve's own post-implementation FAQ names what breaks in production even when the XML is valid: CRLF inside free-format text elements, text elements containing only spaces, error T125 (the routing number in the BAH's From Member ID must belong to the FedLine Direct connection owner) and error T134 (Charge Bearer CRED used with no charges information - use SHAR, or state zero). A payment that has already settled is returned with a pacs.004, never with a new pacs.008 or pacs.009; a request to return one is a camt.056, never a camt.110 investigation. A rejected message comes back as an admi.002 carrying the IMAD of the rejected message in its related reference (or NOTAVAILABLE). Volume: Fedwire originated 217,296,700 transfers in 2025, averaging roughly $4.59 trillion per day. The SECOND mandatory cutover is Monday 16 November 2026 (cutover weekend 14-15 November, last normal day Friday 13 November): the fully unstructured postal address is REMOVED in favour of a single hybrid format for every party AND every agent, in every message (town name and country always required, plus at most two free-text lines of 70 characters, replacing the three lines of 35), the camt.110 and camt.111 investigation messages are redesigned, and an XSD pattern is introduced on text elements. Important nuance, and a common error: structured addresses are NOT yet mandatory for everyone - since July 2025 the hybrid end-state applies only to Ultimate Debtor, Initiating Party, Ultimate Creditor and Originator, while Debtor, Creditor and the agents remain on the interim regime (a structured address OR up to three free lines of 35 characters, never both) until 16 November 2026. Two production test Saturdays are scheduled: 19 September and 31 October 2026; a test group is mandatory above an average of 100 outbound messages per day via import or upload. The Fed states the driver openly: interoperability with the changes Swift and CHIPS are making. Related deadlines: CHIPS migrated to ISO 20022 on 8 April 2024; FedNow is ISO 20022 native; SWIFT's CBPR+ MT/ISO 20022 coexistence for cross-border payment INSTRUCTIONS ended 22 November 2025, while the MT 9xx reporting messages are deprecated rather than withdrawn; and SEPA's structured-address rule applies from 15 November 2026, the day before the Fedwire release. The exact ISO 20022 message version identifiers and the remittance field lengths are NOT published freely - they live in the Fedwire Implementation Guide on MyStandards, behind a login - and this article deliberately does not guess them. ValidateFin validates Fedwire ISO 20022 messages (pacs.008, pacs.009, pacs.004, camt.056) entirely in the browser.

### Validate your Factur-X before 1 September 2026: the checklist
URL: /en/blog/facturx-checklist-september-2026

Covers: what the French e-invoicing mandate actually changes on 1 September 2026 — RECEIVING an e-invoice becomes mandatory for every VAT-registered business with no size threshold, while ISSUING becomes mandatory only for large enterprises and mid-sized companies (ETI); SMEs and micro-enterprises issue from 1 September 2027. Invoices are exchanged through an approved platform (plateforme agréée / PDP): the 2026 Finance Act dropped the public portal (PPF) as an exchange platform and reduced it to a recipient directory, so there is no free state route for B2B, and Chorus Pro remains the B2G channel only. The core of the article is that EN 16931 compliance is NOT enough to be compliant in France: the French tax code adds four mandatory mentions that appear nowhere in the European standard's rules — (1) the buyer's SIREN, (2) the delivery address of the goods when it differs from the buyer's address, (3) the category of operation (exclusively supplies of goods, exclusively services, or both), and (4) the statement "option for payment of tax based on debits" where the seller has exercised that option. These four mentions follow the ISSUING calendar: they bind large and mid-sized companies from 1 September 2026, and SMEs and micro-enterprises from 1 September 2027 (source: service-public.gouv.fr). Also covers the three traps that produce a technically valid but refused invoice: a profile too thin to carry the required data (MINIMUM and BASIC WL carry neither line detail nor the required identifiers — issue in BASIC or EN 16931/COMFORT), a correct-looking PDF wrapping a wrong XML (the embedded CII XML is what the rules check, not the visual rendering), and testing only after the deadline. Ends with a five-step checklist run against a real invoice. ValidateFin validates a Factur-X PDF against EN 16931 using the standard's official Schematron, and adds a separate French-mandate layer — kept apart from the EN 16931 verdict — that checks the buyer's and seller's SIREN including its Luhn check digit, the presence of a delivery address, and the category-of-operation statement; the last two are never blocking, because how they are carried in CII is not settled by a free official source. Everything runs in the browser: no invoice is uploaded.

### SEPA structured addresses: the 15 November 2026 deadline for pain.001 and pain.008
URL: /en/blog/sepa-structured-address-2026

Covers: the EPC153-22 (v2.1) rule that, from 15 November 2026, forces a postal address carried in a SEPA credit transfer (pain.001) or direct debit (pain.008) to be structured or hybrid instead of free-text AdrLine. A structured address puts every component in its own element (StrtNm, BldgNb, PstCd, TwnNm, Ctry) with no AdrLine; a hybrid address keeps at most two AdrLine of 70 characters but must still add TwnNm and Ctry. The country (Ctry) alone is not enough — the town name (TwnNm) is the discriminator between an accepted and a rejected address. If an address is present but unstructured, the bank must reject the instruction. The trigger is the requested execution date (ReqdExctnDt) of a credit transfer or requested collection date (ReqdColltnDt) of a direct debit inside the file, not today's date — a file built today for a November execution is already non-compliant, which matters for standing orders and pre-sent direct debits. Scope is narrow: the requirement concerns the address of the payer and of the payee — the debtor (Dbtr) and creditor (Cdtr). EPC153-22 says nothing about ultimate parties (UltmtDbtr, UltmtCdtr), the initiating party (InitgPty) or the agents, so blocking those goes beyond the guidance. The 15 November 2026 date was aligned by the EPC with the November 2026 Swift Standards MX Release (second full weekend of that month), and the guidance also covers OCT Inst (section 7.2.3) alongside SCT (7.2.1) and SDD (7.2.2). Not to be confused with the SWIFT CBPR+ migration for interbank pacs messages, which is a different rail whose MT/ISO 20022 coexistence already ended in November 2025. ValidateFin reads the execution/collection date in the file, checks each Dbtr and Cdtr address against EPC153-22, and reports a blocking error when the date is on or after 15 November 2026 or a warning when earlier — entirely in the browser.

### SEPA Instant (SCT Inst): the 2025 instant credit transfer explained
URL: /en/blog/sepa-instant-credit-transfer

Covers: what a SEPA Instant Credit Transfer (SCT Inst) is (euro funds credited to the payee in under 10 seconds, 24/7/365), how it differs from a standard SCT, that it uses the same pain.001 message flagged with the local instrument code INST and the SEPA service level, and what the EU Instant Payments Regulation (Regulation (EU) 2024/886) changed: euro-area PSPs must receive instant since 9 January 2025 and send since 9 October 2025, charges may not exceed standard transfers, Verification of Payee is required, and the special €100,000 per-transaction cap has been removed. Includes a four-step checklist to prepare an instant pain.001 (SEPA service level + INST local instrument, creditor BIC where required, drop the old €100k cap, validate the file locally before sending).

### Verification of Payee (VoP): the 2025 SEPA name check explained
URL: /en/blog/verification-of-payee-sepa

Covers: what Verification of Payee (VoP) is (the payer's bank confirms the beneficiary name matches the IBAN before a credit transfer), the four standardised results (match, close match, no match, verification not possible), the legal mandate under the EU Instant Payments Regulation (Regulation (EU) 2024/886) — mandatory for euro-area PSPs since 9 October 2025, free of charge, applying to all SEPA credit transfers (SCT and SCT Inst) not just instant — and a four-step checklist to prepare pain.001 files (exact registered payee name, SEPA character set and 70-char limit, IBAN mod-97 validation, full file validation). A real VoP name-match query requires PSP access and cannot be done client-side; ValidateFin instead validates the file locally so it is ready for VoP without transmitting any data.

### BAI2 to camt.053: how to read and convert US & Canadian bank statements in 2026
URL: /en/blog/bai2-to-camt053

Covers: what a BAI2 file is (Bank Administration Institute v2, the dominant US/Canada cash-management statement format), its 01/02/03/16/88 record hierarchy record by record, how the numeric type code encodes debit/credit direction (100–399 credit, 400–699 debit), integer minor-unit amounts, how BAI2 maps to ISO 20022 camt.053, and how to convert a BAI2 file to camt.053 for free in the browser without uploading it.

### MT940 to camt.053: how to read and convert SWIFT bank statements in 2026
URL: /en/blog/mt940-to-camt053

Covers: what an MT940 file is (the legacy SWIFT Customer Statement Message), its tags (:20:, :25:, :60F:, :61:, :86:, :62F:) tag by tag, how it maps to ISO 20022 camt.053, RC/RD reversals, balance reconciliation, and how to convert an MT940 file to camt.053 for free in the browser. MT940 is being phased out as SWIFT migrates to ISO 20022 (retirement of the MT9xx statement messages is expected around 2027-2028).

### The ACH file format explained: NACHA records, routing check digit & control totals
URL: /en/blog/ach-nacha-file-format

Covers: what an ACH file is (the NACHA-governed fixed-width format for US automated clearing house payments), its record hierarchy (1 file header, 5 batch header, 6 entry detail, 7 addenda, 8 batch control, 9 file control), the routing number check digit (ABA mod-10 algorithm), how entry/batch/file control totals reconcile (entry/addenda counts, entry hash, total debit/credit amounts), common validation errors, and how to validate an ACH file for free in the browser without uploading it.

### Understanding SEPA pain.001 format: a complete guide
URL: /en/blog/sepa-pain001-guide

Covers: what pain.001 is, its XML structure (GrpHdr, PmtInf, CdtTrfTxInf blocks), mandatory fields, common validation errors, and how to fix them.

### Electronic invoicing with UBL 2.1 and Peppol BIS 3.0
URL: /en/blog/ubl-peppol-invoicing

Covers: what UBL is, the Peppol network and access points, BIS Billing 3.0 rules, EN 16931 compliance, and how to validate invoices before sending.

### XML validation best practices
URL: /en/blog/xml-validation-best-practices

Covers: 5 common XML validation mistakes in SEPA and UBL files, how to avoid them, and tools to use.

### IBAN validation: mod-97 checksum explained
URL: /en/blog/iban-validation-guide

Covers: the IBAN structure, how the mod-97 algorithm works step by step, country-specific BBAN formats, and common IBAN errors.

### Understanding camt.053 bank statements
URL: /en/blog/camt053-bank-statement

Covers: what camt.053 is, its XML structure (BkToCstmrStmt, Stmt, Bal, Ntry blocks), how to read balances and entries, and how to export data for accounting.

### Factur-X and ZUGFeRD hybrid PDF invoices explained
URL: /en/blog/facturx-zugferd-explained

Covers: the Factur-X and ZUGFeRD formats, the EN 16931 standard, profile hierarchy (MINIMUM to EXTENDED), and how to extract and validate the embedded XML.

### Validate SEPA, XRechnung & Peppol invoices from your AI assistant - the ValidateFin MCP server
URL: /en/blog/mcp-server-einvoicing

Covers: The ValidateFin MCP server lets AI assistants like Claude or Cursor run the SEPA, UBL/Peppol, XRechnung, IBAN and camt.053 validators directly - 100% locally, no data uploaded.

### EN 16931 Mandatory Fields: Required Invoice Fields and Their Formats
URL: /en/blog/en16931-mandatory-fields

Covers: A field-by-field reference of the mandatory EN 16931 invoice fields: business term codes, formats and examples for seller, buyer, lines, VAT and totals.

### Peppol BIS Billing 3.0 Business Rules: The Complete Reference
URL: /en/blog/peppol-bis-billing-rules

Covers: A reference to the Peppol BIS Billing 3.0 business rules (PEPPOL-EN16931-xx): what they validate, common failures, and how to diagnose and fix them.

### 8 Common IBAN Errors That Cause Payment Rejection - and How to Fix Them
URL: /en/blog/common-iban-errors

Covers: The most frequent IBAN errors in SEPA payments and e-invoices: exact rejection codes, root causes and step-by-step fixes to avoid costly returned payments.

### 10 Common Factur-X / ZUGFeRD Errors and How to Fix Them
URL: /en/blog/common-facturx-errors

Covers: The most frequent validation errors in Factur-X and ZUGFeRD invoices, with detailed explanations and step-by-step fixes. From PDF/A-3 structure errors to EN 16931 business rule failures.

### SEPA Direct Debit Guide 2026: pain.008, Mandates & Validation
URL: /en/blog/sepa-direct-debit-guide

Covers: How SEPA Direct Debit works: pain.008 structure, SDD Core vs B2B, mandate and pre-notification rules, return codes — plus how to validate your pain.008 free, in your browser.

### IBAN Format by Country: Complete Reference Guide for All 36 SEPA Countries
URL: /en/blog/iban-format-by-country

Covers: IBAN formats for all 36 SEPA countries: country codes, lengths, structure, example IBANs and mod-97 validation. A reference for finance teams and developers.

### Camt.052 vs Camt.053 vs Camt.054: What's the Difference?
URL: /en/blog/camt-052-vs-053-vs-054

Covers: Compare the three ISO 20022 cash-management reports: camt.052 (intraday), camt.053 (end-of-day) and camt.054 (debit/credit notification) - when to use each.

### E-invoicing in Belgium: The Complete Guide to the 2026 B2B Mandate
URL: /en/blog/e-invoicing-belgium-guide

Covers: Belgium mandates Peppol B2B e-invoicing from 2026: legal framework, accepted formats (UBL/Peppol BIS 3.0, Factur-X), the Mercurius platform and how to comply.

### ISO 20022 Migration Guide: Everything You Need to Know
URL: /en/blog/iso20022-migration-guide

Covers: The complete guide to ISO 20022: what it is, how it differs from SWIFT MT, its relationship to SEPA, the global migration timeline, and what businesses must do to prepare.

### EN 16931 Explained (2026): Fields, Business Rules & Free Validator
URL: /en/blog/en16931-complete-guide

Covers: Understand EN 16931 for EU e-invoicing: the CEN semantic model, UBL & CII syntaxes, country CIUS and business rules — then validate your invoice free, in your browser.

### XRechnung - Complete Guide to German E-Invoicing
URL: /en/blog/xrechnung-guide

Covers: Everything about XRechnung: the German CIUS of EN 16931, ZRE platform, B2G mandates, Wachstumschancengesetz B2B timeline, and validation rules.

### Chorus Pro - Complete Guide to French E-Invoicing Platform
URL: /en/blog/chorus-pro-guide

Covers: Everything you need to know about Chorus Pro: what it is, how it works, accepted formats, PDP platforms, and the 2026 e-invoicing reform timeline.

### Factur-X Profiles Explained - From MINIMUM to EXTENDED
URL: /en/blog/facturx-profiles-explained

Covers: Understanding the 6 Factur-X/ZUGFeRD profiles: what data each contains, when to use them, and how they map to EN 16931 compliance.

### The Peppol Network - A Complete Guide to European E-Invoicing Infrastructure
URL: /en/blog/peppol-network-complete-guide

Covers: Everything you need to know about the Peppol network: how it works, access points, SMP/SML, supported countries, and how to get connected.

### Fix Common UBL & Peppol BIS 3.0 Errors: Causes & Examples
URL: /en/blog/common-ubl-peppol-errors

Covers: The most frequent UBL 2.1 and Peppol BIS Billing 3.0 validation errors, with root causes, BR codes and practical fixes — plus a free validator to test your invoice in your browser.

### UBL vs CII vs Factur-X - Comparing European E-Invoice Formats
URL: /en/blog/ubl-vs-cii-vs-facturx

Covers: A practical comparison of the three main European e-invoicing formats: UBL 2.1, UN/CEFACT CII, and Factur-X/ZUGFeRD. Which one should you use?

### pain.001 vs pain.008 - SEPA Credit Transfer vs Direct Debit Explained
URL: /en/blog/pain-001-vs-pain-008

Covers: Understand the key differences between SEPA pain.001 (Credit Transfer) and pain.008 (Direct Debit) XML formats, when to use each, and how they work.

### 15 Common SEPA XML Errors and How to Fix Them
URL: /en/blog/common-sepa-xml-errors

Covers: A comprehensive guide to the most frequent SEPA pain.001 and pain.008 validation errors, with practical solutions for each.

### E-invoicing compliance in Europe: what businesses need to know in 2026
URL: /en/blog/e-invoicing-europe-2026

Covers: France, Germany, Belgium, and the Netherlands are all rolling out mandatory e-invoicing. Here is what EN 16931, Factur-X, Peppol, and the ViDA directive mean for your business.

### CSV to SEPA XML Converter: generate pain.001 from a spreadsheet
URL: /en/blog/csv-sepa-converter-guide

Covers: Turn any CSV or Excel file into a valid SEPA pain.001 or pain.008 XML file in seconds. Here is how the converter works and what your spreadsheet must contain.

## Validation rules (EN 16931, Peppol BIS 3.0, XRechnung)

URL: /en/rules

A free reference of 313 business rules enforced on Peppol BIS, UBL, XRechnung and Factur-X / ZUGFeRD e-invoices, organised as three stacked conformance layers. Each rule has its own page, in 8 languages, explaining what it checks and how to fix an invoice that fails it (example: /en/rules/br-co-10).

The three layers (a rule belongs to exactly one):
- EN 16931 (224 rules) - the CEN European core standard. Applies to every European e-invoice.
- Peppol BIS 3.0 (46 rules, PEPPOL-EN16931-*) - rules added by the OpenPeppol network on top of EN 16931. Apply to invoices exchanged on the Peppol network (e.g. Belgium, Luxembourg, Norway, Sweden, and B2G across the EU).
- XRechnung (43 rules, BR-DE-* and BR-DEX-*) - the German KoSIT national CIUS, on top of EN 16931 and Peppol. Mandatory for B2G in Germany.

EN 16931 rule families:
- BR-* - content rules: a field or element must be present (e.g. invoice number, seller VAT ID).
- BR-CO-* - conditional and calculation rules: totals must add up, dependent fields must be consistent.
- BR-DEC-* - decimal rules: amounts must not exceed the allowed number of decimal places.
- BR-CL-* - code-list rules: codes must come from the correct list (currencies ISO 4217, countries ISO 3166, VAT categories, units UN/ECE Rec 20, VATEX, EAS).
- BR-AF-* / BR-AG-* - document-level charge and allowance rules (VAT category, rate and amount consistency).
- VAT category rules (BR-S, BR-Z, BR-E, BR-AE, BR-IC, BR-G, BR-O, BR-B) - one set per VAT treatment (standard, zero, exempt, reverse charge, intra-community, export, not subject).

Severity: each rule is either fatal (the invoice is rejected) or a warning (flagged but not blocking). The rules come from the official Schematron published by CEN (EN 16931), OpenPeppol (Peppol BIS 3.0) and KoSIT (XRechnung); ValidateFin's UBL, XRechnung and Factur-X validators run those official Schematron packs. The same EN 16931 core applies across all three syntaxes; Peppol and XRechnung each add their own rules on top.

## Business terms (EN 16931 semantic model)

URL: /en/terms

A free reference of the EN 16931 semantic data model: every business term (BT-1 … BT-165) and business group (BG-1 … BG-32) that makes up a compliant European electronic invoice. 163 business terms + 32 business groups, each with its own page in 8 languages giving its cardinality, data type, the exact mapping into the three EN 16931 syntaxes (UBL 2.1, UN/CEFACT CII D16B, and the Factur-X / ZUGFeRD profile), and the BR-* / Peppol / XRechnung rules that reference it. Each term page is marked up as a schema.org DefinedTerm, so it can be cited individually; the whole set is a DefinedTermSet and a Dataset with a real CC-BY-4.0 download.

Business terms are grouped into business groups, in document order: header terms (BT-1 Invoice number, BT-2 Issue date, BT-3 Invoice type code, BT-5 Currency, BT-9 Payment due date, BT-24 Specification identifier…), BG-4 SELLER (BT-27 Seller name, BT-31 Seller VAT identifier…), BG-7 BUYER, BG-10 PAYEE, BG-11 Seller tax representative, BG-13 DELIVERY INFORMATION, BG-14 INVOICING PERIOD, BG-16 PAYMENT INSTRUCTIONS (with BG-17 CREDIT TRANSFER, BG-18 PAYMENT CARD, BG-19 DIRECT DEBIT), BG-20/BG-21 document-level allowances and charges, BG-22 DOCUMENT TOTALS (BT-106 … BT-115), BG-23 VAT BREAKDOWN (BT-116 … BT-121), BG-24 supporting documents, and BG-25 INVOICE LINE with its sub-groups (BG-26 line period, BG-27/28 line allowances/charges, BG-29 PRICE DETAILS, BG-30 line VAT, BG-31 ITEM INFORMATION, BG-32 item attributes). Examples: /en/terms/bt-1 (Invoice number), /en/terms/bt-27 (Seller name), /en/terms/bt-112 (Invoice total with VAT), /en/terms/bg-25 (Invoice line).

Nothing exists cleanly on the web for the UBL ↔ CII ↔ Factur-X mapping of every business term, in 8 languages, with a downloadable file. The full dataset is at /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. For each term: id, kind (bt/bg), parent group, cardinality, data type, the UBL/CII/Factur-X mapping, and names + definitions in all 8 languages.

## ISO 20022 schemas

URL: /en/schemas

Factual reference for the SEPA payment (pain) and cash-management (camt) ISO 20022 message schemas ValidateFin supports: namespace, root element, versions and which validate against the official XSD. Each schema page links to a free validator.

- pain.001 (CustomerCreditTransferInitiation) - SEPA credit transfer. Root element CstmrCdtTrfInitn. Versions .03 (2009), .09 (2019), .11 (2021), all XSD-validated. URL: /en/schemas/pain.001
- pain.008 (CustomerDirectDebitInitiation) - SEPA direct debit. Root element CstmrDrctDbtInitn. Versions .02, .08. URL: /en/schemas/pain.008
- camt.053 (BankToCustomerStatement) - end-of-day bank statement. Root element BkToCstmrStmt. Versions .02, .06, .08, .10, .11. URL: /en/schemas/camt.053
- camt.052 (BankToCustomerAccountReport) - intraday account report. URL: /en/schemas/camt.052
- camt.054 (BankToCustomerDebitCreditNotification) - individual debit/credit notification. URL: /en/schemas/camt.054

A namespace looks like urn:iso:std:iso:20022:tech:xsd:pain.001.001.09. Where an official ISO 20022 XSD is bundled, ValidateFin enforces it (Layer 1); otherwise validation is structural.

## Glossary

URL: /en/glossary

A free glossary of 59 defined terms used across the financial formats ValidateFin supports: SEPA, ISO 20022 (pain and camt), UBL / Peppol, EN 16931, IBAN, and the US/Canada formats (ACH, ABA, MT940, BAI2). Each term is marked up as a schema.org DefinedTerm inside a DefinedTermSet, so it can be cited individually.

Terms covered include: access point, bank statement, BBAN, BIC, BIS Billing, Business Application Header, camt.052 / camt.053 / camt.054, EndToEndId, Creditor Scheme Identifier (ICS), IBAN, Leitweg-ID, mandate, pain.001 / pain.008, Peppol, routing number (ABA/RTN), SEPA, XRechnung, ZUGFeRD, and more. Each entry gives a concise definition aimed at people integrating or debugging these formats.

## Downloadable datasets (CC-BY-4.0 JSON)

Open, reusable reference data behind the pages, each served as a static JSON file under a permissive CC-BY-4.0 licence, CORS-open for reuse. These are the real files behind the Dataset JSON-LD declared on the corresponding pages:
- /data/en16931/business-terms.json — the 195 EN 16931 business terms and groups (BT-*, BG-*): cardinality, data type, UBL / UN-CEFACT CII / Factur-X mapping, and names + definitions in 8 languages. Backs /en/terms.
- /data/iban/countries.json — IBAN reference for 42 countries: BBAN structure, a mod-97-valid specimen, and the major banks with their national bank code and BIC. Structure per the SWIFT IBAN Registry. Backs the /en/tools/iban/[country] pages.
- Code-list downloads under /data/codelists/ (e.g. /data/codelists/vatex.json for the VATEX VAT exemption reason codes, BT-121). Backs /en/resources/codelists.
- /data/errors/index.json — the 36 SEPA payment rejection reason codes (ISO 20022 ExternalStatusReason1Code) carried by a pain.002: for each code, the category, a worked pain.002 example, and title + meaning + typical causes + remedy in 8 languages. Each code also carries a `recoverable` boolean — whether the sender can fix the cause and resubmit the same payment (21 codes) or the rejection is final (15 codes). That flag is the part no official ISO 20022 source publishes. Backs /en/errors.
- /data/e-invoicing/mandates.json — the e-invoicing mandate matrix for 32 European jurisdictions (the EU-27 plus the UK, Norway, Switzerland, Iceland and Liechtenstein): B2G, B2B and e-reporting status with dates and phases, the model (clearance / centralised / decentralised / post-audit), formats, network, legal basis and the official government or EU source for each. The part no vendor map ships is the sourcing: every row names its government or EU page, and a row that could not be verified is marked "unverified" rather than guessed. It corrects the widely-repeated wrong dates — Slovenia is 1 January 2028 (not June 2026), Latvia moved to 2028, Hungary has no B2B mandate (RTIR is data reporting), and Spain has no legally fixed B2B date yet. Backs /en/e-invoicing/mandates.

## SEPA payment rejection codes (pain.002)

When a SEPA credit transfer (pain.001) or direct debit (pain.008) is not executed, the bank returns a pain.002 status report carrying a reason code in StsRsnInf/Rsn/Cd. The codes are cryptic (AC04, AM04, MD01) and the official ISO 20022 External Code Sets give only a one-line English label — they do not tell you the thing that actually matters operationally: whether resubmitting the same payment can work.

ValidateFin publishes one page per code at /en/errors/[code], in 8 languages, each stating:
- what the code means (answer-first, marked up as a schema.org DefinedTerm);
- whether the rejection is RECOVERABLE — correct the cause and the identical payment can be resubmitted — or FINAL, where resubmitting will simply fail again. 21 of the 36 codes are recoverable, 15 are final;
- the typical real-world causes;
- the remedy;
- a generated pain.002 example carrying that code in situ (a mandate reason such as MD01 shows a pain.008 original, since it can only ever arrive on a direct debit; all others show a pain.001).

Worked examples of the recoverable/final distinction, which is the hub's reason to exist:
- AM04 (insufficient funds) is RECOVERABLE: nothing is wrong with the file, the balance was simply too low. Top the account up and resubmit the identical payment.
- AC04 (account closed) is FINAL: the account no longer exists. Resubmitting the same payment will fail again for ever; you must obtain a new IBAN from the beneficiary.
- MD01 (no valid mandate) is FINAL: a SEPA mandate lapses after 36 months without a collection, and no amount of retrying creates one. Get a signed mandate first.
- MS03 (reason not specified by bank) is FINAL only in the sense that retrying blindly is futile — the bank gave no reason at all, so the next action is to ask it.

The 36 codes are the curated set actually met in SEPA. The exhaustive raw ISO 20022 list (302 codes, English labels only, no advice, no translation) is published separately as a table at /en/resources/codelists/iso20022-status-reason, deliberately NOT as 302 thin pages.

The pain.002 reader at /en/tools/pain002 decodes a real status report entirely in the browser and links every reason code it finds straight to its page.

## ACH administrative codes — Notification of Change (NOC) and Standard Entry Class (SEC)

Two reference tables at /en/resources/codelists/nacha-noc and /en/resources/codelists/nacha-sec, each with a CC-BY-4.0 JSON download (/data/codelists/nacha-noc.json, /data/codelists/nacha-sec.json) in which every single code carries the official sources it was verified against.

These are NOT rejections, and that distinction is the point. The ACH return codes (R01-R85) live in the /errors hub because they mean the payment failed. A NOC means the opposite: the payment WAS posted, and the receiving bank is telling the Originator that its stored data is wrong and must be corrected for future entries. Re-sending a payment after a NOC is the classic and expensive mistake — it pays twice. The Originator must apply the correction within six banking days or before the next entry to that account, whichever is later. A SEC code, meanwhile, is a classification, not an outcome: it says what kind of entry this is, and it is what decides the authorization the Originator must hold and how long the receiver has to return the entry.

What is true, and where the rest of the web is wrong (the Nacha Operating Rules book is copyrighted and sold, so most public lists are copies of copies):
- There are exactly 10 NOC change codes: C01, C02, C03, C05, C06, C07, C08 (IAT only), C09, C13, C14. C14 is sent by a Gateway, not by the receiving bank, to say an outbound payment must be reclassified IAT.
- C04 ("Incorrect Individual Name/Receiving Company Name") was REMOVED from the Rules in 2015, confirmed by the US Federal Register. moov-io and PayPal still list it as live. It is not a valid code.
- C10, C11 and C12 ("Incorrect Company Name / Company Identification") DO NOT EXIST. The Rules table goes straight from C09 to C13. Many processors and bank PDFs publish them anyway; the likely origin is a confusion with C63, "Incorrect Company Identification Number", which is a refused-NOC code sent by the ODFI — a refusal of a NOC, not a request to fix a company ID.
- The 9 refused-NOC codes C61-C69 travel the other way: the originating bank telling the receiving bank it cannot act on the NOC it received.
- The US federal government's disbursing systems process only a subset: change codes C01, C02, C03, C05, C06, C07, and refused codes C64-C69 (US Treasury Green Book).
- There are exactly 23 SEC codes, not 13 — the "13 SEC codes" claim comes from a mistaken sentence in one widely-copied article and is contradicted by that article's own table.
- CBR and PBR no longer exist: IAT replaced them (confirmed by the Federal Reserve).
- Six SEC codes are non-monetary (zero dollar, not payments): COR, ACK, ATX, ADV, DNE, ENR. ACK is the RDFI acknowledging receipt of a CCD credit; ATX is its CTX counterpart; ADV is produced by the ACH Operator itself, not by a bank.
- Two official titles are routinely published wrong: TRC is "Check Truncation Entry" (not "Truncated Entry") and ACK is "ACH Payment Acknowledgment" (not "Acknowledgment Entry").
- The SEC code sets the return window: an administrative return is due in two banking days for everyone, but a consumer disputing an unauthorized debit under PPD, WEB or TEL has sixty calendar days, whereas a business under CCD or CTX must return an unauthorized entry (R29) by the opening of the second banking day. TEL allows debits only.

Sources used, all official and free: the appendixes Nacha itself publishes (Appendix Three subpart 3.2.2 for SEC codes, Appendix Five part 5.3 for change codes), the US Treasury Green Book chapter 6, the Federal Register (31 CFR Part 210) and the Federal Reserve. The Rules book itself was not purchased.

## IBAN by country — extended coverage

In addition to the SEPA zone, ValidateFin now has dedicated IBAN pages for high-volume non-SEPA countries, each with the BBAN breakdown, a mod-97-valid example, the major banks (national bank code + BIC) and an FAQ: Turkey (TR, 26 chars, /en/tools/iban/turkey), Brazil (BR, 29, /en/tools/iban/brazil), Israel (IL, 23, /en/tools/iban/israel), United Arab Emirates (AE, 23, /en/tools/iban/united-arab-emirates), Saudi Arabia (SA, 24, /en/tools/iban/saudi-arabia). BBAN structure is sourced from the SWIFT IBAN Registry.

## Technical stack

- Frontend: Next.js 16, React 19, TypeScript, Tailwind CSS
- Processing: 100% client-side (browser) — no backend API
- Validation: TypeScript validators (SEPA, UBL, Camt.053, IBAN)
- Deployment: Docker + Traefik, European hosting
- i18n: next-intl (English, French, Dutch, German, Spanish, Italian, Portuguese, Polish)
- Security: CSP with nonce, HSTS, rate limiting, all processing client-side

## Company

Elni Consulting
Belgian digital agency — founded 2024
Location: Ramillies, Brabant Wallon, Belgium
Website: elniconsulting.be
Focus: digital transformation for SMEs, web development, IT equipment