Finance → Collections → Debt Aging → /reports/debt-aging-report
The debt aging report is the platform's canonical answer to "who owes us what, and for how long?". Collections, IoT arrears enforcement and the collections console all read the same semantics, which is why their numbers agree.
Views
A segmented control switches the grain of the report:
| View | Grain | Use it for |
|---|---|---|
| By lease | One row per lease | Working arrears — who to call. |
| By service type | One row per service type | Diagnosing arrears — is it rent, water, or service charge that is not being paid? |
Include zero-balance adds leases with nothing outstanding. Off by default (an arrears report full of zeroes is noise); on, it becomes a complete book review.
Columns
| Column | Meaning |
|---|---|
| Company / Branch / Block / Unit | Where the debt sits. |
| Current | Billed but not yet overdue. |
| 1–30 Days | Overdue up to a month. |
| 31–60 Days | Overdue one to two months. |
| 61–90 Days | Overdue two to three months. |
| 90+ Days | Overdue more than three months. |
| Total Due | Gross contractual debt across all buckets. |
| Wallet Amount | Cash received against the lease that is not yet allocated to any invoice. |
Grouping and column totals are available on the grid, so you can roll the report up by block or branch without exporting it.
Reading it correctly
The two figures answer different questions:
- Total Due — what has been contractually billed and not settled. This is what a tenant statement shows and what a demand letter must quote.
- Net (Total Due − Wallet) — the real cash gap. This is what collections uses for entry thresholds, ladder triggers and case exit.
Related distinction worth knowing: an invoice's prepaid amount is already inside its due amount — it is the settled portion of that invoice, not extra money sitting elsewhere. Only the wallet is unapplied cash that can be netted off.
Grouping and lease identity
Rows are grouped by lease where a lease exists, and fall back to the unit where it does not — for example historical debt on a unit whose lease record has since been removed. This is why the report can show a unit-level row alongside lease-level rows and still total correctly.
Typical workflow
Start on By service type
One minute here tells you whether you have a rent problem or a utilities problem. They need different responses.
Switch to By lease and sort by 90+
Oldest money is hardest money. It is also what drives write-off risk at year end.
Scan the wallet column
Any lease with meaningful wallet and meaningful arrears is an allocation job, not a collection job. Fix those first — they are free.
Hand the rest to Collections
Leases that clear the entry thresholds already have cases. Work them from the worklist, where scoring and history are attached, rather than from the report.
Debt aging vs the collections console
| Debt aging report | Collections console | |
|---|---|---|
| Shape | A table you read | A queue you work |
| Grain | Lease or service type | Case, with score, assignee and next action |
| History | None — it is a point-in-time view | Full timeline, interactions, promises |
| Best for | Reconciliation, reporting, month-end | Day-to-day recovery |
Use the report to verify totals and to brief management. Use the console to actually recover money.
Snapshots
Monthly per-case aging snapshots are written by the collections engine. They are what make cure rate, roll rate and promise-kept trends computable — those metrics cannot be reconstructed retroactively from a point-in-time report.
Export
The grid exports to CSV and Excel with your current filters, grouping and column choices applied.