Remittance Advice: What It Is, Meaning and Examples

Short answer: A remittance advice is a note from the payer to the payee confirming that a payment has been sent and listing exactly which invoices it covers. It is not a legal requirement in US B2B, and it moves no money. Its whole job is to stop the supplier guessing when a lump sum lands in the bank account.

If you have ever watched $47,318.22 arrive from a customer who owes you eleven invoices, none of which add up to that number, you already understand why remittance advice exists. The deposit tells you money came in. The remittance advice tells you what it was for.

What is a remittance advice?

A remittance advice is a document a payer sends to a payee to explain a payment. At minimum it names the payment amount, the payment date or reference, and the invoice numbers being settled. It travels alongside the money rather than carrying it, which is the single most common point of confusion: a remittance advice is not a payment, not an invoice, and not a receipt.

The terms shift a little by region and by system. US accounting software tends to say remittance advice or remittance notice, SAP and a lot of European systems say payment advice, and healthcare says electronic remittance advice. They describe the same thing at different levels of formality.

What does a remittance advice include?

There is no mandated template, but a remittance advice that actually saves the supplier work carries these fields. Anything less and the AR team ends up emailing you anyway.

Remittance advice example

Here is what a normal one looks like in practice. A customer pays $24,300 against three invoices totaling $25,000. Without the advice, AR sees an unexplained $700 gap and opens a dispute. With it, the picture closes immediately.

Notice that the two gaps are different animals. The $100 discount was earned under agreed terms and needs no follow up. The $600 deduction is a claim against an invoice, and until someone accepts or disputes it, that invoice is not closed. Good remittance advice separates the two. Bad remittance advice sends one total and lets AR work it out.

What formats does remittance advice come in?

This is where the concept turns into a practical problem, because the same information arrives in wildly different shapes depending on how sophisticated the payer is.

The three EDI rows are the ones that trip teams up, because a file full of X12 segments looks like corruption if you have never seen one. If that is what landed in your inbox, the EDI 820 to Excel converter turns it into one row per invoice with the payer, amount paid, discount and deduction reason already split into columns. If the remittance is riding inside the ACH payment instead, the NACHA file to Excel converter opens that file, and if it is a PDF the customer emailed, the bank statement converter reads the document into the same structured rows.

Is remittance advice a legal requirement?

No. In ordinary US and Canadian B2B trade, sending remittance advice is a business courtesy rather than a regulatory obligation, and plenty of payers skip it. The exception worth knowing is US healthcare: under HIPAA, electronic remittance advice for claim payments follows the X12 835 standard, so a health plan paying a provider is working inside a mandated format rather than a preference.

Practically, skipping it costs the payer more than it saves. Suppliers who cannot identify a payment call the AP department, and unapplied cash is the reason a lot of those calls happen.

What is the difference between a remittance advice and an invoice?

An invoice is a demand for payment sent by the seller before any money moves. A remittance advice is a confirmation sent by the buyer after or as money moves. They travel in opposite directions and serve opposite parties: the invoice creates the receivable, the remittance advice retires it.

A receipt is a third thing again, issued by the seller to confirm money was received. In EDI terms the sequence is an 810 invoice out, an 820 remittance advice back, and the cash applied against the open item in between.

How do you read a remittance advice when the amount does not match?

Work in this order and most mismatches resolve without contacting the customer.

1. Tie the total first. Sum the paid column and confirm it equals the payment total on the advice. If those two disagree, the advice itself is incomplete and everything downstream is guesswork.
2. Match the payment to the deposit. Use the check number or ACH trace number, not the amount. Amounts repeat, trace numbers do not.
3. Separate discounts from deductions. A discount within agreed terms is closed. A deduction is an open claim that needs a reason code and an owner.
4. Check for credit memos. A payment reduced by an applied credit is not a short pay, and treating it as one creates a dispute out of nothing.
5. Look for invoices you cannot find. Numbers on the advice that are not in your AR ledger usually mean the customer is paying a different legal entity of yours, or referencing their own PO number instead of your invoice number.

Once the rows are in a spreadsheet this is fast, which is the real argument for converting the file rather than reading it. Teams doing this across many accounts every day generally move to automated account reconciliation rather than keeping it in Excel, but the logic is the same either way.

What are remittance advice remark codes?

That phrase almost always refers to healthcare. Remittance advice remark codes, usually shortened to RARCs, are the standardized codes on an X12 835 that explain how a health plan adjudicated a claim line: why a charge was reduced, denied, or paid at a different rate than billed. They sit alongside claim adjustment reason codes and are specific to the 835.

General B2B remittance advice has no equivalent national code set. Deduction reasons on an 820 come from X12 adjustment reason codes in the ADX segment, and on a PDF advice they are usually just free text a person wrote, which is exactly why deductions are harder to automate outside healthcare.

Sending better remittance advice

If you are on the paying side, three habits make you the customer suppliers do not chase. Send the advice at the same time the payment leaves, not days later. Include the payment reference the supplier will see on their bank statement, because your internal payment ID is meaningless to them. And itemize deductions with a reason on the line they belong to, rather than netting everything into one number and leaving the supplier to reverse engineer it.

If you are on the receiving side, the highest leverage change is usually format rather than process: getting your largest payers to send structured remittance instead of PDFs removes the retyping entirely. That is a conversation worth having with the ten customers who account for most of your receivables, and it is why EDI 820 remittance files exist in the first place. Until then, converting what they do send is the next best thing, and bank statement reconciliation covers tying the applied cash back to the bank.