Skip to main content
Finance → Receivables → Allocations → /allocations Receiving money and settling a bill are two different events. A payment lands as cash on the lease; an allocation is what applies it to specific invoices. Until money is allocated:
  • the invoice stays unpaid and continues to age;
  • the debt still appears in the debt-aging report and can open a collections case;
  • the resident’s statement shows both a bill and a credit that have not met.
Allocations is its own destination because allocation runs are an engine concern, not a property of a single payment record.

​
The two tabs

​
Allocating manually

1

Open the payment or the invoice

Both sides offer the allocation dialog.
2

Review the proposed match

The dialog shows the payment, the lease/unit, the available amount, and the candidate invoices with what will be allocated to each.
3

Adjust the split

Change the amount against any invoice. What is not allocated is shown as To Wallet — it stays as unapplied cash on the lease.
4

Read the confirmation panel

Before you commit: Will Allocate, Will Pay, Returns to Wallet. This is the preview — read it rather than clicking through it.
5

Confirm

The allocation is written, invoice payment statuses update, and the ledger posts.

​
The allocation engine

The engine matches unallocated payments to outstanding invoices automatically, using the organisation’s payment rules for ordering (for example oldest-first, or rent before utilities). It is preview-first:
1

Preview

Runs the match and shows what would happen — how many payments, how much would be allocated, what would be skipped and why. Nothing is written.
2

Execute

Commits the previewed run. The execution is linked to the preview that produced it.
3

Revert

Undoes a run in full. The reverted run and the reverting run are linked to each other.

​
Reading the run log

An allocated = 0 run with a high skipped count is almost never a bug in the engine — it usually means the payments in scope had no matching outstanding invoices, or a guard (branch scope, unit scope) excluded them. Open the run to see the skip reasons.

​
Scheduled allocation

The engine can run on a schedule. It works organisation by organisation in rotation, with per-branch limits, so a large branch cannot starve the others of processing. The job is individually switchable and defaults to off outside production.

​
Reversing an allocation

Reversal is a first-class operation, not a delete:
  • Reversing an allocation returns the money to the lease’s wallet and re-opens the invoice balance.
  • Reversing a run reverses every allocation the run created.
  • Both are recorded, linked and auditable.
Never de-allocate by deleting rows or editing amounts directly. The allocation ledger is what the invoice balance, the wallet figure and the general ledger all read; a manual edit produces figures that disagree with each other and are very hard to unpick later.

​
Wallet, prepaid, and what can be netted

Three figures are easy to confuse: Prepaid attributes to the invoice’s unit; wallet attributes to the payment’s unit. On a multi-unit tenant this distinction decides which unit’s balance moves.

​
Over-allocation

Allocating more than an invoice is worth, or more than a payment holds, is guarded server-side. If you see a negative wallet balance on a lease, it is a symptom of an unguarded historical allocation, not a legitimate state — raise it rather than trying to correct it by hand.

​
Troubleshooting