There is a moment in the lifecycle of every commercial loan where the front office's version of the deal meets the back office's version of the deal. It happens when the loan boards in the servicing system. And more often than anyone in the organization is comfortable admitting, the two versions do not agree.
The repayment schedule that the relationship manager presented to the borrower during credit approval — the one in the term sheet, the one the borrower's treasury team used to model their debt service coverage — does not match the repayment schedule that Loan IQ generates after the loan is booked.
The differences are usually small in isolation: a payment date that shifts because of a weekend, an interest amount that varies by a few dollars because of a different day-count convention, a final payment that does not quite zero out because of rounding treatment in the amortization calculation. But these differences are not rounding errors in the traditional sense. They are the predictable consequence of building repayment schedules in two different systems, using two different calculation engines, at two different points in the deal lifecycle.
And resolving them — explaining them to the borrower, reconciling them internally, documenting the variance for audit — consumes far more operational time than the lending industry has been willing to acknowledge.
The Two-Schedule Problem
The root cause is structural, not procedural. In commercial lending, the repayment schedule is created twice: once during origination and once during servicing. The two schedules are built by different teams, in different systems, at different times, for different purposes.
During deal structuring, the front office builds a projected repayment schedule to show the borrower what their payment stream will look like. This schedule appears in the term sheet, the credit memo, and often in the commitment letter. It is the basis for the borrower's financial planning. It is typically built in Excel or in the bank's loan origination system.
After the deal is approved, closed, and funded, loan operations boards the loan in the servicing platform — typically Loan IQ for commercial and syndicated lending. Loan IQ generates its own repayment schedule based on the booked facility terms, the system's accrual engine, and its date and day-count configurations.
These are two independent calculations. And because they are independent, they diverge.
The divergence is not a mystery. It is an arithmetic certainty. Two systems using different assumptions about day counts, non-business-day rules, rounding, and accrual periods will produce different numbers. The question is not whether the schedules will match. The question is how far apart they will be and how much operational effort the bank is willing to spend closing the gap after the fact.
Where the Differences Come From
The schedule discrepancies between origination and servicing are not random. They follow predictable patterns, and understanding those patterns is the first step toward eliminating them.
Day-Count Conventions
Day-count conventions determine how interest accrues between payment dates. A loan documented as Actual/360 accrues interest based on the actual number of calendar days in each period, divided by 360. A loan on a 30/360 basis assumes each month has 30 days. The difference between these conventions can produce materially different interest amounts on the same principal balance — and the front office Excel model does not always apply the same convention that Loan IQ uses at booking.
This is particularly common with syndicated facilities, where the credit agreement specifies the day-count convention but the origination model may use a simplified calculation. The borrower sees one number in the term sheet; the servicing system produces another.
Non-Business-Day Adjustments
When a scheduled payment date falls on a weekend or bank holiday, the system must decide what to do: move the payment to the next business day, the prior business day, or apply modified following logic. Loan IQ applies non-business-day rules systematically based on the facility configuration. The Excel model in origination usually does not.
A quarterly payment schedule on a five-year term loan has twenty payment dates. If three or four of those dates fall on weekends, the adjusted dates change the accrual period lengths, which changes the interest calculations, which changes the payment amounts. The schedule that the borrower received during deal structuring now has multiple line items that do not match the schedule Loan IQ produces.
Accrual Period Boundaries
Loan IQ uses specific accrual period conventions — configured at the facility level — to determine when interest periods begin and end. These conventions interact with rate basis codes, pricing options, and the system's calendar configuration. The combination of these settings produces precise accrual period boundaries that may not align with the simplified assumptions in the origination model.
For construction loans, this problem is amplified. Draw schedules, conversion dates, and sub-note structures create layered repayment timelines where the stop-draw date on the commitment may be 18 months out, but repayment schedules on sub-notes can extend five years or more. Modeling these structures accurately outside of the servicing system is extremely difficult.
Rounding and Residuals
Amortization schedules involve repeated division and rounding. Over the life of a loan with dozens of payment periods, small rounding differences compound. The Excel model rounds one way; Loan IQ rounds another. The final payment — the one designed to retire the remaining balance — ends up being a slightly different amount. This is cosmetic in some cases, but it creates real confusion for borrowers and real reconciliation work for operations teams.
The Operational Cost of Schedule Mismatches
Schedule mismatches are not just an inconvenience. They generate real operational cost at multiple points in the lending lifecycle.
- Borrower confusion at first payment — The borrower's treasury team set up their debt service payments based on the schedule in the term sheet. When the first invoice from the bank does not match, they call. The relationship manager calls operations. Operations explains the difference. Everyone documents the conversation. This cycle repeats for every new loan where the schedules diverge.
- Manual reconciliation at boarding — When loan operations boards a new deal, they often compare the servicing schedule against the origination schedule as a quality check. When differences appear, they need to determine whether the difference is a legitimate calculation variance or a boarding error. This analysis is manual, time-consuming, and requires a person who understands both the origination model and the servicing system's accrual logic.
- Amendment and restructuring complexity — When a loan is amended or restructured, the repayment schedule changes. The front office builds a new projected schedule for the borrower; operations rebuilds the schedule in Loan IQ. The two-schedule problem repeats, compounding the original discrepancy. For borrowers in workout or forbearance situations, where schedule precision matters most, the mismatch creates the most friction.
- Audit trail gaps — Auditors and examiners expect the bank to be able to demonstrate that the repayment schedule presented to the borrower aligns with what is being serviced in the system. When the two do not match, the bank needs documentation explaining why — and that documentation is often informal, inconsistent, or missing entirely.
- Participant reporting in syndicated deals — In an agency role, the agent bank distributes payment information to participants based on the servicing schedule. If the schedule the borrower received differs from the schedule driving participant distributions, the agent is in the middle of a three-way reconciliation that no one budgeted time for.
Why the Problem Persists
The two-schedule problem persists because the servicing platform's calculation engine has historically been inaccessible before booking. Loan IQ can generate repayment schedules — but only after a loan is booked as an outstanding in the system. Before that, there is no supported way to run the servicing platform's calculation engine against a set of proposed deal terms.
This means the front office has no choice but to build their own schedule. They cannot ask Loan IQ what the schedule would look like for a loan that does not exist yet. They build an approximation using the tools available to them — Excel, the origination system, or a third-party cash flow model — and accept that the servicing schedule will be slightly different.
The bank has two options: invest significant effort after boarding to reconcile and explain the differences, or accept the discrepancy as a known operational limitation and manage it through exception documentation. Most banks choose the latter, not because it is good practice, but because the alternative — building a replica of Loan IQ's calculation engine outside of Loan IQ — is impractical.
The Case for Pre-Booking Schedule Projection
The structural solution to the two-schedule problem is to eliminate the second calculation entirely. Instead of building one schedule in origination and a different schedule in servicing, the bank should be able to generate the servicing-quality schedule before the loan is booked.
Concretely, this means the ability to pass a set of proposed deal terms — principal amount, interest rate, spread, maturity date, payment frequency, amortization structure, accrual conventions — to the servicing platform's calculation engine and receive back the exact repayment schedule that the platform would produce at booking. Not an approximation. Not a model built on different assumptions. The actual schedule, calculated by the actual engine, using the actual rules — just without committing a loan to the database.
With this capability, the schedule in the term sheet and the schedule in the servicing system are guaranteed to match, because they are the same calculation. The front office presents a schedule that was generated by the same engine that will service the loan. The borrower's first payment matches their expectation. Operations has no reconciliation to perform. The audit trail shows a single, consistent schedule from approval through servicing.
The value extends beyond origination. The same projection capability supports amendment processing — showing the borrower what their revised schedule will look like before the amendment is released. It supports cash flow forecasting, where treasury and ALM teams need forward-looking payment projections based on proposed portfolio changes. And it supports participant reporting, where the agent bank can project payment schedules for facilities still in the structuring phase.
What Changes Operationally
When pre-booking schedule projection is available, the operational workflow shifts in several meaningful ways:
- Term sheet accuracy — The repayment schedule in the term sheet is generated by the servicing engine, not approximated in Excel. What the borrower sees is what the bank will service.
- Boarding validation eliminated — The post-boarding reconciliation step disappears. The schedule was already correct before the loan was booked because it was generated by the same engine that services it.
- Amendment turnaround accelerated — Amended schedules can be projected and shared with borrowers before the amendment is released in the servicing system, reducing the back-and-forth that currently extends amendment cycles.
- Cash flow forecasting improved — Treasury and ALM teams can model projected repayment streams using servicing-quality calculations, rather than relying on approximations that may diverge from actual serviced amounts.
- Audit and compliance simplified — A single schedule, generated by a single engine, creates a clean and defensible audit trail from origination through servicing.
Closing the Origination-Servicing Gap
The two-schedule problem is one of those operational realities that most commercial lending teams have accepted as unavoidable. Front office builds a schedule. Back office builds a different one. Someone reconciles. The bank documents the variance. And the cycle repeats on the next deal.
It is not unavoidable. It is a technology gap — specifically, the inability to access the servicing platform's calculation engine before a loan is booked. Banks that close this gap do not just eliminate a reconciliation step. They remove a persistent source of borrower confusion, operational rework, and audit exposure. They align origination and servicing around a single calculation — the one that actually governs how the loan will be serviced.
The schedule the borrower receives should be the schedule the bank services. That should not require two calculations and a reconciliation. It should require one calculation, generated once, used everywhere.