PacsLintISO 20022 payment file checkerSend feedback

Check and fix your pain.001 fileConvert pain.001.001.03 to .09Check and fix your ACH (Nacha) file

Validate against the official ISO 20022 schema, see every error in plain English, find addresses that fail the new structured-address rule, and fix them. All without uploading your file.

Check a Nacha ACH file against the record layout, routing numbers, control totals and the 2026 Nacha rules (PAYROLL and PURCHASE descriptions), see every error in plain English, and fix the mechanical ones. All without uploading your file.

Banks are phasing out pain.001.001.03. Drop an old file and get a pain.001.001.09 file: only the structure changes, every amount, account, name and ID stays the same, and the new file is checked against the official .09 schema straight away. What changes

Runs in your browser. Your file is never uploaded.
Phase-out status: German banks planned to stop accepting pain.001.001.03 in November 2026 and suspended that date in September 2026. A new date will follow, and your bank may switch earlier. Details and every change from .03 to .09
Deadlines postponed: Swift and the EPC have both put back the date for rejecting unstructured addresses, and neither has set a new one yet. The rule stays: town and country must sit in their own fields. Switzerland keeps 14 November 2026. Dates and what this means for your files
Nacha rules in 2026–27: since 20 March 2026, PPD credits for wages must start their Company Entry Description with “PAYROLL”, and consumer WEB debits for online purchases of goods must say “PURCHASE”. From 1 January 2027 the Nacha Rules document which characters the ACH Operators accept. What PacsLint checks in an ACH file

Drop a Nacha ACH file here (.ach, .txt or .dat) or choose one from your computer. Checked for the 94-character record layout, record order, routing-number check digits, transaction codes, trace numbers, entry hash and totals, padding, and the 2026 Nacha rules.

A demo PPD payroll and WEB file with dummy data and a few typical mistakes.
Paste the file instead

Check another file: drop it here or choose one from your computer.

Drop a pain.001 XML file here or choose one from your computer. Checked in four steps: readable XML, the official ISO 20022 schema (versions .03 to .13), business rules (ISO code lists, IBAN check digits, control totals, and the EPC rules for SEPA payments), then the structured-address rule.

Drop a pain.001.001.03 file here or choose one from your computer. It's converted to .09 and checked straight away; then you can fix addresses and download the new file.

See schema errors, address problems and fixes on a demo file with dummy data. Or the , typical of SAP exports, or a .
A demo file in the older v03 format, typical of SAP exports, with dummy data.
Paste XML instead

What counts as ready

Address typeWhat it looks likeStatus
StructuredSeparate fields, at minimum TwnNm and Ctry; street, building and postcode in StrtNm, BldgNb, PstCd. No AdrLine.Ready
HybridTwnNm and Ctry in their own fields, plus at most 2 AdrLine of up to 70 characters each. The lines must not repeat the postcode, town or country already given in their own fields.Ready
UnstructuredFree-text AdrLine fields with no TwnNm. A Ctry on its own doesn’t change that: without a town field the address still counts as unstructured.Fix before deadline
No address (SEPA)In SEPA credit transfers the payee’s address is optional, and so is the payer’s when both banks are in the EEA. When a bank in the payment is in a non-EEA SEPA country (for example the UK or Switzerland), the payer’s full address is required.Ready
Agents (banks)A BIC alone is enough. Without a BIC, give the name with town and country. For domestic payments outside SEPA, the UK and the US, a clearing code such as an IFSC also identifies the bank.BIC = ready