Introduction to EDI in Banking
In the banking sector, Electronic Data Interchange (EDI) is the backbone of automated corporate cash management. It allows companies (and individuals) to exchange structured financial information and payment instructions with their banks electronically, without manual intervention. This process primarily uses the Automated Clearing House (ACH) Network for fund transfers, with EDI X12 transactions providing the detailed instructions and remittance information that travels with the payment.
The primary benefits are:
Automation: Eliminates manual data entry, reducing errors and labor costs.
Efficiency: Speeds up the entire payment and reconciliation cycle.
Data Richness: Allows detailed remittance information (like invoice numbers and amounts) to be sent with the payment, enabling automated cash application.
Security: Uses secure, established protocols for transmitting sensitive financial data.
1. Key Stakeholders
Understanding the players is crucial to understanding the flow.
Originator | The company or individual initiating the payment. | Payer, Corporate Customer, Buyer |
Originating Depository Financial Institution (ODFI) | The Originator's bank. It receives payment instructions, converts them into ACH format, and sends them to the ACH network. | Payer's Bank |
ACH Operator | The central clearing facility for ACH transactions. In the U.S., this is either The Federal Reserve (FedACH) or The Clearing House (EPN). | Clearing House |
Receiving Depository Financial Institution (RDFI) | The Receiver's bank. It receives the ACH transaction from the network and credits the Receiver's account. | Payee's Bank, Beneficiary's Bank |
Receiver | The company or individual receiving the payment. | Payee, Trading Partner, Supplier, Vendor |
EDI Translator / VAN | Software or a third-party service (Value Added Network) that converts data from a company's internal format (e.g., from an ERP system) into the standardized EDI X12 format and manages secure transmission. | EDI Provider, Service Bureau |
2. End-to-End EDI Payment Flow (Procure-to-Pay Example)
This is the most common B2B scenario: a company paying its supplier for goods or services.
Scenario: ACME Corp (Originator) needs to pay its supplier, Global Tech (Receiver), for several invoices.
Visual Flow:
[ACME Corp ERP] -> EDI 820 -> [ACME's Bank - ODFI] -> ACH (CTX) -> [ACH Operator] -> [Global Tech's Bank - RDFI] -> EDI 820 -> [Global Tech ERP]
Step-by-Step Breakdown:
Phase 1: Payment Initiation (At the Payer's Side)
Invoice Received (EDI 810): Global Tech sends an Invoice (EDI 810) to ACME Corp. This is the trigger for the payment process.
Payment Approval: ACME's Accounts Payable (AP) department processes the invoice in their ERP system (e.g., SAP, Oracle) and approves it for payment.
Generate Payment File (EDI 820): ACME's ERP system generates a payment file. This file contains:
Payment instructions (who to pay, how much, from which account).
Detailed remittance information (which invoices are being paid, any adjustments).
This data is formatted into an EDI 820 (Payment Order / Remittance Advice) transaction set by ACME's EDI translator software.
Transmit to Bank: ACME transmits the 820 file to its bank (the ODFI) via a secure connection (e.g., SFTP, FTPS) or through a VAN.
Phase 2: Bank Processing and ACH Network
Bank Receives and Validates: The ODFI receives the 820 file.
It sends back an EDI 997 (Functional Acknowledgment) to confirm the file was received and syntactically correct.
It may also send an EDI 824 (Application Advice) to report acceptance or rejection of the transaction based on business rules (e.g., valid account number, sufficient funds).
Create ACH Transaction: The ODFI's systems parse the 820. It extracts the core payment data and creates an ACH transaction. For B2B payments with remittance data, this is typically a CTX (Corporate Trade Exchange) or CCD+ (Cash Concentration or Disbursement plus Addenda) record.
The critical link: The remittance details from the 820 are placed into the "addenda records" of the ACH CTX file. A single CTX transaction can contain up to 9,999 addenda records, accommodating thousands of invoices in one payment.
Send to ACH Operator: The ODFI sends a batch of ACH transactions (including ACME's) to the ACH Operator (e.g., The Fed).
Clearing and Settlement: The ACH Operator sorts the batch and routes the CTX transaction to Global Tech's bank (the RDFI). The settlement of funds between the banks happens here.
Phase 3: Payment Receipt and Reconciliation (At the Payee's Side)
Receive ACH and Credit Account: The RDFI receives the ACH (CTX) file, debits the settlement account, and credits Global Tech's bank account for the total payment amount.
Deliver Remittance Information (EDI 820): The RDFI's system extracts the addenda records (the remittance details) from the incoming CTX file. It then formats this information back into an EDI 820 (Payment Order / Remittance Advice) and delivers it to Global Tech, typically via a secure portal or SFTP transmission.
Automated Reconciliation: Global Tech's ERP or Treasury Management System (TMS) automatically ingests the 820 file. The system reads the invoice numbers and amounts paid, matching them against the open Accounts Receivable (AR).
This final step, called automated cash application, closes the loop. It marks the invoices as paid without any manual data entry, which is the ultimate goal of financial EDI.
3. Catalog of Key Banking-Related X12 Transactions
While the 820 is the star of the payment flow, many other transactions are essential for a complete cash management cycle.
820 | Payment Order / Remittance Advice | The Core Transaction. Used by a company to instruct its bank to make a payment (Payment Order). Also used by the receiving bank to deliver detailed payment information (Remittance Advice) to the payee. |
821 | Financial Information Reporting | The Electronic Bank Statement. Used by banks to send account balance and transaction details (cleared checks, incoming/outgoing wires, ACH credits/debits) to their corporate customers. A cornerstone of automated treasury and cash positioning. |
823 | Lockbox | Used by a bank to provide details of payments received in a company's lockbox. The bank opens mail, scans checks, and creates an 823 file with payer and invoice details, which the company uses for AR reconciliation. |
835 | Health Care Claim Payment/Advice | A specialized version of the 820 used in the US healthcare industry. It's how health insurers (payers) pay providers (hospitals, doctors) and explain which claims are being paid, adjusted, or denied. Mandated by HIPAA. |
827 | Financial Return Notice | Used by a bank to notify a company that a previously initiated ACH payment has been returned (e.g., due to incorrect account number, insufficient funds, or account closed). This is the electronic notice of a failed payment. |
828 | Debit Authorization | Used by a company to provide its bank with authorization details for pre-arranged debits (e.g., authorizing a supplier to pull funds from its account). Less common now, as authorizations are often handled outside EDI. |
824 | Application Advice | A business-level acknowledgment. Used by the bank to report errors in an 820 file beyond basic syntax (e.g., invalid payment date, non-existent account). It tells the sender why their transaction was rejected at the business level. |
997 | Functional Acknowledgment | A technical acknowledgment for any EDI transaction. Confirms that a transmitted file was received and met the X12 syntax standards. It does not confirm that the transaction was processed or accepted. |
810 | Invoice | The Trigger. While not a "banking" transaction itself, it's the start of the financial EDI lifecycle. The 810 invoice from a supplier creates the obligation that the 820 payment later fulfills. |
822 | Account Analysis | Used by banks to provide corporate customers with a detailed statement of services rendered and fees charged (e.g., fees for wires, ACH services, account maintenance). Used for monitoring bank service costs. |
No comments:
Post a Comment