Sent by buyers to suppliers detailing which invoices are being paid, what amount is being remitted, and what deductions or adjustments are being applied - enabling automated cash application and deduction management in supplier AR systems.
The EDI 820 Payment Order / Remittance Advice tells a supplier exactly how a payment is being applied. When a buyer sends an ACH wire transfer, EFT, or check, it's just a dollar amount arriving in the supplier's bank account. The 820 is the structured document that explains that deposit - which open invoices it covers, how much was paid on each, what deductions were taken, and why. Without an 820, a supplier's AR team must manually research each payment by calling the buyer or parsing unstructured remittance email attachments.
A single 820 can reference dozens or hundreds of invoice numbers (RMR segments), each with a gross invoice amount, adjustment amount, and net paid amount. When a buyer short-pays an invoice due to a chargeback, the 820 shows both the invoice gross and the deduction amount with a reason code - giving the supplier's AR team the data needed to either write off the deduction or initiate a dispute. This is particularly critical in retail and grocery where complex deduction ecosystems make manual cash application impractical at scale.
The 820 can also function as a standalone payment order (instructing a bank to initiate payment), not just remittance advice. In this mode, the BPR segment includes bank routing and account numbers. However, most implementations use it purely as remittance advice accompanying an ACH transaction already in flight.
Retail vendors receive 820s from major retailers to reconcile payments. Target, Walmart, and Kroger all send 820s with detailed deduction breakdowns. Without automated 820 parsing, reconciling a single payment covering 200 invoices with 35 deductions would take a full day of manual AR work - the 820 enables straight-through cash application in minutes.
CPG brands receive high-volume 820s from grocery chains and distributors (UNFI, KeHE) that include complex promotional deduction detail. Mapping 820 RMR reason codes to internal trade promotion event IDs is key to understanding whether deductions are valid vs. invalid. Invalid deductions identified via 820 data drive the dispute workflow.
Wholesale distributors use 820s to automate cash application across thousands of retailer customers. A single payment from a large retailer account may cover invoices from multiple warehouses, multiple date ranges, and multiple product categories. The 820 RMR loop itemizes every invoice so the distributor's ERP can auto-apply the payment without human intervention.
Manufacturers receiving 820s from OEM or distributor customers use them to close open AR aging items. In automotive manufacturing, 820s arrive alongside production payment releases - matching payment to parts delivered per the 830 planning schedule. Discrepancies flagged by the 820 matching process trigger formal payment dispute processes.
The most important header segment. BPR01 = transaction handling code: C (payment accompanied by remittance), I (remittance only), U (payment only). BPR02 = payment amount (decimal, e.g., 15234.56). BPR03 = credit/debit flag. BPR04 = payment method code: ACH, CHK (check), FWT (fed wire). BPR16 = check/ACH trace number for bank reconciliation.
Associates the 820 with a specific payment trace. TRN01 = reference identification qualifier (1 = current transaction trace number), TRN02 = the trace ID assigned by the paying bank (often the ACH trace number), TRN03 = originating company ID. Suppliers use the TRN02 value to match the 820 to the corresponding bank deposit entry, especially when multiple 820s arrive for a single ACH batch.
One RMR segment per invoice being paid. RMR01 = reference qualifier (IV = invoice number, PO = PO number), RMR02 = the invoice number, RMR03 = payment action code (PI = paid in full, PA = partial payment), RMR04 = amount claimed (gross invoice), RMR05 = amount remitted (net paid after deductions). The difference between RMR04 and RMR05 is the deduction amount.
Accompanies an RMR to explain deductions. ADX01 = adjustment amount (the deduction dollar amount), ADX02 = adjustment reason code: AH (routing non-compliance), BD (bad debt), OA (other adjustment), PD (pricing discrepancy). ADX03 = reference qualifier, ADX04 = reference number (e.g., the chargeback number from the 812 being referenced).
Identifies the paying organization (N101 = PR - payer) and the receiving organization (N101 = PE - payee). N102 = company name, N103/N104 = identification type and value (DUNS, EIN, or trading partner-assigned vendor number). These identifiers must match what the supplier's bank and AR system expect, or auto-matching of the 820 to the deposit fails.
DTM01 = 097 (transaction creation date) for when the 820 was generated, and DTM01 = 009 (process date) for the actual payment value date. The delta between these two dates tells suppliers whether the payment was on time relative to the payment terms in the original 810 ITD segment - key data for calculating early payment discount eligibility.
Every invoice number in the 820 RMR loop corresponds to an 810 previously received by the buyer. Clean invoice numbering in the 810 BIG02 segment is essential - mismatches between what the 810 sent and what the 820 references cause auto-application failures.
Deductions shown in the 820 ADX segments often correspond to previously issued 812 chargebacks. Matching 820 ADX reference numbers to 812 adjustment IDs enables suppliers to confirm which deductions were expected vs. which are new surprises requiring dispute.
Some 820 implementations reference PO numbers in the RMR loop alongside invoice numbers, providing extra context for cash application. This is common in manufacturing where payment is tied to PO releases rather than individual invoice numbers.
Better EDI handles 820 mapping, testing, and trading partner certification so you don't have to.
Talk to an EDI Expert