What a loan management system actually does, module by module

Every vendor's feature matrix says yes to everything, because a feature matrix is a document designed to be ticked. It is more useful to think about what a loan management system is responsible for, because responsibilities are harder to fake in a demo.

Six of them, in the order a loan meets them.

1. The lifecycle, as a state machine

A loan moves through sanction, approval, disbursement, accrual, repayment, and closure. The system's job is to refuse transitions that should not happen. Disbursement before approval is the obvious one, and it is the one most often enforced by training rather than by software.

2. Interest, held as a method rather than a number

Simple, compound and penal interest are different calculations, and penal is held separately from the rest or you cannot answer what a borrower owes in principal versus what they owe in penalty. Accrual has to be re-runnable, because back-dated entries happen and an accrual that cannot be recomputed is a balance nobody can defend.

3. Repayment allocation, in a fixed order

When money arrives it has to be split across penal interest, interest and principal. The order matters and, more importantly, it has to be the same order every time. A configurable per-transaction waterfall sounds flexible and produces a portfolio whose allocations cannot be re-derived, which means they cannot be defended in an audit.

4. The ledger, and whether it can be edited

This is the one that separates products. An append-only ledger records a correction as a new entry referencing the original. An editable one lets someone fix a mistake in place, and the mistake disappears along with the evidence that it happened.

5. Certificates and statutory output

Institutional lenders issue documents: outstanding balance certificates, no-objection certificates, closure certificates. These have to be generated from live balances rather than typed, or they will eventually disagree with the ledger they are supposed to describe.

6. Reporting that a regulator will accept

Reports need filters, grouping, subtotals and a totals row, and the amounts need to arrive in Excel as numbers rather than text. That last one sounds trivial until someone tries to sum a column and gets zero.

What is not in the list

Origination is not, and neither is credit scoring. Those belong to a different system, and a management system claiming them usually means a thin form somewhere rather than an underwriting engine.

Collections workflow is a genuine grey area. Overdue identification is squarely a management responsibility. Agent allocation, ageing buckets, dialler integration and promise-to-pay tracking are a separate discipline, and a vendor who lists them alongside the six above is worth asking to demonstrate them specifically. GoDravix has an overdue report and does not have a collections module, which is a distinction we would rather make here than in month three of a rollout.

The six, in one view

What sits underneath all six

An event log. Every transition in every module writes an entry recording what happened, who did it and when, and the entry is never revised. That is the thing the other six responsibilities rest on: an interest engine you cannot audit is a calculator, and a certificate you cannot trace to a balance is a letter.

It is also the part hardest to retrofit. A system built to allow edits does not become append-only by adding a history table, because the history table records what the application chose to tell it. Ask when the audit log was added relative to the rest of the product.

Configuration or development, and why the answer matters

Every vendor says the product is configurable. The useful question is which specific things are configuration and which are a quote.

In GoDravix, schemes, interest rates, borrowing entities, data scoping, roles and permissions are configuration. Form fields and certificate formats are fixed today, and changing those is development work. We publish that split on the platform page rather than leaving it to be discovered, because the difference between the two lists is the difference between a two-week rollout and a six-month one.

Ask any vendor for the same two lists in writing. A vendor who cannot produce them has not thought about it, or would rather you found out later.

How to run the demo

Six questions, one per responsibility, in the order above. Ask for each to be performed rather than described.

1. 01
   Disburse without an approval

   The transition should be refused by the software, not by policy.

2. 02
   Back-date a repayment, then recompute accrual

   If accrual cannot be re-run, a back-dated entry leaves a balance nobody can defend.

3. 03
   Change the allocation order on one receipt

   If the system allows it, allocations across the book stop being re-derivable.

4. 04
   Edit a posted ledger entry

   Watch whether it is refused, and whether the correction references the original.

5. 05
   Generate a certificate, then change the balance behind it

   The next certificate should move. If it does not, the number was stored rather than read.

6. 06
   Export a report and sum a column in Excel

   Amounts arriving as text is the most common and least visible defect in lending reporting.