Collections overview

The debt collection console — arrears exposure, aging, case flow, collection rate and enforcement, in one screen.

Finance → Collections → /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.

What the console shows

PanelWhat it tells you
Arrears exposureTotal amount in arrears for the branch, split into in arrears vs not yet due, with the oldest overdue date.
AgeingThe arrears book broken into buckets — current, 1–30, 31–60, 61–90, 90+ days.
Arrears bookThe composition of debt, filterable by service type so you can see whether the problem is rent, water or service charge.
Billed vs collectedBilling performance over the period, by service type: what fell due, what was collected, and what is still outstanding.
Collection rateCollected ÷ billed, to date.
Case flowCases opened vs cases closed over the period — whether the book is being worked down or is growing.
RiskDistribution of cases across collectability bands A–E.
Officer activityContact and interaction volume, so managers can see who is actually working their queue.
PenaltiesLate-fee assessment activity and value. See Penalties.
Legal registerOpen matters, claim values and costs incurred. See Legal register.

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

Configuration checklist

Before Collections is useful in a branch, an administrator sets:

  1. Feature flag — the collections module enabled for the branch.
  2. Entry thresholds — minimum balance, minimum age, debt scope, exit hysteresis.
  3. Strategy — which dunning ladder applies, resolved through the settings scope chain (lease → unit → block → branch → organisation → default).
  4. Templates — the message templates the ladder's reminder and demand-letter steps render.
  5. Assignment rules — manual, round-robin, by branch, or by balance band.
  6. Enforcement mode — shadow (default) or autonomous, per branch.

See Settings and Feature flags.

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.