Collections & Delinquency
Turn overdue loans into a controlled recovery workflow.
Rank every overdue account by days past due, give each officer the next action, capture field payments even offline, and escalate only through your configured, notice-gated recovery policy.
- Amina Joseph · Loan #2318
- 18 DPD · promise to pay
- Collection rate
- 83.2%
- PAR30 / PAR90
- 4.2% / 1.1%
One control center for the whole recovery operation
Collections is an operation, not a reminder. Above the portfolio sits one view of the recovery work — what is overdue, what is due today, what was collected, the promises to chase, the visits to make, and the cases ready to escalate. It is the difference between a collections operating system and a list of late borrowers.
- 1–7 DPD24 cases
- 8–30 DPD18 cases
- 31–60 DPD9 cases
- 61–90 DPD4 cases
- 91+ DPD3 cases
- 14 promises due
- 8 high-value overdue loans
- 5 failed contact attempts
- 3 cases ready for escalation
Before, and with, Ustawi
Drag the slider: the same overdue account, chased from a spreadsheet versus worked as one case in Ustawi.
| A. Joseph | 18 DPD | 420,000 | promised? |
| P. Michael | 12 DPD | 420,000 | called?? |
| Grace K. | #REF! | 300,000 | visit? |
| Dar Logistics | 104 DPD | 1,200,000 | ask Sarah |
Ustawi makes collections consistent and traceable; it does not remove every manual step, and recovery escalation follows your configured policy and the applicable requirements — not a universal rule.
From overdue account to the next action
One overdue account, worked step by step — from the queue to the ladder, the borrower, the promise, the visit and the case.
Tap a stage to stop on it. Hover pauses the animation.
One prioritized queue for every overdue account
Every overdue account lands in one queue, ranked so the officer works the right case next — the amount, the days past due, the risk and the action that is due. No wading through a spreadsheet of late loans to decide who to chase first.
| Borrower | DPD | Outstanding | Overdue | Risk | Next action |
|---|---|---|---|---|---|
| Peter Michael | 12 | TSh 4.2M | TSh 420K | High | Call → |
| Amina Joseph | 18 | TSh 5.24M | TSh 420K | Medium | Call → |
| Grace K. | 34 | TSh 2.1M | TSh 300K | High | Visit → |
| John P. | 68 | TSh 5.8M | TSh 640K | Critical | Notice → |
| Dar Logistics Ltd | 104 | TSh 12.0M | TSh 1.2M | Critical | Escalate → |
Priority and next action are derived from DPD, amount and configured rules.
Turn days-past-due into the next action
Escalation runs off days-past-due, so the same delinquency is handled the same way every time — not left to whichever officer happens to pick it up. The stages and their thresholds are configurable per tenant and product; the ladder below is one product's configuration.
Stages and DPD thresholds are configured per tenant and product — they are not universal legal requirements, and escalation follows your configured recovery policy and applicable requirements.
Configure the recovery ladder for each product
Each product carries its own ladder — the trigger, the action, who owns it, the deadline and the evidence it leaves. That is what makes escalation consistent: the rule decides, not the officer's mood.
| Rule | Trigger (DPD) | Action | Owner |
|---|---|---|---|
| 01 | DPD 1 | SMS · payment reminder | Automated |
| 02 | DPD 8 | Call | Loan officer |
| 03 | DPD 31 | Field visit | Collections team |
| 04 | DPD 61 | Formal notice | Collections manager |
| 05 | DPD 91 | Escalated recovery | Recovery / compliance |
The ladder, thresholds and owners are configured per tenant and product.
One borrower. One complete collection history.
Everything an officer needs to make the next call sits on one profile — the loan, what is overdue, the current action, the last contact, the live promise, and how many past promises were kept or broken.
Turn promises into trackable commitments
A promise-to-pay is captured against a real due date and amount, so it can actually be followed up — not remembered in an officer's notebook. The dashboard shows the promises due today and how they resolved.
Tracked against the actual due date on the loan.
- Fulfilled9
- Pending3
- Broken2
A broken promise triggers the next action
A promise is only useful if what happens next depends on it. When the due date arrives, Ustawi checks whether the payment came in — a kept promise closes, a broken one re-prioritises the case and triggers the next collection action.
Which action follows a broken promise is set by your configured rules.
Give every officer a clear worklist
Each collections officer gets a worklist for the day — who to contact, when, and how — plus a running tally of what they have collected. Management sees the same, per officer: assigned portfolio, actions and outcomes.
- 09:00Amina JosephCall
- 10:30Peter MichaelField visit
- 13:00Grace K.Promise follow-up
- 15:30Dar Logistics LtdField visit
Every field visit leaves a record
A visit is captured with its GPS location, outcome, any promise made and the next action — so a visit is evidence, not a story told back at the branch.
The collection case is distinct from the loan account
The loan is the financial account; the collection case is the recovery workflow around it. Keeping them distinct makes the product clearer — the case carries the actions, the promises and the timeline, all tied to the loan.
Case states (Open / In progress / Escalated / Resolved) are configured per tenant.
- SMS reminder17 Sep
- Officer call17 Sep
- Field visit18 Sep
- Promise to payDue 20 Sep
- Promise follow-up20 Sep
Field collection that never loses a receipt
Collect in the field, even without network coverage
In much of the market the network is not a given. A field agent can take and record a payment with no signal — the receipt is written on the device and queued, and a dropped connection never means a lost receipt. This is one of the two things that make Collections genuinely built for Tanzanian field lending.
When the phone reconnects
A failed sync becomes an exception — not a lost payment
This is the second signature feature. If a sync fails, the payment does not vanish — it drops into a recoverable exception queue to be retried until it posts. Never losing a receipt is the difference between a payment recorded and a borrower wrongly chased for money they already paid.
| Receipt | Borrower | Amount | Status | Action |
|---|---|---|---|---|
| REC-10492 | Amina Joseph | TSh 200,000 | Sync failed | Retry → |
| REC-10488 | Grace K. | TSh 120,000 | Recovered | Posted |
Field capture runs in the Mobile App.
Every payment is reconciled, allocated and posted
A captured payment does not stop at "received". Once synced it is validated, allocated across principal, interest and fees, applied to the loan balance, and posted to the general ledger — so the collection updates the book and the accounts in one move.
- SyncedFrom field device
- ValidatedReceipt matched
- AllocatedPrincipal / interest / fees
- Loan balance updated
- GL posted
The exact split and postings depend on the loan product and configured accounting treatment.
| Dr | Cash / bank | TSh 200,000 |
| Cr | Loans receivable — #2318 | TSh 150,000 |
| Cr | Interest income | TSh 40,000 |
| Cr | Fee income | TSh 10,000 |
See General Ledger & Finance.
See offline collection and sync recovery working on your own book.
Controlled recovery, not improvisation
Not every overdue loan follows the same recovery path
Where a borrower has a genuine, verified cash-flow difficulty, restructuring can be a better outcome than continued chasing. On a borrower request and subject to the institution's lending policy, a delinquent loan can be assessed for restructuring instead of escalation — this is not an automatic entitlement for every overdue borrower.
Restructuring is subject to the institution's lending policy and approval — see Loan Origination & Servicing.
Escalate recovery without losing compliance controls
Escalation does not mean improvisation. Where collection attempts do not resolve a default, recovery follows your configured recovery policy and the applicable requirements — a formal notice, served and recorded, an applicable waiting period, and an eligibility check before any recovery action. Ustawi does not hard-code a single "90 days then legal" rule.
- DefaultRecorded
Delinquency recorded on the loan
- Collection attemptsRecorded
Contact, promise, visit — recorded
- Formal noticeIn progress
Prepared via Compliance & Regulatory
- Notice served
Date and method recorded
- Applicable period
Runs per the applicable framework
- Eligibility check
Recovery action becomes eligible
- Recovery action
Per your process and requirements
Responsible-collection controls, built into the workflow
Responsible collection is a product feature, not a disclaimer. The workflow supports approved communication, a full contact history, required notices and restricted actions — the controls that keep recovery firm and fair. It supports these controls; it does not, on its own, guarantee legal compliance.
- Approved communication templates
- Full contact history
- Contact preferences where applicable
- No duplicate chasing of the same account
- Restricted collection actions
- Required notices before escalation
- Contact attempt & outcome
- Visit with GPS
- Promise, payment and case decision
Applicable microfinance frameworks restrict conduct such as harassment, threats and deceptive representations in debt recovery. Ustawi's controls are designed to support responsible collection within those requirements, configured to the framework that applies to you.
An audit trail for every collection action
Every action — a message, a call, a visit, a promise, a payment, a recovered sync — is captured with a timestamp and the user. When a borrower disputes being chased, or an examiner asks what happened, the trail is on one screen.
- 17 Sep · 09:12SMS reminder sent· System
- 17 Sep · 14:05Call logged· Sarah M.
- 18 Sep · 10:32Field visit recorded (GPS)· Sarah M.
- 18 Sep · 10:40Promise to pay created· Sarah M.
- 18 Sep · 14:32Field payment captured (offline)· Sarah M.
- 18 Sep · 18:20Sync exception recovered · posted· System
Outcomes, movement and where arrears come from
Measure recovery outcomes
Management does not only need to know how many borrowers were contacted — it needs to know what happened. Outcomes turn the activity into results: what was due, what was collected, and how promises, visits and cases resolved.
See accounts worsening, curing, and stuck
A static PAR number hides the story. Delinquency movement shows accounts rolling forward through the buckets — and, just as important, accounts curing back toward current as overdue instalments are paid.
Understand where delinquency comes from
Collections analytics give management operational visibility — PAR and collection rate broken down by branch, officer, product, region and DPD bucket — so effort goes where the delinquency actually is.
Analytics for operational visibility — cut by branch, officer, product, region and DPD bucket.
Connected to the loan, the books and the reports
From collection to regulatory report
This is why Collections is part of a platform, not a bolt-on. The same events that drive a collection — a missed instalment, a payment taken in the field — flow straight through to PAR, classification, provisioning and the regulatory report, with no re-keying in between.
- Loan
- Repayment schedule
- DPD
- Collection case
- Contact / promise / visit
- Payment
- Loan balance
- PAR
- Classification
- Provisioning
- Regulatory report
Connected across the Ustawi platform
Collections is a core operating system inside Ustawi, not an add-on. It reads and writes against the same loan, accounting and field data as the apps around it.
The loan, schedule and restructuring behind every case.
Explore app →Recovery notices and the wider control layer.
Explore app →Delinquency feeds PAR, classification and provisioning.
Explore app →The field agents and visits on the ground.
Explore app →Collected payments post to the GL.
Explore app →Where repossession is gated on a served notice.
Explore app →Collections is about people, not just numbers
Behind every overdue loan is a borrower and an officer meeting, often in the field, often where the network does not reach. Ustawi's job is to make that meeting count — the right next action in hand, the payment captured even offline, and a record that protects both the institution and the borrower who has already paid.
Who uses Collections & Delinquency
Recovery is a team effort from the field to management. Each role sees the part it needs.
- Collections officers
Work the queue, capture promises and record outcomes.
- Loan officers
Follow up early arrears on their own portfolio.
- Field agents
Collect in the field, offline, with GPS-stamped visits.
- Branch managers
Review branch workload, exceptions and performance.
- Credit / risk & compliance
Oversee escalation, notices and responsible-collection controls.
- Management
See collection rate, PAR movement and recovery outcomes.
Getting live
How we get you live
A structured rollout, from mapping your recovery policy to running collections on live delinquency.
- 01Discover
Map your products, DPD ladder, roles and recovery policy.
- 02Configure
Set the dunning rules, thresholds, templates and escalation.
- 03Migrate
Bring overdue loans and their history onto the platform.
- 04Test
Validate the queue, offline capture, sync recovery and reporting feed.
- 05Train
Bring collections officers and field agents up to speed on the workflow.
- 06Go live
Run collections on live delinquency, with support on hand.
See Collections & Delinquency in a live demo
Request a DemoFrequently asked questions
Yes — the action ladder and its DPD thresholds are configurable per tenant and product. They are not universal legal requirements.