EDI in banking is the computer-to-computer exchange of standardized financial documents, most often payment instructions and their remittance detail, between a company’s systems and its bank’s systems. The files travel in a rigid format that both sides have agreed on in advance, so the receiving software can read them without anyone re-keying data. That is what separates EDI from a PDF invoice or an emailed spreadsheet: an EDI file is built for a machine to parse, not a person to read.
The technology sits underneath most high-volume corporate payments in the United States. When a large company pays hundreds of invoices in a single run, the payment and the invoice-level detail move together as structured data, and the recipient’s accounting system applies the cash automatically.
The Problem EDI Solves
Consider a company paying 500 invoices in a single batch. The recipient needs to know which invoices that payment covers. A paper check includes a remittance stub. A wire transfer offers a brief memo field. Neither scales when thousands of transactions flow between trading partners every week.
EDI packages the payment instruction and all the associated remittance detail into a single structured file that the recipient’s accounting software can digest without human intervention. Every field has a fixed position and meaning, so the receiving system knows exactly where to find the dollar amount, the invoice numbers, the discount terms, and any adjustment codes. Banks sit in the middle: a corporation generates the file, sends it to the bank, and the bank executes the payment through a clearing network such as ACH or Fedwire. On the receiving end, the payee’s bank delivers the structured remittance data so the recipient can match payments to open invoices automatically. That automated matching is called straight-through processing, and it is the reason large companies build EDI infrastructure at all.
How an EDI Payment Actually Flows
The process starts inside the paying company’s accounting system. The accounts payable team approves a batch of invoices, and the system generates a payment file in its own internal format.
Then comes translation. Specialized EDI software converts that internal file into the required standard format, typically an X12 820 for a payment with remittance detail. The translator maps each internal data field to the correct segment and element position in the X12 structure, producing a flat file ready to transmit.
The file then moves to the receiver through a secure channel. Some organizations route it through a Value Added Network that acts as a secure mailbox and audit trail. Others use direct connections through protocols like AS2, which transmits EDI data over HTTPS with digital signatures and encryption built in.1IETF. RFC 4130 – MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) SFTP is also common, though it lacks the built-in non-repudiation and delivery confirmation that AS2 provides.
On the receiving end, the process runs in reverse. The recipient’s EDI software translates the standard X12 format back into the proprietary format of their accounting system. The data flows into accounts receivable, matches against open invoices, and updates the ledger.
The final step is acknowledgment. The recipient’s system sends back a 997 Functional Acknowledgment confirming the file arrived intact and was successfully parsed. The 997 does not confirm the payment cleared the bank. It only confirms the data was structurally valid and accepted for processing. That distinction trips people up: a successful 997 means the computers talked correctly, not that the money moved.
The whole cycle typically completes within minutes. The data arrives well before the funds actually settle, which gives the receiving company time to prepare for cash application and update its cash position forecasts.
The Standards That Make EDI Work
EDI only works because both sides agree on the exact format of the data. That agreement is codified in three standards you will encounter in banking.
ANSI X12
ANSI ASC X12, maintained by the X12 organization, is the dominant standard for EDI in the United States. It defines hundreds of transaction sets, each identified by a three-digit number, for different business documents. Each set specifies the exact structure of the file: which data segments appear, what order they follow, and what values are allowed in each field. The format is a flat text file with fixed delimiters, designed for efficient machine parsing rather than human readability.
UN/EDIFACT
For cross-border transactions, the dominant standard is UN/EDIFACT, a set of internationally agreed rules for electronic interchange of structured data between independent computer systems.2United Nations Economic Commission for Europe. Introducing UN/EDIFACT EDIFACT uses a different syntax than X12 but serves the same purpose. Multinational corporations often maintain both, using X12 for domestic U.S. transactions and EDIFACT when communicating with European or Asian trading partners.
ISO 20022
A shift is underway toward ISO 20022, a newer global standard for financial messaging that uses XML rather than flat-file formatting.3Swift. ISO 20022 Standards The practical difference matters: ISO 20022 carries richer, more structured data fields than traditional EDI formats. It supports longer names, specific address components with country codes, and extended remittance information, all of which reduce data loss and improve automated processing for corporate payments.4Federal Reserve Bank Services. Benefits of ISO 20022 It also replaces multiple proprietary formats with a single open standard, cutting the mapping and translation costs that banks and corporations have absorbed for decades.
The Banking Transaction Sets You’ll Actually See
A handful of X12 transaction sets drive most of the day-to-day EDI traffic between corporations and their banks. Each is identified by a three-digit number.
- 820 (Payment Order/Remittance Advice). The workhorse of corporate-to-bank EDI. The 820 contains both the payment instruction and detailed remittance information specifying which invoices are being paid, along with any discounts or adjustments. Automated cash application on the receiving end is the goal.
- 822 (Account Analysis). Banks send this to corporate clients to report detailed account activity, including service charges, balances, and adjustments. Instead of mailing a paper account analysis statement, the 822 lets the corporate treasury system ingest the data and reconcile bank fees against contracted pricing automatically.
- 823 (Lockbox). When a company uses a bank lockbox service to process incoming customer checks, the bank converts the paper check data into an 823 file. It includes check numbers, payer details, and deposit amounts, allowing the accounts receivable system to update without manual entry.
- 824 (Application Advice). The 997 confirms a file was received and structurally valid. The 824 goes further, reporting the results of the receiving system’s business-level review and indicating whether individual transactions were accepted, rejected, or accepted with changes.
- 831 (Application Control Totals). Used to submit control totals for batches of financial transactions, acting as an integrity check before individual items are processed.
- 997 (Functional Acknowledgment). The automated receipt confirmation for any EDI transmission. A positive 997 means the envelope was intact and the format was correct, not that the business content was approved.
How EDI Rides the ACH Network
One of the most common ways EDI payment instructions actually move money is through the ACH network, specifically the CTX (Corporate Trade Exchange) format. A single CTX entry can carry up to 9,999 addenda records, and those addenda records can contain a full ANSI X12 message or UN/EDIFACT payment information.5Nacha. ACH File Details
Here is how the pieces connect. A company generates an EDI 820 in its accounting system. That file goes to its bank, which strips out the payment instruction and originates a CTX entry through the ACH network. The remittance data from the 820 rides along as addenda records attached to the CTX transaction. When the receiving bank delivers the funds to the payee, it also delivers the structured remittance data.
The alternative ACH format for corporate payments is CCD+ (Cash Concentration or Disbursement), which allows only a single addenda record. CCD+ works for simple payments covering one invoice. When a single payment covers dozens or hundreds of invoices, CTX is the only ACH format that can carry all the remittance detail. Without the structured addenda, the recipient would receive a lump sum with no machine-readable explanation of what it pays for.
How the Files Get From Sender to Receiver
The physical transmission method matters for both security and reliability. Three approaches dominate.
Value Added Networks remain widely used, particularly among companies with many trading partners. A VAN simplifies connection management because you maintain a single connection to the network rather than a separate link to every partner. The VAN routes documents to the correct mailbox, tracks delivery, and maintains a full audit trail. The trade-off is cost: VANs typically charge per kilocharacter of data transmitted, and those fees add up at high volumes.
AS2 is the most common protocol for direct, point-to-point EDI transmission over the internet. It wraps EDI data in MIME format, sends it over HTTPS, uses X.509 digital certificates for authentication, and supports both encryption and digital signatures. Its Message Disposition Notification provides built-in non-repudiation: the sender gets cryptographic proof that the recipient received and decrypted the message. AS2 eliminates VAN fees but requires both parties to maintain compatible infrastructure.
SFTP is the simpler option. It encrypts data during transfer using SSH, and many banks accept EDI files this way. The downside is that SFTP does not natively provide non-repudiation, delivery confirmation, or error handling at the protocol level. You know the file transferred, but you lack the cryptographic receipt that AS2 provides.
Where EDI Fits Alongside Real-Time APIs
The obvious question for anyone evaluating EDI today is whether APIs have replaced it. Not yet, and probably not entirely.
EDI processes data in batches. Files are assembled, transmitted, and processed on a schedule. APIs exchange data in real time, one transaction at a time, with an immediate response. For a single payment or a real-time balance inquiry, an API is faster and more responsive. For a batch of 10,000 invoice payments with detailed remittance data, EDI is built for the job and APIs are not.
APIs can be cheaper upfront because there is no ongoing VAN expense or complex translation layer. But APIs lack the established cross-industry standards that EDI has spent decades building. Every new trading partner may require custom API integration work, while EDI’s standardized formats mean a new partner who speaks X12 can be onboarded with predictable mapping effort. In practice, most large banks now offer both, with APIs handling real-time use cases and EDI handling high-volume batch payment processing and remittance delivery.
What ISO 20022 Means for EDI Users
The payment rails that EDI files ultimately ride on are moving to ISO 20022, and that changes the context in which EDI operates even if it does not eliminate EDI itself.
CHIPS, operated by The Clearing House, completed its ISO 20022 migration in April 2024.6The Clearing House. TCH Reschedules CHIPS ISO 20022 Implementation to April 2024 Fedwire completed its initial ISO 20022 migration in mid-2025, with a further release carrying expanded functionality taking effect on November 16, 2026.7Federal Reserve Bank Services. Fedwire Funds Service ISO 20022 Implementation Center On the cross-border side, Swift’s coexistence period for legacy MT messages ended in November 2025, and since January 2026 any institution still sending legacy MT messages is subject to automatic conversion processing and additional charges.8Swift. ISO 20022: Implementation
For a company running traditional EDI workflows, this does not switch the lights off on X12. It does mean the payment rails your EDI files ride on now speak ISO 20022, banks increasingly expect their corporate clients to produce richer data, and the gap between what a flat-file EDI format can carry and what ISO 20022 can carry is growing harder to bridge with translation alone.