The payment arrives with a list of invoices.

A customer sends one ACH payment of US$ 48,312.40. Accounts receivable has nine open invoices for that customer, and no combination of them adds up to US$ 48,312.40. The cash is in the bank, the customer considers the bills settled, and the ledger cannot say which ones.

The answer is in a second document: the remittance advice. It arrives as an email attachment, a portal download, a stub on a check or an EDI file, and it lists what the payment is for, invoice by invoice: what was paid, what discount was taken, what was deducted and why. Cash application is the work of posting the payment the way that list says, not the way the amount suggests.

This piece describes what a remittance advice carries, how to read a payment that pays some invoices in full, some short and one that does not exist, and what an extraction should return so the posting follows the customer’s own explanation and the exceptions reach a person with a reason attached.

Two records of one payment

A payment and its remittance travel separately more often than together. The bank record says who paid, how much and when. It may carry a short reference, but rarely the invoice list. The remittance advice says what the money is for. X12 describes its 820 transaction set in those two roles: it can be an order to a bank to make a payment, a remittance advice “identifying the detail needed to perform cash application to the payee’s accounts receivable system,” or both. The remittance can go from payer to payee directly, through a bank, or through a third party.

The first field of the 820 makes the split explicit. Its handling code says whether the payment accompanies the remittance, whether this is remittance information only, whether it is a payment with no remittance detail, or whether payment and remittance were split to travel by different routes. A trace number in the TRN segment ties the two back together, usually the check number or the electronic payment’s trace. UBL 2.1 has the same document under the same name: a Remittance Advice “specifies details of an actual payment,” sent so the payee knows which of its receivables the money covers.

Most customers never send EDI. They send a PDF printed from their payables system, a spreadsheet from a portal, or a stub torn from a check that went through a lockbox. The layouts differ, but the content is the same short list, and it can be read into the same record.

What each remittance line says

The X12 RMR segment is the clearest map of a remittance line, because it was written for exactly this purpose: to specify the open items to be included in the cash application and convey the detail. Its elements line up with the columns of a typical PDF remittance.

UBL’s Remittance Advice Line carries the same ideas under other names: a reference to the billing document, a debit line amount, a credit line amount, a balance amount and a free-text note. A paper remittance from a payables system usually prints the same columns with the payer’s own labels: invoice number, invoice date, gross, discount, deduction, net paid.

The reason codes deserve attention. X12 element 426, the Adjustment Reason Code, has hundreds of values, from 01 Pricing Error and 06 Quantity Contested to 19 Duplicate Billing, 59 Item Not Received, 76 Cash Discount and A8 Promotional Allowance. A PDF remittance rarely uses the codes, but it usually writes the same reasons in words, and an extraction that maps those words to a short, fixed list makes the deductions countable.

One payment, worked through

Return to the payment of US$ 48,312.40. The customer’s remittance advice, a one-page PDF from its payables system, lists six lines:

The paid column adds up to the bank amount, so the remittance belongs to this payment. Each line also has its own arithmetic: invoice amount, less discount, less deduction, equals paid. Both checks pass. Now each line becomes a posting decision.

• Invoice 30422 — paid in full. Close it.
• Invoice 30418 — paid less a 2% discount. If the invoice terms were 2/10 net 30 and the payment arrived within ten days of the invoice date, the discount is earned: close the invoice and post US$ 372.00 to discounts allowed. If the payment came on day 24, the discount was not earned, and the US$ 372.00 stays open as a short payment to collect or to write off by decision, not by default.
• Invoice 30437 — short by US$ 900.00, with a reason and a debit memo number. Apply US$ 8,975.00, and keep the US$ 900.00 as a deduction that carries the reason and the memo reference, so the person who checks the proof of delivery can find it.
• Credit memo 2207 — the customer took a credit the supplier issued. Apply it, after confirming it is open and was not already used on an earlier payment.
• Invoice 30441 — short by US$ 794.00, labelled as a promotional allowance. That is a claim against a promotion agreement, and it needs the agreement to validate, the same way a rebate deduction does.
• PO 4471-B — the customer paid against a purchase order, not an invoice. Either the invoice for that order has not been issued yet, or it carries a different number. The US$ 2,763.40 goes on account, unapplied, until someone finds the invoice.

Applied by amount alone, this payment would have closed the oldest invoices in date order and left four wrong balances: two invoices shown as paid that were short, one shown as open that was paid, and a credit memo still sitting open after the customer had used it. Every one of those errors would surface later, as a dunning letter to a customer who had already paid.

The rules for what does not match

Most remittance lines match. The posting rules are about the ones that do not, and each has a safe default.

• Short payment with a reason — apply what was paid and carry the difference as a deduction, with the payer’s reason and reference. Do not leave a partial balance on the invoice with no explanation attached.
• Short payment without a reason — this is the case to route. The remittance says the invoice was paid, and the amount says it was not; the customer has to be asked which.
• Discount taken late — compare the payment date with the invoice date and the terms. An unearned discount is a short payment, whatever the remittance calls it.
• Reference not found — a purchase order number, an invoice number from another customer, or a typo. Hold the cash on account; never apply it to the oldest invoice to make the line disappear.
• Remittance total and payment amount differ — do not post either. The remittance may cover two payments, the payment may cover two remittances, or a bank fee came off the wire. The trace or check number usually tells which.
• Payer is not the customer — a parent company paying for its subsidiaries, or a factor paying for a buyer. The remittance lines name the invoices, and the invoices name the customer; post to the customer on the invoice, not to the account that sent the money.

Each of these is a decision someone in receivables makes every day. The point of reading the remittance into fields is to make the easy lines post themselves and the hard ones arrive with the evidence already gathered.

Where this ends and other checks begin

A remittance advice is the customer’s explanation of one payment. It is not proof that the explanation is right. A quantity deduction needs the receiving record or the proof of delivery. A promotional allowance needs the deal terms; matching it to the sell sheet is covered in The sell sheet sets the rebate terms. A check payment that may have been deposited twice is a separate check on the image and MICR line, described in Two deposits can be one check.

The other side of the same relationship has its own document. A supplier’s statement tells the payer what the supplier thinks is owed, and reconciling it against accounts payable is the subject of The statement is what the supplier thinks you owe. Healthcare has its own remittance standard, the 835, with claim adjustment codes that need a different reading; see An adjustment code is not the cause.

What the extraction should return

Cogneris reads remittance advices, check stubs and payment packets for receivables and treasury teams. A useful record for one remittance has four parts:

• Header — payer name and identifier, payee, payment date, payment method, payment amount, currency, and the check number or electronic trace that pairs the remittance with the bank record.
• Lines — for each line, the reference type and number, the invoice amount, the amount paid, the discount taken, and each adjustment with its amount, reason in words, mapped reason code and memo reference, each value tied to the page region it came from.
• Document checks — the paid amounts add up to the payment amount; on each line, invoice amount less discount less adjustments equals amount paid; no reference appears twice unless the invoice amounts tell the two apart.
• Ledger checks — each reference is an open item for this customer, each invoice amount matches the open balance, each discount falls within terms and dates, and each credit memo is open and unused.

Each check that fails should say which line and by how much. In the example, a useful message for invoice 30418 paid on day 24 reads: discount of US$ 372.00 taken 14 days after the 10-day window closed; invoice remains open for US$ 372.00. A message that reads only “amount mismatch” sends the analyst back to the PDF, the bank portal and the ledger to find it again.

Some lines should go to a person every time: a short payment with no reason, a deduction above a set amount, a reference that matches no open item, a credit memo already applied, a remittance that does not add up to any payment received, and a payment from a party that is not the invoiced customer.

Post what the customer said it paid

A payment amount is a single number, and nine open invoices can explain it in many wrong ways. The remittance advice is the customer saying which way is right, line by line, with discounts and deductions named. Posting by that list keeps the ledger in step with the customer’s own records, turns every short payment into a deduction with a reason, and leaves receivables chasing the differences that need chasing instead of the ones the posting created.

This article describes how to read a remittance advice for cash application. It is not accounting, legal or financial advice. Payment terms, deduction policies and the accounting treatment of discounts and unapplied cash are set by each company’s own policies and its auditors.

Sources

• X12 820 Payment Order/Remittance Advice (Release 8010, Stedi EDI reference) — the 820 can make a payment, send a remittance advice, or both; the remittance advice identifies “the detail needed to perform cash application to the payee’s accounts receivable system”; it can go payer to payee directly, through a bank or through a third party.
• BPR segment and element 305, Transaction Handling Code — BPR02 payment amount; handling codes for payment accompanying remittance (C), remittance information only (I), payment only (D) and split payment and remittance (U, X). TRN segment — trace number that identifies the payment and remittance.
• RMR segment, Remittance Advice Accounts Receivable Open Item Reference — reference qualifier and number; payment action code (RMR03; element 482: adjustment, final, payment on account, partial payment, pay item and others); amount paid (RMR04); invoice amount before terms discount, which may distinguish duplicate reference numbers (RMR05); discount taken (RMR06); adjustment reason code and amount (RMR07–08).
• ADX segment, Adjustment and element 426, Adjustment Reason Code — signed adjustment amount that reduces or increases the payment, with a reason code (01 Pricing Error, 06 Quantity Contested, 19 Duplicate Billing, 59 Item Not Received, 76 Cash Discount, A8 Promotional Allowance and others) and its own reference.
• OASIS Universal Business Language 2.1 — Remittance Advice: “a document that specifies details of an actual payment”, in the payment notification process; Remittance Advice Line with billing reference, debit line amount, credit line amount, balance amount and note (document model summary).