Loan Management System
A repayment schedule is a promise. Servicing is what actually happened.
A loan servicing system built around one approved loan — the schedule it generates, what each instalment is due, what was actually received, what stays outstanding, and the review that has to happen before an account can close.
Repayment fileNorthstar Tools Pvt LtdLN-2048
- Product
- Business term loan
- Repayment
- Monthly
- Term
- 12 instalments
- Settled
- 3 of 12
- Account
- Active
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
Instalment 04Due 15 SepPart received
- Due
- ₹50,000
- Received
- ₹30,000
- Outstanding
- ₹20,000
Thirty thousand of the fifty thousand is recorded against instalment four. The instalment is not settled, and the outstanding twenty thousand is derived rather than declared.
ILLUSTRATIVE INTERFACE · SAMPLE DATA
Approved, then serviced
Approval creates a loan. Servicing operates it.
Whatever decided this loan — an origination system, a credit committee, a spreadsheet and a signature — that decision is finished before this record begins. What arrives here is an approved loan and the terms it is authorised to run on.
Before this record · owned upstream
- Application and documents
- Eligibility and credit decision
- Approval and sanctioned terms
Origination, underwriting and the credit decision finish here.
Handed into servicing
- Borrower reference
- Northstar Tools Pvt Ltd
- Approved product
- Business term loan
- Repayment cadence
- Monthly
- Term
- 12 instalments
LN-2048 operates on exactly these terms, and nothing it was not given.
What is the difference between loan management and loan origination?
Loan origination handles the journey towards a decision — application, documents, eligibility, underwriting, approval and the sanctioned terms. Loan management, or loan servicing, operates the loan after that decision: the repayment schedule, what is due, what was received, what is outstanding and how the account eventually closes. Some lenders run both inside one platform and others keep them separate; this Product’s default contract is the servicing half.
Does this system approve loans or assess borrowers?
No. It receives an approved loan and the terms it is authorised to operate. Credit decisions, eligibility, scoring, bureau checks and identity verification sit upstream with the lender and its providers, and recording a borrower reference is not the same thing as verifying an identity.
What is a loan management system?
Software that operates an already-approved loan through its life: it derives the repayment schedule from the approved terms, tracks each instalment’s due state, records payments against it, keeps the outstanding balance, surfaces what is overdue or needs review, holds approved changes to the schedule, and gates closure behind a real review.
Terms into schedule
The schedule is derived, not typed
Twelve monthly instalments come out of the approved terms, each with a due date and a scheduled amount. Change the term and the schedule changes with it — which is exactly what a sheet of pasted rows cannot do.
- Repayment
- Monthly
- Term
- 12 instalments
- First due
- 15 Jun
- Scheduled amount
- ₹50,000
- 0115 Jun₹50,000
- 0215 Jul₹50,000
- 0315 Aug₹50,000
- 0415 Sep₹50,000
- 0515 Oct₹50,000
- 0615 Nov₹50,000
- 0715 Dec₹50,000
- 0815 Jan₹50,000
- 0915 Feb₹50,000
- 1015 Mar₹50,000
- 1115 Apr₹50,000
- 1215 May₹50,000
12 instalments · derived from the approved terms₹6,00,000
Scheduled instalment taken from the approved loan terms.
Does every loan use the same EMI calculation?
No, and this is why EMI is a capability inside loan management rather than the name of the Product. Equated instalments are one common pattern. Reducing-balance structures, flat structures, bullet repayments, moratoriums and genuinely irregular schedules are others, and which applies is a property of the lender’s approved product. The calculation method is configured against that product rather than assumed.
What is the difference between EMI management and loan management?
EMI management is a repayment-schedule capability. Loan management is broader: the account, the schedule, each instalment’s state, payment history, outstanding balance, exceptions, approved changes and closure. The schedule is one part of the record rather than the whole of it.
Can it track instalments and due dates?
That is the base of the record. Each instalment carries its number, due date, scheduled amount, what has been received against it and the state that follows from those — and because the state is derived, it cannot disagree with the payments underneath it.
Due and received
A due date is a schedule state. A payment is an event.
These are two different facts about the same instalment, and a system that keeps them in one field will eventually tell somebody a loan is paid because a date has passed.
LN-2048Instalment 04Due 15 Sep
The outstanding figure is the difference between the two above it. It is never a number anybody types.
Past due
What the record knows, and what the lender’s rules decide
A servicing record can be exact about days, amounts and its own review state. What those facts are worth in regulatory or recovery terms is a different question, decided by rules that belong to the lender.
Derived from the line
- Due
- 15 Sep · ₹50,000
- Received
- ₹30,000
- Outstanding
- ₹20,000
- Days past due
- 12
Operating state · lender-configured thresholds
- CurrentNothing past its due date.
- Past dueA due date has passed with the instalment unresolved.
- Review requiredPast the threshold the lender sets for a person to look.
- Escalated reviewPast the threshold the lender sets for it to go further.
NextReview according to lender policy
Decided by the lender’s approved rules
- Regulatory classification
- Asset classification depends on the lender’s type, jurisdiction, day-end process and current rules. It is configured and scoped where a project requires it, never inferred from a day count.
- Collection and recovery
- Strategy, contact, promises to pay and field activity are a separate operating domain. Servicing tells it what is outstanding.
- Legal action
- A lender decision, with its own process, people and obligations.
- Accounting treatment
- Income recognition and provisioning belong to the books.
What needs a person
- Part payment outstandingLN-2048Twenty thousand still due against instalment four. Needs a decision on follow-up.
- Payment reference needs reviewLN-2051An amount arrived that does not match a scheduled obligation cleanly. Held rather than allocated.
- Schedule change waitingLN-2060An approved change is recorded but not yet effective. The current schedule still governs.
- Closure review pendingLN-2072Obligations resolved, review not done. The account stays open.
Can loan management software handle partial payments?
It has to. A part payment is recorded against the instalment, the outstanding amount becomes the scheduled obligation minus what was accepted, and the instalment stays unsettled until that difference is nil. What a part payment must never do is mark the instalment closed because something arrived.
How is the outstanding amount calculated?
As the scheduled obligation minus the accepted payment amount for that instalment. It is derived on the record rather than stored, so it cannot drift away from the payments it is supposed to describe. How an accepted amount is then allocated between principal, interest and any charges depends on the lender’s configured allocation rules and is defined during scope.
Does the system confirm that money has actually settled?
Only where a payment provider or bank feed tells it so. A payment recorded by a person is a recorded payment; settlement is a separate fact that comes from the system that moved the money. Where that connection is built, the settlement state can come back onto the instalment rather than being assumed.
What does overdue mean in loan management software?
That an instalment is past the due date the schedule gave it and has not been resolved. It is an operating state the servicing record derives from its own data — the due date, what was received, what is outstanding and how many days have passed — and it is what an operations team acts on.
Is overdue the same as NPA?
No. Overdue is an operating observation this record can make. Regulatory classifications such as SMA or NPA depend on the lender’s applicable rules, jurisdiction and day-end process, and are not inferred by the system unless those rules are explicitly configured and scoped in a project. Days past due can trigger an operational review; the classification that may follow is the lender’s to define.
Is this a collections system?
No. Servicing knows what is due, received, outstanding and overdue, and can carry a follow-up state where that is scoped. Collections is a separate operating domain — recovery strategy, promises to pay, field agents, escalation — and it connects to this record rather than living inside it.
Where it sits
One servicing record, between the systems that already exist
This record does not decide the loan and it does not move the money. It owns the long middle — which is where lenders usually find a spreadsheet, because nothing else claimed it.
Before
Origination, credit decision and approval, wherever the lender runs them.
Loan management
Account, schedule, instalment state, payments, outstanding, exceptions, changes, closure.
Alongside and after
Borrower access, payment status, accounting, recovery — each owned where it already lives.
- Loan origination
- Owns the application, the credit decision and the approved terms. It hands a loan over; it does not service it.
- Collections
- Owns recovery once repayment becomes a problem — strategy, promises to pay, field activity, escalation. Servicing tells it what is outstanding.
- Accounting
- Owns the books: income recognition, provisioning, the ledger. Servicing figures are handed over where that connection is scoped.
- Payment provider or bank
- Moves and settles the money. Where connected, its status comes back onto the instalment rather than being assumed.
- CRMCustom CRM
- Owns the relationship and the commercial conversation before an approved loan exists.
- Borrower-facing accessClient portal
- A controlled view of the servicing record, where that is scoped — built on the same pattern as the client portal Product.
- DashboardsDashboards & reporting
- Reads across the record once it exists. Reporting is a view over servicing data, not the place the schedule lives.
Does loan management software connect to accounting or payment systems?
It can, and the direction matters. Servicing figures go out to accounting where that handoff is scoped; payment status comes back in from whatever provider or bank the lender uses. What we confirm first is what each system can expose and accept, because an integration described on a page and an interface that actually exists are different things.
Is loan management the same as a CRM?
No. A CRM owns the relationship and the commercial conversation, including everything before an approved loan exists. Loan management begins at the approved loan and owns what happens to it for the next several years.
Approved changes
A new schedule does not erase the old one
Reschedules, restructures, moratoriums and changed due dates all happen. What must not happen is a past due quietly becoming a different number because somebody edited the plan.
- V1Original terms12 instalments · ₹50,000Kept as history
- V2Current terms14 instalments · ₹42,000In force
The earlier version stays readable. What it was, what replaced it, and from when.
Operations view
- Full schedule and every instalment state
- Payments and references recorded against the account
- Outstanding, overdue and what needs review
- Approved changes and schedule history
- Closure gate and its blockers
Borrower view, where scoped
- Next instalment and what it is for
- The repayment schedule
- Payments recorded on the account
- Selected documents
- Requests raised and their state
Not every internal field belongs in front of a borrower. What appears there is a scoping decision, made once, deliberately.
Can a repayment schedule be changed?
Where the lender approves a change — a reschedule, a restructure, a moratorium, a different due date — yes. The original schedule is kept as history, the approved change records what it is and when it takes effect, and the new version governs from that date forward. Past instalments keep the terms they were operated under. Whether a change is permitted at all is the lender’s decision, not the software’s.
Can prepayments or foreclosure be handled?
As a workflow, where the lender’s rules define it: a request, a payoff figure calculated or reviewed against those approved rules, the payment evidence, and then closure review. What the system does not do by default is invent a foreclosure charge, a prepayment penalty or an interest rebate — those are pricing decisions that belong to the lender’s product.
Can borrowers see their own repayment schedule?
Where a borrower-facing view is scoped, it can show the next due instalment, the schedule, payments recorded against the account, selected documents and a way to raise a request. It is a controlled view of the servicing record — not a banking platform, not a payment account and not a legal statement of account.
Closure
The last date passing does not close a loan
Twelve of twelve scheduled and every obligation resolved is necessary and not sufficient. An account closes when somebody with the authority to close it has looked.
LN-204812 of 12 obligations resolvedLast due 15 May
Time ended
- Obligations
- One instalment part received
- Adjustments
- Adjustment open
- Closure review
- Not done
Account open
Review completed
- Obligations
- Every scheduled and adjusted obligation resolved.
- Adjustments
- No adjustment left open against the account.
- Closure review
- Completed by whoever the lender authorises.
Closed on review
What closure then triggers — a no-objection certificate, releasing a charge or collateral, updating a bureau, a regulatory filing — depends on the lender’s obligations and the systems that own those steps. This record can mark the account closed and hand off; it does not issue any of them by itself.
When can a loan account actually be closed?
When every obligation on the account is resolved, nothing is left open against it, and the closure review the lender requires has been completed. The final due date passing is not a closure event — it only means the schedule ran out.
Coming off spreadsheets and legacy software
A migrated balance is worth nothing until it reconciles
Loan books move as numbers, and numbers arrive looking confident. The work is proving that a rebuilt schedule and a rebuilt outstanding agree with what the lender has actually been operating.
What exists now
The loan sheet, the repayment sheet, exports from a legacy system, payment records, and whatever changes were agreed by email.
Sample check
A representative set of accounts — clean ones, part-paid ones, rescheduled ones, closed ones.
Map the record
Borrower, approved terms, schedule, payments and current state identified in the current data before anything is rebuilt.
Rebuild the schedule
Schedules derived from the approved terms rather than copied, so they can be regenerated and checked.
Reconcile against history
Rebuilt schedules and outstanding balances compared with what the lender has actually been operating. Differences are examined, not averaged away.
Load and verify
Accounts loaded, states verified, and the ones that did not reconcile listed rather than quietly accepted.
Where a rebuilt balance and a legacy balance disagree, that difference is the most valuable thing the migration finds — usually an adjustment nobody recorded.
Can old loan data migrate from Excel or a legacy system?
Accounts, schedules, payment history and current balances can be mapped and loaded, and the schedules can be rebuilt from approved terms so they are reproducible. What we check first is what the current sources can actually export, then reconcile the rebuilt state against what has really been operated — because a balance that does not reconcile is a problem to find before go-live, not after.
What can it connect to?
Upstream, whatever holds the approved loan. Downstream, whatever needs the servicing outcome — a borrower-facing view, a payment provider that returns status, an accounting process that receives the figures. We confirm what each system can expose and accept before defining a connection, rather than listing integrations as features.
What it meets · what changes size
What is in every build, and what a project decides
The servicing lifecycle is the same everywhere. Lending products, allocation rules and regulatory obligations are not, and those are the parts worth scoping honestly rather than promising as a feature list.
- Servicing account and approved termsIn every build
- The approved loan handed into servicing, with the terms it is authorised to operate on.
- Derived repayment scheduleIn every build
- Instalments generated from those terms, each with a due date, a scheduled amount and a state.
- Payments and outstandingIn every build
- Payments recorded against instalments, with outstanding derived rather than stored.
- Overdue and exceptionsIn every build
- What is past due or cannot be resolved cleanly, surfaced as work with an owner.
- Closure gateIn every build
- Obligations, open adjustments and a completed review — all three, before an account closes.
- Calculation methodScoped per project
- Equated, reducing-balance, flat, bullet, moratorium or irregular, configured against the lender’s approved products.
- Payment allocationScoped per project
- How an accepted amount splits across principal, interest and charges, where the lender’s rules define it.
- Schedule changesScoped per project
- Reschedules, restructures and moratoriums, with the earlier version kept as history.
- Prepayment and foreclosureScoped per project
- Request, approved payoff figure, evidence and closure review, against the lender’s configured rules.
- Borrower-facing accessScoped per project
- What a borrower can see of their own account, and at which point in the cycle.
- Payment and accounting connectionsScoped per project
- Provider status coming back onto the record, and servicing figures handed to the books.
- Regulatory classification and reportingScoped per project
- Defined against the lender’s actual obligations and approved rules, never assumed.
What makes a loan servicing project larger or smaller
- How many lending products really exist
- Two documented products with four informal variants is six products. This is usually the largest driver.
- Whether allocation rules matter
- A scheduled-amount model is straightforward. Splitting every receipt across principal, interest, charges and penalties is a different project.
- How much history has to reconcile
- Validating a handful of live accounts is not the same as reconciling a closed book going back years.
- Who has to see what
- An operations-only system is smaller than one where borrowers log in to their own accounts.
- What the regulator requires of this lender
- This depends on lender type and jurisdiction, and it is established with the lender rather than assumed by us.
Does every lender need custom loan software?
No. Established loan management and lending platforms cover standard products well, arrive with servicing and compliance modules already built, and are usually the faster and cheaper answer — we would say so. Custom earns its place when repayment workflows do not fit those products, when several source, payment and accounting systems have to connect, when servicing states are specific to how this lender actually operates, or when an existing system has gaps that are expensive to work around.
What should a lender digitise first?
The record that everything else argues about: the schedule, what is due, what was received and what is outstanding, per account. Reporting, borrower access and integrations are all easier once that record is reliable, and all unreliable while it is not.
Who owns the system and the data?
You do. The loan and borrower records, the configuration, any code written for you and the accounts it runs on are handed over as agreed in scope.
Automation
The servicing arithmetic stays deterministic
Money owed by a person is the last place for a confident guess. The schedule, the outstanding balance and the states derived from them are explicit logic, and the useful automation sits around that rather than inside it.
Deterministic, in every build
- Generating each period’s instalments from the approved terms.
- Deriving outstanding balances and instalment states from recorded payments.
- Surfacing what is past due or cannot be allocated cleanly.
- Routing exceptions and closure reviews to whoever decides.
Bounded, where it earns its place
- Extracting fields from an uploaded document for a person to confirm.
- Summarising an account’s history in plain language from the values already on the record.
Is there AI in the loan calculation?
No. Schedules, outstanding balances and instalment states are explicit, deterministic logic — the same inputs always produce the same figure, and every figure can be traced to the terms and payments behind it. Where AI helps is around the record: reading a document into a draft for someone to check, or explaining an account in plain language. It does not assess creditworthiness, predict default, set a rate, decide a restructure or approve anything.
Selected work
Records, states and the interfaces people operate them in
A servicing record is a structured account with derived state and an operations interface on top of it. These are three builds where exactly that was the deliverable — a record given a structure, a product surface given real states, and a service given a flow somebody could follow.
Questions
Loan management and servicing, answered
- What is loan servicing software?
- Software that operates a loan after it has been approved and disbursed: it holds the account and its approved terms, derives the repayment schedule, tracks what each instalment is due and what was received, keeps the outstanding balance, surfaces overdue and exceptions, records approved changes, and gates closure behind a review.
- Is loan management software the same as a loan origination system?
- No. An origination system answers whether a loan should be made and on what terms. A loan management or servicing system operates the loan once that decision exists. Lenders often run both, and the handoff between them is where most of the cost and confusion lives — which is why this Product is explicit that it begins at the approved loan.
- Does it collect payments automatically?
- Not by itself. It knows what should be paid and records what was received. Moving or collecting money is done by a payment provider or bank under the lender’s own arrangements, and where such a provider is connected its status can come back onto the instalment.
- Can eNACH, UPI AutoPay or a payment gateway be connected?
- Where the lender has those arrangements and the interfaces are available, a connection can be built and scoped as part of the project. What we do not do is list mandate or payment providers as included features — what is possible depends entirely on the provider, the lender’s setup and what that provider exposes.
- Does it classify NPAs or handle regulatory reporting?
- Not by default. Asset classification and regulatory reporting depend on the lender’s type, jurisdiction, day-end processing and the current rules, and they are built against those actual obligations when a project requires them. An Overdue state in an operations screen is not a regulatory classification.
- Is it a collections system?
- No. It identifies what is outstanding and overdue and can carry a follow-up state where scoped. Recovery strategy, promises to pay, field collection and escalation are a separate operating domain that connects to this record rather than living inside it.
- Does it replace our accounting system?
- No. It holds operational values — scheduled, received, outstanding, and any configured charges. Financial treatment, income recognition, provisioning and the books belong to accounting, and servicing figures can be handed over where that connection is scoped.
- Can borrowers access their loan account?
- Where a borrower-facing view is scoped, they can see the next due instalment, the schedule, payments recorded against the account, selected documents and their own requests. It is a controlled view of the servicing record, not a banking or payment platform.
- What determines the scope of a loan management project?
- How many lending products genuinely exist including the informal variants, whether payments have to be allocated across principal, interest and charges, how much history has to reconcile, who needs to see the account, and what this particular lender’s regulatory obligations require.
Start
Bring one live account and one that went wrong
The fastest way to scope a servicing build is a real account with a real complication in it. Bring the approved terms, the schedule as it stands, the payments recorded against it, and the account nobody enjoys explaining.
- The lending products you actually run, including the informal variants.
- Where the approved loan and its terms come from today.
- How payments reach you and what confirms them.
- What happens when a payment is short, late, or does not match anything.
- Who is allowed to change a schedule, and who signs off a closure.