Intro: Cash application is where AR balances quietly go wrong: a deposit that pays five invoices, a processor payout net of fees, a short-pay nobody notes. This guide shows how to automate it so every applied payment records why it was applied that way, and the AR aging still ties to the GL at month-end.
What is cash application?
Short answer: Cash application is matching each customer payment to the invoices it pays and recording any short-pay, overpay or unapplied amount. Automated cash application does this with rules, using amounts, references and remittance data. With an audit trail, every application records the rule that made it, so the AR balance can be defended.
Step 1: How do we get a complete list of receipts?
Pull bank deposits from the bank feed and receipts from your ledger and payment processors for the same period. Record row counts and totals for each source so completeness is visible. A missing day of deposits is a bigger problem than a mismatched one.
Step 2: How do we bridge processor payouts to deposits?
A Stripe or marketplace payout is net of fees, refunds and chargebacks, so it rarely equals sales. Build the gross-to-net bridge first: charges, minus refunds, minus disputes, minus fees, equals the payout. Then match the payout to the bank deposit. → Payout reconciliation
Step 3: How should matching rules be written?
Write rules in passes, from strictest to loosest, and record the pass on every match:
| Pass | Rule |
|---|---|
| 1 | Exact amount and invoice reference |
| 2 | Exact amount, customer, and date within N days |
| 3 | One receipt = sum of several open invoices for the same customer |
| 4 | Anything else goes to a person |
Amounts must match exactly. References and dates can flex within written limits.
Step 4: How should exceptions be handled?
Short-pays, overpays, receipts with no reference and payments from unknown payers go to a named owner with the evidence and suggested invoices. Never auto-apply a payment to the oldest invoice without a rule that says so. Record every decision with who made it.
Step 5: How do we reconcile AR at month-end?
Tie the AR aging total to the AR control account. List unapplied cash separately. Flag items over 90 days with their owner. Any difference stays open as a specific item; never plug it.
Step 6: What evidence should we keep?
For each period: the receipts population with counts and totals, the rule on every match, the exception decisions, the payout bridges and the AR tie-out with preparer and reviewer. If the totals come from saved queries, the auditor can rerun them.
What will auditors check?
| Auditor question | Evidence that answers it |
|---|---|
| Is the receipts population complete? | Row counts and totals per source |
| Were receipts applied to the right customer and period? | Rule recorded on each match; exception decisions |
| Does the AR aging agree to the GL? | Tie-out with the query behind both totals |
| Are processor deposits fully explained? | Gross-to-net bridge per payout |
| Who reviewed it? | Preparer and reviewer, recorded separately |
How do manual, typical AR tools and evidence-first cash application compare?
| Manual (spreadsheet) | Typical AR / collections tool | Evidence-first (e.g. Yoraito) | |
|---|---|---|---|
| Why a payment was applied | Not recorded | In-product | Rule recorded on each match |
| Processor payout bridge | Manual | Varies | Built in for Stripe |
| AR tie-out | Manual | Not the focus | Every close, with query |
| Reproducible totals | Rebuild | Export | Saved SQL |