Loan accounting software is the part of a commercial loan servicing system that turns a loan's terms into money: it accrues interest and fees for each period, produces the bills, applies payments, and keeps the record that the general ledger and the regulatory reports draw on. Most banks already run it inside the core loan system, and most evaluations of a replacement or an add-on go the same way: a scripted demonstration on the vendor's data, a scoring matrix, a reference call. None of that answers the only question a buyer actually has, which is whether the thing computes your bills correctly. Botminds' Loan Interest & Fee Calculation is built to be evaluated the other way round, by recalculating bills the bank has already sent and showing where they differ.
This page sets out that test: what it is, what it proves, what the bank has to supply, and what a good result looks like. The sample figures come from a fictional bank inside the solution; the standards referenced are the Federal Reserve's, the OCC's, NIST's and the ARRC's, linked where they appear.
What should loan accounting software do for a commercial loan?
Four things, and they are worth separating because most products do only some of them well. It has to hold the terms: every pricing and fee term of every facility, as the agreement and its amendments state them. It has to compute: interest and fees for each period, splitting the period wherever the balance or the rate changes, under the day count the agreement specifies. It has to produce and deliver: bills, statements, notices and participant distributions, on the right dates. And it has to explain: for any figure on any bill, show what it was made of.
The fourth is the one most systems treat as optional, and it is the one that costs a servicing desk its weeks. A system that computes correctly but cannot explain a figure turns every borrower question into a manual rebuild, and the rebuild happens in a spreadsheet. The OCC's internal control booklet sets the standard that covers all four at once: "Controls over information processing, whether automated or manual, should be adequate to ensure the integrity of management information systems, books, and records." A figure that cannot be explained cannot be shown to have integrity; it can only be asserted.
The test that costs nothing: a closed quarter, rebuilt
Here is the whole evaluation in one sentence. Take a quarter that has already closed, hand over the credit agreements, the transaction history and the bills you actually sent, and ask the system to rebuild every one of those bills from the agreements and the published rate fixings alone — without ever seeing what was billed.
Then count. How many agree? How many differ, and by how much in each direction? For each difference, what term is named as the cause, and can that cause be proved? The bank already knows which of those bills were disputed, which were corrected and which were paid without a murmur, so it has an answer key the vendor does not. Nothing has to be built, no data has to be created, and the result is not a score anyone negotiated.
A scripted demonstration against a replay on your own closed quarter
The vendor demonstration: The vendor’s, prepared for the purpose.
The replay on your files: Yours — agreements, transactions and bills from a quarter that has closed.
The vendor demonstration: The vendor, from cases the product handles.
The replay on your files: You, including the ones that went wrong and the ones nobody questioned.
The vendor demonstration: That the product can do what it was shown doing.
The replay on your files: That the product reproduces bills you are already committed to, or finds a reason it should not.
The vendor demonstration: Little. A scripted failure is usually a configuration note.
The replay on your files: A great deal: either the product is wrong, or your bill was — and both are worth a morning.
The vendor demonstration: The vendor, on the same script.
The replay on your files: Anyone with the files, including your internal audit function, later.
The vendor demonstration: A day of meetings.
The replay on your files: Assembling one quarter of files, which the bank already holds.
NIST's AI Risk Management Framework states the methodological rule behind this, and it is the one to put to any vendor leading with a percentage: an accuracy figure means nothing unless it comes with a clearly defined, realistic test set that represents the conditions the system will actually be used in, and with the method written down. A closed quarter of your own book is, by construction, representative of your conditions of expected use. A vendor's demonstration set is representative of the vendor's.
How do you evaluate loan accounting software?
Run the replay, then judge it on five things in this order: the differences it found, the causes it named, the proofs it produced, the differences it did not find, and what it did when an input was missing. Most evaluations stop at the first and give the product credit for finding something; the fourth is the one that separates a check from a demonstration.
The test itself, step by step, and where a person decides
Agent
RebuildRead the pricing and fee terms from each agreement and its amendments, collect the published fixings for every reset, read the transactions, and compute each accrual period.
Never: uses the bill under test as an input.
Agent
CompareSet the rebuilt bill against the one actually sent, line by line, and flag any difference above the tolerance.
Never: rounds away a difference to make a line agree.
Agent
ExplainTrace the difference to the term whose set-up differs from the agreement — day count, fee base, margin step, fixing date, default rate.
Never: names a cause it has not tested.
Agent
ReplayRe-run the rebuild with the core system’s own set-up for that term, to see whether it reproduces the original bill exactly.
Never: closes a difference the replay cannot reproduce.
A person decides
Judge the resultRead the proved causes against what the bank already knows about that quarter — which bills were disputed, corrected or paid without question.
Proving a cause instead of naming one
Any system can produce a difference. Producing a difference with a plausible label attached is barely harder, and it is where most evaluations are lost, because a plausible label is indistinguishable from a correct one until somebody checks.
The check is replay. If the system says the cause is the day count, then re-running the rebuild with the core system's own day count must reproduce the original bill to the cent. If it does, the cause is proved: that term, and nothing else, accounts for the whole difference. If it reproduces most of the bill but not all of it, there is something else in there, and the stated cause is at best partial. On the sample loan the replay moves the term loan line from 60 days to 62 and the difference falls to $0.00 against the $186,904.10 that was billed — which is what makes the day count the cause rather than a candidate.
Replay: re-running the rebuild with the core system's own set-up
A buyer should ask for the opposite case too. What happens to a difference the system cannot reproduce? The honest behaviour is to leave it open and say so. A product that always has an answer is telling you it will also have an answer when it is wrong, and the first time that matters will be in a letter to a borrower's counsel.
What "accurate" has to mean before it means anything
Accuracy quoted as a single percentage is close to meaningless for a billing check, because the population decides the number. Ninety-eight per cent of bills agreeing sounds excellent; on the sample quarter it was 405 of 412, which left seven wrong bills and $10,766.96 of differences in one run. The figures worth asking for are four, and they are all countable.
Four measures of a billing check, and what each one answers
| The measure | What it counts | Why it matters more than an accuracy percentage |
|---|---|---|
| Coverage | The share of bills recalculated before they are sent, not after a question. | A system that checks disputed bills is a complaints process. One that checks every bill is a control. |
| Differences found, both ways | Bills billed too high and bills billed too low. | A check that only finds overcharges is a customer-protection tool; one that finds both also pays for itself. |
| Causes proved | Differences whose named cause reproduces the original bill exactly. | This is the number that survives being questioned. An unproved cause is a hypothesis. |
| Differences left open | Differences the system could not explain or reproduce. | A product reporting zero of these is either perfect or not telling you, and one of those is much more likely. |
Supervisors' word for the same idea is outcomes analysis: setting a system's results against what actually happened. The model risk guidance the agencies issued on 17 April 2026, SR 26-2, which replaced SR 11-7, keeps outcomes analysis as sound practice for models and for vendor products alike, and expects the people who challenge a result to have enough independence to stay objective (revised guidance, sections on validation and vendor products). Its definition of a model excludes simple arithmetic and deterministic rules, so a billing check may fall outside it; the discipline still applies. A closed quarter supplies the actual outcomes for free, and the replay should be read by someone other than the team that ran the billing. Where the line falls between what an agent may do and what must be deterministic is set out in what an agent may never be asked to calculate.
Replace the core system, or check it? The case for checking
The instinct, having found that the core loan system bills some loans wrong, is to replace it. That is a two-year programme with its own conversion risk, and the conversion is where the terms get mis-set in the first place — which is the argument of the loan terms that get mis-set in a conversion. Checking is a different proposition: it leaves the system of record alone and puts an independent recalculation in front of the send.
Separation is also what makes the check worth anything. If the thing computing the bill and the thing checking it are the same system, they agree by construction. The OCC's commercial loans examination questionnaire asks for the separation directly: whether the people who prepare and post interest records, or review them, are kept apart from the people who issue official checks alone or handle cash. The modern version of the question is whether the recalculation can see what the core system billed. It should not, until after it has produced its own answer.
A checking product also has a different failure mode, and a far gentler one. If it is wrong, it holds a bill that was fine, and a person looks at it. If a system of record is wrong, it sends a bill that was not fine, and a borrower looks at it.
What you bring to the pilot: agreements, fixings, transactions, bills
The reason this test is cheap is that the inputs are files the bank already holds, in whatever form it holds them. Nothing needs to be extracted into a template first — if it did, the extraction would be doing the work the product is supposed to do.
What the bank supplies, what comes back, and what counts as a pass
| What you supply | In what form | What should come back |
|---|---|---|
| Signed credit agreements, notes and every amendment | As they are filed — scans included | Each pricing and fee term read out, with the clause and page it came from, and a flag where two amendments conflict |
| The transaction history for the quarter | The core system’s own extract | Each draw, repayment, amortization and letter of credit on its own line, where it changes the balance |
| The bills you actually sent | Held back until the rebuild is done | A line-by-line comparison, with any difference above the tolerance flagged and its cause named |
| Your servicing procedures and signing limits | As written | Settings that match them — tolerance, hold, rounding, rate sources and who may sign what |
| Nothing else | — | The rate fixings come from the published sources; a missing fixing should stop the calculation, not be estimated |
One quarter of one portfolio is enough to learn almost everything. Pick a portfolio with variety rather than volume — a few floating-rate revolvers with unused-line fees, a term loan or two on a different day count, something with a pricing grid, one loan with a participation, and at least one bill that was disputed. A hundred bills with that spread will teach a buyer more than a thousand of the same shape.
The settings a buyer should insist on owning
Every billing check embeds decisions the agreement does not make, and those decisions are the bank's, not the vendor's. The test is simple: can the bank see each one, change it, and find out who changed it last? On the sample solution the settings are a screen with a version behind each change.
The tolerance, and what a $1.00 threshold holds or releases
The tolerance
the difference above which a bill is held
$1.00 per bill on the sample settings, adjustable from $0.00 to $25.00 in $1.00 steps
The bank, as a written setting
What it held
bills above the threshold
7 of 412 in the sample quarter — six over by $10,354.30 in all, one under by $412.66
The run of 1 October
What it released
bills within the threshold
405 bills, sent at 16:00 as scheduled
The run of 1 October
What raising it would cost
the differences a wider threshold lets through
Nothing, on this run: the smallest difference was $412.66, so $25.00 would have held the same seven — which itself says the run has no tail of cent-level noise
Worth testing on your own quarter
Rounding is the second setting, and the one most often left to the product. Where the agreement is silent, something has to decide whether interest is rounded per accrual period, per bill or per day, and half up or half even. The ARRC's note on Term SOFR is candid that there is no universal answer: "Like LIBOR today, Term SOFR and SOFR Averages are published to five decimal places and dollar amounts can be calculated to two decimal places and, thus, parties may consider using their current rounding practices." Current practices means the bank's, which means the bank has to be able to state them — and a product that cannot show you its rounding rule is applying one anyway.
Settings with a version behind each change
Four more belong to the bank rather than the product. Which rate sources are permitted — published fixings only, on the sample settings, with a missing fixing stopping the calculation rather than being filled in. When the recalculation runs, which on the sample is three hours before the scheduled send, late enough to catch the run and early enough to do something about it. Who may sign a credit, and up to what amount. And who may release a held bill without correcting it, which should require a written reason that a supervisor sees. The fee mechanics those settings govern are worked through in how an unused line fee is actually calculated.
Reading the result: differences, causes, and the ones left open
A good result is not zero differences. On a real book, zero differences means the check is not independent — it has almost certainly been anchored to the bills it was supposed to test. A good result is a small number of differences, every one with a proved cause, and the bank recognising most of them.
One bill as a receipt, with the difference and its cause on the same page
Expect three kinds of finding, and plan what each one means before the pilot starts. There are differences the bank already knew about, which test whether the product finds what it should. There are differences the bank did not know about, which are the point of the exercise and need a restitution answer. And there are differences where the product is wrong — usually because an amendment was missed or a term was read badly — and these are the most informative of the three, because they show how the product behaves when it is mistaken. A product that flags its own uncertainty is worth more than one that never does.
Finally, ask what one hundred per cent coverage is: a design target or a measured result. In the sample solution, recalculating every bill before it is sent is stated as a target, and the run figures — 412 bills in three minutes, seven held — are demo data on sample loans. A buyer's own replay is the only thing that turns either into a measurement, which is the entire argument of this page.
Questions people ask
How do you test a loan calculation engine?
By giving it the inputs and withholding the answer. Supply the credit agreements, the transaction history and the dates, let it compute each accrual period from the agreement and the published fixings, and only then compare its output with the bill you actually sent. Any test where the engine can see the expected figure measures agreement, not accuracy.
What is a good accuracy test for a billing system?
A closed quarter of the bank's own bills, chosen for variety rather than volume, with the bills held back until the rebuild is done. Count the differences in both directions, require each named cause to be proved by reproducing the original bill exactly, and look hard at the differences the system did not find — those are the ones a borrower will find instead.
Should a servicing system replace the core banking system?
Not necessarily, and usually not first. Replacing the system of record is a multi-year programme whose riskiest phase, the conversion, is exactly where pricing terms get mis-set. An independent check in front of the billing run leaves the system of record alone, is far cheaper to prove, and has a gentler failure mode: a wrong check holds a good bill, while a wrong system of record sends a bad one.
What data do you need for a loan servicing pilot?
Signed agreements and every amendment in whatever form they are filed, the transaction history for the period, the bills that were actually sent, and the bank's servicing procedures and signing limits. Rate fixings should come from the published sources rather than from the bank. If a pilot asks you to prepare the terms in a template first, the template is doing the work.
What tolerance should a bank set before holding a bill?
Low enough that it is not doing the deciding. A dollar per bill is a reasonable starting point for commercial loans; the useful exercise is to run your own quarter at several thresholds and see whether the result changes. If widening the tolerance makes the differences disappear, they were rounding noise. If it does not, the threshold was never the issue.
How long does a loan servicing software pilot take?
The replay itself is short — on the sample run, 412 bills were recalculated in about three minutes. The calendar time goes into assembling one quarter of agreements, amendments and transaction history, and then into reading the result with the people who sent those bills. A pilot that takes months is usually one where the inputs were being reshaped rather than read.