Complete reference for the Per%Sense financial calculator.
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.
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:
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.
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.
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:
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.
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.
Behind the scenes, Per%Sense analyzes the combination of data you have entered, determines what quantities can be computed, selects the appropriate algorithms, and routes the answers to the appropriate cells. You have only to read the output.
Each worksheet has a set of related variables connected by financial formulas. When you provide enough variables to determine the rest, Per%Sense solves the system and displays the results. If you change one input, all dependent outputs update.
The same screen can answer many different questions depending on which cells you fill in. Consider the Mortgage screen:
This reversibility applies to all worksheets. On the Present Value screen, entering a rate computes present value; leaving the rate blank computes an IRR.
The Mortgage screen is designed for choosing among different loan options. Each row models a single, self-contained calculation. Fill in most cells and leave one or two blank for Per%Sense to compute.
Key operations:
The Amortization screen creates detailed loan schedules showing every payment split into interest and principal. Enter loan parameters at the top, click Calculate, and the full table appears below.
Advanced options enable complex loan structures: adjustable rates, balloon payments, prepayments, interest-only periods, and more.
The Present Value screen values any combination of cash flows at a single point in time. Applications include financial planning, legal settlements, annuity valuation, pension analysis, and IRR computation.
Enter single payments (lump sums) on the left, periodic payment series on the right, set a rate and as-of date, and the present value of each payment appears in the Value column.
APR (Annual Percentage Rate) is a standard measure of the true cost of borrowing, defined by the Federal Truth In Lending Act. It takes both points and the base interest rate into account.
When no points are charged, the APR equals the quoted loan rate. When points are part of the loan, the APR rises above the base rate because points are an upfront cost spread over the loan's life.
The quoted APR is the full-term APR — the APR that corresponds to holding the loan for its full scheduled duration. If you pay off the loan early, the effective APR is higher because the upfront points cost is spread over fewer years.
From the Amortization screen, click Export CSV to download the full amortization schedule as a comma-separated file. This can be opened in Excel or any spreadsheet application.
The CSV includes columns for payment number, date, payment amount, interest, principal, remaining balance, and cumulative interest to date.
The Mortgage and Present Value screens have their own Export CSV buttons that save the current grid. Any screen can also be printed (browser Print) — the toolbar and navigation are dropped automatically so only the worksheet appears on the page.
A few conveniences speed up data entry:
MM/DD/YYYY slashes are inserted as you go. Fields also auto-advance whenever there is only one way to read what you typed: a month of 2–9 fills to 02/–09/ and jumps to the day; a day of 4–9 fills to 04/–09/ and jumps to the year; and a two-digit year completes to 20XX — unless you start with 19 or 20, in which case it waits for all four digits so you can type any year (e.g. a 1962 date of birth or 2019). For an ambiguous month or day that won't advance on its own (e.g. 1, which could become 1, 10, 11 or 12), just press / to commit it — 1 then / becomes 01/ and moves to the day.02/30, a month above 12, or a missing year), it is outlined in red with a tooltip explaining why, and a calculation won't run until it is corrected.The Mortgage screen is designed for choosing among different loan options:
Each row in the grid is a separate, self-contained calculation. You can have multiple rows active for comparison.
| Column | Description |
|---|---|
| Price | Total purchase price of the property. |
| Points | One-time bank charge at settlement. 1.0 points = 1% of the amount borrowed, paid to the bank at closing. |
| % Down | Down payment as a percentage of the purchase price. This column, Cash Required, and Amount Borrowed are grouped — fill in exactly one of the three. |
| Cash Required | Sum of the down payment plus the value of points. Generally the bulk of money needed at closing (title insurance and other fees are additional). |
| Amt Borrowed | The loan amount, equal to the purchase price minus the down payment. |
| Years | Duration of the mortgage (e.g. 15, 20, or 30 years). |
| Loan Rate | Quoted annual interest rate from the bank. Equals APR only when Points = 0. |
| Mo Tax+Ins | Monthly real estate taxes plus homeowner's insurance (annual amount ÷ 12). Most banks require insurance and often escrow both tax and insurance into your monthly bill. |
| Monthly Total | Total monthly mortgage payment including principal, interest, taxes, and insurance. |
| Balloon Yrs | Number of years from settlement until a balloon payment is due (optional). |
| Balloon Amt | Lump sum balloon payment amount (optional). If only Balloon Yrs is specified, the amount is computed. |
| APR | Computed Annual Percentage Rate. Always an output (green) cell. |
The Mortgage screen always uses a 360-day calendar and is not affected by Computational Settings.
To compare two mortgages:
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).
Sometimes it's helpful to see the results of several different financing scenarios:
To generate a what-if table:
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.
Canadian mortgages differ from American mortgages in the way the rate is quoted. Although payments are made monthly, interest is compounded semi-annually. If you select CAN in the Default Payments Per Year computational setting, rates will be interpreted as Canadian rates.
docs/discrepancies.md §1 for details. The Amortization screen
uses discrete compounding and will produce a slightly different
schedule for the same nominal inputs.
Then press Calculate Row:
Cash Required = $40,000 down payment + $3,200 in points = $43,200. The $1,538.30 monthly total is the principal+interest payment of $1,338.30 plus the $200 tax/insurance.
Then press Calculate Row:
This illustrates the fill-in-the-blank concept: by entering Monthly Total and leaving Price blank, Per%Sense solves the problem in reverse.
Note: the computed cells in the actual program appear with an accent border, green tint, and italic text. To run this example a second time with different inputs, click Clear Row first, or double-click a green cell to harden it as input.
Then press Calculate Row:
A balloon of about $98,372 in 8 years reduces your monthly payments to $1,600. If you round the balloon up to a tidier $100,000, the monthly drops slightly to $1,593.67 (re-run with Balloon Amt = 100,000 and leave Monthly Total blank).
Step 1: Compute the 30-year monthly payment. Type Price = 240,000, % Down = 0, Years = 30, Loan Rate = 8.1. Press Calculate Row.
Step 2: Double-click the computed Monthly Total cell to harden it (converts the green/computed value into a typed input). Then change Years from 30 to 15 and type Balloon Yrs = 15. Both must be filled in — the engine needs Balloon Yrs to know there's a balloon to solve for. Leave Balloon Amt blank. Press Calculate Row again.
This demonstrates the harden feature: you use a computed value as input for a follow-up calculation. The balloon of ~$184,912 in 15 years lets the borrower keep the lower 30-year payment but settle the remaining principal at the halfway point.
Enter data for both mortgages on two separate rows. The price and down payment are irrelevant to this comparison, but Years must be the same on both rows.
Click Calculate All to compute both rows, then click Compare APR:
Rule of thumb: choose lower points if you plan to be in the house less than ~7 years; choose the lower base rate otherwise.
Start with one row: Price=100,000, %Down=0, Years=30, Rate=7.0000. Calculate it (Monthly = $665.30).
With that row selected, click What-If Table. Set Column = Loan Rate, Increment = 0.25, Lines = 8.
Fill in the source row first with everything Calc needs in order to produce a Monthly Total: Price = 100,000, % Down = 0, Years = 30, Loan Rate = 7.0000. (Optionally click Calc — you should see Monthly Total = $665.30 on this row.) The What-If expansion carries every filled-in field of the source row over to each generated row, so if Price or % Down is blank up front the generated rows have no way to compute Monthly Total.
With that row selected, click What-If Table. Set Column 1 = Loan Rate, Increment = 0.25, Lines = 6. Open the second variable section: Column 2 = Years, Increment = -5, Lines = 3.
This generates (6+1) × (3+1) = 28 rows covering all combinations of rate and duration.
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.
| Column | Description |
|---|---|
| Amt Borrowed | The principal amount of the loan. |
| Loan Date | Settlement date / date the loan originates. |
| Rate % | Quoted annual interest rate. |
| 1st Pmt Date | Date of the first regular payment. Optional — if left blank, Per%Sense defaults it to one period after the loan date (e.g. monthly loans get a first payment one month after settlement). |
| # Periods | Total number of payments. Can be left blank if the Last Pmt Date is supplied; Per%Sense derives it. |
| Last Pmt Date | Date of the final regular payment. Computed automatically from First Pmt Date + # Periods, but you can also supply it directly and leave # Periods blank. |
| Pmts/Yr | Payment frequency: 1=annual, 2=semi-annual, 4=quarterly, 12=monthly, 24=semi-monthly, 26=biweekly, 52=weekly. |
| Pmt Amount | Regular payment amount. Leave blank to have Per%Sense compute it from the loan principal, rate, and term. |
| Points | Discount points charged at settlement, entered as a number of points (1 point = 1% of Amt Borrowed). Used only to compute the APR — it does not affect the payment schedule. Leave 0 for no points. |
| APR % | Computed Annual Percentage Rate including the cost of points, reported as an effective annual yield. Computed automatically (output, green cell) whenever Points is non-zero; equals the loan rate when Points is 0. |
| Basis | Day-count basis: 360 (standard), 365 (actual days), or 365/360 (hybrid). |
Per%Sense automatically derives the missing field when you supply enough of the others. The Amortization screen recognizes these combinations:
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.
Click Export CSV to download the full amortization schedule as a comma-separated file for use in Excel or other spreadsheet applications.
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.
Extra payments beyond the regular payment amount. 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.)
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 includes regular payment" controls whether the regular payment is also due on a balloon date.
For adjustable-rate mortgages (ARMs): change the interest rate and/or payment amount on specific dates during the loan.
An interest-only period where payments cover only interest with no principal reduction. Enter the date when principal repayment resumes.
Force a minimum principal reduction each period. If the regular payment doesn't meet the target, Per%Sense adjusts the payment upward.
Specify months when no payment is made, using a compact notation like "6-8,12" (skip June through August and December).
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:
| Error | Trigger |
|---|---|
| "first date must not be after last date" | 1st Pmt Date is later than Last Pmt Date |
| "two rate adjustments on the same day" | Two ARM adjustments scheduled for the same date |
| "rate adjustment cannot precede the loan" | Adjustment date is on or before the Loan Date |
| "rate adjustment cannot fall on or after the last payment" | Adjustment date is on or after the Last Pmt Date |
| "balloon cannot precede the first regular payment" | Balloon date is before the 1st Pmt Date |
| "balloon cannot precede the first principal repayment (moratorium)" | Balloon scheduled before the moratorium ends |
| "principal repayment cannot precede the first regular payment (moratorium)" | Moratorium first-repay date is before the 1st Pmt Date |
| "principal reduction target is too high" | Target principal reduction exceeds Amount ÷ # Periods (i.e. mathematically unreachable) |
| "cannot solve for loan amount with target principal reduction" | Trying to back-solve for the loan amount while a target reduction is in force (over-determined) |
| "Amount Borrowed is blank and could not be solved (…)" | Amount Borrowed left blank for the back-solver, but the screen is missing the Rate, Pmt Amount, term, or first-payment date the solve needs (see Example 1e) |
| "Rate is blank and could not be solved (…)" | Rate left blank for the back-solver, but the screen is missing the Amount, Pmt Amount, or term the solve needs (see Example 1f) |
| "Prepayment row N: <field> is required" | An Additional Periodic Payments row is missing its Start Date, Amount, or Pmts/Yr — the row is named so you can see which one to fix |
| "Balloon row N: <field> is required" | A Balloon row is missing its Date or Amount |
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.
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.
Several Computational Settings affect amortization calculations:
Enter Amount=100,000, Loan Date=02/12/2024, Rate=8.0000, 1st Pmt Date=03/01/2024, Periods=360, Pmts/Yr=12. Leave Payment blank.
Per%Sense computes Payment = $733.76.
The first period is short: the loan closes on 02/12/2024 but the first regular payment isn't until 03/01/2024 (19 days later under the 360-day basis, which uses 30-day months). Pmt #1's interest portion is therefore $422.22 rather than the full $666.67 a standard month would accrue, so a slightly larger share goes to principal in the very first payment. Total interest over the 30-year schedule is $161,499.77.
Enter Amount=100,000, Loan Date=02/12/2024, Rate=8.0000, Periods=360, Pmts/Yr=12. Leave 1st Pmt Date blank.
Per%Sense automatically defaults 1st Pmt Date to one period after the loan date (03/12/2024). The schedule and computed payment match Example 1 except for the small calendar shift on the first period.
Enter 1st Pmt Date=02/01/2024, Last Pmt Date=01/01/2054, Pmts/Yr=12. Leave # Periods, Amount, and Rate blank.
Per%Sense fills in # Periods = 360. This is a term-derivation shortcut: when Amount and Rate are both blank, Per%Sense skips schedule generation entirely and just answers the dates-to-payments question. To get a full schedule alongside the derived term, fill in Amount and Rate as well.
Enter Amount=250,000, Loan Date=01/01/2024, Rate=6.0000, 1st Pmt Date=02/01/2024, Periods=360, Pmts/Yr=12. Leave Pmt Amount blank.
Per%Sense computes Pmt Amount = $1,498.88 using the closed-form annuity formula. This is an exact solve, not just an estimate.
(For a quick sanity check: solving for the loan amount from this payment, rate, and term recovers the original $250,000 within a few cents — see Example 1e.)
Enter Rate=6.0000, Loan Date=01/01/2024, 1st Pmt Date=02/01/2024, Periods=360, Pmts/Yr=12, Pmt Amount=1,498.88. Leave Amount Borrowed blank.
Per%Sense back-solves Amount Borrowed = $250,000.62 — essentially the $250,000 of Example 1d. The 62¢ excess is an artifact of the quoted payment having been rounded to whole cents; an un-rounded payment recovers exactly $250,000. The solved amount appears in the Amount Borrowed cell with the computed-value highlight, and a full schedule is generated alongside it.
Solving for the amount needs Rate, Pmt Amount, # Periods, Pmts/Yr, and a first-payment date. As in Example 1b, the 1st Pmt Date may be left blank — Per%Sense defaults it to one period after the Loan Date before solving.
Enter Amount=250,000, Loan Date=01/01/2024, 1st Pmt Date=02/01/2024, Periods=360, Pmts/Yr=12, Pmt Amount=1,498.88. Leave Rate blank.
Per%Sense back-solves Rate = 6.0000% by Newton iteration on the schedule residual — the rate that makes this payment stream amortize the loan exactly. This is the Amortization-screen counterpart of an IRR question, and the inverse of Examples 1d and 1e.
Solving for the rate needs Amount, Pmt Amount, Pmts/Yr, and the term. The term may be given either as # Periods or as a Last Pmt Date — when only the Last Pmt Date is supplied, Per%Sense derives the period count first (the Example 1c derivation), then solves the rate.
Enter Amount=200,000, Loan Date=01/01/2025, Rate=6.0000, Pmts/Yr=12, Pmt Amount=1,199.10. Leave both # Periods and Last Pmt Date blank.
Per%Sense fills in # Periods = 360 (a 30-year loan) and the matching Last Pmt Date. It uses a closed-form formula — given the amount, rate and payment, the number of installments follows directly — so this is instant, no iteration.
If the payment is too small to cover even the first month's interest, the loan can never amortize; Per%Sense reports that rather than running forever. This is the plain-loan case — deriving the term while Advanced Options are in use is not supported (supply # Periods or a Last Pmt Date there).
Enter Amount=100,000, Loan Date=02/12/2024, Rate=8.0000, 1st Pmt Date=03/01/2024, Periods=360, Pmts/Yr=12, Points=2.0000.
Per%Sense fills in the APR field. The points are an upfront cost: the borrower effectively receives only $98,000 (loan amount minus the $2,000 in points) but still repays the full 360-payment schedule, so the true annual cost of the borrowing — the APR — comes out above the 8% note rate. The APR is the rate at which the present value of all the scheduled payments equals that net $98,000 (the same idea as Present Value Example 5).
Enter Points=0 and the APR field simply reports the note rate expressed as a yield — a useful baseline to compare against.
Enter Amount=100,000, Loan Date=01/01/2024, Rate=8.0000, Pmts/Yr=52, Periods=1560, Basis=365. (Leave 1st Pmt Date and Payment blank — 1st Pmt Date defaults to one week after Loan Date; Payment is computed.)
Per%Sense computes Weekly payment ≈ $168.79. Switching to the 365-day basis matters here: under 360 the per-period rate uses a 30/360 day count, which subtly shifts the answer for sub-monthly frequencies.
Both runs share: Amount=100,000, Loan Date=01/01/2024, Rate=8.0000, Basis=360. Leave 1st Pmt Date and Payment blank.
Monthly run: Pmts/Yr=12, Periods=360. Payment ≈ $733.76. Total interest over 30 years ≈ $164,156.
Biweekly run: Pmts/Yr=26, Periods=780 (30 years × 26 biweekly periods). Re-run; the per-payment amount drops but the total interest is meaningfully less than the monthly run, because more frequent compounding reduces the average outstanding principal across the term.
Enter Amount=100,000, Loan Date=01/01/2024, Rate=8.0000, 1st Pmt Date=02/01/2024, Pmts/Yr=12, Periods=60, Pmt Amount=666.67 (= $100,000 × 8% / 12). Then expand Advanced Options and under Balloons add a row with Date=01/01/2029 and Amount=100,000.
The fixed Payment of $666.67 covers exactly the monthly interest, so no principal is reduced — each schedule row shows $666.67 interest and $0 principal, and the balance stays at $100,000 for all 60 months. The balloon at month 60 then settles the full principal.
| # | Title | Feature demonstrated | Status |
|---|---|---|---|
| 6 | Adjustable Rate Loan | Rate changes on specific dates | Implemented — an adjustment that gives only a new rate now re-solves the payment over the remaining term (see Advanced Solver Examples below) |
| 7 | Including Balloon Payments | Scheduled lump sum payments | Implemented |
| 8 | Balloon Unknown | Computing the balloon amount needed | Implemented — leave a balloon row's Amount blank to solve the "target balloon" (see Advanced Solver Examples below) |
| 9 | Calculating the Completion Date | Leave # Periods blank, supply Last Pmt Date | Implemented — both the dates-to-periods case (Example 1c) and the solve-term-from-payment case (Example 1g) |
| 10 | Negative Amortization | Payment less than interest | Implemented (engine tracks principal increasing each period) |
| 11 | Neg Amort: Fixed Low Rate | Initial low payment, rising balance | Implemented |
| 12 | 30-Year Terminated at 12 | Balloon terminates early | Implemented |
| 13 | Principal Moratorium | Interest-only start period | Implemented |
| 14 | Targeted Principal Reduction | Minimum principal per payment | Implemented (with input validation: target must not exceed Amount ÷ # Periods) |
| 15 | Interest Plus Principal | Fixed principal + variable interest | Implemented via Target option |
| 16 | 13 Annual Payments | Extra payment each year to accelerate | Implemented via Prepayments |
| 17 | Skipping a Regular Payment | Skip Months or balloon of $0 with "includes regular = YES" | Implemented |
| 18 | Computing the Loan Rate | Leave Rate blank, fill in Payment | Implemented — worked through in Example 1f above (Newton iteration on the schedule residual) |
All of these features are wired up in the API and engine and can be exercised by entering the inputs on the Amortization screen and clicking Calculate. The advanced field-presence solvers — where you leave a field blank for the engine to compute — are worked through in the examples that follow.
Enter Amount=200,000, Loan Date=01/01/2025, Rate=6.0000, 1st Pmt Date=02/01/2025, # Periods=60, Pmts/Yr=12, Pmt Amount=1,199.10. Expand Advanced Options, and under Balloon Payments add a row with Date=01/01/2030 and Amount left blank.
A balloon row with a date but no amount is a target balloon: Per%Sense solves the amount that drives the loan balance to exactly zero. Here it computes a balloon of roughly $186,000 — the principal still outstanding after five years of the smaller 30-year payment.
Use this whenever you know when the loan must be retired but not the lump sum it takes.
Enter the base loan (Amount=200,000, Rate=6.0000, 1st Pmt Date=02/01/2024, # Periods=360, Pmts/Yr=12; leave Pmt Amount blank so the engine computes the starting payment). Expand Advanced Options, and under Rate/Payment Adjustments add a row with Date=01/01/2029, new Rate=9.0000, and Amount left blank.
When an adjustment supplies a new rate but no new payment, Per%Sense re-amortizes the remaining balance at the new rate over the periods that are left — the payment steps up so the loan still finishes on schedule. Without this, the old payment would no longer amortize the loan and a residual balance would be left at the end.
(The reverse — a new payment with no new rate — is a straight recast: the new payment simply applies at the unchanged rate.)
Enter the loan (for example Amount=200,000, Rate=6.0000, # Periods=60, Pmts/Yr=12, Pmt Amount=1,199.10 — the 30-year payment, which leaves a large balance at year 5). Expand Advanced Options, and under Additional Periodic Payments add a series with a Start Date, Pmts/Yr=12, a Stop Date (or a Number of Payments), and Amount left blank.
Per%Sense solves the per-payment extra amount that drives the balance to zero by the end of the schedule. The series must be bounded — give either a Stop Date or a Number of Payments — so the count of extra payments is known.
Enter the base loan, then under Additional Periodic Payments add a series with a Start Date, Pmts/Yr=12, Amount=500, and both the Stop Date and the Number of Payments left blank.
With the amount known but no bound on the series, Per%Sense solves the duration: it runs the extra payments until the loan retires and reports how many were needed. A $500/month prepayment retires the 30-year loan in roughly 15 years instead of 30 — the schedule simply ends early, and an advisory notes the payment number at which the loan was retired.
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:
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.
| Column | Description |
|---|---|
| Date | Date of the one-time payment. Leave blank to back-solve from Amount + Value (PV-2). |
| Amount | Dollar amount of the payment. Leave blank to back-solve from Date + Value (PV-1). |
| Value | Present/future value at the as-of date. Per%Sense computes it from Date + Amount; or, on a row-level back-solve, type a target Value and leave Date or Amount blank to have the engine solve the missing field. |
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.
| Column | Description |
|---|---|
| From Date | Date of the first payment in the series. Leave blank to back-solve from To Date + Amount + Value (PV-6). |
| Through | Date of the last payment in the series. Leave blank to back-solve from From Date + Amount + Value (PV-5). |
| Per/Yr | Payment frequency (12=monthly, 52=weekly, etc.). |
| Amount | Dollar amount of each payment. Leave blank to back-solve from From + Through + Value (PV-4). |
| COLA % | Annual cost-of-living adjustment (optional). Payments increase by this percentage each year. |
| Value | Present/future value of the entire series. Per%Sense computes it from From + Through + Amount; or type a target Value and leave exactly one of those three blank to back-solve it. |
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.
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.
| Rate Type | Use for | Description |
|---|---|---|
| True Rate | Present value, savings | Continuously compounded rate. The mathematically "pure" rate. |
| Loan Rate | Loans, mortgages | Discretely compounded rate (depends on payments per year). |
| Yield | Savings, bonds | Actual interest earned on one dollar during one year, after compounding. |
These are equivalent representations of the same quantity — like pounds and kilograms:
The Rate Type dropdown selects which format you're entering. Bond yields and Canadian rates are loan rates for semi-annual compounding.
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 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.
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:
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.
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.
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.)
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%Sense rejects payment-row combinations that can't be solved mathematically:
| Error | Trigger |
|---|---|
| "specify either date or amount in single payments, line N" | Lump-sum row has only a Value filled in (no Date, no Amount — can't tell which to solve for) |
| "amount cannot be zero on a single payment row, line N" | A lump-sum row supplies Amount = 0 with the other fields blank (the back-solver would divide by zero) |
| "value cannot be zero on a single payment row, line N" | Same with Value = 0 |
| "specify either other date or amount in periodic payments, line N" | Periodic row has only one date supplied (no amount, no other date) |
| "dates are out of order, line N" | Periodic row's From Date is on or after the Through date |
| "too many unknowns" | The screen has both a fully-specified row AND a row with an unknown to solve — choose one mode |
| "insufficient data on screen" | Not enough information to compute or back-solve anything |
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.
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.
Enter As-of Date=01/01/2024, Rate=8.0000. Enter one lump sum: Date=01/01/2025, Amount=10,000.
Present Value ≈ $9,231. The $10,000 next year is worth about $9,231 today at 8% (continuously compounded).
Enter As-of Date=01/01/2024, Rate=6.0000, and a periodic payment: From=01/01/2024, Through=01/01/2034, Per/Yr=12, Amount=1,000.
The present value represents how much money you'd need on the as-of date, invested at 6%, to fund all 120 payments.
Enter As-of Date=01/01/2024, Rate=7.0000. Add one periodic payment: From=01/01/2024, Through=01/01/2044, Per/Yr=12, Amount=500.
Per%Sense computes Sum Value ≈ $64,889. This is the lump sum you'd need today to fund 240 monthly $500 outflows at 7% — equivalent, in present-value terms, to making the deposits yourself.
To get the corresponding future value at 2044 (the bank balance after 20 years of contributions), multiply by the 20-year growth factor: $64,889 × (1 + 0.07/12)240 ≈ $260,463. Per%Sense's PV engine values cash flows as of a single reference date; future-value framings are derived from the PV by the user.
Enter As-of Date=01/01/2024, Rate=5.0000. Add a periodic payment: From=01/01/2024, Through=01/01/2054 (30-year horizon, adjust to taste), Per/Yr=12, Amount=2,000, COLA=3.0000. The computed Sum Value is substantially higher than the same annuity with COLA=0, because each year's payments are 3% larger than the prior year's.
An APR is really an IRR in disguise. Consider a loan of $100,000 at 8% with 2 points and monthly payments of $733.76 for 30 years. The borrower actually receives $100,000 - $2,000 (points) = $98,000.
The APR is the rate that makes the present value of 360 monthly payments of $733.76 equal to exactly $98,000. In other words, the APR is the IRR of a $98,000 investment that returns $733.76 per month for 30 years.
Enter the As-of Date, add a lump sum (Date ten years out, Amount=10,000), and type the price 9,000 into the Present Value field. Leave the Rate blank.
Per%Sense solves the rate that makes the present value of the payments equal your target — the IRR. The Present Value field doubles as a target box: type a value there and leave Rate blank to solve the rate, and the solved rate appears back in the Rate cell.
The rate is reported in whichever form the Rate Type dropdown is set to (True / Loan / Yield). IRR cannot be solved in Variable Rate mode — a rate schedule fixes the rates, so there is nothing to solve.
Enter the Rate, add the payment row(s), and type the known value into the Present Value field. Leave the As-of Date blank.
Per%Sense solves the as-of date at which the payments discount to that value and fills it into the As-of Date cell. Exactly one of Rate and As-of Date may be left blank — leaving both blank is ambiguous, and the screen says so.
| # | Topic |
|---|---|
| 6 | Multiple lump sums at different dates |
| 7 | Mixed lump sums and periodic payments |
| 8 | Backward calculation: find the payment amount |
| 9 | Backward calculation: find the date |
| 10 | IRR of a bond (bond yield to maturity) |
| 11 | Variable rate: IRS underpayment interest |
| 12 | Variable rate: legal prejudgment interest |
| 13 | Simple interest for legal damages |
| 14 | COLA with anniversary escalation |
| 15 | COLA with continuous escalation |
| 16 | Comparing two investment options |
| 17 | Lease vs. purchase analysis |
| 18-20 | Variable rate computations |
| 21 | Simple vs. compound interest comparison |
| 22 | Forward and backward calculations combined |
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:
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.
| Code | Name | Trigger | What it models |
|---|---|---|---|
| N | None | Payment always made; no mortality weighting (default). | Fixed-term annuity, bond, mortgage. The straightforward case — mortality is irrelevant. |
| L | Living | Paid only if person 1 is alive at the payment date. | Lifetime pension, life annuity, lost-wages claim, retiree healthcare benefits. Most common contingency. |
| D | Dead | Paid only if person 1 is deceased at the payment date. | Reverse-mortgage payouts to heirs after death; "if my benefactor predeceases me, I receive X"; certain estate or trust distributions; survivor's-benefit-only structures. Not "no contingency" — that's N. |
| 1 | Only 1 Living | Person 1 is alive AND person 2 is deceased. | Spouse's survivor pension that only pays while the spouse is alive after the primary worker has died. Less common but appears in some defined-benefit plans. |
| 2 | Only 2 Living | Person 2 is alive AND person 1 is deceased. | Mirror of 1. Pick whichever assignment matches who you put in Person 1 vs Person 2. |
| E | Either Living | At least one of the two people is alive. | Joint-and-survivor annuity at the full amount (pays as long as anyone is alive). Common in pension plans — the benefit continues to the surviving spouse. |
| B | Both Living | Both people are alive. | Joint-life annuity that stops at first death. Rare standalone, but a useful building block: a typical "100% joint-and-survivor" pension equals B at one rate plus the post-first-death tail at another. |
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.
A contingency is only meaningful when the people it refers to are actually set up, so the Present Value screen guides you:
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.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.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.
Expand the Life Contingency (Actuarial) section on the Present Value screen. You'll see:
Per%Sense includes the SSA 2021 Period Life Table from the U.S. Social Security Administration, with separate male and female tables. These are the standard tables used for pension and legal calculations in the United States.
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:
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:
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).
Per%Sense computes Sum Value ≈ $253,135. Without the Living contingency the same 420-payment stream is worth ≈ $397,763, so the mortality weighting trims the pension's PV by about 36% — a 65-year-old won't collect every later payment.
Sanity check (complementarity): switching the Life dropdown to Dead on the same inputs yields ≈ $144,628, and $253,135 + $144,628 = $397,763 matches the non-contingent value to the dollar.
Per%Sense computes Sum Value ≈ $959,540 for the survival-weighted lost-support stream, plus PODValue ≈ $12,617 for the expected present value of the $50,000 burial cost. The POD is much less than $50,000 because most of the probability mass for death falls many years out and is heavily discounted.
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.
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.
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, CAN, DAY.
CAN (Canadian): Canadian Standard Rates are computed as if payments were semi-annual, even when payments are monthly. If selected, rate columns will be labeled as Canadian rates.
DAY (Daily): The daily rate is a true interest rate compounded over one day. Numerically very close to the true rate. Used by most savings accounts and rarely by loans.
Controls when cost-of-living adjustments are applied to periodic payments:
Applies only to negative amortization — when a payment is less than the accrued interest.
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.
When a loan closes mid-month with payments due on the 1st:
Only matters when time between loan date and first payment exceeds one period.
If a $5,000 balloon is specified on a date when the regular payment is $1,000:
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.
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.
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.