# EDI Payments Explained: How EDI 820 Works > Learn what EDI payments are, how the EDI 820 payment order works, and how electronic payments fit into the order-to-cash cycle for B2B suppliers. The EDI 820 is a payment order and remittance advice sent from a buyer to a supplier to communicate payment details. It includes invoice numbers, amounts paid, and deduction reasons—so you know exactly what was paid and what was deducted before your bank statement arrives. Most large retailers send 820s with every payment run. **EDI payments use the X12 820 transaction to carry remittance data alongside ACH transfers, telling suppliers exactly which invoices are being paid and what deductions have been applied, so accounts receivable teams can auto-match without manual research.** You shipped the goods. You sent the ASN. Your invoice matched the PO. Now you're waiting for payment, and you need to know exactly when it hits your account, how much it covers, and which invoices it applies to. That's the problem EDI payments solve. If you've ever received a lump-sum ACH deposit and spent hours figuring out which invoices it covered (and which deductions were taken), you already understand why structured electronic payment data matters. Key data points on EDI payment volume and standards: - [NACHA](https://www.nacha.org/) reports that B2B ACH payment volume reached 7.7 billion transactions in 2024, with the CTX format being the primary method for commercial payments that include remittance data - The [ASC X12 standards body](https://x12.org/products/transaction-sets) defines the 820 Payment Order/Remittance Advice structure used by major retailers including Walmart and Target - The [Federal Reserve's ACH processing guides](https://www.federalreserve.gov/paymentsystems/fedach_about.htm) outline settlement timing that affects the gap between when an 820 arrives and when funds clear your account ## What Is an EDI Payment? **An EDI payment is the electronic exchange of payment instructions and remittance data between trading partners using standardized transaction sets, most commonly the [EDI 820](https://x12.org/products/transaction-sets) defined by the ASC X12 standards body.** The 820 tells the supplier what is being paid, how much, and which invoices the payment covers. It is not the money transfer itself: that moves through ACH or wire. The 820 is the detailed remittance stub that accompanies the payment. An EDI payment is not the money transfer itself. This is the most common point of confusion. The EDI 820 is the *data* that accompanies the payment. The actual funds move through banking channels like ACH or wire transfer. The 820 tells you how to apply those funds to your open invoices. Think of it this way: the ACH deposit is the check arriving in your mailbox. The EDI 820 is the remittance stub attached to it, listing every invoice, every adjustment, and every deduction line by line. ## The EDI 820 Transaction Set Explained The EDI 820 Payment Order/Remittance Advice is defined by the [ASC X12 standard](https://x12.org) and serves two purposes (our [EDI 820 guide](/guides/edi/820-payment-order) covers every segment in detail): 1. **Payment order**: Instructs a financial institution to make a payment 2. **Remittance advice**: Tells the supplier which invoices the payment covers and any adjustments applied Most suppliers encounter the 820 as remittance advice from their retail customers. Here's what a typical 820 contains: ### Header-Level Data - **Payer identification**: The buyer's name, DUNS number, or other identifier - **Payee identification**: Your company info as the supplier - **Payment method**: ACH, wire, check - **Total payment amount**: The sum being transferred - **Payment date**: When funds were or will be released - **Trace number**: The banking reference number that ties the 820 to the actual ACH or wire transfer ### Remittance Detail This is where the 820 gets practical. Each remittance record includes: - **Invoice number**: Which of your invoices this payment covers - **Invoice amount**: The original amount you billed - **Amount paid**: What's actually being paid on that invoice - **Adjustment amounts**: Deductions, discounts, allowances, or chargebacks applied - **Adjustment reason codes**: Standardized codes explaining why the paid amount differs from the invoiced amount A single 820 can reference dozens or even hundreds of invoices. For suppliers shipping to major retailers, a weekly payment run might cover 50+ invoices in one remittance. ### A Simplified 820 Example Here's what the key segments look like in an EDI 820: ``` ST*820*0001 BPR*C*15420.00*C*ACH*CTX*01*021000021*DA*123456789*1234567890**01*071000505*DA*987654321*20260315 TRN*1*PAYMENT20260315*1234567890 N1*PR*ACME RETAILERS*01*987654321 N1*PE*YOUR COMPANY*01*123456789 ENT*1 RMR*IV*INV-2026-0401**8500.00*8500.00 ENT*2 RMR*IV*INV-2026-0402**7200.00*6920.00 ADX*280.00*01*AJ SE*13*0001 ``` In this example, two invoices are being paid. The first (INV-2026-0401) is paid in full at $8,500. The second (INV-2026-0402) had a $280 deduction applied, reducing the payment from $7,200 to $6,920. The BPR segment shows the total payment of $15,420 moving via ACH. If you want to inspect the structure of EDI files like this, you can parse them with our [free EDI Inspector](/edi-inspector) to see each segment and element broken down. ## EDI Payments vs. ACH vs. Wire Transfers vs. Checks These terms often get mixed up. Here's how they relate: | | **EDI 820** | **ACH** | **Wire Transfer** | **Paper Check** | |---|---|---|---|---| | **What it is** | Data describing the payment | Electronic funds transfer via bank network | Real-time bank-to-bank transfer | Physical payment instrument | | **Moves money?** | No, data only | Yes | Yes | Yes | | **Remittance detail** | Full invoice-level detail | Limited (addenda records) | Minimal | Paper stub, if any | | **Speed** | Transmitted instantly | 1-3 business days | Same day | 5-10+ business days | | **Cost per transaction** | Minimal (part of EDI infrastructure) | $0.20-$1.50 typically | $15-$45 typically | $4-$20 (printing, postage, processing) | | **Best for** | Matching payments to invoices | High-volume B2B payments | Large, time-sensitive payments | Legacy processes | The key point: ACH moves the money, the EDI 820 tells you what the money is for. Most large retailers use both together. They initiate an ACH payment through their bank and send an 820 through their EDI connection so your accounts receivable team can auto-apply the payment. According to [NACHA (the organization governing the ACH network)](https://www.nacha.org/), B2B ACH payment volume reached 7.7 billion transactions in 2024, with the CTX (Corporate Trade Exchange) format being the primary method for commercial payments that include remittance data. The EDI 820 often accompanies these CTX transactions. ## The Order-to-Cash EDI Flow: Where Payments Fit EDI payments don't exist in isolation. They're the final step in a well-defined order-to-cash cycle. Here's how the full flow works: ### Step 1: EDI 850 (Purchase Order) Your retail customer sends an [EDI 850 purchase order](/guides/edi/850-purchase-order) with item details, quantities, pricing, and ship-to information. This is the starting point for every transaction. ### Step 2: EDI 855 (Purchase Order Acknowledgment) You confirm receipt and acceptance of the order. This is your commitment to fulfill. ### Step 3: EDI 856 (Advance Ship Notice) When you ship, you send the ASN with carton-level detail, tracking numbers, and ship dates. ### Step 4: EDI 810 (Invoice) After shipment, you send your [EDI 810 invoice](/guides/edi/810-invoice). The retailer's AP system performs three-way matching against the 850 and 856 to verify the invoice. You can dig into the segment-level details in our [EDI 810 invoice guide](/guides/edi/810-invoice). ### Step 5: EDI 820 (Payment Order/Remittance Advice) The retailer processes the approved invoice and sends an 820 confirming payment details. The funds move separately through ACH or wire. ### Step 6: Cash Application Your AR team (or your system) matches the 820 remittance data to open invoices and applies the payment in your ERP. When this flow is fully automated through [ERP integration](/erp-integration), the entire cycle from PO to cash application can happen without manual intervention. The 820 data feeds directly into your accounts receivable module, closing out invoices automatically. ## Common Problems with EDI Payments The 820 solves many payment reconciliation headaches, but it introduces its own set of challenges. Here are the issues suppliers run into most often. ### 1. Remittance Matching Failures The 820 references your invoice numbers, but if there's any mismatch between what the retailer recorded and what's in your system, the auto-match fails. Common causes: - **Leading zeros or formatting differences**: Your system stores "INV-00412" but the 820 says "INV-412" - **PO number mismatches**: The retailer references their PO number instead of your invoice number - **Duplicate invoice numbers**: Especially common when working with multiple divisions of the same retailer When matching fails, someone has to manually research and apply the payment. At scale, this becomes a full-time job. ### 2. Partial Payments and Short-Pays Retailers frequently pay less than the invoiced amount. The 820 should include adjustment reason codes explaining each deduction, but in practice: - Some retailers use vague or generic reason codes - Adjustment descriptions may not match the actual issue - Multiple small deductions on a single invoice can be difficult to research and dispute ### 3. Deductions and Chargebacks Retailers take deductions for compliance violations, early payment discounts, promotional allowances, and shipping variances. The 820 is supposed to itemize these, but the level of detail varies dramatically by trading partner. A $200 "compliance" deduction on an 820 doesn't tell you much. Was it a late shipment? Wrong packaging? Missing ASN data? Without digging into the retailer's vendor portal, the 820 alone often doesn't give you enough information to dispute or accept the deduction. ### 4. Timing Gaps The 820 might arrive days before or after the actual ACH deposit hits your bank account. This creates a reconciliation window where your AR team has remittance data but no corresponding bank transaction (or vice versa). The [Federal Reserve's guide to ACH processing](https://www.federalreserve.gov/paymentsystems/fedach_about.htm) outlines settlement timing, but in practice, the gap between EDI transmission and funds availability varies by bank and payment type. ### 5. Missing 820s Not all trading partners send 820s consistently. Some send them for every payment. Others only send them occasionally or not at all. When an ACH deposit arrives with no corresponding 820, your AR team is back to manually researching which invoices were paid. ## How to Handle EDI Payment Data Effectively If you're processing a high volume of EDI payments, here are the practices that make the biggest difference: **Automate cash application.** Map 820 remittance data directly into your ERP's accounts receivable module. Don't let payment data sit in a queue waiting for someone to manually post it. **Standardize invoice numbering.** Make sure the invoice numbers in your 810s will match what comes back in the 820. Talk to your trading partners about formatting expectations. **Track deductions systematically.** Build a process for categorizing, researching, and disputing deductions. The 820 gives you the data. You need a workflow to act on it. **Reconcile daily.** Match 820 data against bank transactions every day. The longer you wait, the harder it gets to research discrepancies. **Use your EDI infrastructure.** If you're already sending and receiving 850s, 810s, and 856s, adding the 820 to your workflow is straightforward. The same EDI connection handles all of it. For a broader look at how all these transactions work together, see [our essential guide to EDI](/blog/essential-guide-to-edi). ## Frequently Asked Questions ### What does EDI payment mean? EDI payment refers to the electronic exchange of payment-related data between business trading partners using standardized formats. The primary transaction is the EDI 820 Payment Order/Remittance Advice, which communicates what is being paid, how much, and which invoices the payment covers. The EDI 820 carries the payment information, while the actual funds move through banking systems like ACH or wire transfer. ### Is the EDI 820 the same as an ACH payment? No. The EDI 820 is a data transaction that describes the payment. ACH is a banking network that moves money between accounts. They work together: the retailer sends funds via ACH and sends the 820 via EDI so the supplier knows how to apply the payment. Think of the 820 as the detailed remittance stub and ACH as the actual deposit. ### What is the difference between an EDI 810 and an EDI 820? The [EDI 810](/guides/edi/810-invoice) is an invoice sent by the supplier to the buyer, requesting payment. The EDI 820 is a payment order or remittance advice sent by the buyer to the supplier, confirming that payment has been (or will be) made. The 810 says "you owe me $10,000 for these items." The 820 says "I'm paying you $9,700 on these invoices, with $300 in deductions." ### Do all trading partners send EDI 820s? No. While major retailers like Walmart and Target typically send 820s, many trading partners do not. Some provide remittance information through vendor portals or email instead. If your trading partner doesn't send 820s, you'll need to reconcile payments manually against your bank statements or request they add the 820 to your EDI setup. ### How do I start receiving EDI 820 payments? If you already have an EDI connection with a trading partner for transactions like the 850 or 810, adding the 820 usually requires a mapping update and testing with that partner. You'll need to map the 820 segments to your ERP's cash application fields. If you're new to EDI entirely, check out our [EDI implementation guide](/blog/essential-guide-to-edi) for a step-by-step walkthrough.