A payment file format is the agreed structure an accounts payable system uses to package approved payments into an outbound payload that a bank will accept and execute. For a legal department, that payload is the final step between an invoice your team approved in eBilling and money arriving at the law firm. This guide covers how the payload is built, where legal invoice data breaks it, and how to test the handoff before go-live.
What is a payment file format in accounts payable?
A payment file format in accounts payable is the message structure and field hierarchy that tells a bank who pays, who gets paid, how much, in which currency, and why. The dominant global standard is ISO 20022 pain.001, the customer credit transfer initiation message.
In the United States, ACH payments also run on the NACHA file layout, and many banks accept pain.001 and translate it on their side. Your concern as a legal operations lead is the data feeding it: the payee name, bank account, address, amount, currency, and the invoice numbers carried as remittance information.
How do approved legal invoices become an outbound AP payment payload?
Approved legal invoices become an outbound AP payment payload through a chain of four or five systems, each adding or reshaping data.
- Approval in eBilling. The invoice clears billing guideline review and approval routing, then exports with the vendor ID, invoice number, matter, and approved amount.
- Payable creation in the ERP. AP matches the export to the vendor master record, which holds the bank details and payment method.
- Payment run selection. On a weekly or twice-weekly cycle, AP selects due payables and groups them by payment method and currency.
- File build and dispatch. A connector or bank module serializes the batch into pain.001 or NACHA and sends it over a host-to-host link or a bank portal.
The design of that export is covered in integrating ELM with finance and ERP systems. Every field the bank rejects was created upstream, often in the legal platform.
What does an ISO 20022 pain.001 payment file contain?
An ISO 20022 pain.001 payment file contains three nested building blocks: a Group Header, one or more Payment Information blocks, and one or more Credit Transfer Transaction Information blocks inside each of those. The nesting lets one file carry hundreds of payments.
- Group Header. Carries the Message Identification, creation timestamp, number of transactions, and control sum.
- Payment Information. Groups payments that share a debit account, payment method, and execution date. A weekly legal run might produce one block for domestic ACH and a second for international wires.
- Credit Transfer Transaction Information. Holds one payment each, with the end-to-end ID, amount, creditor, account, and remittance data. Structured remittance carries each invoice reference as its own field, so a firm paid across 15 invoices in one transfer can apply the cash without a phone call.
Individual banks can set shorter field limits than the ISO 20022 datatypes, so your bank’s implementation guide is the binding version.
How does a pain.001 payload map to the NACHA file format?
A pain.001 payload maps to the NACHA file format through a published crosswalk that converts each element into fixed-width ACH records for CCD, CTX, PPD, or Outbound IAT entries. Every NACHA record is exactly 94 characters, and because ACH limits are tighter than ISO 20022 limits, the tighter rule always wins.
- Receiver name. The receiver name is capped at 22 characters on CCD and PPD entries. Most full law firm names, with two or three partner surnames and an LLP suffix, run well past that.
- Amount. The amount field holds 10 digits with an implied decimal, which covers any single payment up to $99,999,999.99.
- Entry class. CCD carries one addenda record, CTX carries up to 9,999 addenda records for detailed remittance, and IAT applies when funds cross a US border. CTX is usually the better fit when one payment settles many invoices.
Which outbound payment payload fields fail most often on law firm payments?
The outbound payment payload fields that fail most often on law firm payments are the payee name, bank details, invoice references, and currency. Each one is owned by a different team, which is why the same defect can survive three payment cycles before anyone traces it.
- Payee name mismatch. The firm name in eBilling, the ERP vendor master, and the bank account holder name drift apart after mergers and rebrands.
- Stale bank details. A firm changes banks, and the update reaches eBilling but stops short of the vendor master data that routes each payment. Callback verification on every bank change belongs in AP, because payment fraud is common: business email compromise caused close to $2.8 billion in losses reported to the FBI in 2024, and 63 percent of organizations experienced it.
- Lost invoice references. The export carries the eBilling invoice ID, the firm expects its own invoice number from the LEDES billing file, and the remittance shows neither.
- Currency and entity. A UK firm billing in GBP needs a cross-border payment in a market where the US dollar is on one side of 89 percent of FX trades, and a run that defaults every legal vendor to USD ACH rejects or misroutes it. The ledger side of that invoice is covered in multi-currency accounting for legal GL splits.
Most of these are vendor setup problems. A disciplined outside counsel onboarding workstream captures legal name, remittance address, tax ID, and a banking contact once, and the payment file inherits clean data from day one.
What changes for payment payload addresses in November 2026?
Payment payload addresses must be fully structured or hybrid in cross-border ISO 20022 messages from November 2026, and payments carrying only free-text address lines risk rejection by the bank.
A structured address puts street, postal code, town, and country in their own fields. A hybrid address structures town and country and allows two free-text lines. A single block of free text is the form at risk.
For a department paying 50 to 200 outside firms, the fix is a one-time vendor address cleanup, usually two to four weeks of AP and legal operations effort, with country codes validated against ISO 3166.
How should AP payment file validation be layered before bank dispatch?
AP payment file validation should be layered as a sequence of checks that all run before the file leaves your network. A defect caught at build time costs minutes, and the same defect caught at the bank gateway costs a full payment cycle.
- Schema and business rules. The file is checked against the bank’s XSD or the NACHA layout, then against field lengths per your bank, required fields per payment method, and valid currency per debit account.
- Duplicate detection. Same vendor, same amount, and same invoice reference within a 30 to 90 day window gets held for review.
- Control totals and release. Transaction count and control sum in the Group Header match the payment run register to the cent, and two approvers release the file seeing the same totals the bank will see.
How do payment status reports close the AP reconciliation loop?
Payment status reports close the AP reconciliation loop by returning the original Message Identification from your pain.001 inside the bank’s pain.002 response, so every acceptance or rejection ties back to the exact file and payment that produced it.
File-level status usually arrives within minutes of dispatch, and individual payment rejects follow with a reason code, such as an invalid account or a missing creditor address. The final step is posting paid status back from the ERP into the eBilling platform so firms can see it in the portal. Firms that can see paid status stop emailing legal operations to chase payments.
How do you test an AP payment file integration before go-live?
You test an AP payment file integration before go-live by running real legal invoice data through the full chain, from eBilling approval to bank status report, in the bank’s test environment.
- Scenario coverage. Build 25 to 40 test payments covering domestic ACH, CTX with multiple invoices, international wires, long firm names, and a deliberate duplicate.
- Bank test cycles. Plan two to three round trips with the bank’s test gateway, each taking one to three business days, then one or two live cycles with five to ten firms before moving the full panel.
- First-time accuracy. Track rejected payments per cycle. Most finance teams expect nearly every disbursement to process error-free the first time, so a legal run with 20 rejects in 200 payments sits well below typical.
Version the bank connection and file mapping as configuration.
Conclusion
A payment file format is the last translation your legal invoice data goes through, and every rejection at the bank traces back to a field that someone upstream owned. Map the fields once, clean the vendor data before November 2026, and close the loop so paid status reaches the firms who are waiting for it.
How Basla can help
Basla provides delivery teams for enterprise legal management and eBilling software implementation, covering business analysis for invoice export and ERP integration, law firm and vendor data cleanup, test scripting across eBilling, AP, and bank status flows, documentation, and post-go-live support. Basla teams have delivered legal technology services for matter management and eBilling across more than 10 global jurisdictions.
Basla business analysts map each invoice field through to the payment payload, and QA proves that remittance, address, and currency data survive the trip. Hypercare runs through the first live payment cycles.
Frequently asked questions
What is a payment file format?
A payment file format is the structure an accounts payable system uses to package approved payments into a file a bank will accept. In the United States, ISO 20022 pain.001 and the NACHA ACH layout are the two most common.
What is the difference between pain.001 and a NACHA file?
pain.001 is a nested XML message, and NACHA is a fixed-width layout of 94-character records. A published crosswalk maps pain.001 into NACHA entry classes, and the tighter NACHA limits, such as the 22-character receiver name, take precedence.
Why do law firm payments get rejected by the bank?
Law firm payments get rejected most often because of payee names that exceed field limits, stale bank details, missing structured addresses, or a currency the payment method cannot carry. Nearly all originate in vendor setup data.
Does legal operations own the AP payment file?
Legal operations owns the data that feeds the AP payment file, while treasury and AP own the file build and the bank connection. Both teams agree field mapping and who acts on each rejection.
What is a pain.002 payment status report?
A pain.002 payment status report is the ISO 20022 message a bank returns to confirm whether a file and its payments were accepted or rejected. It carries the original Message Identification from your pain.001.
How long does it take to test a payment file integration?
Testing a payment file integration usually takes four to six weeks, including two to three round trips with the bank’s test gateway and one or two live parallel cycles.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*