Audience: EDI developers, B2B integration teams, accounting teams
The 820 Payment Order/Remittance Advice is an EDI transaction sent by a buyer to notify you of a payment being made against your invoices. This article covers what 820 transactions contain, how to set them up in Orderful, and what to expect when receiving them.
What the 820 Does
The 820 is a notification document — it tells you a payment is coming and provides the detail needed to apply it to your open accounts receivable. It does not transfer funds.
The actual payment (ACH, wire, check) is arranged separately between you and your trading partner and will arrive through your bank regardless of the 820.
820s are most common in retail supply chains where large buyers — major retailers and grocery chains — operate full EDI workflows.
Outside of that, remittance is often delivered by email (PDF or Excel), through a vendor portal, or not at all (lump-sum ACH with no remittance detail).
If you're already receiving orders and invoices via EDI with a trading partner, adding the 820 closes the loop on the payment side of the workflow.
What a 820 Contains
BPR — Payment details
The BPR segment is the header of the 820. It contains:
BPR02 — total payment amount
BPR03 — credit/debit indicator
C(Credit) — funds are being sent to you; money coming inD(Debit) — the buyer is collecting from you, typically for chargebacks or fees
BPR04 — payment method (e.g., ACH, check)
BPR16 — payment date
Not all 820s will carry full banking detail — this depends on whether the remittance is traveling with the funds (CTX/ACH) or separately.
N1 — Party identification
N1*PR— the paying entity (your buyer)N1*PE— the payee (you)
ENT and RMR — Invoice-level detail
A single 820 almost always covers multiple invoices and purchase orders. The ENT loop groups the remittance, and each RMR segment within it references one open item:
RMR01/RMR02 — reference qualifier and number (typically invoice number)
RMR04 — amount paid
RMR06 — discount taken
A REF*PO inside the RMR links the invoice back to the originating purchase order. One 820 from a large retailer can contain hundreds of RMR segments covering hundreds of POs in a single payment run.
ADX — Adjustments and deductions
The ADX loop carries adjustments that are not tied to a specific invoice — chargebacks, blanket allowances, promotional deductions, and other amounts the buyer is taking off the total payment.
These may include REF segments providing context for the deduction, but they often don't map cleanly to a single PO or invoice.
This is the part of the 820 that requires the most manual work during cash application, particularly when integrating into an ERP like NetSuite.
What the 820 Is Not
Not a guarantee of payment — it is a statement of intent. Confirm actual receipt with your bank.
Not a 1:1 document — a single 820 typically covers many invoices and POs. Do not expect one payment per invoice.
Not a source of funds — if you receive 820s but no money, the issue is with your banking/payment setup with the trading partner, not with the EDI transaction.
Integrating 820 Data into Your Accounting System
Many customers route 820 data into NetSuite or other ERP systems for automated cash application. A few things to plan for:
Multi-invoice structure — your integration needs to handle one-to-many matching (one 820 to many AR items)
ADX deductions — not all adjustments will have a corresponding open invoice; your system needs logic to handle unmatched deductions
Format changes — trading partners occasionally update their 820 format (e.g., how invoices are grouped in ENT/RMR). Build your parsing to handle format variations rather than hardcoding assumptions about structure
BPR03 credit vs. debit — make sure your integration handles both directions; a debit 820 represents money going out, not in
Frequently Asked Questions
I'm receiving 820s but no actual money — what's wrong?
The 820 is a notification only. Actual payment delivery depends on separate banking arrangements with your trading partner. Contact your buyer to confirm your payment details are current and ask about processing timelines.
Why does one 820 reference so many invoices and POs?
Large buyers typically run weekly or bi-weekly payment cycles that consolidate all outstanding invoices into a single payment and a single 820. This is normal — your cash application process needs to match the total payment against all referenced invoices individually.
What are the ADX deductions in my 820?
ADX carries adjustments not tied to a specific invoice — chargebacks, allowances, and other amounts deducted from the total payment. The REF segments inside ADX provide context, but matching these back to specific POs often requires manual review or coordination with your buyer's AP team.
BPR03 shows "D" — does that mean I owe money?
A debit (D) on BPR03 means the buyer is collecting from you rather than paying you. This typically indicates a chargeback or fee being deducted. If you weren't expecting a debit, contact your buyer's AP team for clarification.
Can I automatically process 820 transactions into my accounting system?
Yes, many customers integrate 820 data into NetSuite or other ERPs. Plan for multi-invoice matching and ADX deductions that don't map directly to open invoices. Format changes from trading partners can also break integrations — build robust parsing that handles structural variations.
My trading partner sends remittance by email — should I switch to 820?
If you're already on EDI with the partner for orders and invoices, asking them to add 820 is a reasonable next step. It removes manual email processing and enables automated cash application. Not all partners support it — check their EDI capability list or ask their EDI team.
What happens if the same invoice appears multiple times in one 820?
This is a data generation issue on the trading partner's side — the same invoice reference is being duplicated across RMR segments. Contact your trading partner's IT team to correct their file generation.