Sumvia

Methodology & Accuracy

This page explains how Sumvia calculators are built, how their accuracy is verified, and what their limitations are. It exists so you can judge for yourself how much to trust a result — and so that "the calculator said so" never has to be taken on faith.

This methodology is the ground the rest of the publication stands on. Seven companion guides put each rule here to work on a single topic, with every figure computed the same way: margin vs. markup arithmetic, break-even quantity and contribution margin, ROI and CAGR explained, VAT added and removed, commission and discount arithmetic, salary conversions and overtime pay, and how Sumvia rounds and displays numbers. The full set, alongside the sixteen calculators, is listed on the guides hub. Where a guide and this page describe the same arithmetic, they use the same fictional inputs, so the numbers line up figure for figure.

How Sumvia calculators are implemented

Every calculator's mathematics lives in small, pure functions written in TypeScript, separate from the page and interface code. Each function declares exactly what inputs it accepts, validates them (rejecting non-numeric, infinite, or out-of-range values), and returns either a typed result or an explicit, human-readable error. The interface layer only formats and displays what the engine returns — it never does its own arithmetic. Calculations run entirely in your browser; your inputs are never sent to a server.

Why calculation functions are tested

Separating the math from the interface makes it independently testable, and we use that: an automated test suite runs the engine against standard cases, decimals, negative numbers, zeros, division-by-zero attempts, very large and very small values, and floating-point corner cases before any change ships. Edge cases that once caused a bug become permanent tests, so a fixed problem cannot quietly return.

The worked examples printed on tool pages are computed by the same engine when the page is built. If the copy and the code ever disagreed, the site would fail to build rather than publish inconsistent numbers.

How rounding is handled

Sumvia calculators follow one documented rounding policy:

  • Internally, calculations keep the full precision of IEEE-754 double-precision arithmetic — nothing is rounded between steps.
  • Before display, results are normalized to 12 significant digits to remove binary floating-point artifacts (the reason a naive calculator shows 0.1 + 0.2 as 0.30000000000000004).
  • On screen, values are rounded to at most six decimal places. Small nonzero results that would round to zero are instead shown with six significant digits, so a tiny result is never displayed as "0".

The practical consequence: what you see is a cleanly rounded presentation of a more precise internal value. If you copy a result and feed it into further hand calculations, be aware that it is the displayed (rounded) figure — for chained work, prefer doing the whole calculation in one pass.

Displayed rounding vs. internal precision

One third expressed as a percentage is 33.333333…% without end. Sumvia shows 33.333333% (six decimal places) while the engine holds the full-precision value. This distinction matters when comparing our output against another tool: two calculators can both be right and still display slightly different digits if their display rounding differs.

What each engine computes, on one fictional example

The sections above describe the machinery in general; the ones that follow run it. Each subsection takes one labelled, fictional input set, states what the engine does with it and why that convention and not another, and shows where the definition stops. Every number is interpolated from an engine call made when this page is built — change the engine and these figures move with it, or the build fails.

Margin and markup are one profit over two bases

Take a sale with a cost of 60 and a selling price of 100. The profit is the same 40 however you describe it, but the two percentages the business module reports are not the same, because they divide that profit by different bases. Margin divides by revenue: 40 ÷ 100 = 40%. Markup divides by cost: 40 ÷ 60 = 66.67%. Same sale, two numbers — the confusion these calculators exist to answer. Running the figures the other way round, from a known cost and price rather than a revenue and cost, returns the identical pair: 40% margin and 66.67% markup. Margin is always the smaller of the two for a profitable sale, because it divides by the larger number. The margin here is exact; the markup is a repeating decimal, which the next part of the page follows through the rounding policy.

Break-even is fixed cost divided by what each sale contributes

Give the break-even engine 9,000 of fixed costs, a 20 price, and 8 of variable cost per unit. It first works out the contribution margin — price minus variable cost, 20 − 8 = 12 — the amount each sale puts toward fixed costs before any profit begins. Dividing fixed costs by that contribution gives the break-even count: 9,000 ÷ 12 = 750 units, at which point sales revenue reaches 15,000 and the fixed costs are exactly covered. The contribution margin as a share of price is 60%. The engine refuses the case where price does not exceed variable cost: with a zero or negative contribution, every sale covers nothing, break-even is never reached, and it returns a plain error rather than an infinity.

ROI, annualized ROI, and CAGR are one investment, three questions

Consider putting 8,000 into something that returns 12,000 after four years. The ROI engine answers the total-return question first: net gain 4,000, which over the 8,000 invested is a 50% total return. Ask it for the yearly pace as well, by supplying the four years, and it reports an annualized ROI of 10.67% — the constant rate that, compounded over four years, turns 8,000 into 12,000. That second figure is exactly what the CAGR engine computes from the same start value, end value, and span: its compound annual growth rate is 10.67%, and its total growth over the whole period is 50%. The two engines agree by construction — annualizing an ROI and taking a CAGR are the same arithmetic — which is why a 50% total return is a far smaller 10.67% per year once it is spread across four years rather than read as if it all happened at once. Reading a multi-year total return as if it were an annual rate is a common confusion this pair of tools is built to prevent.

VAT divides coming down, and subtracting the rate is wrong

Adding VAT to a net price is a multiplication: a net of 200 at a fictional 18% rate becomes a gross of 200 × (1 + 18 ÷ 100) = 236, of which 36 is the tax portion. Removing VAT from that gross is not the reverse keystroke it looks like. The tax was charged on the net, not the gross, so to recover the net you divide: 236 ÷ (1 + 18 ÷ 100) = 200, back to the original 200 exactly. Subtracting 18% of the gross instead — the intuitive shortcut — lands on 193.52, short of the true net by 6.48. The rate is a labelled example, not any jurisdiction's figure: the engine assumes no rate of its own and computes only with the one you enter.

Salary conversions annualize once, then divide out

The pay engine converts a rate in any period to every other period by going through a single annual figure, on the standard 52-week-year convention. A fictional 30 an hour at 40 hours a week annualizes to 62,400 a year, and that annual amount then divides out to each period:

  • Hourly: 30
  • Daily: 240
  • Weekly: 1,200
  • Bi-weekly: 2,400
  • Semi-monthly: 2,600
  • Monthly: 5,200
  • Quarterly: 15,600
  • Annual: 62,400

Every amount is gross — pre-tax — and the pages that use this engine say so explicitly, because the conversion knows nothing of deductions, which vary by person and place. The hourly and daily figures depend on the hours-per-week and days-per-week you supply; the rest follow from the calendar alone.

The rounding policy, watched through the formatting layer

The three rules stated above are easiest to trust when you can see them act. Plain double-precision arithmetic evaluates 0.1 + 0.2 to 0.30000000000000004 — the trailing error is how binary floating point represents those particular fractions, not a Sumvia bug. Normalization to twelve significant digits removes it, and the formatter shows 0.3. A genuinely non-terminating value behaves differently: one third as a percentage is held by the engine as 33.33333333333333, normalized to 33.3333333333, and displayed at the six-decimal cap as 33.333333% — there is no exact figure to print, only a documented place to stop. And a result too small for six decimal places is not swallowed: 0.00004% of 1 is shown as 0.0000004, a value the plain six-decimal format would have rounded to 0, so the formatter falls back to six significant digits and keeps the leading digit visible. The policy is content-blind — it rounds a margin, a markup, and a churn rate by the identical rule — which is exactly why one documented policy can stand behind every calculator. The dedicated guide, how Sumvia rounds and displays numbers, walks the same three examples in more detail.

Constants the rules depend on

A few fixed values sit behind the behavior described above, and they are interpolated here from the engine itself rather than restated by hand:

  • Supported input range. Inputs are capped at a magnitude of 1,000,000,000,000,000 in either direction — the documented range of -1,000,000,000,000,000 to 1,000,000,000,000,000. The ceiling keeps every calculation inside the territory where double-precision arithmetic represents integers and products exactly enough for a general-purpose calculator; a value beyond it is reported as out of range rather than quietly computed with eroding accuracy.
  • Normalization precision. Before display, values are normalized to twelve significant digits — enough to preserve every figure this site computes while sitting well short of the sixteenth- or seventeenth-digit noise where binary artifacts begin.
  • Display cap. On-screen values are rounded to at most six decimal places, with the single significant-digits fallback that keeps a tiny nonzero result from rounding to "0".
  • Default overtime multiplier. When the overtime engine is given hours and a base rate but no multiplier, it applies a conventional one: a base rate of 20 returns an overtime rate of 30, an implied multiplier of 1.5×. That default is a convention, not a legal ruling — jurisdictions and contracts differ, so the multiplier is always editable, and the pages that use it say so.

Limitations of generic calculators

  • Sumvia tools implement general mathematical definitions. Specific domains — tax rules, regulated interest calculations, jurisdiction-specific rounding of currency — often impose their own conventions that a generic tool does not know.
  • Inputs are limited to a documented range (±1015) so results stay in territory where double-precision arithmetic is dependable for everyday use.
  • Undefined operations are reported as such rather than answered: a percentage of a zero whole, or a percentage change from a zero baseline, has no conventional value, and the calculator says so explicitly instead of showing an infinity or an error code.
  • A correct calculation can still be the wrong calculation for your situation — choosing the right formula for a real-world decision is judgment we cannot automate.

For consequential financial, legal, tax, medical, or business decisions, verify results independently and consult a qualified professional.

Reporting a suspected issue

If a Sumvia result looks wrong, we want to know. Send the tool name, the exact inputs, the result you saw, and the result you expected via the contact page. Confirmed issues are fixed in the engine and locked in with a new automated test.

Last reviewed: 2026-10-02.