A payment advice, a check remittance stub, an ACH remittance, and an EDI 820 file are four names for the same document. Each one tells you what a payment covers: these invoices, these amounts, minus these deductions. The only real difference is how the document reaches you, printed under a check, attached to an email, carried inside the payment itself, or sent over an EDI connection. That difference matters, because it is the reason this paperwork is hard to automate, and because most teams treat the four as separate problems and staff them separately.
What a payment advice is
A payment advice is the document a customer sends when they pay you, listing which of your invoices the payment covers. A typical advice shows the payer's name, the payment date, a payment reference, the total paid, and one line per invoice: the invoice number and the amount applied against it. Where the payer has taken a discount, a credit, or a deduction, the advice records that too, and it is usually the only place the reduction is itemized at all.
Payment advice and remittance advice are two names for the same document. Enterprise ERP systems tend to title the document a payment advice, while cloud ledgers and most UK and Australian payers say remittance advice. US teams often shorten it to the remittance, or the remittance detail. Nothing about the contents changes with the name, and nothing in this article turns on which one your payers use.
The document matters because your bank does not carry its information. A deposit arrives as one number. The advice holds the split: which of the forty open invoices on that customer's account the payment settles, and why the total is short of the sum of them. Reuniting the deposit with its detail is most of what an accounts receivable team does all day, whatever the team calls the paperwork.
One distinction is worth keeping sharp: an advice is a claim, not a fact. It says what the payer intends the payment to cover, while the deposit on the bank feed is the payment. The two disagree more often than teams expect. A payment run gets trimmed after the advice is emailed, a check is reissued, or two advices turn out to describe one consolidated deposit. Reconciliation anchors on the bank amount and uses the advice as the map, never the other way around.
Check remittance: the stub on the paper payment
When the payment is a paper check, the advice is printed on the same sheet, as the stub above or below the check itself. A check remittance carries the same fields as any other advice: invoice numbers, the amount applied to each, and any deductions taken. The check clears the bank as a single amount, so the stub is the only record of how that amount splits across invoices.
Checks remain a stubbornly large share of US business-to-business payments, which is why the phrase check remittance survives. Operationally the stub gets detached, scanned, and keyed, either in-house or through a bank lockbox service that charges per document and per keyed field. A scanned stub is just a small PDF, and from that point on it behaves like every other remittance document. People searching for a remittance check usually mean this stub, though some mean the check itself.
ACH remittance: the detail the deposit leaves behind
ACH is the electronic bank-to-bank network US businesses use for most non-card payments. An ACH credit can, in principle, carry its remittance detail inside the payment as addenda records, and the corporate trade exchange format can wrap an entire EDI 820 inside the transaction. The rails were designed so the money and the detail could travel together.
In practice most receivers never see an addenda record, because a bank statement shows the deposit and nothing else. So payers send the detail separately: an email from the accounts payable system at the moment the payment run executes, carrying a PDF, a spreadsheet, or just invoice numbers typed into the body. That email is what ACH remittance means in daily use. The deposit and the detail arrive by different routes, hours or days apart, and the receiving team reunites them. The same pattern holds for wire and other bank payments: the faster the money moves, the more likely the detail travels separately.
EDI 820: the same advice as structured data
The EDI 820 is the X12 transaction set titled Payment Order/Remittance Advice. It carries the same information as a printed stub or an emailed PDF, expressed as machine-readable segments rather than a formatted page. Large trading partners send them: big-box retailers, distributors, and government payers whose volumes justified an integration project. Healthcare claim payments travel as a different transaction set, the 835, which belongs to medical billing and is not what this article covers.
An 820 rarely reaches a person as raw data. It travels through an EDI translator or a value-added network, and what most teams actually handle is the version their EDI portal or their customer's portal produces: a CSV, an Excel export, or a PDF. RemitClear processes remittance detail in all of those formats, along with Word, TSV and plain email body text, so the exported version of an 820 goes through the same pipeline as any other advice. If your payers send a format that isn't listed here, book a demo and we can discuss it; the intake is built to keep absorbing new formats.
The hard part is how it arrives
Line for line, the four carry the same information. What differs is the state each one reaches you in. A stub is paper, so it needs scanning before anything can happen. An emailed PDF is formatted for human eyes, and every payer formats it differently. A spreadsheet is structured until the payer merges cells or buries the total three tabs in. A body-text email has no document at all. None of these variations changes what the payer is telling you. All of them change how much work it is to find out.
One payer can use all four. A national retailer might pay its largest suppliers by EDI 820, mail checks with stubs to its mid-tier, and email PDF payment advices to the rest, all cut from the same payment run and identical line for line. The paperwork is the same. Only the way it was sent is different.
The tempting fix is standardization: ask every customer to send the same format to the same address. It fails because how the advice is sent is decided by the payer's systems, not by your preference, and no accounts payable department is changing its payment run because a supplier asked. You get whatever their software produces. A process that can only handle one of the four covers one slice of your customers.
The hard content does not vary at all. A discount taken, a disputed line short-paid, a credit applied against the run: these appear on the stub, in the addenda, in the 820 segments, and on the PDF in exactly the same way, because they are decisions the payer made before the document went out. Treat the four as four separate problems and you end up building the same deduction handling four times over.
One intake for one document
Treating the four as one document is what makes the work automatable, and it is the premise RemitClear is built on. It reads the payment advice in whatever form it arrives: forward the payer's email, or upload the file, and the scanned check stub goes through the same pipeline as the emailed spreadsheet and the body-only email.
Every invoice line is extracted and matched against your open invoices in Xero or QuickBooks Online, and matching handles exact, partial, and prefix-based invoice numbers. Deductions and credits are surfaced as their own lines rather than silently absorbed, an invoice that is already paid is flagged with a link to the existing payment, and if the lines do not add up to the total the document states, the difference is shown and posting waits for a person. However the document arrived, it lands in the same review queue.
Summary
A payment advice, a check remittance stub, an ACH remittance email, and an EDI 820 are the same document under four names, and the name tells you how it reached you, nothing more. The practical moves follow from that: pick one internal name for all of them, point everything you receive at one inbox, and keep your team's judgment for the lines that need it, the deductions and the short payments, rather than the retyping. Once everything arrives in one queue, the work stops scaling with the number of payers and starts scaling with the number of exceptions.