/collections/overview Beta
Collections turns debt from a report somebody reads into a queue somebody works:
debt detected → case opened → scored and prioritised → assigned → contacted → commitment recorded → payment monitored → escalated or closed.The overview console is the module’s landing page. It answers three questions before you open a single case: how much is owed, how old it is, and whether the team is keeping up.
Collections is an orchestrator over the accounting ledger, not a second ledger. Invoices,
payments, allocations and balances stay authoritative in the core ledger; Collections manages the
recovery process. That is why a case, the debt-aging report and a tenant statement always agree.
What the console shows
Each panel has a How these are calculated disclosure that states the exact definition used, so
a number on the console can be reconciled against the underlying report.
How debt reaches the console
The engine sweeps arrears on a schedule (and re-evaluates a single lease immediately when a payment or allocation lands, so cases clear promptly).1
Balance read
Per-lease balances are read from the ledger with the same semantics as the debt-aging report:
gross due, wallet (unallocated cash), net balance, bucket amounts, oldest due date and last
payment date — plus a per-service-type breakdown.
2
Entry test
A lease enters collections when it crosses the configured thresholds — minimum balance,
minimum age in days, and which debt counts (all, rent only, or utilities only).
3
Case open
A case is opened for the lease and the resolved strategy and thresholds are snapshotted onto
it, so later config changes never rewrite an in-flight case.
4
Score
A collectability score (0–100, bands A–E) is computed and stored with the feature values that
produced it.
5
Stage the next action
The next step on the dunning ladder is staged, not sent.
Shadow mode
Phase 1 runs recommend-only. The engine computes, scores, assigns and stages actions — a human confirms every send, disconnect and fee. Autonomy is earned per branch through the enforcement-mode setting, never by a global switch. This is the same convention the IoT arrears engine and the Boma Yangu dispatcher follow: nothing that touches money or reaches a resident goes out unattended until it has been proven in shadow.The pieces of the module
Worklist & cases
The ranked queue and the case workspace where the work actually happens.
Strategies
The dunning ladders that decide what happens next, and when.
Promise to Pay
Recorded commitments, instalments, and kept/broken evaluation.
Penalties
Late-fee policies and the assessments they produce.
Legal register
Matters, hearings, parties and costs once a case leaves internal recovery.
Debt aging
The underlying arrears report, by lease and by service type.
Configuration checklist
Before Collections is useful in a branch, an administrator sets:- Feature flag — the collections module enabled for the branch.
- Entry thresholds — minimum balance, minimum age, debt scope, exit hysteresis.
- Strategy — which dunning ladder applies, resolved through the settings scope chain (lease → unit → block → branch → organisation → default).
- Templates — the message templates the ladder’s reminder and demand-letter steps render.
- Assignment rules — manual, round-robin, by branch, or by balance band.
- Enforcement mode — shadow (default) or autonomous, per branch.
Reading the numbers correctly
- Net balance = gross due − wallet. Used for triggers and exit tests.
- Priority ≈ net balance × (100 − score). Big debt owed by an unlikely payer floats up.
- Delinquency bucket and recovery state are derived from the ledger on read, never stored — they cannot drift from the accounts.
- Disputed amounts (where enabled) are excluded from collectible balance and from ladder triggers; recovery continues on the undisputed remainder.