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. What separates them 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, and that difference is why this paperwork is hard to automate, and why 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 with 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's 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 payers in the US, UK and Australia say remittance advice, often shortened to the remittance or the remittance detail. The contents don't change with the name, and nothing in this article turns on which one your payers use.
The document matters because your bank doesn't carry its information. A deposit arrives as one number, and 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.
An advice says what the payer intends the payment to cover, and the deposit on the bank feed is the money that arrived. 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.
The check remittance stub on a 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. The stub gets detached, scanned, and keyed, either in-house or through a bank keying service that charges per document and per keyed field. A scanned stub is 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 and 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, so the rails were designed for the money and the detail to travel together.
Most receivers never see an addenda record, though, because a bank statement shows the deposit and nothing else, so payers send the detail separately, as 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. Wire and other bank payments behave the same way, and the faster the money moves the more likely the detail travels separately. The deposit and the detail arrive by different routes, hours or days apart, and the receiving team reunites them.
An EDI 820 is the same advice as structured data
The EDI 820 is the X12 transaction set titled Payment Order/Remittance Advice, and it carries the same information as a printed stub or an emailed PDF, expressed as machine-readable segments. 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 isn't what this article covers.
An 820 rarely reaches a person as raw data, since it travels through an EDI translator or a value-added network, and what most teams 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, since 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, and they differ in 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 that changes what the payer is telling you, though it changes how much work it takes 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, with only the method of sending different.
Asking every customer to send the same format to the same address is the tempting fix, and 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, so if your process only handles one of the four, it's covering one slice of your customers.
The hard content doesn't 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're decisions the payer made before the document went out, and the same deduction handling gets built four times over by a team that runs the four as four separate problems.
One intake for one document
Treating the four as one document is what makes the work automatable, and it's the premise RemitClear is built on. It reads the payment advice in whatever form it arrives, so 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, an invoice that's already paid is flagged with a link to the existing payment, and if the line amounts don't 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 only tells you how it reached you. 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. Once everything arrives in one queue, the work is driven by how many exceptions there are, whatever the number of payers sending them.
