EDI 820 Payment Order/Remittance Advice Guide

The EDI 820 Payment Order/Remittance Advice is the X12 transaction set a buyer sends to tell a vendor which invoices were paid, what amounts were applied, and how the funds were transferred. Without it, vendors are left matching bank deposits to open invoices manually, which is slow and error-prone at any scale.

What Is an EDI 820?

An EDI 820 is a structured remittance document defined by the ASC X12 standards body that maps each invoice being paid to its disbursement amount, deductions, and the underlying bank transaction that carries the funds.

Authoritative sources for 820 implementation:

• The X12.org Transaction Sets reference defines the BPR, TRN, RMR, and ADX segment structure for all 820 implementations
• NACHA governs ACH payment standards, including the CTX format used in BPR05 when the 820 accompanies a Corporate Trade Exchange ACH transaction

An EDI 820 is sent from the buyer (payer) to the vendor (payee) to communicate payment details. It typically accompanies or follows an electronic funds transfer (EFT) such as an ACH payment or wire transfer.

The 820 answers three questions for the vendor:

1. How much was paid? Total payment amount and method.
2. Which invoices does this cover? Specific invoice references and amounts applied.
3. Were there any adjustments? Deductions for discounts, chargebacks, or disputes.

How the 820 Differs from the 810 Invoice

The EDI 810 invoice flows from vendor to buyer and requests payment. The 820 flows in the opposite direction, from buyer to vendor, and confirms that payment was made. Think of the 810 as "here is what you owe" and the 820 as "here is what we paid."

Key Segments in the EDI 820

The 820 uses a specific set of segments to describe the payment and map it back to individual invoices. Here is a breakdown of the most important ones.

BPR - Beginning Segment for Payment Order

The BPR segment is the heart of the 820. It contains the total payment amount, the payment method, and banking information for both the sender and receiver.

BPR*C*15000*C*ACH*CTX*01*021000089*DA*123456789*9876543210**01*071000013*DA*987654321*20260310

Key elements:

• BPR01: Transaction handling code (C = Payment with remittance)
• BPR02: Total payment amount ($15,000.00)
• BPR03: Credit/debit flag (C = Credit)
• BPR04: Payment method (ACH, CHK, FWT for wire)
• BPR05: Payment format (CTX = Corporate Trade Exchange)
• BPR06-09: Originating bank routing and account
• BPR10: Originator's ID
• BPR12-15: Receiving bank routing and account
• BPR16: Payment effective date

TRN - Trace Segment

The TRN segment provides a unique reference number that ties the EDI data to the actual bank transaction. This is critical for reconciliation.

TRN*1*PYMT-2026-0451*9876543210

• TRN01: Trace type code (1 = Current transaction trace)
• TRN02: Reference identification (your payment trace number)
• TRN03: Originating company identifier

N1 - Party Identification

N1 segments identify the parties involved in the payment. You will typically see at least two: the payer (PR) and the payee (PE).

N1*PR*ACME DISTRIBUTION INC*92*BUYER001
N1*PE*WIDGET SUPPLY CO*92*VENDOR001

• N1*PR: Payer (the company sending money)
• N1*PE: Payee (the company receiving money)

RMR - Remittance Advice Reference

This is where the 820 gets specific. Each RMR segment maps a portion of the payment to an individual invoice.

RMR*IV*INV-10234**5000
RMR*IV*INV-10235**7500
RMR*IV*INV-10236**2500

• RMR01: Reference number qualifier (IV = Invoice)
• RMR02: Invoice number being paid
• RMR04: Amount applied to this invoice

In the example above, three invoices totaling $15,000 are covered by a single payment.

DTM - Date/Time Reference

Date segments provide context for the payment and individual invoices.

DTM*007*20260310

• DTM01: Date qualifier (007 = Effective date, 003 = Invoice date)
• DTM02: Date in CCYYMMDD format

Payment Methods in the 820

The BPR04 element specifies how the payment was actually transferred. Here are the most common codes:

ACH is by far the most common method for EDI 820 transactions. It is cost-effective and settles within 1-2 business days. Wire transfers are faster (same day) but carry higher fees, so they are usually reserved for large or urgent payments.

How the 820 Fits the Order-to-Cash Cycle

The 820 is the final step in the standard EDI order-to-cash workflow. Here is the full cycle:

1. EDI 850 Purchase Order      Buyer places the order
2. EDI 855 PO Acknowledgment   Vendor confirms the order
3. EDI 856 Ship Notice (ASN)   Vendor ships and notifies buyer
4. EDI 810 Invoice             Vendor requests payment
5. EDI 820 Payment Order       Buyer sends payment details

The EDI 850 purchase order starts the cycle, the 810 invoice requests payment, and the 820 closes it. Without the 820, vendors are left matching bank deposits to invoices manually, which is slow and error-prone.

For a business-level overview of this flow, see our article on order-to-cash automation.

Reconciling 820s Against Invoices

Automated reconciliation is where the 820 delivers the most value. Here is what to match:

Step-by-Step Reconciliation

1. Match the TRN trace number to the incoming bank deposit.
2. Loop through each RMR segment and match invoice numbers to your open AR.
3. Compare amounts. If the RMR amount matches the invoice total, mark it paid. If it is less, check for adjustments.
4. Process any ADX (adjustment) segments. These explain deductions like early payment discounts, chargebacks, or returns.
5. Flag exceptions. Any invoice referenced in the 820 that does not exist in your system needs manual review.

Adjustment Segments (ADX)

When the buyer takes a deduction, the ADX segment follows the related RMR:

RMR*IV*INV-10234**4900
ADX*100*01*TD

• ADX01: Adjustment amount ($100 deducted)
• ADX02: Adjustment reason code (01 = Pricing error)
• ADX03: Reference ID qualifier

Common adjustment reason codes:

Common Errors and Troubleshooting

1. Payment Amount Does Not Match Invoice Total

Symptom: The BPR02 total does not equal the sum of RMR amounts.

Fix: Check for ADX adjustment segments. Buyers often take deductions for discounts, freight claims, or chargebacks. The math should work out as: BPR total = sum of RMR amounts minus sum of ADX deductions.

2. Missing or Unrecognized Invoice Numbers

Symptom: An RMR segment references an invoice number that does not exist in your system.

Fix: Check for formatting differences. Some buyers strip leading zeros or add prefixes. Confirm the invoice numbering convention with your trading partner.

3. Duplicate TRN Trace Numbers

Symptom: You receive an 820 with a TRN reference you have already processed.

Fix: Implement duplicate detection on the TRN02 field. Contact the buyer to confirm whether this is a correction or a duplicate transmission.

4. Bank Deposit Does Not Match BPR Amount

Symptom: The actual bank deposit differs from BPR02.

Fix: Check if the buyer batched multiple 820s into a single wire or ACH transfer. Also verify the payment effective date in BPR16. The deposit may not have settled yet.

5. Incorrect Payment Method Code

Symptom: BPR04 says ACH but the payment arrived as a wire, or vice versa.

Fix: This is usually a configuration issue on the buyer side. Flag it with the trading partner and update your mapping if the buyer has changed their payment process.

Full 820 Example

Here is a complete EDI 820 showing payment for two invoices:

ISA*00*          *00*          *ZZ*BUYER001       *ZZ*VENDOR001      *260310*1200*U*00401*000000012*0*P*:~
GS*RA*BUYER001*VENDOR001*20260310*1200*12*X*004010~
ST*820*0012~
BPR*C*12500*C*ACH*CTX*01*021000089*DA*123456789*9876543210**01*071000013*DA*987654321*20260310~
TRN*1*PYMT-2026-0310*9876543210~
DTM*007*20260310~
N1*PR*ACME DISTRIBUTION INC*92*BUYER001~
N1*PE*WIDGET SUPPLY CO*92*VENDOR001~
ENT*1~
RMR*IV*INV-20450**7500~
DTM*003*20260224~
RMR*IV*INV-20451**5000~
DTM*003*20260228~
SE*13*0012~
GE*1*12~
IEA*1*000000012~

This 820 shows ACME Distribution paying Widget Supply Co $12,500 via ACH, covering invoices INV-20450 ($7,500) and INV-20451 ($5,000).

Validating Your 820 Implementation

Use our free EDI Inspector to parse and validate 820 transactions before going live with a trading partner. It will check segment structure, required elements, and reference formatting so you can catch issues before they cause payment delays.

FAQ

How is the EDI 820 different from a bank statement?

A bank statement shows raw deposits and withdrawals without any invoice-level detail. The 820 breaks down each payment by invoice number, adjustment, and amount applied. It is the bridge between your bank account and your accounts receivable ledger.

Can one 820 cover multiple invoices?

Yes. This is the most common scenario. A single 820 can contain dozens of RMR segments, each referencing a different invoice. The BPR total should equal the sum of all RMR amounts minus any ADX adjustments.

Is the 820 required for EDI compliance?

It depends on the trading partner. Many large retailers and distributors send 820s as part of their standard EDI program, but it is not universally required. If your buyer sends payments via ACH, you should strongly encourage them to send 820s. Without them, you are stuck matching deposits manually.

What should I do if the 820 amount does not match the bank deposit?

First, check the payment effective date (BPR16). The deposit may not have cleared yet. If the date has passed, look for batched payments where multiple 820s correspond to a single deposit. If neither explains the discrepancy, contact the buyer's AP team with the TRN trace number for investigation.

Related Guides

• EDI 810 Invoice Guide - The invoice that triggers the payment
• EDI 850 Purchase Order Guide - Where the order-to-cash cycle begins
• EDI payments explained - Business-level overview of electronic payment flows
• Order-to-cash automation - How to automate the full cycle from order to payment

Need Help?

Try our free EDI Inspector to validate your 820 transactions, or book a call with the OrderSync team to discuss payment automation for your trading partner network.