X12 transaction guide · Finance

EDI 820 Payment Order/Remittance Advice

The X12 document that explains a payment, listing the invoices paid, amounts and any deductions, and in some cases instructs a bank to pay.

Sent by: Payer (buyer) or its bank
Received by: Payee (supplier) or bank
Standard: ANSI ASC X12
EDIFACT equivalent: REMADV (remittance) / PAYORD (payment order)

What is an EDI 820?

The EDI 820 Payment Order/Remittance Advice is the ANSI X12 transaction set used to communicate payment information. As a remittance advice, a buyer sends it to a supplier to explain which invoices a payment covers, the amounts paid and any deductions or adjustments. As a payment order, a company can send it to its bank with instructions to make the payment.

For suppliers, the 820 is the key input to cash application. Payments often arrive separately from the remittance detail and frequently cover many invoices at once, so matching 820 data to open receivables automatically saves considerable manual effort.

How to read this diagram: the top row shows who sends the 820, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 820 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.

Expand diagram Download SVG

When it is used

Retailers explaining payments and deductions to suppliers
Companies sending payment instructions with remittance detail to their banks
Carriers and 3PLs receiving payment details for freight invoices
Automating cash application against open invoices

Where it fits in the document flow

Usually follows 810 Invoice

This document 820 Payment Order/Remittance Advice

Usually followed by 997 Functional Acknowledgment

Structure

Key segments in the 820

The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 820; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.

Segment	Name	What it carries	In X12 004010
BPR	Beginning Segment for Payment Order/Remittance Advice	Payment amount, payment method, bank and account details, and payment date.	Required
TRN	Trace	Trace number that links the remittance to the payment.	Optional, common
N1 loop	Party Identification	Payer and payee names and identifiers.	Optional, common
ENT	Entity	Groups remittance detail by entity, such as a payee account.	Optional, common
RMR	Remittance Advice Accounts Receivable Open Item Reference	Each invoice paid with the amount paid and, where applicable, the original and discount amounts.	Optional, common
ADX	Adjustment	Deductions or adjustments with reason codes.	Optional, common

Example

Sample EDI 820

A 1,500.00 ACH payment with remittance detail covering two invoices. BPR carries the amount, method and fictional bank details, TRN the trace number, and each RMR an invoice paid.

Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.

ST*820*0001~
BPR*C*1500.00*C*ACH*CCP*01*123456780*DA*1111111111*1234567890**01*987654320*DA*2222222222*20261030~
TRN*1*TRC9001*1234567890~
N1*PR*Example Retailer~
N1*PE*Example Supplier~
ENT*1~
RMR*IV*INV1001**300.00~
RMR*IV*INV1002**1200.00~
SE*9*0001~

The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.

Expand diagram Download SVG

Avoid problems

Common 820 errors and how to prevent them

Remittance not linked to payment

Without the trace number, remittance detail cannot be matched to the bank deposit it explains.

Deductions ignored

Adjustments with reason codes should flow into deduction management, not be written off automatically.

Invoice numbers reformatted

Buyers sometimes truncate or reformat invoice numbers. Matching logic should handle common variations.

Trading partners

Integration guides that include the 820

How ECOM helps

Automate the 820 with ECOM

Solution

Procure-to-Pay Automation

Automate purchasing, receiving and supplier invoicing across EDI, portals and documents.

Solution

Financial Document Automation

Automate invoices, remittances, payment files and bank statements from capture to posting.

Industry

Financial Services

Secure file transfer and B2B integration for banks and financial institutions.

EDI 820 FAQs

What is an EDI 820 used for?

It explains a payment, listing the invoices paid, amounts and deductions, and can also serve as a payment instruction to a bank.

Does the 820 move money?

When used as a payment order sent to a bank, it can instruct payment. As a remittance advice between trading partners, it only describes a payment made separately.

How does an 820 help cash application?

It provides the invoice-level detail needed to apply a payment to open receivables automatically.

More general questions about EDI are answered in the EDI FAQ.

Related transactions

Need help with the EDI 820?

ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.

Request a Demo Contact us