Allocations

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

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.

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