EDI documents
EDI 820 Payment Order/Remittance Advice
The EDI 820 tells a supplier which invoices a payment covers, how much was paid on each, which discount was taken and what was deducted. This page covers the BPR, TRN, RMR and ADX segments, a sample that pays two invoices for 1,586.05, the envelope, and how the 820 becomes a cash application in your ERP.
Updated
What is an EDI 820?
The EDI 820 is the X12 Payment Order/Remittance Advice transaction set. X12 defines three uses for it: an order to a bank to make a payment, a remittance advice that tells the payee what a payment covers, or both in one document. In retail and distribution it is almost always the second: the buyer sends it to the supplier to explain a payment against 810 invoices. The EDIFACT counterpart is the REMADV message.
The value is in the detail lines. A retailer that pays 40 invoices with one transfer and deducts on three of them sends one amount to the bank and one 820 that splits it per invoice. Without the 820, accounts receivable has to work out from a single bank line which invoices were paid in full, which were short-paid and why.
Where the 820 sits in the order-to-cash flow
| Step | Document | Direction | Relation to the 820 |
|---|---|---|---|
| 1 | 850 purchase order | Buyer to supplier | The PO number can appear in the 820 as a reference |
| 2 | 856 ship notice | Supplier to buyer | Receiving against it drives quantity deductions |
| 3 | 810 invoice | Supplier to buyer | Each RMR line in the 820 names one invoice |
| 4 | 820 remittance advice | Buyer to supplier | Explains the payment per invoice |
| 5 | 997 acknowledgment | Supplier to buyer | Confirms the 820 arrived and parsed |
The 820 closes the cycle that the 850 opened. It is also where earlier errors become money: a short shipment, a price the 810 billed above the PO, or a freight charge the buyer did not authorize comes back as a deduction on this document.
The segments of an 820
The full X12 definition is long, with loops for payroll, taxes and pensions that retail never uses. A retail 820 uses a small part of it. The functional identifier of the group is RA.
| Segment | Name | What it carries | What goes wrong |
|---|---|---|---|
| BPR | Beginning Segment for Payment Order/Remittance Advice | BPR01 handling code, BPR02 total amount, BPR03 C or D, BPR04 payment method, BPR16 effective date | BPR02 differs from the bank deposit by a fee or a missing invoice |
| TRN | Trace | TRN01 code 1, TRN02 trace or check number | No trace number, so the payment cannot be matched automatically |
| DTM | Date/Time Reference | 097 transaction creation, 009 process, 003 invoice date | Dates read in the wrong format |
| N1 | Name | PR payer, PE payee, BY buyer, with an ID | A payee ID that does not map to the right company in the ERP |
| ENT | Entity | Groups remittance lines, for example per division | Two divisions paying the same invoice series |
| RMR | Remittance Advice Accounts Receivable Open Item Reference | RMR01 IV, RMR02 invoice number, RMR04 paid, RMR05 invoiced, RMR06 discount | An invoice number that lost a prefix matches no open item |
| ADX | Adjustment | ADX01 amount, signed if negative; ADX02 reason code | A deduction without a usable reason code |
| SE | Transaction Set Trailer | Segment count and control number | A count mismatch rejects the set |
BPR01 and ADX02 codes
BPR01 says whether money moves with the document. ADX02 says why an amount was adjusted; X12 004010 defines 370 values for it, and partner guides allow a few.
| Where | Code | Meaning |
|---|---|---|
| BPR01 | C | Payment accompanies remittance advice |
| BPR01 | I | Remittance information only |
| BPR01 | X | Handling party's option to split payment and remittance |
| BPR04 | ACH, CHK | Automated Clearing House, check |
| BPR05 | CCP, CTX | ACH formats CCD+ and CTX |
| ADX02 | 01 | Pricing error |
| ADX02 | 02 | Allowance/charge error |
| ADX02 | 06 | Quantity contested |
| ADX02 | ZZ | Mutually defined |
The amounts follow one rule from the standard: RMR05 is the invoice amount before terms discount, RMR06 the discount taken, RMR04 the amount paid. ADX01 is signed; a negative amount reduces the payment.
A sample 820, with delimiters
The buyer from the 850 sample, PO 4500018236, pays two invoices with one ACH transfer. The first is INV-20417 for 415.40 from the 810 page, dated 3 October with terms of 1% in 10 days, net 30. The second is an older invoice, INV-20388 for 1,236.00, on which the buyer deducts a price difference.
ST*820*0001~
BPR*I*1586.05*C*ACH*CCP***********20261012~
TRN*1*0012604417~
DTM*097*20261012~
N1*PR*HARBOR RETAIL*92*0001~
N1*PE*NORTHFIELD SUPPLY*92*0412~
ENT*1~
RMR*IV*INV-20417*PI*411.25*415.40*4.15~
DTM*003*20261003~
RMR*IV*INV-20388*PI*1174.80*1236.00~
DTM*003*20260921~
ADX*-61.20*01~
SE*13*0001~
Read it as arithmetic. INV-20417 is paid on 12 October, inside the 10 days, so the 1% discount applies: 1% of 415.40 is 4.154, rounded to 4.15, and 415.40 minus 4.15 is 411.25. INV-20388 is dated 21 September and is past its discount date. It billed 120 units at 10.30, which is 1,236.00, against a PO price of 9.79. The buyer deducts 120 times 0.51, which is 61.20, with reason 01, pricing error, and pays 1,236.00 minus 61.20 is 1,174.80. The payment is 411.25 plus 1,174.80, which is 1,586.05, and that is BPR02. BPR01 is I, so the money arrives as a separate ACH deposit with trace 0012604417, effective on the date in BPR16. There are 13 segments from ST to SE, so SE01 is 13.
The envelope around it
ISA*00* *00* *01*123456789 *ZZ*NORTHFIELD *261012*0610*U*00401*000001291*0*P*>~
GS*RA*123456789*NORTHFIELD*20261012*0610*1291*X*004010~
ST*820*0001~
SE*13*0001~
GE*1*1291~
IEA*1*000001291~
The 820 comes from the buyer, so the sender in ISA06 and GS02 is the buyer's ID, as on the 850. The control numbers continue the buyer's own sequence (1203 on the 850, 1291 here). Each pair has to match: ISA13 and IEA02, GS06 and GE02, ST02 and SE02, and SE01 has to be the real segment count of 13. GS01 is RA. ISA15 is P for production and T for test. Each payment is its own transaction set, so a file with 4 payments has GE01 of 4 and four ST and SE pairs, each with its own BPR02 that has to match its own deposit.
Who sends the 820, and how they differ
Kroger publishes two 820 maps in version 5010, one for electronic funds transfer and one for remittance advice, checked on 3 October 2026. They show how one buyer uses the same transaction set two ways.
| Element | Kroger EFT 820 | Kroger remittance 820 |
|---|---|---|
| BPR01 | P (prenotification) or X | I, remittance information only |
| BPR04 and BPR05 | ACH, with CCP or CTX | CHK |
| TRN02 | Kroger-assigned trace number | Kroger check number |
| RMR03 | ER, evaluated receipts settlement | ER |
| ADX02 | ZZ only | 02 or ZZ |
| Store detail | NM1 with division and store number | NM1 PE or SN, REF BT batch number |
Two details matter for mapping. RMR03 ER is evaluated receipts settlement, where the buyer pays from its own receiving record, so the RMR amounts can differ from the 810. And with ADX02 ZZ, mutually defined, the code says nothing; Kroger's map puts a free-text NTE segment under the ADX, which the integration has to read and classify. Kroger lists the 820 under "EFT and Remittance Advice" on its EDI requirements page; more on its program under EDI with Kroger.
What goes wrong in cash application
- Payment and remittance arrive apart. With BPR01 I the deposit can land a day before or after the 820. Matching on amount alone fails as soon as two payments of the same amount arrive in one week; TRN02 is the key.
- Invoice numbers that do not match. The 810 sent
INV-20417; the buyer's system stores20417. RMR02 then matches no open item, and the payment sits unapplied. - Discount taken late. A buyer that takes 4.15 on a payment made on day 14 has taken a discount the terms did not allow. The integration has to compare the payment date with the invoice date and the ITD terms, not just accept RMR06.
- Deductions without a reason. ZZ with a free-text note, or a reason code your ERP has no mapping for, ends up as an unexplained difference. In the sample, 61.20 is traceable to one invoice line and one price; without the ADX it would be 61.20 missing.
- Credit memos inside the payment. An RMR with CL or CM and a negative amount reduces the total; a mapping that ignores negative RMR lines overstates what was paid.
The cost of these errors is open receivables and the hours spent researching them. Retailers set their own process and deadline for disputing a deduction; how they check documents is under EDI compliance.
Handling the 820 on the ERP side
The 820 becomes a customer payment applied to open invoices. Four records come out of it.
| 820 data | ERP record | Rule |
|---|---|---|
| BPR02, TRN02, BPR16 | Customer payment, matched to the bank line | Amount and trace number both match |
| RMR02, RMR04 | Application to the open invoice | Invoice found by number; paid amount applied |
| RMR06 | Terms discount booked to the discount account | Allowed only inside the terms in the 810 |
| ADX01, ADX02 | Deduction or claim against the invoice | Reason code mapped to a deduction type |
An invoice that is paid in full and on terms closes without anyone touching it. An invoice with a deduction stays open for the deducted amount, linked to the reason, so it can be disputed or written off. The rounding rule for the discount, 4.154 to 4.15, has to be the same in the ERP as at the buyer, or every discounted invoice leaves a cent open; the note on money, tax and rounding covers that.
We build the 820 as part of an EDI integration to your ERP: payments matched to the deposit, invoices closed, discounts checked against the terms, and deductions recorded with their reason so nothing disappears into an unexplained difference. Remittances that do not balance are held in the dashboard with the line that does not match. Tell us which partners pay you by 820.
Frequently asked questions
What is the difference between BPR01 C and I in an EDI 820?
C means the payment accompanies the remittance advice: the money and the detail travel together through the bank. I means remittance information only: the money moves separately, by check or ACH, and the 820 explains it. With I, the supplier has to match the 820 to the deposit itself, usually on the trace number in TRN02.
Why does the 820 amount not match the invoice?
Because the buyer took a terms discount, made a deduction, or both. RMR05 carries the invoiced amount, RMR04 what was paid, RMR06 the discount taken, and ADX segments the adjustments with a reason code. The 820 total in BPR02 is the sum of what was paid, not of what was invoiced.
What is the EDIFACT equivalent of the 820?
The REMADV message, the remittance advice. The pairing is industry convention and consistent across sources; neither X12 nor UN/CEFACT publishes an official crosswalk between the two standards.
Does the supplier answer an 820?
Only with a 997 functional acknowledgment, which confirms the file was received and parsed. There is no business reply. A deduction the supplier disputes goes back through the retailer's claims process, not through another 820.
Is the 820 also used in healthcare?
Yes. HIPAA has its own 820 implementation, 005010X218, for group insurance premium payments, with its own rules. The retail and distribution 820 on this page is the general X12 transaction set; a health plan guide does not apply to it.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase