Does an EDI 820 Confirm a Payment Was Made?

No. An EDI 820 confirms payment intent and allocation, meaning which invoices a buyer says it's paying, how much, and what got deducted. It does not confirm that cash has actually settled in your bank account. As Corpay frames it, the 820 carries "intent and allocation; no settlement confirmation". The money itself usually moves on a separate rail, most often ACH, and you have to match the two records yourself.

What information does an EDI 820 actually carry?

An 820 carries payment method, total amount, and effective date in the BPR segment, plus invoice-level detail in the RMR segment that tells you which open items the payment applies against. The transaction set exists specifically to explain a lump sum, not to prove it landed.

Cleo describes the 820 as a specific EDI transaction, where payment data is transferred between a buyer and seller, and it's typically issued after an EDI 810 invoice or an EDI 850 purchase order has already been exchanged. The segments you'll work with most:

• BPR (Beginning Segment for Payment Order): total payment amount, payment method code (ACH, CHK, FWT for wire), and bank routing details.
• TRN (Trace): a unique reference number you'll use to tie the remittance back to the actual bank transaction.
• RMR (Remittance Advice Accounts Receivable Open Item Reference): links the payment to specific invoice numbers.
• ADX: carries adjustment or deduction reason codes when the paid amount doesn't match the invoiced amount.

QServices sums up the ERP posting logic cleanly: "decode the BPR and RMR segments, match each line to an open invoice, and post cash once the bank credit lands". Notice the sequencing. Matching happens on receipt of the file. Posting cash happens only once the bank confirms the credit.

Why doesn't my EDI 820 match the bank deposit?

Usually because the file and the funds transfer took different paths, or because deductions were netted out in a way your AR team didn't expect. This is the single most common source of "why isn't this payment showing up" tickets in any EDI-heavy AP/AR shop.

A few recurring causes worth checking before you assume non-payment:

• The 820 arrived days before or after the ACH credit, because remittance and funds transfer are separate processes with separate timing.
• Deductions, chargebacks, or short pays were netted against the gross invoice total, so the deposited amount is smaller than what you billed.
• The payment rode as a plain CCD entry with no addenda record, so your bank statement shows a generic ACH credit with nothing to match against.
• Your 820 enrollment with that trading partner was never fully configured separately from the banking setup, so remittance detail never reaches you at all.

On that last point, SPS Commerce notes that a missing remittance detail issue is often explained because "the payment was sent as a plain CCD entry, which carries no addenda record, or your EDI 820 enrollment with that retailer was never completed separately from your banking setup". The fix is almost always the same: match on the TRN trace number rather than the dollar amount alone, and ask your bank whether it's actually passing through ACH addenda records or stripping them.

Is an EDI 820 the same as an ACH payment?

No. The 820 is data describing a payment. ACH is the network that actually moves money between banks. They can travel together or completely separately, and conflating the two is where most reconciliation headaches start.

OrderSync's guide draws this distinction directly, noting that the 820 is the remittance advice and ACH is the payment rail, and they answer different questions and are governed by different standards bodies. There are two delivery patterns in practice. In "separate delivery," the buyer sends the 820 over your normal EDI channel while instructing their bank to move funds by ACH independently. In "bundled delivery," the remittance detail rides inside the ACH transaction itself as CTX addenda. A CCD+ entry, by contrast, only carries a single short addenda record, nowhere near enough for multi-invoice remittance detail, which is exactly why some deposits show up with zero explanation attached.

How is an EDI 820 different from an EDI 835 or an EDI 997?

An 835 is the healthcare-specific equivalent used for claim adjudication, while a 997 is just a functional acknowledgment confirming a document was received and structurally valid, nothing about payment at all. Mixing these up with the 820 leads to false confidence about what's actually been confirmed.

Corpay's comparison puts it plainly: the 820 covers "intent and allocation; no settlement confirmation," while the 835 is the "adjudication outcome; settlement still comes from the bank" in a healthcare claims context. If you've read our earlier breakdown of what an EDI 997 actually guarantees, the parallel is obvious. An accepted 997 tells you the file parsed correctly. It says nothing about dollars, invoices, or deductions. Treating a 997 as payment confirmation is the same category of mistake as treating an 820 as settlement proof. Neither one touches the bank.

How does an EDI 820 fit into freight and carrier payment reconciliation?

It doesn't, directly. Freight invoices run on their own EDI 210 and EDI 110 motion, but shippers are increasingly applying the same reconciliation discipline that AP/AR teams built around 820/810 pairs to carrier invoices. The underlying problem is identical: a lump sum payment needs line-level detail before anyone can confirm it's correct.

In practice this shows up as freight audit and invoice reconciliation sitting inside or alongside a TMS, checking each carrier invoice against the rate that was actually agreed at tender time rather than approving charges blind. Freight billing errors have been estimated to cost mid-market shippers between 3% and 7% of total annual freight spend, and those errors only surface if the expected cost was recorded somewhere before the invoice arrived. Platforms like MercuryGate, Descartes, and Cargoson all sit in this space in different ways, centralizing carrier connectivity and giving finance teams a record to audit invoices against instead of trusting the carrier's number outright. None of this runs through an 820. But the discipline, don't post cash or approve a payable until you've matched it against a known-good reference, is the exact same muscle an EDI manager builds doing 820-to-bank reconciliation on the retail side.

Is an EDI 820 required for EDI compliance with major retailers?

Usually it's supplementary rather than a hard compliance gate. Core mandates center on the 850, 856, and 810. The 820 shows up as a "supporting" or "commonly used" document on most retailer EDI guides rather than a pass/fail requirement.

SEEBURGER confirms this directly: "the use of EDI 820 is optional and is less common than some compulsory EDI document types", though larger buyers lean on it more because they're more likely to settle multiple invoices in a single payment run. That said, don't read "optional" as "unimportant." Large retailers increasingly expect it because it cuts the volume of AP phone calls their own finance teams field, and most VAN and translator providers, including SPS Commerce, TrueCommerce, and Cleo, support 820 mapping as a standard offering rather than a custom build.

What should you actually check before calling it a missed payment?

Pull the TRN trace number from the 820, not the invoice total, and search for it on your bank statement or ask your bank to confirm whether ACH addenda records are being passed through intact. If the numbers still don't reconcile after that, check the ADX segment for deduction codes before escalating, because a short pay dressed up as a missing payment wastes everyone's time. The 820 did its job the moment it told you what was supposed to happen. Whether it actually happened is a separate question, and it always will be.