Practical guide

Why the right formula can produce a stale saved estimate

Last materially reviewed 2026-09-23

Quick answerCheck where calculation occurs and when the visitor last changes an input; arithmetic alone does not establish freshness.
What to know

The symptom: two believable results disagree

A visitor may see an estimate on one page, change an answer later and submit a record that does not match the final intended scope. Both figures can be mathematically valid for different inputs. The problem is state and timing, not necessarily the formula itself. Diagnose which answers each result used and when it was calculated. Do not overwrite the discrepancy with a reassuring completed label or assume the latest-looking display is the retained source of truth.

What to know

Understand the documented cause

The calculator help page describes updates on the page containing the calculation and saving behavior tied to viewing that page. It also distinguishes legacy submission-based plan behavior from current plan arrangements. These details make it unsafe to assume that every result automatically refreshes whenever any answer anywhere changes. Map the final dependency: which last answer can change the estimate, and which calculation is responsible for the value the team will later retrieve?

What to know

Repair the journey, not just the number

Place the final review after all relevant inputs or provide a deliberate route that returns the visitor to a current calculation before submission. Keep the estimate assumptions visible enough that a changed answer is recognizable. If using a sticky or global display, verify its separate saving requirement. Do not conceal an old result with styling while leaving the stored value unchanged. The fix should connect the visible promise and retained record to the same final input state.

What to know

Test a revision that changes the outcome

Use a harmless case where changing quantity clearly changes the expected total. View the first result, revise the earlier answer and finish the workflow. Compare the last visible result with the actual saved data. Repeat for a branch-changing answer if the form supports one. Documented behavior provides a reason for this test, not proof of its outcome in your implementation. Preserve the discrepancy until it is understood instead of manufacturing a successful record.

Continue when useful

Next: Let visitors change scope without losing the meaning of the estimate

A revised answer should lead to a revised, identifiable result—not a mixture of old and new assumptions.

Open Let visitors change scope without losing the meaning of the estimate →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Using calculators — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23
  2. Global formulas — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23
WORKSHEET 02 / KEEP THE STATES DISTINCT

A number is only one acceptance check.

CaseExpected visitor outcomeRecord to inspect
Required answer missingExplain what is needed; no invented zeroMissing state, not a valid free quote
Quantity is legitimately zeroUse the explicitly allowed zero ruleZero remains distinct from blank
Answer changes after a resultRecalculate or return to reviewFinal inputs and final estimate agree
Request is outside the modelExplain the human-review pathException and requested next action

Original acceptance framework, not observed merchant test results. Build the complete test set.