Beyond a single early payoff, the Housing panel's Extra principal payments sub-block lets you plan several smaller principal payments across the life of the note, and the panel's readouts compare that entered schedule against the same note financed to term. This topic is the methodology behind both: the two dollar bases, what "funded" actually means, and what each readout is computed from.
One ledger, monthly and nominal
Every figure on this panel, the deterministic schedule and the simulated outcomes alike, comes from ONE amortization: interest at the note's rate divided by twelve, charged each month on that month's opening balance, with a level payment frozen at origination. Nothing here is re-derived by hand, so the panel and the simulation can never disagree about the same note. An extra payment or an early payoff reduces the balance only by what actually reduces it (the month's payment date matters), and a payoff always clears the same quote: the remaining principal plus that month's own unsettled interest, after that month's extras and with that month's own installment skipped rather than charged twice.
Two dollar bases, one assumed rate
Each row's amount is entered in today's dollars (the default, matching the rest of the page) or in payment-year dollars, the actual number that would appear on a statement in the year the payment is made. The field beside the toggle previews the other basis at the plan's assumed inflation rate, so you can see both readings before committing to one. That preview and a zero-volatility run agree exactly; a Historical replay or an inflation-volatility run still realizes its own path, so a payment-year-dollar row can land a little differently there than the preview suggested. The Planned schedule readouts below the sub-block are always stated in statement (nominal) dollars, the opposite convention from the rest of the page, because that is the basis a lender's own amortization table uses and the one a payment-year-dollar row is actually sized in.
What "funded" means, and the D11 assumption
The plan's ordinary mortgage installment is treated as a contract: it is deemed paid ahead of other recurring spending, on every simulated outcome, whatever else that year's budget cannot cover. A shortfall from that assumption is booked against your OTHER spending, not against the mortgage, and the note keeps amortizing on schedule. Extra principal and an early payoff are different: each is funded like any other one-time expense, capped at what the portfolio can actually deliver that month, through the draw order you set. An extra that comes up short pays only what it can, and an outcome that cannot fully fund an entered extra or payoff fails, exactly as it would for an unfunded car purchase or any other planned lump sum. Arrears are not modeled: there is no concept of a missed installment being carried forward with interest.
Each row's funding priority is read-only next to its amount: it names Roth, tax-deferred or taxable in the order the engine will actually try them, and it is called a priority rather than an order because the engine always falls back to the other accounts once the ones you named run dry. An "Edit funding order" link opens One-time expenses, where every extra-principal payment (and an early payoff) is listed again as its own derived row with the usual draw-order editor, the same treatment the down payment already gets. There is no second copy of the amount and no second place to edit it; only the draw order changes there.
Extra principal and payoff draws from tax-deferred money are uncapped: "Keep income under" (Money flow → Withdrawals) never limits a mortgage paydown, so the panel shows the resulting tax and Medicare/ACA impact rather than promising the ceiling held. A big single draw can also raise your marginal tax rate for that year, your Medicare premium two years later through IRMAA's lookback, and can cost an ACA subsidy in a year the cliff binds; none of that is new mortgage-specific logic, it is the same tax and benefit modeling every dated one-time row already runs through.
Reading a row's placement
A row you enter is never refused just for its date; the sub-block instead names what actually happens to it, and none of these wordings mean the row was deleted or that its full amount is guaranteed to be funded:
- Ignored: dated before the mortgage exists (before the purchase, for a financed home).
- Not simulated: dated before the first calendar year this plan simulates, or after the last one. The plan still shows the row so you can see it, but it is never drawn.
- Not needed: dated after the note is already retired by an earlier payment on the entered schedule. If an earlier row fails to fund in a given simulated outcome, this row's own simulated result can still show the money it would have needed.
- Capped: larger than the balance still owed at that row's month; the panel names the amount that was not needed.
- Counted now: dated a month that has already passed this year. The plan never assumes a payment already happened just because its month went by, so the row is still drawn, immediately.
The two readouts compared
The Planned schedule group is the deterministic ledger, run once at the plan's assumed inflation with every entered row treated as fully funded: when the loan ends with your extras and payoff versus without them, total contract interest each way, and the interest saved between the two. That saved figure is a statement-dollar comparison against financing the SAME note to term with no extras and no early payoff, never a comparison against a different loan. Lifetime contract interest is the note's own total, which can run past this plan's horizon (the note does not know when your projection stops); the figure scoped to this plan's own simulated years is a shorter read of the exact same ledger, not a second source.
The panel names your age at each end date too, so "loan ends August 2037" also reads as an age you can picture. Statement-dollar totals appear beside their own today's-dollar equivalents, converted through the SAME assumed inflation rate as everything else on the page, never a second conversion. On a note with a temporary rate buydown, the total interest is further split into what you actually paid and what the buydown subsidy covered, so a lower payment during the buydown years does not read as a lower total cost of the loan. The split is made month by month: the subsidy pays that month's interest first, and in a month where the subsidy is larger than the interest due, the rest of it goes to that month's principal, which the panel says in the same sentence. That happens whenever the balance has fallen far enough that a month's interest is small, most obviously after a large extra payment, because the subsidy is sized against your original payment. Either way the buydown never changes the principal path, only who wrote the check. A collapsed Remaining balance by year table (statement and today's dollars, one row per year the note is open) is available below the summary for the entered schedule.
The Simulation group is what the engine's own paths actually did with that schedule: the age at which the loan is repaid (median and the 10th-90th range) over the paths that repay it inside your horizon, the share of all paths that repay it at all, and each row's own eligible and fully-funded share (eligible meaning the row's date was actually reached and something was still owed there; fully funded meaning every one of those outcomes covered the full amount, not a fraction of paths on average). A share of "N/A" means no simulated outcome was ever eligible for that row, not that it succeeded 100% of the time.
paydownOnlyShortfallShare answers a narrower question than the failure
rate itself: of every modeled outcome, what share went unfunded on extra
principal ALONE, with every recurring bill, tax, premium and other one-time
expense on that same path fully funded. Read it as a statement about this
entered schedule specifically, not as a claim about a plan with no extras at
all; a paydown that partially drains an account can still leave a later bill
short, and that outcome is not counted here; see Detail's own diagnostics for
the household-wide picture.
In the goal seekers
When your live plan runs a mortgage, Explore's goal seekers score every candidate with these rows as fixed amounts in the basis you entered, and Apply writes back exactly what a row was scored with. The home-purchase optimizer says how the box that carries them works and which rows each kind of result keeps.