Amortization Precision Troubleshooting: The Failure Modes That Break Lease Schedules

A lease amortization engine is one of the few pieces of accounting software that is graded pass or fail to the cent. An auditor does not re-perform the calculation approximately; under ASC 842 and IFRS 16 they take the same payments, the same locked rate, and the same day-count basis, re-derive the schedule, and expect it to reproduce the published opening liability, every interest figure, and a terminal balance of exactly zero. When a schedule fails that re-derivation, the cause is almost never the accounting policy — the effective-interest recursion is four lines of arithmetic. The cause is an implementation defect in how the numbers are represented, how the calendar is measured, or how history is stored. This page is the troubleshooting reference for those defects: the five failure modes that account for nearly every broken lease schedule, framed as an engineering-reliability problem tied back to the standards that mandate re-derivability. It sits inside the broader liability amortization and schedule generation framework and debugs the two calculations that feed it — the present value calculation logic that seeds the opening balance and the interest vs principal splitting algorithms that fill each row.

Standard References: Why Precision Is a Compliance Requirement, Not a Nicety #Link to this section

The demand for penny-exact, reproducible schedules is not a stylistic preference imposed by engineers; it is what the subsequent-measurement provisions of both frameworks require when read alongside the control expectations of a financial audit.

• ASC 842-20-35-3 requires the lessee to increase the lease liability for interest and decrease it for payments made, using the interest method. Because the standard specifies a method rather than a table of pre-computed numbers, the reported figures are only defensible if the method re-runs deterministically. A schedule that cannot be reproduced from its inputs is, in audit terms, unsupported.
• IFRS 16.36 mirrors the requirement: the liability is measured by increasing the carrying amount to reflect interest and reducing it to reflect payments, with the interest producing a constant periodic rate on the remaining balance. "Constant periodic rate" is a mathematical invariant that a float-drifted schedule quietly violates.
• ASC 842-20-35-4 / IFRS 16.40–41 govern remeasurement and reassessment. Both require a revised opening balance struck at the reassessment date; neither permits silently discarding the pre-event schedule. This is the standards basis for treating the schedule store as append-only rather than mutable.

The engineering consequence is that an amortization schedule is not a spreadsheet output but a pure function of (payment_vector, locked_rate, day_count_basis, commencement_date) whose inputs are retained so any figure can be re-derived byte-for-byte during external review. Every failure mode below is a way that purity is broken — either the function is not deterministic (float), its inputs disagree (day-count mismatch, stub period), or its history is not preserved (snapshot gaps), or its terminal invariant is not enforced (non-zero close). The materiality of any residual left behind is judged against the entity's threshold tuning for materiality policy, but "material or not" is a last resort — a correct engine leaves no residual to judge.

Input / Output Specification: Symptom, Root Cause, Fix #Link to this section

Treat this table as the triage index. When a schedule fails validation, match the observed symptom to its root cause and jump to the guard that eliminates it. Every fix below is implemented in the reference engine further down the page.

Formula Block: The Rounding-Drift Bound and the Day-Count Fraction #Link to this section

Two quantities explain why precision defects appear and how to bound them. The first is the accumulated rounding error. If each period's figures are quantized to the cent, every row can introduce an error of at most half a cent, so after $n$ periods the worst-case accumulated drift in the closing balance is bounded by:

$$\left|{\epsilon }_n\right|\le n\cdot \frac{1}{2}\cdot 10^{-2}$$

where ${\epsilon }_n$ is the residual in the terminal balance and $n$ is the number of periods. For a 120-month lease that bound is $0.60$ — small in isolation, fatal to a re-derivation that expects exactly zero. The terminal adjustment exists to drive ${\epsilon }_n$ to zero deterministically rather than hoping it stays small. Crucially, this bound assumes exact decimal arithmetic per period; under binary float, the per-term error is unbounded relative to the cent because most cent values have no exact binary representation, so no clean bound exists at all.

The second quantity is the day-count fraction that both the present value and the interest accrual must share. For a period running from date $d_0$ to date $d_1$ the fraction of a year is:

$$\tau =\frac{\Delta (d_0,d_1)}{B}$$

where $\Delta (d_0,d_1)$ is the day-count numerator — actual calendar days, or the 30/360-adjusted count — and $B$ is the basis denominator (360 or 365). The period accretion factor applied to the opening balance is then $(1+r_a{)}^{\tau }-1$, where $r_a$ is the locked annual rate. The failure mode is not the formula; it is using one $\Delta /B$ convention to seed the liability and a different one to unwind it.

Step-by-Step Python Implementation: A Decimal-Correct Engine With Five Guards #Link to this section

The following module builds a schedule that survives re-derivation. It threads a single day-count basis through both the present value and the accrual, handles a mid-period stub, rejects float at the boundary, keeps remeasurement append-only, and forces the terminal balance to zero. Read it as five guards layered onto the effective-interest recursion.

Step 1 — Pin precision and reject float money. Raise the decimal context well above cent precision so intermediate division never loses cents, and reject float at the engine boundary. A single float that leaks in from an upstream JSON parser is enough to make two runs disagree.

from __future__ import annotations
from dataclasses import dataclass
from datetime import date
from decimal import Decimal, ROUND_HALF_UP, getcontext

getcontext().prec = 34                 # headroom above the cent; no float in the chain
CENT = Decimal("0.01")


def _reject_float(*values: object) -> None:
    """Guard 1 — money and rates must be Decimal, never binary float."""
    for v in values:
        if isinstance(v, float):
            raise TypeError("use Decimal for money and rates, never float")


def q(x: Decimal) -> Decimal:
    """Quantize to the cent with the entity's documented rounding policy."""
    return x.quantize(CENT, rounding=ROUND_HALF_UP)

Step 2 — Share one day-count basis. A single year_fraction function serves both the discounting and the accrual, so the opening liability and the first interest figure can never be struck on different conventions.

def year_fraction(start: date, end: date, basis: str) -> Decimal:
    """Guard 2 — one basis, reused by PV and by interest accrual."""
    if basis == "30_360":
        d1 = min(start.day, 30)
        d2 = 30 if (end.day == 31 and d1 == 30) else end.day
        days = (end.year - start.year) * 360 + (end.month - start.month) * 30 + (d2 - d1)
        return Decimal(days) / Decimal("360")
    denom = Decimal("360") if basis == "ACTUAL_360" else Decimal("365")
    return Decimal((end - start).days) / denom

Step 3 — Seed the opening liability on that basis. The present value uses Decimal ** Decimal for the fractional-period power, so even the discount factors stay in exact decimal arithmetic — no float power call is needed.

@dataclass(frozen=True)
class Lease:
    commencement: date
    payments: tuple[tuple[date, Decimal], ...]   # (due_date, amount) per ASC 842-20-30-5
    annual_rate: Decimal                         # locked at commencement, immutable
    basis: str = "ACTUAL_365"


def opening_liability(lease: Lease) -> Decimal:
    """PV of unpaid payments on the shared basis (ASC 842-20-30-1 / IFRS 16.26)."""
    base = Decimal(1) + lease.annual_rate
    pv = Decimal("0")
    for due, amount in lease.payments:
        tau = year_fraction(lease.commencement, due, lease.basis)
        pv += amount / (base ** tau)             # Decimal ** Decimal, no float power
    return q(pv)

Step 4 — Unwind with a stub-aware accrual and a terminal zero. Each period accrues interest on the opening balance over the actual elapsed fraction from the prior date, so a mid-month first period is handled by construction. The final period absorbs the residual and the closing balance is forced to zero.

def build_schedule(lease: Lease) -> list[dict]:
    _reject_float(lease.annual_rate, *(amount for _, amount in lease.payments))
    base = Decimal(1) + lease.annual_rate
    balance = opening_liability(lease)
    prev, n = lease.commencement, len(lease.payments)
    rows: list[dict] = []
    for t, (due, pay) in enumerate(lease.payments, start=1):
        tau = year_fraction(prev, due, lease.basis)          # Guard 3 — stub uses days
        interest = q(balance * (base ** tau - Decimal(1)))   # accrue on OPENING balance
        if t == n:                                           # Guard 5 — force close to 0
            principal = balance
            interest = q(pay - principal)                    # residual absorbed here
        else:
            principal = q(pay - interest)
        closing = q(balance - principal)
        rows.append({"period": t, "due": due, "opening": q(balance),
                     "interest": interest, "principal": principal, "closing": closing})
        balance, prev = closing, due
    assert rows[-1]["closing"] == Decimal("0.00")            # audit invariant
    return rows

Step 5 — Keep remeasurement append-only. A reassessment or modification never overwrites a posted schedule; it appends a new snapshot keyed by the event date, so the pre-event interest history remains re-derivable.

def remeasure(store: list[dict], revised: Lease, event: str) -> dict:
    """Guard 4 — append a snapshot; never mutate a posted schedule (ASC 842-20-35-4)."""
    snapshot = {"event": event, "as_of": revised.commencement,
                "schedule": build_schedule(revised)}
    store.append(snapshot)                                   # append-only history
    return snapshot

The engine is deterministic end to end: the same Lease always yields the same rows, the terminal assertion is a machine-checkable form of the auditor's re-derivation, and every guard maps back to a row in the taxonomy above. A columnar variant of this same loop, built for portfolio-scale generation, is walked through in automated amortization table generation.

Debugging and Precision Gotchas #Link to this section

When a schedule fails to reconcile, work down this list in order — the cheapest, most common causes are first.

1. A float leaked past the boundary. The symptom is that a schedule reconciles on one machine and drifts by a cent on another, or that a re-run produces a different hash. Trace every money value back to its source: a json.load yields float, a pandas column defaults to float64, and Decimal(0.06) (from a float literal) is already contaminated — only Decimal("0.06") is clean. The _reject_float guard turns this from a silent drift into a loud TypeError at ingestion.
2. The two day-count bases disagree. If the opening liability ties out but the first interest figure is off, the present value and the accrual almost certainly ran on different conventions. Confirm that one year_fraction value flows through both opening_liability and build_schedule; do not let the PV service default to Actual/365 while the schedule service defaults to 30/360.
3. The stub period was accrued as a whole period. A lease commencing on the 15th whose first payment falls on the 1st of next month covers roughly half a period, yet a naive loop charges a full month of interest. Because the closing balance carries forward, that first-row error contaminates every subsequent opening balance. Accrue the first period on year_fraction(commencement, first_due, basis), not on a hard-coded full period.
4. Interest was accrued on the closing balance. Using balance after subtracting principal understates early interest and overstates late interest — an off-by-one-period defect that still closes to zero and so hides from the terminal assert. Guard it with an independent check that total interest equals the sum of the interest column and that period-one interest equals opening times the period-one factor.
5. The terminal residual was left in place. Without the final-period adjustment, accumulated cent rounding leaves a closing balance bounded by $n/2$ cents. The fix is not a larger precision context — it is absorbing the residual into the last principal and asserting the close is Decimal("0.00").
6. Remeasurement overwrote the schedule. If a modified lease loses its pre-event interest expense, the schedule row was mutated in place. Store schedules as append-only snapshots keyed by event date; the prior schedule must remain retrievable for the periods it governed.
7. The rounding mode is inconsistent across services. One service rounding half-up and another half-even will disagree at ties. Pin a single documented rounding policy and apply it in exactly one q helper.
8. Precision context was set too low or locally. A getcontext().prec left at a small value, or reset inside a called library, silently truncates intermediate division. Set it once at module import and keep cent-rounding as the only deliberate loss of precision.

Compliance Checklist — Before You Publish a Schedule #Link to this section

• Every money value entering the engine is a Decimal constructed from a string, and float is rejected at the boundary
• One day-count basis is threaded through both the present value and the interest accrual
• The first period is accrued on its elapsed-day fraction whenever commencement is mid-period
• Interest each period is accrued on the opening carrying amount, not the closing balance
• The final period absorbs the rounding residual and the closing balance asserts to exactly Decimal("0.00")
• Total interest reconciles to the sum of the interest column, and period-one interest ties to opening times the period-one factor
• Remeasurement appends a new schedule snapshot keyed by the event date; no prior schedule is overwritten
• A single documented rounding policy is applied in one place, and the precision context is set once at import
• Inputs and a run hash are retained so the schedule re-derives byte-for-byte on audit

Frequently Asked Questions #Link to this section

Why is a non-zero terminal balance a compliance failure and not just a rounding quirk?

Because the standards define the liability by a method (ASC 842-20-35-3 / IFRS 16.36), the reported numbers are only supported if the method re-runs to the same result — including a liability that fully unwinds. A closing balance of a few cents means either the schedule was never re-derivable or a residual was left unallocated, and an auditor re-performing the calculation will not reproduce the published figures. Absorbing the residual into the final period and asserting a zero close turns the invariant into a machine-checkable control rather than a hope that drift stays small.

Is float ever acceptable inside a lease amortization engine?

Not for money, balances, rates, or discount factors. The reference engine keeps even the fractional-period power in Decimal using Decimal ** Decimal, so no float is needed at all. If a legacy component forces a float math call, confine it to a single expression, cast back to Decimal immediately, and never let a float participate in an accumulating sum. The practical rule is to reject float at the engine boundary so contamination fails loudly instead of drifting silently.

How do I know whether a symptom is a day-count mismatch or a stub-period error?

Check what ties out. A day-count basis mismatch typically shows the opening liability disagreeing with the schedule's implied opening, or the first interest figure being off while the opening liability itself is defensible. A stub-period error shows the opening liability correct but the first period's interest looking like a full period when the lease commenced mid-period, with the discrepancy roughly proportional to the missing days. The dedicated guide on debugging day-count mismatches in lease interest walks the mismatch case end to end.

Why must remeasurement append a snapshot instead of recalculating in place?

Because the pre-event schedule governed real periods that were already posted and disclosed, and those figures must remain re-derivable. ASC 842-20-35-4 and IFRS 16.40–41 strike a revised opening balance at the reassessment date and continue prospectively; they do not restate the history before the event. Overwriting the schedule destroys the interest expense and closing balances that were reported, breaking both the audit trail and any rollforward that reconciles opening to closing liability across the period.

Related #Link to this section

• Fixing floating-point drift in amortization schedules — the first failure mode in depth, with a before-and-after float-versus-Decimal snippet that closes to zero.
• Debugging day-count mismatches in lease interest — the second failure mode in depth, diagnosing a schedule where the opening liability and first interest figure disagree.
• Present value calculation logic — the discounting step that seeds the opening balance these guards protect.
• Calculating lease liability interest using the effective interest method — the per-period recursion the engine unwinds.
• Threshold tuning for materiality — how large a residual may be before it must be reworked rather than absorbed.

Up: Liability Amortization & Schedule Generation