Financial EDI

Financial EDI (FEDI) is the use of electronic data interchange (EDI) to exchange payment-related information between companies and their banks, and between payers and payees. It covers payment instructions sent to a bank, the remittance details that explain what a payment is for, and the statements and notifications a bank sends back. The aim is to let money and the information about it move electronically together, so that payments can be made and matched without manual work.

Financial EDI sits where corporate supply-chain EDI meets the banking system. A company that already receives purchase orders and invoices by EDI can use the same standards, chiefly ANSI ASC X12 and UN/EDIFACT, to pay those invoices and tell suppliers which ones were paid. It is often discussed in contrast with ISO 20022, the XML-based standard that banks increasingly use for the same purposes.

When a large company pays a supplier for 40 invoices at once, a single amount lands in the supplier's bank account. On its own, that number says very little. The supplier needs to know which invoices are covered, whether any discount was taken and why one invoice was paid short. Without that note, someone has to phone or email to find out, and the money sits unallocated in the meantime.

Financial EDI is the standard way to send that note electronically, in a form the supplier's computer can read. It works like a parcel with a packing slip taped to it: the payment is the parcel, the remittance information is the slip, and both arrive in a format the receiving warehouse already knows how to open.

A typical financial EDI flow involves the following steps:

1. The payer's accounts payable system selects invoices for payment and produces a payment order with remittance details, in the United States often as an X12 820 Payment Order/Remittance Advice.
2. The file goes to the payer's bank, which checks it and turns the instruction into a payment on a chosen rail, such as an automated clearing house (ACH) credit or a wire.
3. The remittance data travels either with the payment or separately. In the US ACH network, the Corporate Trade Exchange (CTX) format can carry large amounts of X12 remittance data in addenda records attached to the payment itself.
4. The receiving bank credits the payee and passes the remittance data on, or reports it in a statement or a dedicated file.
5. The payee's system uses the remittance details for automatic cash application, closing the right invoices in accounts receivable.

Banks also send EDI messages back to their corporate customers, including balance and transaction reports and lockbox reports that list cheques received on the customer's behalf.

• X12 820. The Payment Order/Remittance Advice, used either to instruct a bank to pay or to tell a payee what a payment covers.
• X12 823. The lockbox transaction set, used by banks to report cheques received and processed on a company's behalf.
• EDIFACT PAYMUL and REMADV. Multiple payment orders and remittance advices, common in European and international corporate banking.
• EDIFACT FINSTA. A financial statement of an account sent from bank to customer.
• X12 835. The healthcare claim payment and remittance advice that US health insurers send to providers.

The US ACH network also offers a simpler corporate format, CCD+, which carries a single short addenda record, enough for an invoice number. Matching relies on consistent references, which is why payment reference matching remains a core concern even in mature EDI programmes.

Banks have increasingly offered ISO 20022 messages to corporate clients, including pain.001 for payment initiation and camt.053 for account statements. These carry structured remittance information in XML and are now used by many high-value and instant payment systems, which makes end-to-end straight-through processing easier. EDI remains entrenched in some industries, so many treasury management systems and banks translate between the two. The choice often depends on what a company's trading partners and banks support rather than on technical merit alone.

• Lower processing cost. Automatic matching reduces manual keying and exception handling in both payables and receivables.
• Better cash visibility. Treasurers can see what has been paid and received sooner, which supports cash management.
• Fewer disputes. Suppliers know exactly which invoices were paid and why deductions were taken.
• Setup effort. Each bank and trading partner needs agreed formats and testing, and many smaller suppliers lack the systems to receive EDI remittance.
• Split data. When remittance travels separately from the payment, the two must be reconciled, and a lost file leaves an unexplained credit on the bank statement.

• X12
• Nacha
• ISO 20022