A Cost-to-Service Line Item Names the Cost. Not Where the Time Goes.
Six cost lines make up what an NBFC spends servicing a loan. Inside each one sits a specific manual task nobody put a name to: a re-key, a hand match, a spreadsheet a person rebuilds every morning.
A cost-to-service model gives a lender six clean lines: servicing operations, payments and reconciliation, collections, compliance and reporting, technology, grievances. Each line has a number attached to it. None of the six numbers says where inside that line the actual minutes go.
Every cost-to-service line hides one specific manual task that eats disproportionate time: servicing operations loses time to re-keying the same request across systems, reconciliation to hand-matching imperfect receipts, collections to rebuilding the day’s call list by hand, compliance to hand-assembling reports, technology to waiting in a vendor’s configuration queue, and grievances to tracking a compensation clock nowhere the system tracks automatically. Knowing what a line costs is different from knowing what inside it actually consumes the hours.
A cost model answers “how much.” It was never built to answer “on what, specifically.” The two questions get treated as the same one often enough that the second never gets asked, and the six manual tasks below stay invisible on a spreadsheet that shows only the total.
Servicing operations: the re-key
A borrower calls to update a phone number, request a statement, or flag a dispute. The request often has to be entered in the loan system, then again in whatever tool logs the interaction, then again in a spreadsheet someone uses to track open cases because neither of the first two systems shows a queue view. Three entries for one request, and the third one exists purely because the first two do not talk to each other.
The time-eater here is not the borrower interaction. It is the re-keying that happens after it, invisible in a cost model that only counts “cases per loan” and never asks how many systems each case touches.
Payments and reconciliation: the hand match
A payment rarely arrives with a perfect match. The amount is short by a few rupees, the reference number is garbled, or a payment splits across two loan accounts because the borrower has more than one. Automated matching clears the clean cases in seconds. Every imperfect one lands on someone’s desk, and imperfect cases are the routine, not the exception, on any book with real volume.
The fix nobody reaches for is more matching rules. It is a system that surfaces an unmatched receipt the moment it fails to match, rather than letting it sit until a month-end reconciliation sweep finds a pile of them at once.
Collections: the rebuilt call list
Every morning, someone pulls a bucket report and turns it into a working call list, then updates that list by hand after every call, because the disposition from yesterday’s calls does not write back automatically into the source the report was pulled from. By the third week, the “working list” and the “system of record” have quietly diverged, and nobody fully trusts either one.
Bucket treatments tell a collections team what to do with an account. They say nothing about the hour spent each morning rebuilding the list of which accounts to do it to, which is where a meaningful share of a collections team’s actual day disappears.
Compliance and reporting: the hand-assembled file
A bureau file, a regulatory return, a board pack number, all of these commonly get built by exporting data from two or three places and assembling it by hand into the format the recipient expects, because the loan system produces its own format and nobody else’s. The task is not analytical. It is formatting, and it repeats on a fixed schedule regardless of how many loans are on the book.
This is the least visible time-eater of the six, because the output looks identical whether it took fifteen minutes or five hours to assemble, and nobody downstream can tell the difference from the file itself.
Technology: the vendor queue
The technology line in a cost model captures licence fees and hosting. It does not capture the time spent waiting on a vendor’s professional-services team to make a configuration change that should have been self-serve: a new field on a form, an adjusted fee schedule, a report layout tweak. On a platform not built for configuration by the lender’s own team, these requests queue behind every other client’s requests, and the wait itself is a cost nothing in the model line-items.
Grievances: the untracked clock
A complaint opens a compensation clock under RBI’s rules, and that clock does not pause for a weekend or wait for someone to remember it exists. Where nothing in the system flags an approaching SLA breach automatically, someone tracks the clock manually, usually in the same kind of spreadsheet that tracks everything else these six lines have in common: a workaround for a system that does not do the tracking on its own.
There are three honest ways to find where this shows up in your own book. Ask each team what felt repetitive and pointless in the last week, not what the job description says the role is. Time-and-motion a single case through each of the six lines and count how many systems and spreadsheets it touches. Or treat every manual re-key, hand match and rebuilt list as its own line item the next time a cost model gets rebuilt, instead of letting six clean numbers hide what is actually inside them.
Frequently asked questions
What is the biggest hidden time cost in loan servicing?
It depends on the line, but the pattern repeats everywhere: a task that looks like it should be automatic but requires a person to manually match, re-key or rebuild something because no single system owns the full picture. Payment reconciliation is the clearest example: matching an unapplied receipt to the right loan account by hand, one at a time, when the amount, reference or channel does not match exactly.
Why does reconciliation take so much manual time in loan servicing?
Because a payment rarely arrives with a perfect match. The amount is short by a few rupees, the reference number is garbled, or the payment splits across two loan accounts. Automated matching handles the clean cases; every imperfect one lands on a person's desk, and imperfect cases are not rare, they are routine. The fix is not more matching rules, it is a system that surfaces the unmatched case immediately instead of at month-end reconciliation.
Does a loan management system automatically fix these time-eaters?
Only the ones the system was actually built to close. A platform that stores loan data but was not designed around reconciliation, case ownership or SLA tracking still leaves these tasks to a person, even with a modern interface on top. The time-eater is a workflow gap, not a missing feature checkbox, so the right question in an RFP is whether the specific manual step disappears, not whether the platform has a matching module.
How do you find where servicing time actually goes in your own book?
Ask each team what they did yesterday that felt repetitive and pointless. Not what the process document says the job is, what the actual last hour of manual work looked like. The gap between the two is almost always one of these six: a re-key, a hand match, a rebuilt list, a hand-assembled file, a vendor request queue, or an untracked compensation clock.
Read next:
- What it costs to service a loan: the six-line cost model this post’s time-eaters sit inside.
- NBFC collection strategy by bucket: the bucket treatments a collections team’s rebuilt call list is supposed to execute.
- The LMS selection mistakes that have nothing to do with features: why a platform with a matching module can still leave the hand-match problem untouched.
Chandramouli is the co-founder and CEO of Lokta, the agentic loan servicing platform. He has spent two decades building AI for decisions that change people’s lives, and has served as an independent director on an NBFC board. He writes here about the manual work a cost model counts but never actually names.
