Methodology

The scheduled payment comes from the standard amortization formula. The periodic rate comes first: the annual percentage rate divided by 100, then by the number of periods in a year — twelve for a monthly schedule, twenty-six for a bi-weekly one. The payment is the balance multiplied by that rate, divided by one minus the quantity (one plus the rate) raised to the power of minus the number of periods. At a zero rate the formula has no meaning and the payment is the balance divided by the number of periods. Each calculator page renders this typeset with every term named; the words here describe the same expression.

Run backwards, the same identity gives a number of periods from a payment. It is the natural logarithm of one minus the quantity (the rate times the balance, divided by the payment), negated, and divided by the natural logarithm of one plus the rate. That is what runs when you enter a payment instead of a term. It needs the payment to be larger than one period's interest on the opening balance; when it is not, the logarithm's argument is zero or negative, there is no answer to round, and the page enters the state described further down rather than printing a number.

The inverse gives a real number, and the site does not report it as the answer. It appears in prose as an estimate — "about 46.6 months" — while the payment count in the result panel is the row count of the schedule. The two can differ by several months. On $10,000.00 at 12.000% with a payment of $100.01, the formula says 925.64 periods and the schedule takes 934 payments to finish.

Asking for payoff in a chosen number of months is the first formula again, with the target count in place of the term. The result is rounded up to the cent and then run through the schedule, so what the page shows is what those payments actually do rather than what the formula asked for.

Every balance, payment and interest charge is an integer number of cents. No dollar amount is held as a floating-point number, because a fraction of a cent that binary cannot represent exactly turns into a visible error somewhere in the three hundred and sixty additions of a mortgage schedule. The rate is an integer too: thousandths of one percent, so 6.000% is stored as 6000 and 6.125% as 6125. That is the precision rates are quoted to, and it keeps the rate out of floating point as well.

One period's interest is one integer division. Multiply the balance in cents by the rate in thousandths of a percent, add half the denominator, divide by the denominator, and discard the remainder. The denominator is 1,000 × 100 × 12 = 1,200,000 for a monthly period and 1,000 × 100 × 26 = 2,600,000 for a bi-weekly one. Adding half the denominator before dividing is what makes the rounding half-up: half a cent becomes a whole cent, so a balance of $9,999.50 at a 1% monthly rate is charged $100.00 and not $99.99. That rounding happens once per period, on the interest, and nowhere else in the schedule.

The largest product this arithmetic ever forms is about 10 to the fifteenth, at the input ceiling of $100,000,000.00 and 100.000%. That is well inside the range where integers are exact, so each period's interest is exact and no floating-point value ever touches a balance. Floating point appears in one place only — computing the scheduled payment from the formula above — and that value is rounded to a whole cent immediately and never carried in its exact form again.

The payment is rounded up to the next cent, not to the nearest. Precisely, it is the ceiling of the exact payment in cents minus one millionth. The small subtraction is there so that a payment which is already an exact number of cents is not pushed a cent higher by floating-point noise: $12,000.00 over 24 months at 0% is $500.00, not $500.01.

Rounding up exists because rounding to the nearest cent leaves a stray payment at the end. $300,000.00 at 6.500% over 360 months has an exact payment of $1,896.204070. Rounded half-up that is $1,896.20, and 360 of them do not quite clear the loan — the schedule runs on to a 361st payment of $4.74. That is arithmetically correct, and on a page that says thirty years it reads as a bug. Rounded up, the payment is $1,896.21, the loan closes on payment 360, and the last payment is $1,889.51, which is smaller than the others rather than extra to them.

One cent per period is all that rounding up buys. Over 360 periods that is $3.60 of extra principal spread across the life of the loan, against a monthly payment of $1,896.21. It is enough in almost every case and it is not enough in all of them, which is the subject of the next section.

Rounding the payment up makes a 361st payment rare. It does not make it impossible, and this site does not claim otherwise. Two effects work against each other. Rounding up adds at most one cent of extra principal per period, and often far less, because the exact payment can land a hair above a cent boundary and the round-up then has almost nothing to give — the smallest headroom measured was six ten-millionths of a dollar. Meanwhile, rounding each period's interest half-up is biased upward: the expected error is about a quarter of a cent per period rather than zero, so across 233 periods it charges roughly 58 cents of interest that the closed-form payment was never sized to cover. When the second effect is larger than the first, the schedule needs one more payment than the stated term.

This was measured rather than argued. Forty thousand random loans were generated for each of five product shapes, run through the schedule in whole cents, and counted.

The worst case inside those ranges was $206,439.19 at 4.746% over 233 months. The exact payment is $1,357.69999940, so the rounded-up payment of $1,357.70 carries six ten-millionths of a dollar of headroom against 233 periods of upward-biased interest rounding. Payment 233 leaves two cents outstanding, and the schedule runs to a 234th payment of $0.02. Across the entire legal input range the overrun reaches five payments, but only in a corner where the first month's principal is a single cent — $46,885,416.56 at 18.238% over 1,195 months — and no page here defaults anywhere near there.

So roughly one ordinary loan in a hundred ends with a small extra payment, and the page says so when it happens. The result panel names the overrun and shows the residue: this many payments at the scheduled amount leave such-and-such outstanding, so the schedule runs one row further, for that amount. The extra row is in the table like any other row.

The alternative was rejected deliberately. Quietly adding a cent to the scheduled payment would make the term come out right every time, and would mean the payment printed on the page is not the payment the formula on this page produces. A calculator that disagrees with its own stated method is worse than a calculator with one extra row in the table, so the schedule is reported as it runs.

The final payment is whatever clears the balance. Each period the schedule charges interest first, and if the balance plus that interest is at or below the payment due, it pays exactly that and stops. The last payment is therefore the remaining balance plus one final period of interest, and because the scheduled payment was rounded up it is normally a little smaller than the rest. On $20,000.00 at 6.000% over 60 months, 59 payments of $386.66 are followed by one of $386.41.

This is also why total interest is read off the schedule and never from the payment. Multiplying $386.66 by 60 and subtracting $20,000.00 gives $3,199.60. Summing the interest column gives $3,199.35. The 25-cent difference is entirely in that smaller final payment, and the schedule is the one that is right. Every total on this site is a column sum, and every schedule satisfies the identity that the payments add up to the principal plus the interest, to the cent — which is asserted in the test suite for every vector, not just the published ones.

A balance of zero produces an empty schedule rather than a formula result. No payment, no payoff date, no rows, and the page says there is nothing to pay off. It is listed here because an empty schedule is exactly the sort of input that produces a blank table with a total row, or the word Infinity, on a calculator that reasons from the closed form instead of from the rows.

Bi-weekly here is true bi-weekly: a payment every fourteen days, twenty-six times a year. Interest accrues per bi-weekly period at the annual rate divided by twenty-six, using the 2,600,000 denominator, and the payment is half the monthly payment rounded half-up to the cent. The payoff date is the first payment date plus fourteen days times one less than the number of payments, which is a count of days rather than a count of months.

It is not the thirteenth-payment approximation, and the two do not agree. The approximation keeps a monthly schedule and adds a twelfth of the monthly payment each month, on the reasoning that twenty-six half-payments a year come to thirteen whole ones. On $20,000.00 at 6.000% over five years, true bi-weekly is 119 payments of $193.33 ending on 10 April 2031, with $2,877.85 of interest — $321.50 less than the monthly schedule. The thirteenth-payment version adds $32.22 a month, finishes in 55 monthly payments, and saves $290.52. The $30.98 between them is the interest the monthly schedule accrues on money a bi-weekly schedule had already taken off the balance.

Which of the two you actually get depends on the servicer rather than on arithmetic. Some lenders hold each half-payment and post the pair once a month, in which case the thirteenth-payment figure is the one that applies. The mortgage payoff calculator shows both treatments side by side for that reason, and says which is which.

A payment at or below the first period's interest never pays a loan off, and the site prints no date for one. On $10,000.00 at 12.000% the first month's interest is exactly $100.00. A payment of $99.00 leaves the balance one dollar larger every month. A payment of exactly $100.00 leaves it precisely where it started, forever. The page says which of those two it is, names $100.01 as the smallest payment that reduces the balance, and renders no payoff date, no schedule and no savings figure. Detection is not a formula: the schedule stops the first time a period's principal is zero or negative, which also catches the case where a payment covers the interest at first and stops doing so later.

Just above that threshold the closed form stops being trustworthy, which is the other half of the argument for running the schedule. At $100.01 the loan does pay off — 934 payments, $83,377.93 of interest, a final payment of $68.60 — while the inverse formula says 925.64 periods. The gap is rounding: while the balance is at or above $9,999.50 the half-up rule charges exactly $100.00, so the principal reduction is exactly one cent for the first 51 months, and a continuous formula has no way to see that. At $101.00 the same loan takes 464 payments against a formula estimate of 463.82, which is fine. The error is not proportional to anything; it appears when the payment is close to the interest and disappears when it is not.

The schedule stops at 1,200 periods — a hundred years of monthly payments — and reports that instead of continuing. $1,000,000.00 at 12.000% with a payment of $10,000.01 clears each month's interest by a single cent, and the inverse formula puts it at about 1,388 periods. What the page shows is the state: not paid off within 100 years, $858,457.44 still outstanding after 1,200 payments, the partial schedule available to open, and no payoff date. The closed-form estimate is not printed in its place, because a date that far out is not an answer to anything.

The same 1,200 is the term ceiling on the input side. A term outside 1 to 1,200 periods is refused with a message naming the field and the limit, as are a balance outside $0 to $100,000,000.00 and a rate outside 0% to 100.000%. Out-of-range or non-numeric input is refused rather than clamped to the nearest legal value, because a silently clamped input produces a schedule for a loan nobody asked about.

The debt payoff planner runs one month at a time across every debt at once. Charge each open debt its own interest and add it to that debt's balance. Pay every open debt its minimum from a single monthly budget. Send whatever the budget has left to the first open debt in the ordering, and then to the next one if anything is still left over. A debt whose balance reaches zero that month is closed, and the month it closed in is recorded.

The ordering is fixed once, from the starting balances and rates, and does not re-sort as balances fall. The snowball takes the smallest starting balance first, breaking a tie on balance by the higher rate and then by input order. The avalanche takes the highest rate first, breaking a tie on rate by the smaller balance and then by input order. Ties are exact equality — in cents for a balance, in thousandths of a percent for a rate.

The rollover is a consequence of that loop, not a rule inside it. A closed debt is paid no minimum, so its minimum stays in the pool and reaches the next target — in the same month it closed, if clearing that target left anything over. On the worked example below, the $1,500 debt is cleared in month 5 by $40.00 of its own minimum and $87.17 of the surplus, and the $222.83 of surplus still unspent goes to the $4,000 debt that same month, taking it to $3,673.09 instead of $3,917.57. Reserving a closed debt's minimum for it, or holding the rollover until the following month, moves every date after it.

A minimum that does not cover its own debt's interest is allowed, and noted per debt. That balance grows until the surplus reaches it, which is a real situation rather than an error. The plan as a whole only stops as unpayable when the total principal paid across all debts in a month is not positive. Separately, if the budget is below the sum of the minimums nothing runs at all: against $290.00 of minimums, a $600.00 budget leaves $310.00 of surplus, while a $250.00 budget is $40.00 short and the page says so and stops.

These six are a subset of the vector suite the engine is tested against, published so that the site can be checked against its own stated method. Each was derived from the formulas above, in integer cents, independently of the code that runs on the pages, and the code is required to reproduce it exactly. Every date assumes a first payment on 1 October 2026. Enter the inputs on the page named and the outputs should be these, to the cent.

The model is a fixed-rate amortizing loan and nothing else. Where a page cannot represent something a visitor may actually have, it says so on the page rather than approximating it and letting the number stand.

The calculation runs in your browser. The schedule, the totals and the dates are computed by JavaScript on the page in front of you. No balance, rate, term, payment or debt label is sent anywhere, because there is nowhere to send it: the site is a set of static files with no server-side component and no API behind it.

Nothing is saved between visits. There are no accounts, no saved plans and no local copy of what you typed. What replaces persistence is the address bar — as inputs change the page rewrites the URL to encode them, so a scenario can be bookmarked or sent to someone and will reopen with the same numbers. That link carries figures, dates and a mode, never a result and never a label; debt names in the planner exist only on your own screen and are not encoded. Analytics receive the page path with the query string stripped, so a shared scenario's numbers do not reach the analytics property either, and the privacy page sets out what is collected and for how long.