Loan Lifecycle Core
Sanction, approve, disburse, recover, waive, close. Six states, each one an audited event, with approval separation enforced by the workflow rather than by trust.
The loan lifecycle core is the state machine at the centre of GoDravix. It moves a loan from creation through approval, disbursement, repayment and closure, and it refuses to let a loan skip a step, disbursement is blocked in software until an approval has actually been recorded by a different user.
Every transition writes an event to the append-only log with the actor and the timestamp.
What is built today
- Loan creation against a scheme
Whoever holds loan entry creates the loan with borrower, scheme, sanctioned amount, interest method, rate, penal rate and repayment frequency drawn from the configured masters.
- Maker–checker approval
A second permission approves or rejects. The creator cannot approve their own loan, and the rejection carries a reason that stays on the record.
- Hard disbursement block
Until approval is recorded, the disbursement action is unavailable. This is enforced in the workflow, not by hiding a button.
- Single or multi-tranche disbursement
Release the full amount at once, or in INITIAL and ADDITIONAL tranches, each with its own date and payment reference. Remaining-to-disburse is tracked continuously.
- Repayment recording
Repayments are recorded with date, amount, recovery method and reference, then allocated automatically down the waterfall.
- Waivers with authority
A waiver carries the approving authority, the order number, an explicit split across principal, interest and penal, a funding type and supporting documents.
- Closure and NOC
Full repayment or an approved waiver closes the loan and unlocks the closure certificate and no-objection certificate.
- Complete running ledger
Every event in sequence with the balance after it, exportable to Excel or PDF.
The mistake stays
on the record.
A ledger that can be tidied is a ledger that cannot be trusted. Corrections are appended, never applied over the top, so an auditor reads what happened rather than what was left behind.
See certificates and auditWhy the approval separation matters more than it sounds
Most loan systems have an approval field. Far fewer make approval a gate that the software will not let you walk around when it is Friday afternoon and the disbursement has to go out.
In GoDravix the three duties that touch a loan’s money are distinct by construction. One permission creates. A second approves. A third releases the funds. One person holding two of them is a configuration decision your organisation makes deliberately, not an accident of how the screens were built. When an auditor asks who authorised a particular release, the answer is a name and a timestamp rather than a reconstruction.
- Creator cannot approve
The maker–checker split is enforced per loan, not per session.
- Rejection is a recorded state
A rejected loan keeps its reason and stays visible; it is not deleted.
- Disbursement requires an approval event
No approval event, no disbursement action.
- Every transition is attributed
Actor, action and timestamp, appended and never edited.
Multi-tranche disbursement in practice
Institutional and project lending rarely releases a sanction in one payment. GoDravix tracks each tranche separately (typed as INITIAL or ADDITIONAL, dated, and carrying its own payment reference) and keeps a live figure for how much of the sanction remains undisbursed.
- Tranche typing
INITIAL and ADDITIONAL, so the first release is distinguishable from later ones.
- Per-tranche dating
Interest accrues from each tranche’s own date, not from sanction.
- Payment references
Each release carries its own reference for bank reconciliation.
- Remaining-to-disburse
Visible on the loan at all times.
Waivers that survive an audit
A waiver is the most scrutinised event in an institutional loan book, because it is the one where money stops being owed without money being paid. GoDravix treats it accordingly: a waiver cannot be recorded as a bare amount.
- Approving authority
The named body, committee or officer that authorised the relief.
- Authorisation reference
The board resolution, committee minute, delegation number or order reference, whichever your approval produces, held on the record.
- Explicit P / I / Penal split
You state how much of each component is being waived. The system does not guess.
- Funding type
Where the waived amount is being absorbed from.
- Supporting documents
Attached to the waiver event itself, not filed elsewhere.
- Ledger impact
Recorded as an event with the resulting balance, visible in the running ledger.
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.
- Loan product typesTerm-style and scheme-based loans only. No working capital or overdraft, no joint-liability group lending, no gold or LTV, no pre-EMI or floating-rate housing, no co-lending splits.
- Restructuring workflowRescheduling a loan is handled through waiver and re-entry rather than a dedicated restructure action with its own approval path.
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
Not on the same loan. Creating and approving are separate permissions, and the workflow will not accept an approval from the user who created the record, whatever roles that user holds. If one individual holds both permissions in your organisation, that is a deliberate assignment decision you make in the permission editor, and it will be visible in the audit trail every time it happens.
The ledger is append-only, so the original entry is not edited away. A correcting event is recorded, and both entries remain visible in the running ledger with the balance after each. An auditor can see what was entered, when it was corrected and by whom. This is deliberately less convenient than an edit button.
Yes. An amortisation schedule is generated at sanction, so the borrower gets an instalment table and your team has an expected position to reconcile against. Monthly, half-yearly and yearly frequencies are supported, and interest is still computed on demand against the live balance, so the schedule is an expectation rather than a substitute for the ledger.
Yes, in configuration. Six roles ship as the default because they map to the separation most lenders need, but a role builder lets you add your own and a granular permission editor sets what each one can see and do, down to the individual action. Data scoping, which zone and which entity, is configured the same way.
Related modules
Interest & 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 moreRecovery & Repayment
Automatic waterfall allocation, penal, then interest, then principal. Monthly, half-yearly or yearly frequency. Grant deduction and cheque recovery methods.
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