Dev.to WebDev 🛠 Dev 👁 0 📖 2 min read

Future Value of a Lump Sum and an Annuity: One Formula, Two Cases

Future Value of a Lump Sum and an Annuity: One Formula, Two Cases "Future value" shows up anywhere you project money forward: a one-time deposit, a monthly savings plan, a pension contribution schedule. Developers ofte

Future Value of a Lump Sum and an Annuity: One Formula, Two Cases

"Future value" shows up anywhere you project money forward: a one-time deposit, a monthly savings plan, a pension contribution schedule. Developers often reach for a loop, but the two canonical cases have closed forms. Get those right and you can handle most projections without iterating year by year.

Case 1: a single lump sum

A single amount PV invested at rate r per period for n periods:

FV = PV * (1 + r)^n

This is compound interest with the periods already normalized — r is the per-period rate, so if your input is an annual nominal rate compounded monthly, use r/12 and n = years * 12.

Case 2: a series of equal payments (annuity)

If you add the same amount PMT at the end of each period, the future value is a geometric series:

FV = PMT * [ ((1 + r)^n - 1) / r ]

That bracket is the "future value interest factor of an annuity." Derivation: each payment compounds for a different number of periods — the first for n-1 periods, the last for zero — and summing that geometric progression gives the closed form.

Edge case: when r = 0, the formula divides by zero. The limit is simply FV = PMT * n. Any implementation must special-case this or it will produce NaN for zero-interest scenarios.

Worked example

PMT = 100 per month, r = 0.005 per month (6% annual / 12), n = 120 months (10 years):

(1.005)^120 = 1.8194
FV = 100 * (1.8194 - 1) / 0.005 = 100 * 163.88 = 16,388

You deposited 100 * 120 = 12,000; the remaining ~4,388 is interest earned on earlier payments.

Payment timing matters

The formula above assumes end-of-period payments (ordinary annuity). If payments happen at the start of each period (annuity due), every payment earns one extra period:

FV_due = FV_ordinary * (1 + r)

Getting this wrong is a silent off-by-one-period error that compounds over the whole horizon. Always expose the timing as an explicit parameter.

Where implementations go wrong

  1. Rate period. Annual rate with monthly payments must be divided by 12 — and n counted in months.
  2. Zero-rate divide-by-zero. Special-case r = 0.
  3. Rounding. Round only at display time, not each period, or drift accumulates.
  4. Sign convention. Cash outflows negative, inflows positive — mixing signs flips the result.
  5. Float precision on money. Use decimal types for anything that settles real currency.

Tooling

To see the split between contributions and interest without hand-coding the series, I built a Future Value Calculator. It handles both the lump-sum and recurring-payment cases, shows the contribution-vs-interest breakdown, and lets you tweak rate and timing interactively — all client-side.

Bottom line

  • Lump sum: FV = PV (1+r)^n.
  • Annuity: FV = PMT [((1+r)^n - 1)/r], with r = 0 → PMT*n.
  • Multiply by (1+r) for start-of-period payments, and always document the rate's period.
📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.