Help

Complete reference for the Per%Sense financial calculator.

1. Introduction

What is Per%Sense?

Per%Sense is a tool for economic analysis. Its three worksheets are so flexible and general in their format that almost any financial question you can imagine fits logically and neatly into one of them.

Per%Sense is a completely flexible fill-in-the-blank calculator. Your job is to place the numbers you know in appropriate rows and columns of one of Per%Sense's worksheets. Per%Sense determines when you have provided sufficient information to solve the problem and fills in the answers automatically.

Your input numbers are hard data, displayed on a white background. Per%Sense's computed output is soft data, displayed on a green background. Soft data is erased and recomputed each time you make a change.

What Does Per%Sense Do?

Every economic decision involves the trade-off of costs and benefits over time. Per%Sense reduces complex cash flows at different times to common terms so they can be compared directly.

Applications include:

• Analyzing annuities and other payment structures
• Valuing legal claims for damages
• Financial planning
• Investment analysis and internal rate of return (IRR)
• Comparison of business options — which is the best deal?
• Deciding whether to lease or to purchase

Per%Sense also handles structured loans with advanced features: multiple balloon payments, interest-only periods, fixed principal targets, skipped payments, and combinations of monthly, weekly, and quarterly payments on the same loan.

Quick Start

1. From the welcome screen, click one of the three worksheet buttons.
2. Enter the values you know into the white cells. Leave the unknown(s) blank.
3. Click Calculate (on the Mortgage screen, Calculate Row or Calculate All).
4. Read your answers from the green cells.

To change which value is computed, clear a green cell and fill in the one that was blank before. Per%Sense automatically figures out which values to solve for based on what you've entered.

The Fill-in-the-Blank Concept

Every Per%Sense worksheet works like an equation where you choose which variable to solve for simply by leaving that cell blank. For example, on the Mortgage screen:

• Enter Price, Rate, Years, % Down → Per%Sense computes Monthly Total
• Enter Monthly Total, Rate, Years, Cash Available → Per%Sense computes Price
• Either way, you fill in what you know and read what you don't

This principle extends to all three worksheets. On the Present Value screen, you can compute a present value (enter rate, read value) or compute an IRR (enter value, read rate). The interface adapts to your question.

Hardening Values

Sometimes you want to use a computed (green) value as the starting point for a new calculation. Hardening converts a green output cell into a white input cell, preserving its value so it won't be recalculated.

To harden a cell: double-click it, or select it and press H. The cell background changes from green to white.

This is essential for multi-step problems. For example: first compute a monthly payment, then harden it, change the loan term, and compute a balloon amount.

Opening a Legacy File (.psn)

If you used the original DOS or Windows Per%Sense, you can open your saved workspace files directly — there is no need to re-key the numbers. Click Import .psn File on the welcome screen and choose a .psn file from your computer.

Per%Sense reads the file, decides which worksheet it belongs to (Mortgage, Amortization, or Present Value), switches to that screen, and fills in the saved inputs for you. From there it behaves like any other worksheet: press Calculate to reproduce the results, or edit the numbers and recompute.

• What carries over: the input fields for the detected screen, including Amortization advanced options (additional payments, balloons, and rate/payment adjustments) and Present Value lump-sum and periodic rows.
• What to check: the import overwrites the target worksheet, so save or export anything you want to keep first. Computed (green) values are not imported — they are recomputed when you press Calculate. A few rarely-used legacy fields may not have an exact web equivalent; review the worksheet before relying on the numbers.
• If it doesn't load: if the file isn't recognized as a Per%Sense workspace, Per%Sense reports the problem rather than importing partial data. Confirm the file has a .psn extension and came from a Per%Sense Save.

Files are read entirely in your browser session; nothing is stored on a server.

2. Quick Tour

3. Financial Math in Plain English

New to Per%Sense — or to financial math itself? Start here. This is a plain-language walkthrough of the mathematics Per%Sense uses to value loans, mortgages, cash-flow streams, and life-contingent payments. It builds the ideas up in layers, stays high-level (no formulas you need to memorize), and assumes no prior finance background. You don't need any of it to start clicking around, but a few minutes here makes every screen make sense.

One idea, many screens

Per%Sense looks like several different calculators — a mortgage sizer, a loan amortizer, a present-value worksheet, an actuarial annuity tool. Underneath, it is one idea applied with increasing richness. That idea is the time value of money: a dollar promised in the future is worth less than a dollar in hand today, and an interest rate sets exactly how much less.

Every screen is, at heart, a way of (a) writing down a set of dated money movements, (b) translating them all to a common point in time so they can be compared and added, and (c) solving for whatever the user left unspecified. Two themes recur:

• Everything reduces to discounting and summing. Whether the cash flows are a single balloon, a level mortgage payment, an escalating pension, or a benefit paid only on death, the machinery is the same: move each amount through time with an interest factor, then add the pieces. Where payments are regular, the sum collapses into one compact formula — a geometric series — the engine the whole program turns on.
• The user fills in the blanks. You supply what you know and leave one field blank; Per%Sense figures out which quantity is missing and solves for it. Each screen is a small system of equations in which any single variable can be made the unknown. (See the fill-in-the-blank concept.)

The time value of money

If the interest rate is positive, having a dollar now is strictly better than being promised a dollar later, because today's dollar can be put to work in the meantime. The reverse question — “what is a future dollar worth to me today?” — is called discounting, and it is the operation Per%Sense performs most.

Per%Sense works internally with continuous compounding, where money grows over t years at rate r by the factor e^r·t. Discounting is the inverse: a payment of C due t years from now is worth, today, C · e^−r·t. That factor is always between 0 and 1 for a future payment, so discounting shrinks future money — the further away or the higher the rate, the more it shrinks. The continuous convention is chosen because the algebra stays clean: factors for adjacent periods simply multiply, and payment streams telescope neatly.

People don't think in continuous rates, though — a loan is quoted as, say, “6% compounded monthly.” So Per%Sense keeps two views of every rate and converts at the edges of the calculation: yield from rate is y = n·(e^r/n − 1), and rate from yield is r = n·ln(1 + y/n). You enter and read a familiar quoted yield; the engine computes in the continuous rate. (See True Rate, Loan Rate, and Yield.)

Measuring time: day-count conventions

Interest is rate × time × principal, so before computing anything we must answer a deceptively hard question: how much of a year is the gap between two dates? There is no single right answer — it is a market convention, and using the wrong one produces a subtly wrong number. Per%Sense supports the common conventions:

The differences look small but compound across a long schedule — a 30-year mortgage has 360 interest calculations, and a fraction-of-a-day discrepancy in each moves the final balance by real money. That is why the basis is a first-class input, not a hidden default. (See Basis Days Per Year.) Internally each calendar date becomes a single running day-number, so the gap between two dates is just a subtraction, with sensible month-end behavior.

The annuity: a geometric series at the core

Discounting a single payment is easy. The reason Per%Sense can value a thirty-year stream instantly is that a regular stream collapses into one formula. Take a level payment A at the end of each period for n periods. If the one-period discount factor is v (a little less than 1), the payments are worth A·v, A·v², A·v³, … The total is a geometric series, which has a famous closed form:

PV = A · v · (1 − vⁿ) / (1 − v)

This is the annuity factor — the single most important formula in Per%Sense. You don't add up hundreds of payments; the regularity replaces the whole sum with one expression in v and n. Almost every Per%Sense quantity is a version of it: a loan payment is the number that makes the annuity value of the payments equal the amount borrowed; a mortgage price is an annuity relationship; a pension's worth is an annuity value. Master this one formula and you have the spine of the program.

The degenerate case, handled deliberately. When the rate is exactly zero, v = 1 and the formula becomes 0/0. But the meaning is clear — with no interest, n payments of A are simply worth n·A. Per%Sense detects when the rate is near enough to zero that the general formula would misbehave and substitutes the plain count. This pattern recurs: watch for the handful of inputs where a clean formula degenerates, and supply the correct limiting value by hand.

Amortizing a loan

An amortizing loan is repaid by regular payments, each part interest and part principal, until the balance reaches zero. The forward schedule is one simple recurrence: start a period owing balance B; interest accrues (rate × period length × B); the payment first covers that interest, and the rest reduces principal; the new balance is B_new = B + interest − payment. Iterate and you get the whole schedule. Early on the balance is large, so most of each payment is interest; as the balance falls, more goes to principal.

The level payment inverts the annuity. What payment retires the loan in n periods? The one whose payments, discounted at the loan rate, total the amount borrowed — the annuity relationship read backwards. Because the principal appears linearly, this is clean algebra, no trial and error. The same idea solves instead for the number of payments, or (with more work) the rate.

Real loans depart from the textbook case in well-defined ways, each a precise modification of the basic recurrence rather than an ad-hoc tweak:

Beyond level payments, the cash-flow stream can be sculpted — balloons, prepayments, rate adjustments, a moratorium, a target, and skipped months. Mathematically none of these change the engine: the period-by-period recurrence simply consults, at each date, whatever events apply. The richness lives in the schedule of events, not in new mathematics.

The present value of arbitrary cash flows

The Present Value screen generalizes the loan idea: instead of one borrower and a level payment, value any collection of dated amounts against a chosen valuation date. Two kinds of flow are allowed — single payments (a lump on a date) and periodic streams (a level amount paid so many times a year between two dates). Each lump is discounted by the time-value factor; each stream by the annuity factor; the grand total is their sum, all expressed as of the common as-of date. Same discount-and-sum recipe, over a freely chosen set of flows.

Escalating payments (COLAs). Pensions and settlements often grow over time. A stream can carry a cost-of-living rate, so two forces act on each payment: it grows with escalation and shrinks with discounting. Their net effect is one combined factor, and the stream is again a geometric series — the annuity machinery carries straight over. If a stream grows at exactly the discount rate the two forces cancel (every payment is worth the same today), the ratio becomes 1, and Per%Sense substitutes the plain count rather than dividing by zero — the same care as the zero-rate annuity.

Streams that run forever. A perpetuity has a finite value only if discounting outruns growth; if growth keeps pace or exceeds it, the value is infinite, and Per%Sense says so rather than returning a meaningless number — the honest mathematical answer.

Mortgages and the true cost of borrowing

A mortgage screen is an annuity problem dressed in home-buying vocabulary — price, down payment, points, monthly payment — plus two questions unique to comparing loans. The quantities are tied by simple relationships: the amount financed is price less down payment; the cash needed is down payment plus points; the monthly payment is the annuity payment that amortizes the financed amount, plus a flat tax-and-insurance allowance that is added on but never amortized. Because the relationships are mutually consistent, you specify whichever subset you know and the program rearranges them to fill in the rest.

APR is the true cost as an internal rate of return. The quoted rate isn't the true cost, because the borrower pays points up front and so receives less cash than the face amount. The APR answers: what single rate, applied to the money actually advanced, reproduces the payments the borrower makes? Formally it is the discount rate at which (present value of all payments and any balloon) = (amount financed) × (1 − points). Because points reduce the cash advanced but not the payments, the APR is always at least the note rate — more so on a shorter loan, over which the points are spread thinner. This rate has no closed form, so it is found by the iterative solver. (See APR comparisons.)

The crossover. Low-rate-high-points versus high-rate-low-points: the high-points loan only pays off if you keep it long enough to amortize those points. Per%Sense finds the crossover — the holding period at which the two loans' effective costs are exactly equal — by solving two cost equations simultaneously for a rate and a time.

Life contingencies: paying only if…

The most sophisticated screen values payments that happen only under a condition involving human life — an annuity that continues only while someone is alive, or a benefit paid when someone dies. It is a graceful extension of everything so far. If a payment will be made only if a person is alive on its date, then from today's vantage point it is uncertain, and the right way to value an uncertain payment is its expected present value: the ordinary present value, multiplied by the probability the payment actually happens.

value = (amount) × (discount factor) × (probability the condition holds)

Those probabilities come from a mortality table, which records how many of a large starting population survive to each age. The chance a person now aged x is alive t years later is just the ratio of survivors at age x+t to survivors at age x (the program interpolates smoothly between whole-year entries). Each life-contingent payment is weighted by the survival probability for its date, so the annuity becomes a life annuity — valued payment by payment, since the weight differs at every date.

With two people the condition can be richer — pays while both are alive (joint life), while either is alive (last survivor), or while exactly one survives. Assuming independent lives these combine by elementary probability (both-alive is the product of the two survival probabilities; either-alive is one minus the product of the two death probabilities). A payment on death sums, over each possible year of death, the benefit × the probability of dying that year × the discount factor. In every case the principle is unchanged: discount each possible cash flow, weight it by the probability it occurs, and add. (See Life Contingency.)

How a calculation actually proceeds

Follow one calculation from the moment you press Calculate. Step one: read the screen by counting. Every row has a small number of defining quantities (a lump: its date, amount, and value; a stream: two dates, amount, and value; the screen: a rate and an as-of date). Per%Sense counts, on each row, how many are supplied and how many are blank, and classifies it:

This counting is the mathematical content of “fill in the blanks”: one unknown is one equation in one unknown (solvable); zero is something to evaluate; two or more is ambiguous. Step two: choose a direction — everything specified runs forward; exactly one blank with a target runs backward; two blanks has no unique answer and the program says so. Step three: invert directly, or search. If the unknown enters linearly (a loan amount, a level payment, a single lump's value) it is isolated by algebra in one exact step. If it is tangled — a rate buried inside the discount exponentials, a date that changes both the count of payments and how far each is discounted — no rearrangement frees it, and the program builds an error function and hands it to the iterative solver.

The iterative solver, in brief

When the unknown cannot be isolated, Per%Sense finds it by successive approximation — the same method across every screen. It never works on the unknown directly; it works on an error function g(x): a single number, depending on a guess, that is positive when the guess is too far one way, negative the other, and exactly zero when right. Solving the screen becomes finding the root of g. Two natural choices of g are used: a leftover-balance error (run the whole amortization schedule at the guess and read the balance remaining — zero means the loan retires exactly), and a value-gap error (compute the present value the guess produces and subtract the target). Both are built to move steadily in one direction, guaranteeing a single crossing.

To drive g to zero, Per%Sense uses the secant method — Newton's method with the slope estimated from the two most recent evaluations rather than a derivative (the error functions are simulations, with no tidy slope formula). When the error is smooth this is very fast, the number of correct digits roughly doubling each step. The bare iteration is wrapped in safeguards that make it dependable: a smart first guess near the answer, damping that caps each jump, a “best-so-far” memory, a restart from a fresh seed if it stalls, and an honest non-convergence report if a maximum number of steps is reached. Where the error is not smooth — the amortization leftover jumps when the number of payments flips — the program falls back to bisection, which only ever asks “is the root above or below this midpoint?”, cannot be fooled by a discontinuity, and cannot diverge. The mortgage crossover solves for two unknowns at once by the same idea generalized to a small two-by-two system. And some inversions are genuinely ill-posed — asking for the date of a life-contingent payment from its value, where the survival weight depends on the very date being solved — so the program recognizes them and declines rather than returning a number a confused search happened to stop at.

Rounding, precision, and trust

Financial answers must be reproducible to the cent. Two concerns get deliberate care. Rounding is a definition, not an afterthought: money is carried to the cent, and the tie-breaking rule at exactly half a cent must be fixed and applied uniformly or two correct calculations can disagree by a penny. Per%Sense uses one consistent rule (a tie rounds down, toward zero) at the same points every time. Precision near the edges: several formulas involve tiny differences of nearly-equal numbers (the annuity factor when the rate is near zero, a logarithm of a number near one), exactly where naive computation loses accuracy — so the program substitutes mathematically equivalent short-series expressions there. Together these make the results deterministic and auditable: the same inputs always produce the same figures, and every figure traces to a defined calculation.

Why it all works

Step back and the whole edifice rests on one idea, extended in layers. At the base is the time value of money: a future amount is worth its discounted value today. Add that a regular stream of discounted payments forms a geometric series, and the valuation of any level stream collapses into a single annuity formula. That formula is the engine — a loan's payment is its inversion, a schedule is a one-line recurrence iterated, a mortgage is annuity relationships, a present-value worksheet is annuities and lumps summed against a common date, a life annuity is the same sum weighted by survival. Nothing genuinely new is added as the problems grow richer — only more elaborate cash-flow shapes fed through the same discount-and-sum machinery. On top sits the inverse problem (solve for any one quantity), handled by clean algebra where the unknown is linear and reliable numerical search where it is not, all wrapped in a discipline of precision. That is why Per%Sense gives, for a level loan or an adjustable mortgage with a balloon or a joint-life pension alike, the right answer for the right reason.

Adapted from the Per%Sense Financial Math Explainer (code_docs/Persense_Financial_Math_Explainer_DOS.pdf), derived from the original DOS application.

4. Mortgage Screen

Overview

The Mortgage screen is designed for choosing among different loan options:

• How much house can you afford on your budget?
• Which loan has the lowest APR?
• Should you choose a larger down payment or a larger monthly payment?
• Is it worthwhile to pay more points to obtain a lower base interest rate?
• What is the effect of a balloon payment on your monthly payments?
• How do different loan scenarios compare side by side?

Each row in the grid is a separate, self-contained calculation. You can have multiple rows active for comparison.

The Mortgage Grid

Calculation rules

• Fill in Price or Monthly Total — whichever is blank gets computed.
• Fill in exactly one of: % Down, Cash Required, or Amt Borrowed.
• All other required cells (Points, Years, Loan Rate) must be filled by you.
• The Balloon area is optional. If both Yrs and Amount are filled, the monthly payment adjusts accordingly. If only Yrs is filled and both Price and Monthly Total are known, the Balloon Amount is computed.

Two kinds of balloon

"Balloon" can mean two different things, and this screen handles both. The difference is entirely in what you put in Years — because Years is how long you actually make the regular payment, not the amortization assumption.

• A lump that lowers your monthly (the loan still runs the full term). Keep Years at the full term (e.g. 30), enter a Monthly Total below the full payment, set Balloon Yrs, and leave Balloon Amt blank. Per%Sense sizes the balloon to make up the shortfall. See Example 3. If your Monthly Total is the full amortizing payment, no balloon is needed and the amount solves to about 0.
• A payoff of the balance still owed (the loan ends early). Compute the long-term monthly first and harden it (double-click or H), then set Years to the payoff year and Balloon Yrs to that same year, leaving Balloon Amt blank. The balloon equals the remaining principal at that year. See Example 4.

Common mix-up: for a payoff balloon, you must change Years to the payoff year. Leaving Years at 30 with a full monthly payment makes the balloon solve to ~$0 — the payment already retires the loan, so no balloon is owed.

The same remaining-balance figure is also available on the Amortization worksheet via its "Payoff as of" date, if you'd rather see the full schedule.

The Mortgage screen always uses a 360-day calendar and is not affected by Computational Settings.

Using the Mortgage Screen

1. Click Mortgage Worksheet from the welcome screen.
2. Click on a row to select it (the selected row is highlighted).
3. Enter values into the white cells. Leave one or two cells blank.
4. Click Calculate Row (or Calculate All to compute every row that has data).
5. Computed values appear in green. APR is computed automatically when sufficient data is present.

APR and Loan Comparisons

To compare two mortgages:

1. Enter data for both loans on two separate rows.
2. Click Calculate All so both rows have computed APRs.
3. Click Compare APR.

Per%Sense compares the full-term APRs and reports which loan is better. When the loans differ in points, one loan may be better for short holding periods and the other for long periods. Per%Sense identifies the crossover point.

In general: if you plan to sell the house soon, prefer lower points. If you plan to stay long-term, prefer the lower base rate (even with higher points).

"What-If" Tables

Sometimes it's helpful to see the results of several different financing scenarios:

• What if the down payment is increased?
• How does the monthly payment depend on the loan rate?
• What is the impact of different balloon amounts?

To generate a what-if table:

1. Calculate a starting row first.
2. With that row selected, click What-If Table.
3. Choose the column(s) to vary, the increment, and how many lines to generate.
4. Click Generate. New rows are created with varied values and automatically calculated.

You can vary two columns simultaneously for a combinatorial table. For example, varying both Years and Rate produces (N+1) × (M+1) rows covering all combinations.

Mortgage Examples

5. Amortization Screen

Overview

The Amortization screen is a flexible loan analysis tool. Use it to create amortization schedules or compute payment amounts for complex, structured loans.

An amortization table (or schedule) is a list of loan payments in which each payment is divided into interest and principal parts. Per%Sense amortization tables also include cumulative interest to date and the remaining balance.

Basic Loan Information

Field-Presence Behavior

Per%Sense automatically derives the missing field when you supply enough of the others. The Amortization screen recognizes these combinations:

• Loan Date + Pmts/Yr (no 1st Pmt Date) → 1st Pmt Date is set to Loan Date + 1 period.
• 1st Pmt Date + # Periods → Last Pmt Date is computed.
• 1st Pmt Date + Last Pmt Date → # Periods is computed.
• Amount + Rate + # Periods (Payment blank) → Payment is computed exactly using the annuity formula.
• Amount + Payment + # Periods (Rate blank) → Rate is solved via Newton iteration.
• Rate + Payment + # Periods + 1st Pmt Date (Amount blank) → Loan Amount is solved.

Using the Amortization Screen

1. Enter Amount Borrowed, Loan Date, Rate, 1st Payment Date, # Periods, and Pmts/Year.
2. Leave Payment Amount blank to have it computed — or, instead, leave Amount Borrowed or Rate blank, and Per%Sense back-solves whichever one you omitted (see Examples 1d–1f). Leaving both Amount and Rate blank is the term-derivation shortcut of Example 1c.
3. Click Calculate.
4. The schedule table appears below, with the computed payment shown in the summary bar.

Payoff / Balance

After generating a schedule, enter any date in the Payoff as of field. Per%Sense calculates the remaining loan balance at that date. This is useful for determining how much you'd owe if you sold the house or refinanced.

The figure is a payoff quote, not the running schedule balance. It is the principal still outstanding as of the most recent payment plus the interest accrued from that payment up to the as-of date — and it does not credit the scheduled payment falling on that date, since a payoff retires the whole loan rather than making that installment. Early in a high-rate loan the quote can therefore exceed the original amount borrowed: little principal has amortized yet, so a full period's accrued interest more than offsets the small paydown. (The loan is not growing — you are just seeing near-full principal plus one period of unpaid interest in a single number.)

CSV Export

Click Export CSV to download the full amortization schedule as a comma-separated file for use in Excel or other spreadsheet applications.

Advanced Options

The Advanced Options section (click to expand) supports complex loan structures. Filling in any Advanced field automatically switches Per%Sense into fancy mode, which runs a period-by-period engine that honors all the options below.

Additional Periodic Payments

Recurring extra payments. For example, an extra payment each December to accelerate the loan payoff. Specify start date, frequency, and amount, then bound the series in one of two ways: give a stop date, or give a number of payments — the extra payments end at whichever limit is reached. (Supplying both is allowed; the series ends at whichever comes first.)

Added on top, or in place of, the regular payment? The same computational setting that governs balloons — "Balloon / prepayment includes regular pmt" — also controls these extra payments. With the default (NO) each extra is paid in addition to the regular payment; with YES the amount you enter replaces the regular payment that period (a payment schedule). The same number can mean very different things under the two settings — see Advanced Solver Example E.

Balloon Payments

One-time lump sum payments applied to principal. Some mortgages are structured with lower monthly payments and a balloon that makes up the difference. The computational setting "Balloon / prepayment includes regular pmt" controls whether the regular payment is also due on a balloon date (and, with the same switch, on a prepayment date).

Enter one row per balloon: a Date and an Amount. A balloon can fall on a regular payment date or between payments — off-cycle balloons are applied to principal on their exact date, not folded into the next payment. A balloon may not precede the first regular payment (or, if a moratorium is in force, the first principal-repayment date); see Input Validation. To model a skipped payment rather than an extra one, enter a $0 balloon with the includes-regular-payment setting turned on.

Rate/Payment Adjustments

For adjustable-rate mortgages (ARMs): change the interest rate and/or the payment amount on a specific date during the loan. Enter one row per adjustment with its effective Date, and a new Rate, a new Payment, or both.

• New rate only. Interest accrues at the new rate from that date forward. Unless you also change the payment, the existing payment keeps being charged — which may now over- or under-amortize the remaining balance, absorbed in the final payment.
• New payment only. The rate is unchanged; the payment steps to the new amount (for example, a graduated-payment loan).
• Both. The usual ARM reset: a new rate plus a payment re-solved to amortize the remaining balance over the remaining term.
• Date only (no new rate, no new payment). Per%Sense treats this as re-amortize at the current rate (internally "AO7"): it re-solves the regular payment over the remaining term at the unchanged rate. This is useful when a future balloon, or drift from an earlier adjustment, has left the running payment no longer amortizing the loan cleanly.

Adjustments must fall strictly inside the loan: an adjustment date on or before the Loan Date, on or after the Last Payment Date, or sharing a date with another adjustment is rejected (see Input Validation).

Moratorium

An interest-only deferment at the start of the loan: until the date you specify, each payment covers only the accrued interest and the principal balance does not fall. Enter the date on which normal principal repayment resumes (the first principal-repayment date).

From the loan date until that date the borrower pays interest only; on and after it, payments amortize principal as usual over the remaining term. The moratorium date must be on or after the first regular payment date. A balloon may not be scheduled during the interest-only window — it cannot precede the first principal repayment (see Input Validation). Moratoriums are common in construction loans and seasonal-income loans, where the borrower needs breathing room before full payments begin.

Target Principal Reduction

Force a minimum amount of principal to be retired each period. If the regular payment wouldn't reduce principal by at least the target, Per%Sense raises that period's payment so it does.

Use it to guarantee a loan pays down at a chosen pace regardless of the rate — for instance, "at least $1,000 of principal every month." The target must be reachable: it may not exceed Amount ÷ # Periods (otherwise the loan could never retire its principal in the given term), and you cannot back-solve for the loan Amount while a target is in force, because the two would be mutually under-determined. Both are reported as errors (see Input Validation). When a target and a skip-month fall on the same period, the target wins — the minimum principal reduction still applies, overriding the skip.

Skip Months

Specify calendar months in which no payment is made, using a compact notation: a comma-separated list of month numbers and ranges, where 1=January … 12=December. For example 6-8,12 skips June, July, August, and December every year the loan is active.

Skipped payments make no contribution that period, so interest accrues and is picked up by later payments — lengthening the effective payoff or enlarging the final payment. Skip Months models a seasonal borrower (for example, a business that closes over the summer). Note the interaction above: if a Target Principal Reduction is also set, the target overrides the skip for any period where both apply, matching the original DOS behavior. To suppress a single specific payment instead of a recurring month, use a $0 balloon with the includes-regular-payment setting on.

Input Validation

Per%Sense rejects loan configurations that are internally inconsistent before generating a schedule, so you don't silently get a wrong answer. The Amortization screen surfaces these errors:

A Rate/Payment Adjustment row may now also be a date-only entry (no new Rate, no new Pmt Amount). Per%Sense treats that as AO7 — re-amortize at current rate: it re-solves the regular payment over the remaining term at the unchanged rate. That matters when a future balloon (or drift from a prior adjustment) means the running payment no longer amortizes the loan cleanly.

Pennies and Rounding

Per%Sense amortization schedules are accurate to the penny. Rounding discrepancies that accumulate over the life of the loan are absorbed in the final payment, which may differ slightly from the regular payment amount.

Settings That Affect Amortization

Several Computational Settings affect amortization calculations:

• Basis days per year (360 or 365-day computations)
• 1st interest prepaid at settlement (YES or NO)
• Interest paid in arrears or advance
• Treatment of interest on interest (USA Rule or Actuarial)
• Balloon includes regular payment (YES or NO)
• Rule of 78s (basic mode only)
• Exact method (precise but non-standard)

Amortization Examples

6. Present Value Screen

Overview

The Present Value screen is a very flexible tool for working with the time value of money. Applications include financial planning, structured legal settlements, valuation of legal claims, annuities, pensions, and internal rates of return (IRR).

As with all Per%Sense screens, flexibility comes from choosing which cells to fill in:

• Present value: List payments, fill in date and rate, read the Value.
• IRR: List payments, fill in the Value, leave Rate blank to be computed.
• Future value: Set the as-of date in the future instead of the past.

Present or Future Value: the Concept

The promise of one dollar next year has a certain value today — certainly less than one dollar. If you trust the promise, the present value is the amount you'd need to invest today for it to grow to one dollar by next year.

Conversely, a dollar received in the past has a value of more than one dollar today: its present value is the amount it would have grown into, had it been invested with compound interest.

You can think of present value as a loan: How big a loan can I take out today if I want to pay it back with this cash flow? Or as a bank account: How big must my balance be to make these withdrawals, emptying the account with the last withdrawal?

Future value is simply the bank balance on a future date after scheduled deposits. To adjust present dollars for inflation, put the inflation rate in the Rate field and set the as-of date in the future.

Payment Grids

Single Payments (Lump Sums)

Multiple rows can be entered. Each payment is valued independently. Field-presence dispatch: exactly two of the three columns ({Date, Amount, Value}) must be filled — whichever one is blank is the field Per%Sense solves for.

Periodic Payments

Field-presence dispatch: exactly three of the four columns ({From, Through, Amount, Value}) must be filled — whichever one is blank is the field Per%Sense solves for. Pmts/Yr is always required.

True Rate, Loan Rate, and Yield

Interest rates are quoted differently for loans than for savings. An eight-percent savings account pays slightly more than an eight-percent loan because of compounding within each period.

These are equivalent representations of the same quantity — like pounds and kilograms:

The Rate Type dropdown selects which format you're entering. Bond yields are loan rates for semi-annual compounding.

COLAs (Cost of Living Adjustments)

Annuities, pensions, and structured settlements often provide for increases tied to the cost of living. Use the COLA column for present value computations involving rising (or falling) payments.

COLA values are interpreted as yields (not compounding rates), following convention. A blank COLA column is the same as 0%.

The COLA escalation month setting controls when the adjustment is applied: on the anniversary of the first payment, in a specific month, or continuously with each payment.

IRR (Internal Rate of Return)

IRR is the number you want to know when you ask "How well did my investment do?" It is the true measure of investment performance over time.

IRR is computed on the Present Value screen by entering payments and their value, then leaving the Rate blank. Per%Sense solves for the rate that makes the present value equal the stated amount.

Why not a separate IRR screen? Because the calculations are the same. "What rate makes the present value of these payments equal $100,000?" is precisely an IRR calculation. Conversely, "How much should I bid for this instrument to achieve a 10% IRR?" is a present value calculation.

Variable Rate Mode

The regular Present Value screen uses a single interest rate. The Variable Rate Schedule section (expand it under the grids) allows different rates for different time periods.

Common uses:

• IRS tax interest — rates change by quarter
• Legal damages — statutory rates that vary over time
• Forward-rate analysis — valuing cash flows under a piecewise yield curve

How to use it

Fill in the rate-schedule grid under the Lump Sum and Periodic blocks. Row 1's date cell is fixed (it says "—") because Row 1 is the starting rate — the rate in effect at the beginning of your computation. Rows 2 and 3 each name a date on which a new rate kicks in. Within each row, you can enter the rate as True Rate, Loan Rate, or Yield (use any one column — True Rate takes precedence if you fill more than one). Loan Rate is converted to True Rate assuming monthly compounding.

As soon as any row in the schedule is populated, Per%Sense switches into variable-rate mode for the entire screen: the As-of Rate field above is ignored, and every cash flow is discounted through the schedule.

Worked example

IRS tax interest scenario: $100,000 owed on 01/01/2024, paid 3 years later on 01/01/2027, with rates of 5% in 2024, 7% in 2025, and 10% in 2026.

1. As-of Date = 01/01/2024.
2. One lump sum: Date = 01/01/2027, Amount = 100,000.
3. Rate schedule — Row 1 (starting rate): True Rate = 5.0000. Row 2: Date = 01/01/2025, True Rate = 7.0000. Row 3: Date = 01/01/2026, True Rate = 10.0000.

Per%Sense computes Sum Value ≈ $80,251.88. (Cross-check: the integral of the rate over the 3-year span is 0.05 + 0.07 + 0.10 = 0.22, so PV = $100,000 × e^−0.22.)

Back-solving the amount

Limitations

• Amount can be back-solved; rate and date cannot. Leave one payment's Amount blank and supply the screen's Present Value, and Per%Sense solves that amount through the rate schedule (see the back-solve example above). What variable-rate mode cannot solve is a rate or a date: a rate schedule fixes the rates, and the payment dates stay fully specified. Matches DOS Per%Sense Pro's VR screen: "rates cannot be the target of a computation."
• No IRR. IRR is by definition a single rate; the concept doesn't fit variable-rate mode.
• No SIMPLE interest. DOS exposed a SIMPLE/COMPOUND toggle for the niche legal-damages case where statute mandates non-compounding interest on past losses. This port assumes COMPOUND. Tracked as a follow-up.

Combining with life contingency

The variable-rate path also supports actuarial weighting: set a Life dropdown on any row and provide a life table + DOB in the Life Contingency section as usual. Each payment is then discounted through the rate schedule and weighted by the survival probability at the payment date. POD (Payment on Death) value is likewise integrated through the schedule rather than a single rate.

The complementarity property still holds: under the same VR schedule, Living-PV + Dead-PV = non-contingent-PV. This combination existed in DOS Per%Sense Pro (compiled with both PVLX and ACTU flags); the Windows port shipped without ACTU and lost it. The web port restores it.

Per-Row Validation

Per%Sense rejects payment-row combinations that can't be solved mathematically:

These checks fire during the FirstPass step, before any solver runs. If the screen passes validation, the appropriate forward or backward calculation is dispatched automatically based on which fields you left blank.

Over-specified rows are a warning, not an error

Supplying more than a row needs is not rejected. If a lump-sum row carries all three of Date, Amount, and Value — or a periodic row carries both dates plus Amount and Value — Per%Sense does not stop. It treats the extra Value as redundant, recomputes it from the other fields, and returns a non-fatal warning alongside the normal result (for example, "single payment row 1 is over-specified — the supplied Value is redundant and will be recomputed"). This mirrors DOS Per%Sense, which surfaced the situation as a cancelable "value already determined by data above" prompt rather than a hard error.

Present Value Examples

7. Life Contingency (Actuarial)

Overview

The Life Contingency feature integrates actuarial (mortality) tables with present value calculations. This allows you to compute the present value of payments that are contingent on a person being alive or deceased at the payment date.

This feature was present in the original DOS version of Per%Sense but was never ported to the Windows version. It is essential for:

• Pension valuation — what is a lifetime pension worth today?
• Life annuities — annuity payments that stop at death
• Structured legal settlements — payments contingent on the plaintiff's lifespan
• Wrongful death damages — lost earnings and services over a projected lifetime
• Life insurance analysis — expected payouts weighted by mortality

How It Works

Each lump sum or periodic payment on the Present Value screen has a Life dropdown with seven contingency types. Each one models a real-world product or claim. When a contingency is set, each payment's present value is multiplied by the survival probability — the probability that the contingency condition is met at the payment date, derived from the life table and date of birth.

For two-life contingencies (codes 1, 2, E, B), survival probabilities combine using the independence assumption — this is a simplification, since spouses' mortality is somewhat correlated in practice, but it's the standard convention for pension and structured-settlement work.

What each contingency requires (and how the screen enforces it)

A contingency is only meaningful when the people it refers to are actually set up, so the Present Value screen guides you:

• Two-life options are disabled until Person 2 is configured. Only 1, Only 2, Either, and Both stay greyed out in every row's Life dropdown until Person 2 has both a life table and a date of birth. With only one person they are degenerate: Either would always pay (identical to None), Only 1 would never pay, and Only 2/Both would silently duplicate Dead/Living. If you clear Person 2, any row using a two-life option resets to None.
• Single-life options need Person 1 and the reference date. Living and Dead require Person 1's table + date of birth, and every contingency requires the reference date ("Now"). If a row uses a contingency while these are missing, the calculation is blocked with a message naming exactly what to fill in, the Actuarial section opens, and focus jumps to the first missing field. Set the row's Life column back to None if you don't intend a contingency.

Why "Dead" isn't "without contingency"

The most common point of confusion: people read "Dead" and assume it means "ignore mortality." It doesn't — that's None. Dead means the payment requires the person to be deceased by the payment date, which is the survivability complement of Living. The two satisfy a clean identity:

The Lifetime Pension example below makes this concrete: $253,135 (Living) + $144,628 (Dead) = $397,763 (None), to the dollar. If you set Dead expecting "non-contingent" you'll get the complementary value, not the unconditional one.

Setting Up Life Tables

Expand the Life Contingency (Actuarial) section on the Present Value screen. You'll see:

1. Person 1 — Select a life table (Per%Sense 1988 Male/Female, SSA 2021 Male/Female, or custom) and enter the date of birth.
2. Person 2 (optional) — Required only for two-life contingencies (Only 1, Only 2, Either, Both).
3. Reference Date — The "now" date. Survival probabilities are conditional on being alive at this date.
4. Payment on Death (POD) — Optional lump sum payable at the moment of death. Its expected present value is computed automatically.

Built-in Life Tables

Per%Sense includes two sets of built-in tables. The SSA 2021 Period Life Table from the U.S. Social Security Administration is the default, with separate male and female tables — the standard modern basis for pension and legal calculations in the United States. The Per%Sense 1988 male and female tables are also available: they are the original mortality basis the program shipped with (U.S. Dept. of HHS, 1988), for reproducing the original program's results.

Custom Life Tables

Select "Custom (paste CSV)" and enter mortality data in the format: age,qx (one per line), where qx is the probability of dying within the year at that age. Example:

The Mathematics

For a lump sum payment of amount A at date t, the life-contingent present value is:

where P(alive at t) is computed from the life table as lx(age_at_t) / lx(age_now).

For periodic payments, each individual payment is computed separately (exact method) and weighted by its survival probability. This is slower than the formula method but necessary because survival probabilities are not constant.

For two-life contingencies, the probabilities combine using the independence assumption:

• Both Living = P1 × P2
• Either Living = 1 - (1-P1)(1-P2)
• Only 1 Living = P1 × (1-P2)

Key Property: Complementarity

For any payment, the Living and Dead contingent values sum to the non-contingent value. This is a useful sanity check: if a $100,000 payment at date T has a Living value of $65,000 and a Dead value of $35,000, the non-contingent value should be $100,000 (before discounting).

8. Computational Settings

Click Settings in the header bar to open the Computational Settings panel. These settings affect how calculations are performed across worksheets. The Mortgage screen always uses 360-day and is not affected by most settings.

Year to Divide Century (obsolete)

Originally, Per%Sense accepted two-digit years (MM/DD/YY) and used this setting to decide whether "57" meant 1957 or 2057. That convention was practical in 1995 but causes silent misparses today — e.g. a Through-date of 5/15/57 on a 30-year horizon gets interpreted as 1957 instead of 2057, producing an "out of order" error or worse, a wrong answer that happens to validate. To remove this trap, every date field now requires a 4-digit year (MM/DD/YYYY). The setting is left in the panel for layout continuity but is disabled and has no effect on parsing.

Default Payments Per Year

By convention, loan rates and savings rates are quoted differently. The conversion between them depends on the number of payments per year. This setting resolves ambiguity when a rate appears without an explicit payments-per-year on the same row.

Options: 1, 2, 3, 4, 6, 12 (default), 24, 26, 52.

COLA Escalation Month

Controls when cost-of-living adjustments are applied to periodic payments:

• Anniversary: Payments increase once a year on the anniversary of the first payment date.
• Specific month (1-12): Payments increase every year in that month (e.g., every June).
• Continuous: Adjustments applied proportionally with each payment (e.g., ~1/4% per month for a 3% annual COLA).

Treatment of Interest on Interest

Applies only to negative amortization — when a payment is less than the accrued interest.

• Actuarial (default): The shortfall (accrued interest minus payment) is added to the outstanding principal balance. Interest then compounds on the larger balance.
• USA Rule: No interest on interest. The shortfall is tracked separately. Two balances are maintained: one that accrues interest (principal) and one that does not (unpaid interest). Payments are applied first against the interest balance, then against principal.

Basis Days Per Year

• 360 (default): All months are treated as 30 days. Standard for loans and bonds. The rules for computing days between dates at month-end are complex but well-defined.
• 365: Actual calendar days divided by 365 or 366. Standard for savings accounts and weekly/biweekly loans. Most "365-day loans" actually use 365-day only for the odd first/last periods, with regular months as 1/12 year.
• 365/360: Actual calendar days divided by 360. A non-standard hybrid used by some banks that slightly overstates interest. APRs are always reported as 365-day when this is selected. Not recommended except for reproducing a specific bank's calculations.

Combining Basis=365 with Exact Method=YES produces true 365-day calculations where each month's interest varies by actual number of days. This is mathematically correct but non-standard — the results look unfamiliar because interest and principal portions vary from month to month.

First Interest Prepaid at Settlement

When a loan closes mid-month with payments due on the 1st:

• YES (default): Interest for the partial month is prepaid at settlement from loan proceeds. The first regular payment covers the next full month.
• NO: The regular payment amount is adjusted slightly to spread the partial month's interest over the loan's life.

Only matters when time between loan date and first payment exceeds one period.

Interest Paid in Advance or Arrears

• Arrears (default): Each payment includes interest for the period just ended. This is the common arrangement.
• Advance: Each payment includes interest for the period to come. Much less common.

Stated Balloon Includes Regular Payment

If a $5,000 balloon is specified on a date when the regular payment is $1,000:

• NO (default): Total payment = $6,000 (balloon is in addition to the regular payment).
• YES: Total payment = $5,000 (balloon replaces the regular payment).

To model skipped payments: enter a balloon of $0 with this set to YES. To model "13th payments" (one extra payment per year): enter a balloon in the regular amount with this set to NO.

Exact Method

• NO (default): Uses a computational shortcut assuming equally-spaced payments. Standard practice for all loan calculations.
• YES: Computes every individual payment separately, accounting for the actual number of days in each month. More precise but slower and produces non-standard results.

The difference is generally a few dollars per $10,000 or a few hundredths of a basis point. Tables generated from the Present Value screen always list individual payments (equivalent to Exact), so the table total may differ slightly from the screen total unless Exact Mode is on.

Rule of 78s

An accounting method that front-loads interest allocation, favoring the lender on early repayment. Payment amounts are not affected — only the split between interest and principal in the schedule.

Available only with basic (non-advanced) amortization. Automatically disabled when Advanced Options are active, because there is no standard for Rule of 78 with balloon payments or rate changes.