LMS vs LOS: why the difference decides your shortlist

An origination system answers one question: should we lend to this borrower, and on what terms? A management system answers a different one: what is this loan doing now, and what does it owe? Everything else follows from that split.

The two get confused because some vendors sell both under one name, and because a procurement document written by someone outside the lending team often asks for “loan software” without saying which half of the problem it means. The result is a shortlist with two categories of product on it, evaluated against one set of criteria, and a demo where half the room is confused.

Where the boundary sits

The boundary is sanction. Everything up to the lending decision belongs to origination: application capture, document collection, credit bureau checks, scoring, underwriting, approval of the application itself. Everything after belongs to management: disbursement, interest accrual, repayment allocation, restructuring, waivers, certificates, closure, and the audit record of all of it.

A useful test. If the question is about someone who is not yet a borrower, it is origination. If the question is about a loan that exists, it is management. Both terms, and the sixty-two others that come up in a procurement conversation, are defined in the lending glossary.

Where the boundary sits, drawn

What each one is judged on

The evaluation criteria barely overlap, which is the practical reason the distinction matters.

Why buying the wrong one is expensive

An origination system bought to manage a book will disburse and then lose interest. It typically holds a loan as a decision record rather than a running ledger, so accrual, penal interest and allocation either live in a spreadsheet or get bolted on. The book becomes unauditable roughly at the point it becomes large.

A management system bought to originate will run the book correctly and give you nothing for the decision. Applications arrive by email, underwriting happens in a committee and someone types the outcome in. For a lender doing a few hundred sanctions a year that is genuinely fine. For one doing a few hundred a day it is not.

Neither failure shows up in a demo. Both show up in year two.

The handover is the expensive part

Lenders who need both usually discover that the interesting question is not which origination system and which management system, but what passes between them at sanction and who owns the record afterwards.

At minimum the handover carries the borrower, the sanctioned amount, the scheme or product, the interest method and rate, the penal rate, the repayment frequency and the approval evidence. Get the last one wrong and the management system holds a loan it cannot prove was approved, which defeats the point of maker-checker entirely. Ask both vendors to show you that payload, as a document, before you sign either.

The other half of the question is what happens when a sanction changes. A revised amount, a rescheduled repayment, a top-up: does the origination system re-issue and the management system replace, or does the management system hold the amendment as its own event? Both are defensible. Neither works if the two vendors assumed different answers.

Where the line genuinely blurs

Three cases sit awkwardly, and they are worth naming rather than arguing about in a demo.

Restructuring. Changing the terms of a live loan is a credit decision, which sounds like origination, applied to a loan that already exists, which is management. Most lenders take the decision outside the system and record the outcome in the lifecycle as an amendment with its own approval.

Top-up lending. A new sanction against an existing relationship. Origination by nature, but the eligibility usually depends on the repayment history the management system holds.

Collections. Overdue identification is a management responsibility, because it is arithmetic on the ledger. Agent allocation, ageing buckets and promise-to-pay tracking are a separate discipline again, and a vendor listing them next to accrual is worth asking to demonstrate specifically. GoDravix has an overdue report and does not have a collections module, which is set out on the recovery page.

Which one GoDravix is

GoDravix is a loan management system. It picks up at sanction and runs the loan to closure. It does not score applicants, does not pull credit bureau data, and does not make lending decisions.

We say that plainly because the alternative is a demo where everyone works out in the first ten minutes that this is not the product they came for. If origination is what you need, an origination vendor is the right answer and we will say so on the call. The comparison page lists six situations in which we recommend buying from a competitor, and this is one of them.

If you are writing the requirement

Three questions settle it before anyone books a demo.

1. 01
   Does the thing we are buying for exist yet as a loan?

   If no, you are buying origination. If yes, management. If both, you are buying two systems and should say so in the RFP.

2. 02
   Who signs off, and against what?

   A credit committee signing off applications is an origination workflow. A second officer approving a disbursement against an existing sanction is a management workflow, and needs maker-checker rather than scoring.

3. 03
   What has to be defensible three years from now?

   If the answer is the decision, weight origination. If it is the balance, weight the ledger, and ask every vendor whether an entry can be edited after the fact.