Cash application is the process of matching incoming customer payments to the correct open invoices, credit notes, deductions, and customer accounts in the accounts receivable system. A payment has not completed the AR process merely because cash reached the bank. Finance still has to identify the payer, interpret the remittance, allocate the amount, record any difference, and clear the resulting receipt against the right receivable.
The operational objective is a traceable link from bank receipt to customer account and from customer account to invoice-level allocation. When that link is incomplete, the cash may sit in an unapplied or suspense account while invoices continue to appear overdue.
Cash application inputs
| Input | Information used | Common limitation |
|---|---|---|
| Bank statement or lockbox file | Value date, amount, currency, payer name, account, and bank reference | Reference may be truncated or identify a parent company rather than the invoiced entity |
| Remittance advice | Invoice numbers, credit notes, deductions, payer entity, and intended allocation | May arrive separately, use the payer's document numbers, or omit disputed lines |
| AR open-item report | Customer, invoice, due date, currency, original amount, and remaining balance | Can contain duplicates, stale credits, or incorrect customer master data |
| Customer master | Legal entity, trading names, bank accounts, parent-child relationships, and identifiers | Payer and billed customer may not share the same name |
| Credit and deduction records | Approved credit notes, short-pay reasons, returns, rebates, and disputes | Commercial approval may not yet be reflected in the accounting system |
| Prior allocation history | Repeated payment patterns, payer aliases, and normal invoice combinations | History is supporting evidence, not permission to override current remittance |
Cash application process
- Establish the receipt population. Load all customer receipts for the period from controlled bank or lockbox sources. Preserve the bank transaction ID, value date, currency, gross amount, fees, and original reference so that no receipt disappears during file transformation.
- Identify the payer and customer account. Use bank-account mappings, remittance details, legal names, aliases, and established customer relationships. Where a shared-service centre pays for several entities, retain both the payer and the accounts to which the payment is applied.
- Retrieve and validate remittance. Link the payment to the relevant remittance advice. Confirm that amount, currency, payer, date, and bank reference reasonably correspond; a remittance email by itself does not prove that funds settled.
- Match open items. Apply the receipt to the stated invoices, credit notes, and approved deductions. Validate that the items belong to the correct customer and entity, remain open, and use a compatible currency and amount.
- Classify differences. Separate timing, bank fees, foreign-exchange effects, short pays, duplicate payments, overpayments, credit notes, and disputed deductions. Do not write off or force a residual simply to achieve a full match.
- Post the allocation. Record the receipt and invoice clearing in the AR subledger using the approved accounting date. If an amount cannot be allocated, record it transparently as unapplied cash with an owner and investigation status.
- Reconcile and review. Prove that bank receipts agree to receipts posted in AR, that AR batches agree to the GL control account, and that suspense and unapplied-cash balances are complete. Review older or material unmatched items before close certification.
Worked example: one payment covering several invoices
A customer sends an illustrative payment of 47,000 and identifies three invoices with open balances of 20,000, 18,000, and 12,000. The remittance states that the final invoice is being short-paid by 3,000 because of a disputed service item. The operator applies 20,000 to the first invoice, 18,000 to the second, and 9,000 to the third. The remaining 3,000 stays open as a documented dispute rather than being written off or hidden in unapplied cash.
| Open item | Before application | Applied | Remaining |
|---|---|---|---|
| Invoice A | 20,000 | 20,000 | 0 |
| Invoice B | 18,000 | 18,000 | 0 |
| Invoice C | 12,000 | 9,000 | 3,000 disputed |
| Total | 50,000 | 47,000 | 3,000 |
The bank receipt, remittance, allocation batch, dispute record, and customer balance should remain linked. Amounts are illustrative; write-off, deduction, and dispute treatment follows the organisation's policy and authorization limits.
Common cash application exceptions
| Exception | Likely cause | Controlled next step |
|---|---|---|
| Unidentified payer | Trading name, payment agent, parent company, or weak bank reference | Use approved master data and request clarification; do not guess from amount alone |
| Missing remittance | Advice sent to another inbox or not supplied | Hold as unapplied cash while tracing payer and invoice evidence |
| Payment covers many invoices | Consolidated settlement across a statement | Validate the invoice schedule and ensure its total reconciles to the receipt |
| Several payments cover one invoice | Instalments, split bank accounts, or multiple entities | Apply each verified receipt without closing the invoice until its balance is cleared |
| Short payment | Deduction, dispute, tax, fee, or payment error | Record the residual with a reason and owner; follow the approved dispute or write-off route |
| Overpayment | Duplicate transfer, credit not considered, or advance payment | Record on account or as a customer credit under policy; confirm refund authorization separately |
| Payment in a different currency | Customer settlement arrangement or payer error | Use the approved conversion and bank evidence; identify fees and exchange differences separately |
| Invoice already closed | Duplicate payment, prior allocation, credit note, or wrong customer | Investigate the history before reopening or reallocating the item |
Cash application versus accounts-receivable reconciliation
Cash application allocates individual receipts to customer open items. Accounts-receivable reconciliation is the broader control: it compares the AR subledger with the GL, bank receipts, customer balances, credit notes, and the AR aging report. Good application improves that reconciliation, but it does not replace it. A batch can be allocated to the wrong customer and still equal the bank total.
Controls for an automated workflow
Automation can join bank data, remittance files, open invoices, and customer mappings to propose allocations. Straight-through posting should be limited to matches that satisfy approved rules. Ambiguous payer identity, new bank details, cross-entity allocation, unapproved deductions, refunds, and material write-offs require explicit review. Every proposal should retain the source fields and the reason a match was suggested.
Aetherix operates matching, exception, and evidence workflows within managed reconciliation engagements. Related issues can be traced through billing reconciliation, while ledger-level differences belong in ledger reconciliation.
Frequently asked questions
What is unapplied cash?
Unapplied cash is a received and recorded customer payment that has not yet been allocated to specific invoices or another approved customer-account item. It should remain visible, owned, and aged until resolved.
What is the difference between cash application and cash allocation?
The terms are often used for the same invoice-matching activity. In some teams, allocation describes selecting the customer or invoices, while application describes posting that allocation in the AR system.
Can cash application be fully automated?
Complete, consistent payments with reliable remittance can often follow rules. Ambiguous references, deductions, cross-entity payments, currency differences, and policy decisions should be routed for review rather than forced into an automatic match.