Insights
Show a figure's state beside it: final, estimated and what it excludes, due for recalculation, blocked by a named cause, or overridden with a reason. Put the figure's state next to the figure, in words, and let that state decide what someone may do with it.
Put the figure's state next to the figure, in words, and let that state decide what someone may do with it. A figure is final, estimated (with a note of what the estimate leaves out), due for recalculation because an input changed, blocked by something the screen names, or set by hand by a person who gave a reason. Show exact amounts where the figure is known, and an estimate that states what it leaves out where it is not.
This page is about figures a system calculates but has not settled yet: payouts, balances, release amounts, totals. Model confidence in a prediction is a different problem, and the last section points to where we cover it.
Five states a figure can be in
| State | When it applies | What the screen says beside the number | What the reader may do with it |
|---|---|---|---|
| Final | Every input is settled and the calculation has run on them | The amount, with no qualifier | Approve, pay, release or report it |
| Estimated | The exact figure is costly or not yet possible to work out | "Estimated", and what the estimate leaves out | Decide with the gap in view; not report it as settled |
| Needs recalculation | An input changed after the figure was calculated | That the figure is out of date, and which input changed if the system knows | Recalculate before approving |
| Blocked | The figure is waiting on something else, such as an earlier approval | What it is waiting on, by name | Deal with the blocker first |
| Overridden | A person set the amount by hand | Who set it and the reason they gave | Act on it, with the reason on record |
Treat these five as a starting vocabulary, not a standard. Add a state only when it permits something different from the ones you have. The GOV.UK Design System guidance on status tags makes the same point from the other side: every extra status is one more thing people have to remember, so start with the smallest set that works.
Why the state matters as much as the number
At Tcules, we work from a judgement about how screens are read: a number on a screen is taken as a fact. When the system knows a figure may be out of date, waiting on something or partial, and shows it plainly anyway, the screen tells a quiet lie, and people act on it. They approve a payout, release funds or put a total in a report. That is our judgement rather than a measured finding. The research below tests a narrower point: what happens when uncertainty is shown.
Showing that a number is uncertain need not cost much trust. In five experiments with 5,780 participants in total, including a field experiment on the BBC News website, van der Bles and colleagues (PNAS, 2020) found that people did perceive more uncertainty when uncertainty about published facts and numbers was communicated, but trust in the numbers and in their source fell only slightly, and mostly when the uncertainty was put in words rather than numbers. Those were public statistics in the news, not figures in a work tool.
Showing it can also improve the decision. In an incentivised experiment on when to leave for a bus, Fernandes, Walls, Munson, Hullman and Kay (CHI 2018) found that two visual displays of how far an arrival prediction might be off (quantile dotplots and cumulative distribution plots) led to better and more consistent decisions than the prediction shown alone. Those were probabilistic predictions, a neighbouring problem to an unsettled payout, so read the result as a direction rather than proof.
Where consumers are concerned, regulators have written versions of this rule. Under US Regulation E, a remittance transfer provider that is permitted to give estimated disclosures must describe them using the term "Estimated" or a substantially similar term, in close proximity to each estimated amount. In the UK, the FCA Consumer Duty requires firms' communications to equip retail customers to make decisions that are effective, timely and properly informed. Neither rule covers an operations screen inside a business application, but the reasoning carries over: a person deciding on a figure should know what kind of figure it is.
The obvious alternative is to recalculate everything the moment any input changes, so that every number on screen is always final. Where the calculation is expensive, that can cost more than it is worth, which is why the state has to be shown instead.
Where this comes from: payouts and holds at Chestnut
At Tcules, we worked as an embedded design partner for Chestnut for about thirteen months, alongside its own product, design and engineering teams, and built some of the front end ourselves. Chestnut is a producer performance platform for the insurance industry: carriers use it to pay the producers who sell their policies. Much of the product is arithmetic, and working out the correct number can be expensive.
A payout can change when a policy, a plan setting or an override changes, and recalculating it on demand is costly. So instead of presenting every figure as settled, each payout says where it stands: Needs Recalculation when an input has changed, Blocked when an earlier payout is still awaiting approval. Overrides, where an operator sets an amount by hand, require a reason and leave an audit trail. A reviewer approving payouts can see whether each figure is final, waiting on an earlier approval or due to be recalculated.
Bonuses raised the same question in a harder form, because the consequence is money. A bonus has two lives. In draft, setup is the page and Publish leads; once it is live, payouts come first and setup sits behind a single button. Reports stay empty until a bonus is live.
The engagement concluded in August 2026. Our Chestnut case study shows the product decisions and how they were built, not usage or business results, and nothing on this page claims more.
Say what an estimate leaves out
"Estimated" tells the reader the figure may move. It does not tell them why, or which way. A label that names the missing part does.
Chestnut has a hold that stops a producer's earnings early, a policy hold. Working out the exact figure after debt repayment, across a producer hierarchy, is costly. So the screen that releases a policy hold does not pretend: it says plainly that its estimate excludes debt payoff. Whoever releases the hold knows that debt repayment has not been taken out of the number in front of them.
Regulation E asks for the word "Estimated" next to the figure. The more useful version adds the gap: "Estimated, excludes debt repayment" lets someone judge whether the gap matters to the decision they are about to make. An estimate that says only "approx." leaves them guessing.
Name what a figure is waiting on
A figure that is blocked should say by what. "Blocked" alone sends the reader looking; a label that names the blocker, such as "Blocked until the previous payout is approved", tells them where to go. At Chestnut, a payout shows Blocked when an earlier payout is still awaiting approval.
Public design systems already treat "waiting on something" as its own state. The GOV.UK pattern for completing multiple tasks uses "Cannot start yet" when another task must be completed first, and does not link the row, so the screen does not offer an action the person cannot take. Stripe, a payments provider, makes the same distinction with money: its documentation on balances separates pending funds from available funds, says pending funds cannot be withdrawn or spent until they are available, and gives each balance transaction the time at which it becomes available. That is a state, what it permits and when it will change, in one place. At Tcules, we cite it as an illustration of the pattern, not as a recommendation of a provider.
However the state is shown, do not carry it in colour alone. IBM's Carbon Design System asks status indicators to use at least two of colour, shape and symbol, and says relying solely on colour is insufficient; WCAG 2.2 success criterion 1.4.1 sets the same floor for accessibility. A word beside the number is the cue that survives a printout, a screenshot in a support ticket and a screen reader.
Do not force one pattern onto numbers that behave differently
Two figures can look alike in a list and still behave differently. Chestnut has two kinds of hold, and they act at different points. A producer hold stops the final payout, so releasing it can show exact amounts. A policy hold stops earnings much earlier, where the exact figure is costly to calculate. At Tcules, we kept them as separate flows instead of forcing one pattern onto both: two kinds of hold, two kinds of number.
One rule held across both. Each release asks what should happen to the held funds before anything is confirmed, so the decision about the money is made while the person can still change it.
The general test: if two numbers differ in when they can be known exactly, they probably need different screens, even when they share a name.
Run the expensive calculation when someone needs it
A state label is cheap. A recalculation across a hierarchy of producers is not. That trade-off is the reason for the vocabulary: flag the figure when an input changes, and spend the computing when someone is about to rely on it.
Chestnut follows this in both places. Recalculating a payout on demand is costly, so a payout whose inputs have changed is marked Needs Recalculation instead of being presented as settled. The policy release opens straight away, calculates when needed, and shows its estimate with the exclusion stated.
At Tcules, our judgement for other products is this: decide which actions commit money or a report, such as approving, releasing, paying out or exporting, and make sure the figure is either final at that moment or clearly labelled as something else. Between those moments a flag is enough. Where a figure was calculated at a point in time, saying when helps the reader judge how stale it might be.
A checklist for your own screens
Run this on any screen where someone acts on a calculated number.
- List every figure a person can approve, pay, release, report or export from.
- For each one, write down which of the five states it can be in. If the answer is only "final", check that every input really is settled whenever it renders.
- Every estimate says what it leaves out, beside the figure.
- Every blocked figure names what it is waiting on, and the screen does not offer an action that the block prevents.
- A changed input marks the figure as needing recalculation, and you have decided whether anyone may approve it before it is recalculated.
- Every manual override records who made it and why, and the reason is visible to the next person.
- Each state is shown in words and at least one other cue, never colour alone.
- Numbers that become exact at different moments get different flows, even if they share a name.
- Any step that moves money asks what should happen to it before anything is confirmed.
- Reports and exports carry the state with the number, so a total built from estimates does not arrive looking final.
Where this work sits
At Tcules, we design financial and workflow products where the state of a figure decides what people can do next. Our FinTech and InsurTech work starts from the same rule as this page: an estimate should not look like approval, and the product should make clear which state is still provisional.
For how held or pending money should read to a customer, see our guide to fintech UX for trust, compliance and speed. If your uncertain number comes from a model rather than an unfinished calculation, that is a different design problem, covered in why users stop using an AI feature after trying it once.