Loan Management Software: Schedules, Accrual, Collections

Loan management software runs a loan after it is approved: the repayment schedule, daily interest accrual, fees, how each payment is allocated, arrears and collections. A $10,000 loan at 12% a year over 12 months, for example, has a monthly payment of $888.49, of which $100.00 is interest in month one. Getting that arithmetic exact, every day, for every loan, is the whole job.

If you would rather have it built for you, see how RAITHub would build this below.

This is engineering guidance for lenders, small-business finance teams and microfinance institutions deciding whether to buy a platform or build their own. RAITHub has not shipped a regulated or licensed lending product; its client work includes a fintech dashboard, and the money patterns below come from payment and trade-credit code it has shipped. Licensing and consumer-credit rules are questions for your adviser.

What is the difference between loan origination and loan servicing?

Origination gets a loan approved and funded. Servicing manages it from the first payment to the last. Loan management software usually means servicing, though many platforms sell both.

Stage	What it covers	Core data	Typical failure
Origination	Application, identity and document checks, credit decision, offer, agreement, disbursement	Applicant, application, decision record, signed agreement	A decision nobody can explain later, because the rules and inputs were not stored
Servicing	Schedule, accrual, fees, repayments, allocation, statements, early settlement, restructuring	Loan, schedule, ledger entries, payments	Balances that drift because of floats or recalculated history
Collections	Arrears tracking, reminders, promises to pay, hardship plans, write-off	Delinquency status, contact log, arrangements	Reminders sent after a customer has already paid
Reporting	Portfolio balances, arrears ageing, income, regulator and investor reports	Ledger, snapshots by date	Numbers that do not match the ledger

How do you calculate an amortisation schedule without rounding errors?

Store every amount as integer minor units (cents, pence, poisha), round once per instalment by one written rule, and let the final instalment absorb the remainder so the balance reaches exactly zero.

An amortisation schedule splits a fixed payment into interest and principal for each period. The payment formula needs a power function, so it uses a floating-point number once; every amount stored afterwards is an integer. The rate is held in basis points (1,200 bps is 12%) to keep it exact.

type Instalment = {
  n: number
  payment: number   // minor units, e.g. cents
  interest: number
  principal: number
  balance: number   // balance after this instalment
}

// Monthly amortising loan. Amounts are integer minor units;
// annualRateBps is the annual rate in basis points (1200 = 12%).
export function amortise(
  principalMinor: number,
  annualRateBps: number,
  months: number,
): Instalment[] {
  const r = annualRateBps / 10_000 / 12
  const payment =
    r === 0
      ? Math.ceil(principalMinor / months)
      : Math.round((principalMinor * r) / (1 - Math.pow(1 + r, -months)))

  const rows: Instalment[] = []
  let balance = principalMinor
  for (let n = 1; n <= months && balance > 0; n++) {
    // Integer interest for the period, rounded half up: one rule, one place.
    const interest = Math.round((balance * annualRateBps) / 120_000)
    let principal = payment - interest
    if (n === months || principal > balance) principal = balance
    balance -= principal
    rows.push({ n, payment: principal + interest, interest, principal, balance })
  }
  return rows
}

// amortise(1_000_000, 1200, 12)[0]
// => { n: 1, payment: 88849, interest: 10000, principal: 78849, balance: 921151 }

Three notes for production. First, the rounding rule (half up, half even, always down) is a policy decision; write it down and test it. Second, plain JavaScript numbers are exact integers only up to about 9 quadrillion, so for very large balances multiplied by rates, switch to BigInt or a PostgreSQL NUMERIC column. Third, a schedule is a plan, not a record: store it with a version, and when a loan is restructured, create a new version instead of editing the old one.

The money-type reasoning is covered in payments engineering in practice.

How should interest accrue: monthly or daily?

Most servicing systems accrue interest daily and bill it on the due date. Daily accrual makes early, late and partial payments fair, because interest follows the balance actually outstanding each day.

• Day-count convention. Actual/365, Actual/360 or 30/360 decide how a year's rate turns into a day's interest. Your loan agreement should name one, and the code should use only that one.
• Accrue in a scheduled job. A nightly job posts each day's interest as a ledger entry. It must be idempotent: if it runs twice for the same date, the second run changes nothing. A unique constraint on loan and accrual date enforces that in the database.
• Keep precision, round at posting. Accrue in a fixed-precision decimal and round to minor units only when interest is capitalised or billed, by the same rule each time.
• Back-dated events. A payment recorded today for last Tuesday means re-running accrual from Tuesday. Design for it from the start; it is the most common source of servicing bugs.

In what order should a repayment be allocated?

The common default is fees first, then interest, then principal, oldest instalment first. But the order is a product and legal decision, not an engineering one, and some markets set it by rule.

Allocation order	Effect	Where it is used
Fees, interest, principal (oldest due first)	Clears charges before reducing the balance	A common default in servicing platforms
Interest, principal, fees	Reduces the balance faster; fees wait	Products that want to show principal falling
Principal first for overpayments	An extra payment shortens the loan or lowers later instalments	Where the agreement or consumer rules allow prepayment

Make the order configurable per product, store which rule was applied to each payment, and post the split as ledger entries. When a customer disputes a statement, you can then show exactly where every cent went. An append-only audit log helps here; see audit log design.

How do arrears and collections work in loan software?

Arrears are tracked as days past due on the oldest unpaid instalment, grouped into buckets such as 1–30, 31–60, 61–90 and 90+ days. Each bucket triggers a collections step.

• Status is derived, not typed. A nightly job recomputes days past due from the schedule and payments, so a missed manual update never leaves a loan wrongly current or wrongly late.
• Reminders check the ledger first. Every reminder job re-reads the balance right before sending, so nobody is chased for money they paid an hour ago.
• Arrangements are versions. A promise to pay or a hardship plan creates a new schedule version with its own start date and reason.
• Late fees follow the agreement. Caps and grace periods are product settings, and in many markets they are regulated. Confirm them with your adviser.

What reports does loan management software need?

At minimum: outstanding principal and interest by product, arrears ageing, portfolio at risk, income, disbursements and repayments by period, and a reconciliation of the loan ledger against the bank or payment provider.

Portfolio at risk over 30 days (PAR30), the share of outstanding principal on loans more than 30 days late, is the headline figure in microfinance. Every report should be computable from the ledger for any past date, which is why the ledger stays append-only and schedules are versioned.

Which loan management software can you buy instead?

Several platforms cover origination, servicing and collections. Most quote prices through sales rather than publishing them, so budget time for demos and contract negotiation.

Product	What it covers	Pricing published?
LoanPro	Origination, servicing, collections and payments; instalment loans, credit cards, lines of credit and leases	No; demo and sales quote
TurnKey Lender	Loan origination with a decisioning engine, servicing, and debt-collection software	No pricing on the site when checked; contact sales
Bryt Software	Loan servicing with modular, pick-the-features pricing	Through a pricing calculator and features grid, not fixed tiers
Apache Fineract	Open-source core banking: loan and savings portfolios, configurable products, real-time accounting	Free under the Apache License 2.0; you pay to host, configure and support it

Buy, build or hire: which one fits a lender?

Option	Example and price	Choose this when	Watch out for
Off-the-shelf platform	LoanPro, TurnKey Lender or Bryt; priced through sales (pages cited above)	Your products are standard instalment loans or lines of credit and you want proven servicing quickly	Licence fees that scale with loan count; workflows you cannot change
No-code, template or open source	Bubble web app plans at $59, $209 or $549 a month billed annually (Bubble pricing), or self-hosted Apache Fineract	A pilot with a handful of loans, or a team with Java skills ready to run Fineract	No-code tools struggle with exact money arithmetic and audit trails; Fineract needs real operations capacity
Custom build	Engineering time, plus hosting and payment-provider fees	Your product terms are unusual, servicing logic is your advantage, or you need it inside an existing platform	You own the correctness of every calculation; it needs heavy testing

A hybrid is common: buy or self-host the servicing core, and build the customer portal, origination flow and reporting around it through its API.

What does small-business and microfinance lending need differently?

Small-business lending brings lines of credit, invoice-based advances and payment terms, where the borrower draws and repays repeatedly. That needs a running credit limit checked inside the same database transaction as each draw, so two requests cannot both spend the last of it. Sundor Skin, a B2B wholesale platform RAITHub built, enforces buyer credit limits and payment terms in the database for exactly this reason. It is trade credit inside a commerce platform, not a lending product.

Microfinance adds group loans with joint liability, weekly or fortnightly repayments, field officers collecting in cash or mobile money, and patchy connectivity. A progressive web app that queues collections offline and syncs with idempotency keys suits field work well. Reporting centres on PAR30 and per-officer portfolios. Apache Fineract was built with this kind of institution in mind and is worth evaluating before any custom build.

What about loan management software in South Africa?

South African credit providers are registered and overseen by the National Credit Regulator under the National Credit Act, which also governs fees, interest caps and collections conduct. Those rules shape your product settings, so confirm with a South African credit adviser before you configure them. This is general information, not legal advice. Johannesburg has 5 hours of working-day overlap with RAITHub in Dhaka; development cost context is in app development cost in South Africa.

Why RAITHub for this

• Money arithmetic that holds. Sundor Skin stores every amount as integer poisha, enforces credit limits and payment terms in a 146-table PostgreSQL schema with row-level security, retries on serialisation conflicts and keeps a hash-chained audit log, under 530+ automated tests.
• Payment code in production. TheSkinProof, the founder's own marketplace, runs bKash, Nagad, SSLCommerz and cash on delivery across 217 API endpoints and 750+ tests.
• Fintech client work. RAITHub's 8 client projects include a fintech dashboard.
• QA first. Schedules, accrual and allocation are exactly where named tests pay for themselves; see how RAITHub tests.
• Your data stays yours. We sign NDAs and DPAs and work inside your controls. Production and borrower data stay in your own cloud account; development uses synthetic data.

When you don't need us

• Your loans are standard. If an off-the-shelf servicing platform fits your products, buy it.
• You need a vendor that has shipped a licensed lending platform. RAITHub has not. Hire one that has taken a lender through a regulator's review, and ask to speak to that client.
• You need someone to interpret credit regulation. RAITHub engineers to requirements your adviser sets; it gives no legal advice and holds no licences or certifications.
• You need native mobile apps. RAITHub builds web apps and PWAs only.

How RAITHub would build this

• Ledger and schedule core: integer minor units, versioned schedules, configurable allocation order and an append-only ledger, specified in writing before code.
• Scheduled jobs: idempotent daily accrual, days-past-due recalculation and reminders, each with a database guard against double runs.
• Repayments: one payment provider with verified webhooks, plus reconciliation against settlement reports.
• Operations portal: role-based access for staff, arrangements and hardship plans, arrears views and reports by date.
• Tests: schedule and rounding cases, back-dated payments, double job runs and concurrent draws, running in CI on every change.

Timeline: 6–12 weeks as a backend build through the Backend & API service, depending on products and integrations; a narrow fixed-scope MVP such as a servicing portal over an existing core can take 4–6 weeks.

What you receive: automated tests and CI, handover documentation and runbooks for the scheduled jobs, and full IP ownership under an NDA.

Next step: book the free 15-minute technical audit, then receive a written fixed quote with every assumption stated. Book your lending software audit. What RAITHub does and does not build for fintech is on the FinTech page.

Frequently asked questions

What is loan management software?

Software that services loans after approval: repayment schedules, interest accrual, fees, payment allocation, statements, arrears, collections and reporting. Many platforms also include origination.

How is a loan's monthly payment calculated?

With the annuity formula: principal times the monthly rate, divided by one minus (1 + rate) to the power of minus the number of months. A $10,000 loan at 12% over 12 months gives $888.49 a month.

Should loan amounts be stored as decimals or integers?

Store balances and payments as integer minor units with a currency code, and use a fixed-precision decimal for rates and accrual. Never use floating-point numbers for stored money.

Is it better to buy or build loan servicing software?

Buy if your loan products are standard and a platform fits. Build, or build around a bought core, when your terms are unusual, servicing is your advantage, or it must live inside an existing product.

Can loan software work for microfinance field officers?

Yes. A progressive web app can queue collections offline and sync them with idempotency keys when connectivity returns, which suits group loans and weekly repayments collected in the field.

Has RAITHub built a lending platform?

No. RAITHub has not shipped a regulated or licensed lending product. Its client work includes a fintech dashboard, and it has built trade-credit limits and payment terms into Sundor Skin, a B2B wholesale platform.