Auto-Apply Cash Receipts
Most customer payments don't need judgment — the tenant pays, the money should settle their oldest open invoices, done. Auto-apply does exactly that: tick one checkbox and REDA Financials matches the receipt to the customer's open invoices for you, oldest first, the moment it posts. Meridian's AR clerk uses it for every routine rent payment and saves the Apply screen for the exceptions.
Access you'll need. Auto-applying receipts requires the Accounts Receivable v2 permission set (AR clerks & managers) or Accounting Admin v2 (system administrators). The Accounting Controller v2, Accounts Payable v2, and Read Only v2 sets can view receipts and their applications but not apply them. The scheduled fleet-wide run is set up by an administrator.
How to trigger it
When creating the receipt
Tick Auto Apply Receipt on the form before posting. The receipt posts and applies in one motion.
On an already-posted receipt
Edit the receipt and tick Auto Apply Receipt — it's one of the few fields editable while posted, precisely for this. The matching runs immediately and the checkbox clears itself afterwards (it's a "do it now" button, not a setting).
On a schedule, for everything
Administrators can schedule a nightly run that sweeps every posted receipt with Unapplied Cash and auto-applies each one — the same logic, fleet-wide. See Auto-Apply Batches.
Which invoices get paid, in what order
| Priority | Rule |
|---|---|
| 1 | The receipt's Original Invoice, if one is linked — that invoice is settled first, whatever its date. |
| 2 | Invoices with an Application Priority number, lowest number first — a per-invoice override your team can set on strategic invoices. |
| 3 | Everything else oldest invoice first (by invoice date) until the money runs out. |
Candidates are the same ones the manual Apply screen shows: this customer's posted invoices in this entity (same ledger, same currency) with a balance due — Invoice and Receipt type documents only, never credit memos — and only those whose invoice date has already arrived. A future-dated invoice is never auto-settled: its receivable doesn't exist yet on the run date, so the run leaves it open and the receipt stays unapplied until a later pass finds it current. A partial match at the end is fine — the last invoice reached simply gets whatever remains.
A worked run — GreenLeaf's three months
Meridian's tenant GreenLeaf fell behind: April, May, and June invoices, $4,350 each, all unpaid. A payment of $8,700 arrives with Auto Apply Receipt ticked. The run walks oldest-first:
| Invoice | Balance due before | Auto-applied | Balance due after |
|---|---|---|---|
| April rent | $4,350.00 | $4,350.00 | $0.00 — settled |
| May rent | $4,350.00 | $4,350.00 | $0.00 — settled |
| June rent | $4,350.00 | $0.00 — money ran out | $4,350.00 — still aging |
The receipt ends fully applied (Unapplied Cash $0.00), two application records exist on its Applications tab, and the aging report now tells the truth: GreenLeaf owes one month, not three. Oldest-first matters precisely here — it clears the oldest buckets first, so overdue balances shrink before current ones.
What actually happens under the hood
Auto-apply creates ordinary application records — exactly what you'd get from the manual Apply screen, with the same accounting (each application moves the money from the deposits holding account onto the customer's receivable). The run happens synchronously, in the same save: by the time the record refreshes, the applications exist. And it triggers the same way from every entrance — the form, a flow, the API, or a Data Loader import — so migrated receipts can self-apply too.
The checkbox always clears itself afterwards, applied or skipped. That's deliberate: it's a command ("match this now"), not a standing preference, so you can safely tick it again later after fixing whatever blocked the first run.
One place you'll see auto-apply without ever ticking anything: cash sales. Posting a Receipt-type Sales Invoice creates its own born-posted Cash Receipt with the auto-apply flag already set — which is how those invoices arrive already settled. See Posting a Sales Invoice.
The scheduled batch, in detail
The nightly sweep lives in REDA Settings, on the Cash Receipt operations card, where an administrator sets a daily schedule and a batch size — or clicks Run Now for an immediate pass. The batch selects every posted, non-voided receipt with Unapplied Cash remaining (reversals excluded), oldest receipt first, and runs the same matching logic on each. A guard prevents two sweeps running at once, and any receipts that couldn't apply are collected into an error report on the Audit Log — so a backlog of on-account money gets worked down automatically, with the exceptions listed for a human.
What auto-apply refuses to touch
- WHT Received receipts — withholding certificates must be matched to specific invoices by a person: "WHT Received receipts must be manually applied to specific invoices."
- Closed books — nothing is applied on or before the entity's AR closure date.
- Future-dated invoices — an invoice dated after the run's application date is skipped; its receivable isn't on the books yet. It's not an error — the money simply waits as unapplied cash, and a later run (or the nightly batch) settles it once the invoice date is current.
- Dimension-restricted receipts — with Enforce Dimension Match On Apply ticked, only invoices with an open balance in the receipt's own dimension qualify, capped to that dimension's balance.
The exact messages you may meet
| The message | What it means / what to do |
|---|---|
| "WHT Received receipts must be manually applied to specific invoices." | Withholding certificates carry tax meaning per invoice — match them by hand on the Apply screen. See WHT on Cash Receipts. |
| "Application Date {0} falls on or before the AR book closure date ({1}) for this entity." | The books are closed through that date — nothing applies until the date is in an open stretch. |
| "No open Accounting Period found for Application Date {0}." | The application's period is derived from its date — an administrator needs to open the period first. |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Auto-applying money the customer earmarked for a specific invoice | Oldest-first sends it to a different (older) invoice — the customer's records and yours stop agreeing | Link the Original Invoice before ticking the box; that invoice settles first |
| Auto-applying when an old invoice is disputed | The disputed invoice is the oldest, so it gets paid first — undermining your own dispute position | Use the manual Apply screen, or set Application Priority on the invoices that should absorb the money |
| Treating the checkbox as a saved setting | You expect future receipts to self-apply; they won't — the flag is per-run and self-clearing | Tick it per receipt, or let the scheduled batch handle everything unapplied |
| Assuming silence means success | A benign skip (closed books, no eligible invoices) also clears the checkbox — the money quietly stays unapplied | Glance at Unapplied Cash after posting; zero means matched |
| Leaving genuine on-account money to the nightly batch | The batch will spend it on the oldest invoices — but the customer asked you to hold it | On-account money should stay unapplied deliberately; note the instruction in the receipt's Description |
When to use which
| Situation | Best tool |
|---|---|
| Routine payment, customer just pays what they owe | Auto-apply at creation |
| Payment references a specific invoice | Link the Original Invoice + auto-apply (that invoice settles first) |
| Partial payment, disputed invoice, customer instructions | Manual Apply screen |
| On-account money the customer wants held | Neither — leave it unapplied |
| A backlog of unapplied receipts | The scheduled batch (administrator) |
Where to go next
- Applying Receipts to Invoices — the manual screen and the matching rules.
- Auto-Apply Batches — scheduling the nightly sweep.
- Understanding Cash Receipts — the two-step money model.
Frequently asked questions
Usually there was nothing eligible: no posted invoices with a balance for that customer in that entity, or the books are closed for the application date. The checkbox clears itself either way — check the customer's open invoices, fix the cause, and tick it again.
The default is deliberately oldest-first (that's what keeps aging clean). To steer it, set an Application Priority number on the invoices you want settled first — lower numbers win — or link the receipt's Original Invoice.
Yes — it walks the list in order, settling each invoice in full until the money runs out; the last invoice it reaches may get a partial application. One receipt, several applications, is the normal result.
No — candidates are always the receipt's own entity (and ledger and currency). Cross-entity settlement exists as a deliberate, opt-in feature with its own intercompany bookkeeping — see Cross-Entity AR Settlement — but auto-apply never does it for you.
Yes — the flag triggers the same matching from the UI, flows, the API, and Data Loader imports. Migrations often import receipts with the flag set so historical payments land on the right invoices automatically.
Completely — every application it made is an ordinary record with the same trash-icon removal as a manual one. Un-apply, then reallocate by hand on the Apply screen. (Removals in closed periods are refused, same as any application.)
Was this article helpful?