Remittance Advice: What It Is and How It Travels

A remittance advice is the payer telling the payee what a payment is for: which invoices it settles, how much of each, and which deductions, discounts or credit notes were taken. The payment moves the money. The remittance advice is what lets the payee's accounts receivable team apply that money to the right open items — and when it is missing, late or illegible, the payment sits on a suspense account while someone rings the customer.

It is easy to think of remittance as one thing. In practice it reaches you by four different routes, and each one fails in its own way.

Four ways remittance travels

The first route is the cleanest and the most cramped. The other three exist because a large payment settling many invoices simply does not fit.

Inside the payment: 140 characters

ISO 20022 defines remittance information as what enables the matching of an entry with the items the transfer is intended to settle. In a pain.001 it sits in RmtInf, in one of two forms (references and remittance are covered field by field elsewhere):

• Unstructured, <Ustrd> — free text, up to 140 characters per occurrence. ISO allows it to repeat; SEPA allows one occurrence.
• Structured, <Strd> — typed fields, including referred documents and the creditor reference in CdtrRefInf. SEPA allows structured or unstructured, not both, and caps the structured block at 140 characters, tags included.

That is enough for one invoice number, or a creditor reference such as an ISO 11649 RF reference that identifies the invoice exactly. It is not enough for a payment that settles forty invoices, three credit notes and a short-payment for damaged goods. That payment needs a separate advice.

When the payment carries its remittance, it comes back to the payee through bank reporting — the transaction details of a camt.054 notification or a camt.053 statement — which is why the same 140 characters, if the payer's bank and every bank after it pass them on, end up next to the cash on the payee's side.

ISO 20022 remt.001: the stand-alone remittance advice

ISO's Stand-Alone Remittance Advice message set has two messages. The first, remt.001 RemittanceAdvice, "allows the originator to provide remittance details that can be associated with a payment". Its structure is a group header, one or more RmtInf blocks, and optional supplementary data.

Two things about it matter in practice.

It is tied to a payment by that payment's references. Each remittance block carries the original payment information, and inside it the references of the payment it describes. The end-to-end identification is mandatory; the payment information id, instruction id, transaction id, UETR and mandate id are optional. That is the join key — the payee matches the advice to the incoming credit on the same reference the payer put on the payment, so a payer who leaves EndToEndId as NOTPROVIDED has made the advice hard to use.

It can say why the amounts differ. For each referred document the structured remittance carries a due payable amount, any discount applied, a credit note amount, tax amounts, adjustments with an amount, a debit/credit indicator and a free-text reason, and the amount actually remitted. That is the information a cash application team spends its time reconstructing: why the payment is 4,830 when the invoice was 5,000.

The second message, remt.002 RemittanceLocationAdvice, carries no remittance detail at all. It tells the payee where the remittance advice is: ISO defines the delivery methods as fax, EDI, a URI, e-mail, post or SMS. It is a pointer — useful when the detail lives in a portal or an EDI channel and the payment can only say where to look.

X12 820: the US EDI equivalent

In the United States, the long-established electronic route is the X12 820 Payment Order/Remittance Advice transaction set, maintained by X12's finance subcommittee (X12F) and used by other subcommittees too. It plays the same role as remt.001 — the detailed breakdown of what a payment covers — exchanged between trading partners over EDI. In ACH, the corporate trade exchange (CTX) format exists to carry that kind of remittance alongside the payment; the NACHA file format post covers the addenda records.

PDF and email: still the most common

Many payers send remittance the way they always have: a PDF attached to an email, a spreadsheet, a portal download, occasionally a letter. None of it is linked to the payment by anything stronger than an amount, a date and whatever the payer typed in the subject line.

This is the route that creates most of the manual work in cash application. Someone opens the email, finds the payment on the statement, keys the invoice list, and investigates the difference. It is also where extraction tools earn their keep: SAP's payment advice extraction reads invoice references, amounts and deductions out of PDFs and emails and hands them to matching. Extraction produces inputs, not decisions; the control sits in the matching that uses them.

What happens to the advice in SAP

In SAP, remittance arrives as a payment advice. SAP's S/4HANA documentation describes two ways one gets into the system: created and uploaded manually in the Manage Payment Advices app, or imported automatically through APIs. When a bank statement item or a lockbox item arrives and the system cannot find the payment advice that belongs to it, it cannot post and clear the item, and the item goes to the Reprocess Bank Statement Items or Reprocess Lockbox Items app.

There, someone picks the right advice — SAP suggests filtering by the same payment amount — and the system lists the open receivables on one side and the advice items on the other, matches what it can, and leaves the rest to be matched by hand before posting and clearing. One detail catches people out: after posting, the system deletes the payment advice automatically unless Hold Payment Advice was selected when it was created in FBE1. If you need the advice afterwards as evidence, keep it somewhere else or set that flag.

This is the same split as every bank reconciliation: the matching of a well-referenced advice to its open items is a rule, and the work is in the items that do not match.

What to ask a payer — or your own AP team

If you receive payments:

1. Ask for a reference you can match on. A creditor reference or invoice number in the payment's remittance field settles most single-invoice payments without a separate advice.
2. Ask for structured advice when a payment covers many invoices — remt.001 or X12 820 where the payer can send it, a consistent spreadsheet layout where they cannot.
3. Ask for the end-to-end reference on the advice to match the payment. It is the field remt.001 makes mandatory for exactly this reason.

If you pay: fill the remittance field with the invoice reference the supplier gave you, not your own payment number, and send the deduction reasons with the payment, not in a later email. The supplier's cash application team is the one who will call if you do not.