EDI 820: When the Remittance Is Reconcilable and When the Money Is Still Moving

The EDI 820 is the ASC X12 Payment Order/Remittance Advice transaction set. It can be used to make a payment, to send a remittance advice, or to do both in one transmission, according to ASC X12's current release transaction set catalog. Which of those three a given 820 is doing determines whether you can post against it.

That ambiguity is the whole problem. An AP or treasury analyst holding an 820 usually wants one answer, which is whether the cash has arrived, and the transaction set frequently doesn't contain it. Posting a remittance-only 820 as cash received is the error that produces a reconciliation mess three weeks later when the funds never land.

Key Takeaways

• An 820 can carry a payment order, a remittance advice, or both. Read which one you have before you post anything.

• Remittance detail and settlement status are different records, and the 820 reliably carries only the first.

• A 997 acknowledges that the file was received and syntactically accepted. It says nothing about money.

• Settlement finality depends on the rail, and the gap between the 820 arriving and funds clearing can run several days on ACH.

• Post on the settlement event, match on the remittance detail, and keep those two operations separate in your process design.

What is an EDI 820 and what does it assert?

An 820 asserts the payer's intent and the allocation of an amount across invoices. It tells you who is paying, how much in total, which invoices the payment covers, and what adjustments or deductions were applied to each. That's a complete description of what the money is meant to do.

What it asserts about the money itself depends on how it was sent. When the 820 is routed to a bank as a payment order, it instructs the bank to originate a payment. When it's sent directly to the payee as a remittance advice, it describes a payment that's been initiated somewhere else, on a timeline the 820 doesn't specify. The same transaction set, two very different meanings, and the difference isn't always obvious from the file.

Which segments carry the remittance detail?

Map the structure once and reuse it, because implementations vary less than the guides suggest. The BPR segment carries the beginning payment order or remittance advice, including the total monetary amount, the payment method code, and the effective date. TRN carries the trace or reference number that ties the payment to the payer's own records.

Below that, the detail loop does the allocation work. Each RMR segment identifies an invoice and the amount applied to it, ADX segments carry adjustments and the reason codes for them, and REF segments carry additional identifiers your ERP may need for matching. DTM segments carry the dates, and the effective date in BPR is the one people misread most often.

• BPR carries the total amount, the payment method code, and the effective date

• TRN carries the payment trace or reference number

• N1 loops identify the payer and the payee

• RMR carries a per-invoice reference and the amount applied to it

• ADX carries an adjustment amount and its reason code

• REF and DTM carry supplemental identifiers and dates

What does the 820 not say?

It doesn't say the funds have settled, and nothing in the standard requires it to. The payment method code in BPR tells you which rail was intended, and the effective date tells you when the payer expects it to land, but neither is a confirmation from a bank that money moved.

It also doesn't reliably tell you when the file was generated relative to the payment run. Trading partners vary. Some send the 820 after the payment file goes to the bank, some send it the same day, and some send it in advance as a courtesy. Any of those is a legitimate implementation, which is why "we got the 820" is never sufficient grounds to relieve a receivable or post cash. The general shape of EDI payments in B2B transactions is worth having in view if you're new to the transaction sets.

How does an 820 differ from an 835 and a 997?

Different jobs entirely. The 820 is the general B2B payment order and remittance advice. Its healthcare counterpart, the 835, is the claim payment and remittance advice used between payers and providers, carrying claim-adjudication data an 820 has no equivalent for. A 997 is a functional acknowledgment, which reports that a file was received and passed syntax validation.

The last row is the operative one. Your settlement evidence comes from your bank, not from your trading partner, and no acknowledgment in the EDI chain substitutes for it.

When does the acknowledgment chain matter?

For dispute resolution and for detecting silence. A missing 997 means the receiver never confirmed the file arrived and parsed, which is a different failure from a rejected payment and needs a different phone call. Teams that don't monitor 997s discover missing files at month end rather than at transmission.

Build the monitoring around expected files rather than received ones. A trading partner who normally sends an 820 every Thursday and sends nothing this week produces no error anywhere unless someone is watching for an absence, and absences are precisely what nobody notices.

Which document proves receipt?

The bank record, every time. A posted credit on your bank statement, or the equivalent line in an intraday BAI2 or camt file, is the only document that proves funds arrived. Everything upstream describes an intention with varying degrees of confidence.

One concept worth internalizing here is good funds, which is the point at which money is irrevocably available rather than merely announced. Settlement guarantee is a property of the payment rail and the bank's rules, and it isn't conferred by a document your trading partner generated.

When is an 820 reconcilable and when is settlement still pending?

An 820 is always reconcilable in the matching sense, because it carries the invoice-level allocation you need to clear open items. Whether it's postable as cash is a separate question, answered by the rail and the calendar rather than by the file.

The practical rule most AP and AR teams end up with has two steps:

1. Match on receipt of the 820, which clears the allocation and surfaces short pays immediately.

2. Post on receipt of the bank credit, which is the event that actually moved money. Keeping those two operations separate in your payment reconciliation process removes the entire class of error this article exists to describe.

What does the payment method change about the answer?

Everything, because the lag between initiation and finality varies by rail from seconds to days. The payment method code in BPR tells you which rail to expect, and your posting rule should key off it.

An ACH credit initiated today typically settles on the next banking day or the one after, depending on the originator's file cutoff and whether Same Day ACH was used. That window is where most timing mismatches live, and the volume passing through it is enormous. The ACH Network moved 8.9 billion payments worth $24.1 trillion in the first quarter of 2026, up 4.8% by volume and 9.3% by value, according to Nacha's Q1 2026 ACH Network volume statistics, with B2B ACH volume growing 9.4% year over year to 2.1 billion transactions. The mechanics of how an ACH credit is originated explain why the lag exists and where it can be shortened.

Checks are the other extreme, and they're still present in volume that surprises people. Checks account for 26% of B2B payments, down from 33% in 2022, according to the Association for Financial Professionals's 2025 Digital Payments Survey, and a check referenced in an 820 may not clear for a week or more after the effective date in the file.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

Which rail gives finality and when?

Real-time rails give finality on receipt, which is the cleanest case for posting logic. The RTP network cleared 2.05 million payments on 13 February 2026, its first day at or above two million, and set a single-day value record of $8.36 billion on 18 February 2026, according to The Clearing House. When an 820 references an RTP or FedNow payment, the settlement question is essentially already answered by the time you read the file.

Wire transfers settle same-day with finality. ACH settles on a schedule with a return window that extends past settlement, which matters for reversals rather than for posting. Checks settle whenever they're deposited and cleared. The comparison between RTP and FedNow is worth understanding before you decide which rails your posting rule should treat as immediate.

Migration toward the faster rails is underway but slow, and the honest read of the data is that both states will coexist for years. 73% of organizations are in the process of moving their B2B payments from paper checks to electronic payments, while 86% still make outgoing payments by check, according to the Association for Financial Professionals's 2022 Payments Cost Benchmarking Survey. PYMNTS Intelligence's 2026 study Ready and Willing: B2B Payments Are Headed for Real-Time Rails found that most businesses call their accounts payable processes efficient and 94% say they pay suppliers on time, while 24% of firms not on the RTP network say their current methods work well enough. Self-assessment and reconciliation reality diverge a long way in those numbers.

What does the field-to-ledger map look like for one invoice?

Straightforward, until a partial payment or a deduction shows up. For a clean single-invoice payment the mapping is nearly mechanical, and it's worth writing down once so every analyst applies it the same way.

Only the last row carries a settled status, which is the point of laying it out this way.

Which identifier carries through to the GL?

The TRN reference is the one that survives the journey, because it's the value most likely to appear in the bank credit's description or addenda. Match the TRN to your bank record and you've linked the remittance to the settlement without guesswork.

Invoice numbers in RMR carry through to your open items, not to your cash. They're the matching key on the receivables side and they're frequently mangled by the payer's own systems, with leading zeros stripped, prefixes dropped, or an internal reference substituted. Normalizing those on receipt is unglamorous work that pays back immediately, and remittance advice handling is where most teams build that normalization.

Where do partial payments break the map?

At the point where the sum of RMR applied amounts doesn't equal the BPR total, which happens more often than it should. Three causes account for most of it.

• A deduction recorded in ADX that the payee hasn't agreed to

• A payment covering invoices the payee hasn't issued yet, or has already written off

• A rounding or currency difference in a partially applied amount

Each requires a different resolution and each should be routed to a different owner. Treating them as one bucket called "unapplied cash" is how a reconciliation queue grows to four figures. The discipline is the same one behind three-way matching, which is that a variance without a named owner and a resolution rule will sit indefinitely.

Which exceptions should stop a posting?

Four, and only four. A short pay with no ADX explanation, a total that doesn't reconcile to the sum of its lines, an 820 referencing an invoice that doesn't exist in your system, and an 820 whose expected settlement date has passed with no corresponding bank credit.

Everything else can be matched provisionally and resolved in the normal queue. Stopping a posting is expensive in attention, so the stop list should be short enough that people actually respect it.

Who owns the exception?

Split it by type rather than by volume. Deduction disputes belong to whoever owns the customer or supplier relationship, because resolving them requires a commercial conversation. Data quality exceptions, meaning mangled references and unknown invoice numbers, belong to the EDI or integration owner because the fix is in the mapping. Missing settlement belongs to treasury, because the question is about a bank.

Assigning all three to AP is the default in most companies and it's the reason the queue never clears. An AP analyst can't resolve a deduction dispute or fix an EDI map, so the items age until someone escalates.

What evidence closes it?

A bank credit for the missing-settlement case, a written agreement or a credit memo for the deduction case, and a corrected map plus a reprocessed file for the data case. Write those three down and the queue stops being a judgment call.

One more control belongs in this conversation, because an 820 referencing a payment nobody authorized is a fraud signal rather than a reconciliation problem. Positive pay and ACH debit filters on the disbursement side are the corresponding controls, and the usual ACH credit fraud prevention practices apply to the origination side of the same flow.

Where Corpay fits in reconciling payment files to settlement

The reason this article needs writing is that the payment file and the settlement event usually live in different systems owned by different teams. When one platform originates the payment and carries the settlement result back, reconciliation runs against the event rather than against the advice, and the timing question stops arising.

That's the structural argument for Corpay AP automation here rather than a feature claim. Corpay executes payments across virtual card, ACH, and check, and returns settlement back as a reconcilable transaction. To be clear about the boundary, this doesn't verify a trading partner's bank on your behalf or turn a remittance advice into a settlement confirmation. Nothing can. What it does is remove the case where the two records come from different places on different schedules.

What does fully managed AP change about this?

It changes who resolves the exceptions. Corpay's AP service is fully managed, so our team enrolls suppliers, delivers payments, and chases the exceptions that would otherwise sit in your reconciliation queue waiting for someone with time. Customers report about 40% less time spent on AP after the move, most programs are live in weeks, and Corpay returns more than $800 million in rebates to customers each year on card-eligible spend.

Which ERPs does it connect to?

Corpay maintains 100+ ERP integrations, including NetSuite, Sage Intacct, Microsoft Dynamics 365 Business Central, and Acumatica. The integration is what determines whether the settlement result posts itself or waits for an analyst, which is the same question this whole article has been circling. If your remittance volume arrives as ACH debits rather than credits, the authorization and return rules change the exception handling more than the posting rule does.

Frequently Asked Questions

What is an EDI 820?

The EDI 820 is the ASC X12 Payment Order/Remittance Advice transaction set. It can instruct a bank to make a payment, advise a payee of a payment made elsewhere, or do both in one transmission, and it carries invoice-level allocation of the total amount.

What is the difference between an EDI 820 and an EDI 835?

The 820 is the general B2B payment order and remittance advice used across industries. The 835 is the healthcare-specific claim payment and remittance advice exchanged between payers and providers, carrying claim adjudication data that has no 820 equivalent.

What fields are in an EDI 820?

BPR carries the total amount, payment method code, and effective date. TRN carries the trace number. N1 loops identify payer and payee. RMR carries per-invoice references and applied amounts, ADX carries adjustments with reason codes, and REF and DTM carry supplemental identifiers and dates.

Does an EDI 820 mean the payment was made?

Not on its own. An 820 asserts payment intent and allocation. Settlement is confirmed by your bank record, not by the transaction set, and depending on the rail the gap between the 820 arriving and funds clearing can run several days.

What is a 997 acknowledgment?

A functional acknowledgment reporting that an EDI file was received and passed syntax validation. It confirms transmission, not payment. A missing 997 means the receiver never confirmed the file arrived, which needs a different investigation than a rejected payment.

Should I post cash when the 820 arrives?

Match on the 820 and post on the bank credit. Matching lets you clear open items and identify short pays immediately, while posting against a document that doesn't confirm settlement is what creates unexplained cash differences later.

How do I test an 820 implementation before go-live?

Test the exception cases rather than the clean ones, since clean files almost always pass. Partial payments, deductions with reason codes, mangled invoice references, and a payment covering an invoice that doesn't exist are the four cases worth building deliberately.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

Payments Automation

AP Automation