Interest & Accrual Engine
Simple interest, monthly compound interest, and a penal rate that runs alongside both. Accrual is an explicit run you trigger and can recompute, not a black box.
The interest engine computes what a loan owes. It supports simple interest and monthly compounding, applies a separate penal rate to overdue amounts, and accrues on demand rather than on a hidden nightly schedule, so the person responsible for the number knows exactly when it was produced.
Accrual runs are themselves logged events, visible in the audit trail with who ran them.
What is built today
- Simple interest
Computed on principal outstanding, per the configured rate on the loan’s scheme.
- Compound interest, monthly rest
Interest capitalises monthly where the loan is configured for it.
- Separate penal rate
A distinct rate applied to overdue amounts, held separately from normal interest throughout the ledger.
- On-demand accrual runs
An authorised user triggers accrual for a period. Nothing accrues silently overnight.
- Recompute existing accruals
A back-dated repayment or correction can be followed by a recompute, which rebuilds accruals from that point.
- Scheme-level rate configuration
Rates live on the scheme master, so a scheme change propagates rather than being rekeyed per loan.
- Accrual events in the ledger
Every run appears in the running ledger with the resulting balance.
- Audit logging of runs
Interest runs are recorded in the append-only audit trail alongside certificate issuance.
One receipt.
Three components.
A repayment is not filed against a loan. It is split across penal interest, interest and principal in a fixed order, and the split is re-derivable from the events that produced it.
See the interest engineOn-demand accrual, and why we did not automate it away
A nightly interest job is convenient right up to the moment somebody asks why last March’s figure changed. GoDravix makes accrual an explicit action: a person with the right role runs it for a period, the run is logged with their name, and the resulting events appear in the ledger.
The recompute capability exists because real loan books are entered out of order. A repayment surfaces three weeks late, a correction lands after a month-end, a migration brings in history retrospectively. Recompute rebuilds accruals from the affected point forward rather than leaving the ledger quietly wrong.
- Deliberate, attributable runs
The number has an owner and a timestamp.
- Recompute after back-dated entries
Accruals rebuild from the point of change forward.
- Penal held separately
Penal interest never merges into normal interest in the ledger.
- Scheme-driven rates
Change the scheme, not two hundred loans.
A known weakness we are not going to hide
The interest engine is currently order-sensitive. Entering a batch of repayments and then recomputing can produce incorrect (in some cases negative) interest. The correct operating procedure today is interleaved: record one repayment, recompute to that month’s end, then record the next.
We are stating this on a public product page because it is the kind of defect that destroys trust when a customer discovers it themselves. Two fixes are planned: making the computation order-independent, and adding a hard invariant that refuses to write an accrual where interest would be negative.
A second related issue: outstanding balance recomputes on page load, and has shown instability under that pattern. Balances should be deterministic and reproducible from the event log rather than recalculated on view. That work is scheduled.
- Current mitigation
A documented interleaved procedure that operations teams follow, and which we walk through during onboarding.
- Planned fix: order independence
Computation that yields the same result regardless of entry sequence.
- Planned fix: non-negative invariant
A guardrail that blocks the write rather than storing a wrong figure.
- Planned fix: deterministic balances
Outstanding derived from the event log, not recomputed on render.
Legacy interest methods and the migration decision
When a loan book has been maintained for fifteen years in a spreadsheet or an old system, the interest convention used is often undocumented and sometimes inconsistent. During our own migration testing, neither simple nor monthly-compound interest reproduced the board’s historical figure exactly on one test loan.
That is not a bug in either method. It means the historical book used a convention that has to be identified and then decided upon. We surface the variance before cut-over and put the choice in writing:
- Option one: replicate
Reproduce the historical convention so opening balances tie exactly.
- Option two: adopt and adjust
Move to the new method and treat the residual as a documented waiver or adjustment.
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.
- Daily-balance accrualThe engine is built around term-style lending. Working capital and overdraft accrual on daily balances is a different product type, and roadmap.
- Floating and reset ratesNo floating-rate loans with periodic reset, and no pre-EMI interest handling for housing or construction lending.
- Other compounding restsMonthly compounding today. Quarterly, half-yearly and annual rests are roadmap.
- Day-count conventionsAlternative day-count bases such as actual/365 versus 30/360 are not selectable per scheme today.
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
Two: simple interest, and compound interest with a monthly rest. A separate penal rate runs alongside either, applied to overdue amounts and held distinctly in the ledger throughout. Quarterly, half-yearly and annual compounding rests are not supported, nor is daily-balance accrual for overdraft-style products.
When someone runs it. Accrual is an explicit, logged action taken by an authorised user for a defined period, rather than a scheduled overnight job. The trade-off is deliberate: it means every interest figure in the ledger has a person and a timestamp attached, which matters a great deal when a figure is later questioned.
Record the repayment with its true date, then run a recompute, which rebuilds accruals from that point forward. Important operational note: do this one repayment at a time rather than in a batch. The engine is currently order-sensitive, and entering several back-dated repayments before recomputing can produce wrong figures. Making this order-independent is scheduled work.
Sometimes exactly, sometimes not, and we test rather than promise. Where a legacy book used an interest convention that neither of our methods reproduces, we quantify the variance loan by loan before cut-over and agree the treatment in writing: either replicate the historical method, or adopt the new one and handle the residual as a documented adjustment.
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 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