> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nyumbazetu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Debt aging

> The arrears report behind collections — who owes what, how old it is, and how to read it correctly.

**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.

<Note>
  This report moved from Accounting reports into **Collections**, where it is used. The old link
  still resolves.
</Note>

## 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

<Warning>
  **Total Due is gross.** It does not subtract the wallet. A lease showing KES 60,000 due and
  KES 60,000 wallet does not owe you anything — it owes you an
  [allocation](/guides/allocations).
</Warning>

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

<Steps>
  <Step title="Start on By service type">
    One minute here tells you whether you have a rent problem or a utilities problem. They need
    different responses.
  </Step>

  <Step title="Switch to By lease and sort by 90+">
    Oldest money is hardest money. It is also what drives write-off risk at year end.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Hand the rest to Collections">
    Leases that clear the entry thresholds already have cases. Work them from the
    [worklist](/guides/collections/worklist-and-cases), where scoring and history are attached,
    rather than from the report.
  </Step>
</Steps>

## 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.