@validatefin/mcp

@validatefin/mcp

MCP server to validate SEPA, UBL/Peppol, XRechnung, KSeF FA(3), camt.052/053/054, ACH/NACHA, CPA-005 (Canada), Belgian CODA and French CFONB 120 e-invoice / payment / bank-statement files, to read and write SEPA (EPC) and Swiss QR codes, and to convert MT940, BAI2, CODA and CFONB to ISO 20022 camt.053 — 100% locally, no data leaves your machine. Powered by ValidateFin.

Tools

34 tools, grouped by what they take as input.

Tool	Input	What it does
validate_sepa	xml	SEPA Credit Transfer (pain.001) & Direct Debit (pain.008)
validate_ubl	xml	UBL / Peppol BIS Billing 3.0 invoice & credit note
validate_xrechnung	xml	German XRechnung (UBL or CII)
validate_camt	xml	ISO 20022 camt.052 / camt.053 / camt.054
validate_ksef	xml	Polish KSeF FA(3) structured invoice
validate_nav	xml	Hungarian NAV Online Számla 3.0 invoice — reports whether the NAV would reject the file, with its official ValidatorFaultType and verbatim message. Two layers: the official NAV XSD (published by the tax authority under the MIT licence), then the rejection controls the NAV publishes itself (line numbering, seller ≠ buyer, VAT codes, and the full arithmetic of lines and summary). Handles batch invoices and header-only modification documents. Since 2021 every Hungarian invoice goes through this XML, with no threshold — and when completenessIndicator is true, the XML is the electronic invoice. Lists what needs the NAV database.
validate_jpk	xml	Polish JPK_V7M(3) VAT control file (variant (3), in force since 1 Feb 2026) — not an invoice and not KSeF: the monthly VAT return (P_* boxes) plus the sales and purchase registers (K_* columns). Beyond the official Ministry of Finance XSD, it reports — as non-blocking warnings — whether the registers actually feed the return (Σ K_* against each P_* box), the control counters, the row numbering and the NIP mod-11 check digit. Warnings and not errors because the Ministry publishes no numbered rejection codes, and its own two sample files are internally inconsistent.
validate_efactura	xml	Romanian RO e-Factura — the official CIUS-RO Schematron of the Ministry of Finance (ro16931-ubl-1.0.9: EN 16931 core + BR-RO-*), the OASIS UBL 2.1 XSD, and the CUI/CNP check ANAF runs outside the Schematron (ERRIdentif) and that Schematron-only validators miss.
validate_verifactu	xml	Spanish Verifactu / SIF billing records (AEAT) — reports whether the AEAT would reject the submission, with its official code. Two layers: the official AEAT XSD (SuministroLR + SuministroInformacion), then the controls published in Validaciones y errores v1.2.2 (1108, 1114/1115, 1130, 1138/1139, 1142 CuotaRepercutida ±10 €, 1152, 1177, 1189/1190, 1195/1196, 1223). It recomputes the huella, the chained SHA-256 fingerprint that makes the invoice chain tamper-evident — reproducing the three official vectors of the AEAT hash spec. A wrong huella is not a rejection but code 2000 (aceptado con errores). Lists what needs the AEAT censo and cannot run offline. Not certified or endorsed by the Agencia Tributaria.
validate_facturae	xml	Spanish Facturae electronic invoice — the official B2G format (invoicing public administrations via FACe, law 25/2013). Two layers: the official XSD of facturae.gob.es (Ministerio de Hacienda) for versions 3.2 / 3.2.1 / 3.2.2, selected from the root namespace; then coherence controls derived from the schema's own formulas (line TotalCost = Quantity × UnitPrice, GrossAmount, InvoiceTotal = before-tax + tax − withheld, per-tax cuota, batch totals), the form of the NIF/CIF/NIE, and whether a XAdES <ds:Signature> is present — all as warnings, since Facturae/FACe publishes no numbered offline rejection list. States what it cannot check offline: the cryptographic validity of the signature, the NIF against the AEAT censo, the DIR3 codes and the FACe status. Not certified or endorsed by the Ministerio de Hacienda.
validate_fatturapa	xml / contentBase64	Italian FatturaPA — official AdE XSD and the SdI rejection controls (00421, 00422, 00427, 00445, 00471…), with the exact code the SdI would return. Signed .p7m (CAdES) envelopes supported.
validate_fedwire	xml	Fedwire Funds Service ISO 20022 message (US) — the official ISO 20022 XSDs (head.001 BAH + pacs.008 / pacs.009 / pacs.004 / pacs.028 / camt.056 / camt.029), plus the hybrid postal address the Federal Reserve requires from 16 Nov 2026 (triggered by the settlement date in the message, never today's), the ABA 3-7-1 check digit, and header/document coherence. The Fedwire Usage Guidelines are on Swift MyStandards behind a login and are not checked — the response says so.
read_mt103	content	SWIFT MT103 credit transfer → structured JSON: the five SWIFT blocks, every field of block 4 with a plain-language label, and the parsed parties. Field specs sourced from the ECB TARGET2 UDFS (public). The SWIFT Network Validated Rules are not checked.
generate_camt_test	xml	camt.053 test statement from a pain.001 / pain.008
validate_ach	content	US ACH / NACHA fixed-width file
validate_cpa005	content	Canadian CPA-005 / AFT payment file
validate_coda	content	Belgian CODA bank statement (Febelfin)
convert_coda	content	CODA → camt.053
validate_cfonb	content	French CFONB 120 / AFB120 bank statement
convert_cfonb	content	CFONB 120 → camt.053
convert_mt940	content	SWIFT MT940 → camt.053
convert_bai2	content	BAI2 (US/Canada) → camt.053
convert_camt_to_mt940	content	camt.053 → SWIFT MT940 (the reverse direction)
convert_camt_to_csv	content	camt.052/053/054 → CSV, one row per entry
sepa_dates	date, scheme	SEPA settlement date, D-1 deadline, refund window; TARGET calendar
validate_epc_qr	payload	SEPA EPC QR code payload (EPC069-12)
generate_epc_qr	fields	Build a SEPA EPC QR code payload
validate_swiss_qr	payload	Swiss QR-bill payload (SIX guidelines)
validate_iban	iban	IBAN (mod-97)
validate_aba	routingNumber	US ABA routing number (RTN)
validate_lei	lei	Legal Entity Identifier (ISO 17442)
validate_creditor_id	ics	SEPA Creditor Identifier (ICS / CI) — the identifier in <CdtrSchmeId> of a pain.008 and on every mandate. ISO 7064 MOD 97-10. ⚠️ The Creditor Business Code is EXCLUDED from the check digits: FR72ZZZ123456 and FR72ABC123456 carry the same key — treating the ICS like an IBAN rejects precisely the large issuers.
validate_portugal_qr	payload	Portuguese invoice QR code + ATCUD (Autoridade Tributária). Field structure A→S, amount format, the ATCUD ↔ document-number link, the issuer NIF, and the two arithmetic identities of the spec — verified against its seven official examples. ⚠️ The ATCUD has no check digit at all (the code is assigned by the tax authority), and the buyer NIF is only checked when the country is PT.
validate_pix	payload	Brazilian Pix / BR Code (Banco Central do Brasil). TLV structure and CRC-16 — the implementation reproduces the five CRCs of the five official BCB examples. Static / dynamic / recurring QR codes, and the mod-11 of CPF and CNPJ, including the alphanumeric CNPJ of 2026 (whose check digits are computed on ASCII − 48: a digits-only implementation rejects lawfully issued numbers).

E-invoicing & payments

• validate_sepa — SEPA Credit Transfer (pain.001) & Direct Debit (pain.008): validates against the official ISO 20022 XSD schemas and the EPC Rulebook business rules (IBAN mod-97, BIC, SEPA character set, mandates, Creditor Scheme Identifier, control sums).
• validate_ubl — UBL invoice / credit note (EN 16931, Peppol BIS Billing 3.0 syntax): runs the official EN 16931 Schematron — the same rule set used by the official European e-invoicing validators — and returns the failed business rules with their official IDs (BR-, BR-CO-). Accepts both the UBL and CII syntaxes (auto-detected).

  ⚠️ The Peppol-specific rules (PEPPOL-EN16931-*) are not run. OpenPeppol publishes no licence for its validation artefacts, so we do not redistribute them; written permission has been requested. A file that passes is EN 16931-conformant — necessary, but not sufficient, for Peppol BIS conformance.

• validate_xrechnung — German XRechnung (the German CIUS of EN 16931, mandatory for B2G): runs the official EN 16931 core Schematron + the KoSIT XRechnung BR-DE rules — the same rule sets as the official German validator. Accepts UBL and CII. Returns failed rules with their IDs (BR-, BR-DE-).
• validate_ksef — Polish KSeF FA(3) structured invoice (Krajowy System e-Faktur), mandatory since 1 Feb 2026 (sales > PLN 200m) / 1 Apr 2026 (everyone else): validates against the official Ministry of Finance XSD published on crd.gov.pl — structure, data types, cardinalities and closed code lists (RodzajFaktury, VAT rates) — and clearly reports files still using the retired FA(2) schema. Also reports, as non-blocking warnings, the NIP mod-11 check digit and the coherence of the VAT totals (P_13_, P_14_, P_15) with the invoice lines.
• validate_ach — US ACH / NACHA file (fixed-width Nacha format): validates the 94-character record structure (File Header, Batch Header, Entry Detail, Addenda, Batch/File Control), the ABA routing-number check digit (3-7-1), the entry hash, and all batch & file control totals (debits, credits, entry/addenda count, block count). Decodes returns (addenda 99), Notices of Change (addenda 98) and international entries (IAT, addenda 10-18).
• validate_cpa005 — Canadian CPA Standard 005 AFT payment file (also called EFT 1464) — the format Canadian banks use for direct deposits and pre-authorised debits. Records are 1464 characters: a 24-character prefix plus six 240-character segments, so one record carries up to six transactions. Checks the record types (A header, C credit, D debit, E/F error corrections, I/J returns, Z trailer), the logical record count, the origination control data repeated on every record, the four separate pairs of control totals in the Z trailer (error corrections are never folded into the debit/credit totals), the 0YYDDD Julian dates, and the transaction and 900-series return reason codes of CPA Standard 007. Also reads Notice of Change files (U/S/V records). Note: a Canadian routing number has no check digit — unlike the US ABA number — so only its shape is validated, never an invented checksum.

QR codes

• validate_epc_qr — decode and validate the payload of an EPC QR code (EPC069-12 v3.1) — the "scan to pay" QR code printed on European invoices for a SEPA credit transfer. Checks the twelve-line structure, the BIC (mandatory in version 001, conditional in 002), the beneficiary IBAN (mod-97), the euro amount bounds, the ISO 11649 creditor reference check digits, the mutual exclusivity of the structured reference and the unstructured message, and the 331-byte payload cap (bytes of the declared character set, not characters).
• generate_epc_qr — build the payload of an EPC QR code for a SEPA credit transfer, and validate it on the way. Returns the payload text to encode into a QR code (error correction level M).
• validate_swiss_qr — decode and validate the payload of a Swiss QR-bill (SIX Implementation Guidelines). Checks the 31-to-34-line structure, the fixed values (SPC / 0200 / 1 / EPD trailer), the CH or LI IBAN, the currency (CHF or EUR only), and above all the account/reference pairing the guidelines require a decoder to verify: a QR-IBAN (institution ID in positions 5-9 between 30000 and 31999) requires a QRR reference, while a standard IBAN forbids one and takes SCOR (ISO 11649) or NON. Verifies the recursive modulo-10 check digit of the QR reference (not the IBAN's mod-97) and the mod-97 check digits of an RF creditor reference. Use spec: "2.4" for the rules that take effect on 14 November 2026; version 2.3 stays valid until November 2027.

Bank statements

• validate_camt — ISO 20022 camt cash-management file — camt.053 (bank-to-customer statement), camt.052 (account report / intraday) or camt.054 (debit/credit notification), versions .02/.06/.08/.10/.11: extracts account, balances and entries (camt.053 also validated against the official ISO 20022 XSD schema).
• validate_coda — Belgian CODA bank statement ("Coded statement of account", the Febelfin standard, version 2.8): parses the fixed-width 128-character record hierarchy (0 header, 1 old balance, 2.1/2.2/2.3 movements, 3.1/3.2/3.3 information, 8 new balance, 4 free communication, 9 trailer), the 8-character transaction codes, the explicit debit/credit sign (0 = credit, 1 = debit) and the 3-decimal amounts. Checks the trailer control totals and record count (record 9), the accounting identity (old balance ± booked movements = new balance) and — uniquely — the check digits of the Belgian structured communication (+++123/4567/89012+++, mod 97, types 101/102) and of the ISO 11649 "RF" creditor reference (mod 97-10, type 100). A wrong structured reference is the most common reason a Belgian payment is never matched to its invoice, and no other free CODA validator verifies it.
• convert_coda — convert a CODA statement to an ISO 20022 camt.053.001.02 XML statement (booked movements only — the detail records under a globalisation would double-count).
• validate_cfonb — French CFONB 120 bank statement ("Relevé de compte sur support informatique", also called AFB120): parses the fixed-width 120-character records (01 old balance, 04 movement, 05 supplement, 07 new balance) and correctly decodes the two traps of the format — the sign is overpunched on the last character of the amount (COBOL zoned decimal: { and A–I = credit, } and J–R = debit), and the number of decimals is a field of the file (position 20), not a property of the currency. Decodes the SEPA data carried by the 05 records through their 3-letter qualifiers (LIB, MMO, NPY, IPY, NBE, IBE, LCC, LC2, LCS, RCN, REF, CBE, CPY, RUM…) and checks the accounting identity the CFONB itself requires (§1 rule 2: the new balance equals the algebraic sum of the old balance and of every movement).
• convert_cfonb — convert a CFONB 120 statement to an ISO 20022 camt.053.001.02 XML statement.
• convert_camt_to_mt940 — convert a camt.053 to SWIFT MT940 — the reverse of every other converter here. Banks now deliver camt.053, while a long tail of ERP and accounting systems only reads MT940; this is the gap. Emits :20:/:25:/:28C:/:60F:/:61:/:86:/:62F: (plus :64: when the statement carries a closing available balance), one block per statement. Preserves the balances with their sign, the value and booking dates, the customer reference (from EndToEndId) and the bank reference (from AcctSvcrRef), and marks reversals with the MT940 RC/RD marks rather than flattening them into an ordinary movement. The limits are reported, not hidden: only booked entries are emitted (MT940 cannot express "pending", so including one would claim money moved, and would break the :60F: ± :61: = :62F: reconciliation); text is folded into the SWIFT character set, so accents are stripped ("Société Générale" → "Societe Generale"); references are cut to MT940's 16 characters where camt.053 allows 35. Only camt.053 converts — camt.052 and camt.054 carry no opening/closing balance pair and are refused rather than given invented balances.
• convert_camt_to_csv — flatten a camt.052/053/054 into CSV, one row per entry, for Excel, an import mapping or a reconciliation script. Every statement of a multi-statement file is included. Amounts follow the currency's own minor unit (JPY none, KWD three) rather than a hardcoded two. Unlike the MT940 conversion it keeps pending entries, because CSV has a status column and can say so. Cells are guarded against spreadsheet formula injection.

Dates

• sepa_dates — what actually happens to a SEPA payment, and when, from the rulebooks in force. For a direct debit Due Date: the settlement date (a due date on a closed day is not an error — the rulebook states that settlement moves to the next Inter-PSP Business Day), the D-1 presentation deadline, the earliest presentation and latest pre-notification (both 14 calendar days before), the latest return settlement (5 Inter-PSP Business Days for CORE, 3 for B2B), and for CORE the refund window (8 weeks no-questions-asked, 13 months for an unauthorised transaction — B2B has no refund right for an authorised collection). Also says whether TARGET is open on a date and lists a year's six closing days. D-1 applies to every sequence type: the rulebook says the deadline holds "irrespective of whether the Collection is presented as an one-off or a recurrent Collection", and that using FRST at all "is no longer mandatory" — the D-5/D-2 split was retired in November 2016 and survives only in stale guides. Sources: ECB long-term TARGET calendar (14/12/2000) and EPC rulebooks EPC016-06 SDD Core 2025 v1.1, EPC222-07 SDD B2B 2025 v1.0, EPC125-05 SCT 2025 v1.1. What it will not tell you: a credit transfer's settlement date (the SCT rulebook counts in Banking Business Days — days a PSP in the relevant jurisdiction is open for customers — not on the TARGET calendar), national bank holidays, or your bank's cut-off time. None of the three is in any free authoritative source, so none is asserted.
• validate_fedwire — validate a Fedwire Funds Service ISO 20022 message (the Federal Reserve's USD RTGS, on ISO 20022 since 14 July 2025). Both halves — the head.001 business application header and the pacs/camt document — are checked against their official ISO 20022 XSD. On top: the hybrid postal address required from 16 November 2026 for all parties and agents (town name + country, at most two free-text lines), the ABA 3-7-1 check digit of every USABA routing number, and header/document coherence. It does not tell you whether Fedwire would accept the message: the Usage Guidelines are on Swift MyStandards behind a login, and the response lists what was skipped.
• read_mt103 — decode a SWIFT MT103 into structured JSON: the five blocks, every field of the text block with a plain-language label, and the parties (account and BIC kept apart). Field specifications come from the European Central Bank TARGET2 UDFS — public and free. The SWIFT Network Validated Rules (C1–C18) are in the paid User Handbook and are not verified.
• convert_mt940 — convert a legacy SWIFT MT940 bank statement (Customer Statement Message) to an ISO 20022 camt.053.001.02 XML statement: parses the balances and transactions, checks that opening balance + turnover = closing balance (RC/RD reversals handled), and returns the camt.053 XML.
• convert_bai2 — convert a BAI2 (Bank Administration Institute, version 2) cash-management statement — the dominant US/Canada format — to an ISO 20022 camt.053.001.02 XML statement: parses the 01/02/03/16/88 record hierarchy, infers the direction from the numeric type code (100–399 credit, 400–699 debit), scales the integer minor-unit amounts by the currency, and checks that opening ledger (010) + turnover = closing ledger (015).

Identifiers & test data

• validate_iban — IBAN (mod-97 checksum, country & length).
• validate_aba — US ABA routing number (RTN): 9-digit structure, the 3-7-1 check digit (mod 10) and the Federal Reserve routing symbol / district.
• validate_lei — Legal Entity Identifier (ISO 17442): 20-character structure and the check digits (ISO/IEC 7064 MOD 97-10, the same scheme as the IBAN); suggests the expected check digits when a LEI is mistyped. A valid checksum only proves there is no typo — it does not prove the LEI exists, which entity it belongs to, or whether it is still active (a LEI is renewed yearly and can be LAPSED, RETIRED or ANNULLED). Those need the GLEIF registry, which is an online lookup.
• generate_camt_test — generate a camt.053 test statement from a pain.001 / pain.008 file.

The XML validation tools take the file content as xml (a string) and return the result (valid/invalid, errors, summary) as JSON. The fixed-width / text formats (validate_ach, validate_cpa005, validate_coda, convert_coda, validate_cfonb, convert_cfonb, convert_mt940, convert_bai2) take the raw file as content; validate_epc_qr and validate_swiss_qr take the decoded QR text as payload; validate_iban takes an iban string and validate_aba a routingNumber. The convert_* tools and generate_camt_test return the generated camt.053 XML, and generate_epc_qr returns the payload text to encode into a QR code.

Install

Add this to your MCP client configuration (Claude Desktop, Cursor, etc.):

{
  "mcpServers": {
    "validatefin": { "command": "npx", "args": ["-y", "@validatefin/mcp"] }
  }
}

Then ask your assistant to validate a SEPA, UBL/Peppol, camt.052/053/054, ACH/NACHA, CODA or CFONB file — or to convert an MT940, BAI2, CODA or CFONB statement to camt.053.

Privacy

Validation runs entirely on your machine. No file or data is ever uploaded to a server — the same privacy guarantee as the ValidateFin website.

License

The MCP server code is MIT. It bundles third-party components under their own licenses:

• SaxonJS (© Saxonica) — runs the official Schematron; redistributed under the SaxonJS license (free, used unmodified).
• EN 16931 validation rules (© European Union / ConnectingEurope) — EUPL v1.2. Compiled to a Saxon SEF; the rules themselves are unmodified.
• XRechnung validation rules (© KoSIT) — Apache-2.0. Compiled to a Saxon SEF; the rules themselves are unmodified. The KoSIT NOTICE is reproduced in THIRD-PARTY-NOTICES.txt, shipped with this package.
• RO_CIUS validation rules (© Ministerul Finanțelor, Romania) — EUPL v1.2.
• Peppol BIS 3.0 validation rules (© OpenPEPPOL AISBL) — not included. OpenPeppol publishes no licence for these artefacts and states that its BIS "may not be modified, re-distribute, sold or repackaged […] without the prior consent of OpenPEPPOL AISBL". We have asked for that permission; until it is granted, the artefacts are not shipped.
• libxml2 (libxml2-wasm) — MIT.

Full notices, including which artefacts were modified and how: THIRD-PARTY-NOTICES.txt.

ValidateFin is an independent tool and is not certified or endorsed by OpenPEPPOL, the European Commission, or any Peppol Authority. "Official" refers to the rule sets/schemas used, not to any accreditation of this tool.