Recovery & Repayment
Repayments allocate down a fixed waterfall without anyone deciding case by case, so the same payment produces the same split every time and the ledger stays defensible.
Every repayment recorded in GoDravix is allocated automatically: penal interest first, then normal interest, then principal. The allocation is not a per-transaction judgement call, which is precisely what makes the resulting ledger something an auditor can follow.
Recovery method and reference are captured on each repayment for bank reconciliation.
What is built today
- Automatic waterfall allocation
Penal → interest → principal, applied consistently to every repayment.
- Monthly repayment frequency
The standard cadence for most term lending.
- Half-yearly frequency
Added in July 2026 for institutional and scheme lending cycles.
- Yearly frequency
For annual recovery cycles common in government on-lending.
- Grant deduction recovery
Recovery by deduction from a grant or transfer due to the borrowing entity.
- Cheque recovery
Recovery by cheque, with reference captured against the repayment event.
- Per-repayment references
Each entry carries its date, method and reference for reconciliation.
- Ledger visibility
The split across penal, interest and principal is visible for every repayment in the running ledger.
Why a fixed waterfall beats a flexible one
A configurable allocation order sounds like a feature until you audit a portfolio where three operators each applied a different one. GoDravix uses a single allocation sequence (penal, interest, principal) and applies it to every repayment without exception.
The consequence is that any repayment can be re-derived from its amount and the balances at that moment. Nothing depends on remembering what somebody chose in a dropdown eighteen months ago. When a borrower disputes an allocation, the answer is arithmetic rather than archaeology.
- Deterministic
The same payment against the same balances always splits the same way.
- Reproducible
Any historical allocation can be re-derived and checked.
- Penal cleared first
Overdue penalties do not accumulate quietly behind principal repayment.
- Visible in the ledger
Each repayment shows its three-way split, not just a total.
Recovery methods built for institutional lending
Two recovery methods exist today, and both were built because the live deployment needed them rather than because a competitor had them.
- Grant deduction
Recovery netted against a transfer due to the borrowing entity, with the deduction recorded as a repayment event.
- Cheque
Conventional cheque recovery with reference and date captured for bank reconciliation.
Grant deduction is the mechanism that makes government on-lending work: rather than a municipality writing a cheque, the amount due is deducted from a grant the state is already transferring to it. Retail-shaped lending platforms generally have no concept of this, which is a large part of why institutional lenders end up with spreadsheets alongside their software.
Two recovery methods, both finance-process driven. Grant deduction and cheque are what the platform records today, each entered once the money has actually moved. NACH and e-mandate, UPI collection, direct debit and payment gateways sit on the integrations roadmap, so if your recovery runs on automated mandate presentation, raise it in the first conversation.
What a collections module would add, and why we do not claim one
GoDravix has an overdue report. It does not have a collections module, and the distinction matters if collections is central to your operation.
| Capability | Status | What exists instead |
|---|---|---|
| Overdue identification | Live | An overdue report across the portfolio, exportable to Excel and PDF. |
| DPD bucketing | Roadmap | No 0–30, 31–60, 61–90 ageing bands. |
| Ageing analysis | Roadmap | Overdue is a flag rather than a time-graded classification. |
| Promise-to-pay tracking | Roadmap | No commitment capture or follow-up scheduling. |
| Collections dashboard | Roadmap | The portfolio dashboard shows position, not collections workload. |
| Agent allocation | Roadmap | No case assignment or agent productivity view. |
| Automated reminders | Roadmap | No SMS, WhatsApp or email dispatch from the platform. |
If your business runs on a collections floor with daily allocation of accounts to agents, GoDravix is not the right platform for you today. If your recovery is a finance-team process driven by scheduled deductions and periodic follow-up, the overdue report and the ledger are usually sufficient.
Where this module stops
These sit outside what this module does today. They are named here so a fit decision can be made now rather than during implementation.
- Payment integrationsNo NACH or e-mandate, no UPI, no direct debit, no payment gateway and no bank statement import for automatic matching.
- Collections operationsNo DPD buckets, ageing analysis, promise-to-pay tracking, agent allocation or collections dashboard.
- Automated communicationNo SMS, WhatsApp or email reminders dispatched from the platform, and no vernacular message templates.
- Payroll recoveryNo payroll integration for employer or staff loan recovery. Deductions would be recorded manually.
Some of it is built into an engagement, some is genuinely out of scope, and some is development we can quote against your requirement. Which one it is depends on your workflow, and that is a fifteen-minute conversation rather than a guess.
About this module
Down a fixed waterfall: penal interest is cleared first, then normal interest, then principal. This applies to every repayment automatically and is not configurable per transaction, deliberately, because a configurable order produces portfolios where allocations cannot be re-derived and therefore cannot be defended in an audit.
Monthly, half-yearly and yearly. Half-yearly was added in July 2026 specifically for institutional and scheme-based lending cycles, where six-monthly recovery is common. Quarterly, fortnightly and weekly frequencies are not available today.
Recovery is recorded rather than collected. Two methods exist (grant deduction and cheque) and both are entries your team makes once the money has moved. Mandate presentation, UPI collection, direct debit and gateway integration sit on the integrations roadmap.
If automated mandate-based collection is central to your model, that is a real mismatch and worth establishing in the first conversation.
Not as a module. What exists is an overdue report that identifies accounts behind on repayment and exports to Excel and PDF. DPD ageing, promise-to-pay capture, agent allocation and a collections dashboard are roadmap.
For a finance-team recovery process the report is usually enough. For a collections floor it is not, and knowing which of the two you run is the quickest way to settle whether we are a fit.
Related modules
Loan Lifecycle Core
Sanction, maker–checker approval, single or multi-tranche disbursement, repayment, waiver, closure and NOC. Disbursement stays blocked until the approval actually happens.
Learn moreInterest & Accrual Engine
Simple and monthly-compound interest with a separate penal rate. Accrual runs on demand, and existing accruals can be recomputed when a back-dated entry changes the picture.
Learn moreCertificates & Audit Trail
Six statutory certificates generated from live balances, plus an append-only event log that records who issued what and when, with no edit path and no delete path.
Learn moreSee this module running on live data
We demo on the production deployment, not a sandbox with tidy numbers chosen to make the software look good.
45 minutes | On the live deployment | A straight answer on fit