The EDI 820, Decoded: Payment Is Only Half the Message — the Remittance Is the Other Half

An 820 · Payment Order / Remittance Advice is how a buyer tells a seller not just that money is moving, but exactly what that money is for: which invoices it pays, in what amounts, and what was deducted and why. The payment answers "how much arrived?" The remittance answers "how do we apply it?" — and without the second answer, the first one creates work instead of closing books.

I run SignalEDI. This series has walked the order-to-cash chain step by step — the 850 · Purchase Order, the 855 · Purchase Order Acknowledgment, the 856 · Ship Notice / ASN, the 810 · Invoice, the 846 · Inventory Inquiry/Advice that feeds the front of the chain, and the 997 · Functional Acknowledgment that proves a file parsed. The 820 is where the chain closes. It is also the document whose absence most people only notice at month-end, when a bank deposit sits in the account unapplied and nobody can say which orders it settled.

What is an 820 · Payment Order / Remittance Advice?

It is the X12 transaction set a payer uses to make or report a payment and to send the remittance detail that goes with it. One 820 can do both jobs — instruct a financial institution to move funds and tell the payee how to apply them — or it can travel as remittance advice alongside a payment made another way, such as an ACH transfer through the banking network.

The structure reflects that split. A payment section states the total amount, the payment method, and the payer and payee identities. Then, for each invoice being paid, a remittance loop names the invoice, the amount paid against it, and any adjustment — a deduction taken, with a reason code. That line-by-line detail is the entire value of the document. A total with no breakdown is a riddle; a total whose parts sum visibly to the invoices it covers is a closed transaction.

How is an 820 different from an 835?

They sound alike because they are cousins, and confusing them is common. The 835 · Healthcare Benefit Payment / Remittance Advice is the healthcare-specific remittance document: it reports how a payer adjudicated claims submitted on an 837 · Claim, including allowed amounts, denials, and patient responsibility. The 820 is the general-purpose payment and remittance document used across retail, manufacturing, distribution, and most other industries.

A useful rule of thumb: if the thing being paid for is a healthcare claim, the remittance is an 835. If the thing being paid for is an invoice for goods or services, the remittance is an 820. Both exist for the same reason — money without explanation is only half a message — but their data, their vocabularies, and their regulators are different.

Why do deductions and short-pays cause so much pain?

Because a short payment is a claim, and the 820 is where that claim has to be explained. A buyer rarely pays an 810 · Invoice short by accident. They deduct for a damaged shipment, a pricing dispute, a missed promotion, or a compliance chargeback — and each deduction is supposed to arrive in the remittance loop with a reason code the seller can route: to logistics, to pricing, to the compliance team.

When that detail is missing, late, or trapped in a PDF or a bank-portal note instead of the 820, the seller's accounts-receivable team becomes a detective agency. Cash sits unapplied, invoices that were actually paid stay open, credit holds trigger on customers who owe nothing, and the deduction dispute window quietly expires. The argument is almost never about the money. It is about whether the explanation travelled with it, in a form a system can match.

What should a good 820 get right?

Reference every invoice exactly as it was billed — the seller's invoice number from the 810, not the buyer's internal voucher number nobody else can see. Make the arithmetic visible: invoice amounts minus stated adjustments should equal the payment total, to the cent, because the receiver's first automated check will do exactly that sum. Give every deduction a reason code and, where the deduction refers to a shipment or an order, the reference that lets the seller find it. And send the remittance when the payment is initiated, not days later — remittance that arrives after the cash forces the same manual matching the document exists to prevent.

What should sellers do with an 820?

Auto-match it before a human touches it. Most 820s in a healthy relationship should apply themselves: invoice numbers match, amounts agree, deductions carry known reason codes and route to their owners. Reserve human attention for the exceptions — the unexplained deduction, the invoice number that matches nothing, the total that does not foot. Then reconcile the pattern, not just the payment: a buyer whose deductions cluster on one reason code month after month is telling you about a real operational problem, in data you already have.

Frequently asked questions

Does an 820 move the money itself?
It can instruct a financial institution to make a payment, but in many relationships the funds move separately — commonly by ACH — and the 820 travels as the remittance advice that explains the payment. Either way, its remittance detail is the part the receiver cannot do without.

What is the difference between paying an invoice and applying a payment?
Paying moves the funds. Applying tells the seller's books which invoices those funds settle. An 820 does the second job explicitly, line by line, which is why a payment without one leaves invoices open even though the money arrived.

Can one 820 pay invoices from more than one order?
Yes. A single payment commonly settles many invoices at once, with one remittance loop per invoice — that batching is precisely why the line-level breakdown matters.

The pattern across this series holds one last time: each EDI document answers exactly one question well. The 820's question is "what is this money for?" — and answering it in the same breath as the payment is the discipline we build SignalEDI around.

— Chris, founder of SignalEDI