The Estimate Nobody Revisited: A Guess With a Date on It

Here is a worked example we constructed for this article. Every figure is invented so that a reader can check the arithmetic by hand. The 18% GST rate appears only to keep the totals checkable, and is described that way every time it appears; nothing here is guidance on how anything should be treated, and tax questions belong with your own chartered accountant.

In March, a business estimates a website rebuild at ₹4,00,000 taxable. It is a considered figure, built from a list of work items and some judgement about how long each will take. Nobody disputes it. The customer decides to wait, because of budget timing rather than doubt. The estimate sits in the system.

Eleven months later, the work starts. In the meantime, the person who built the estimate has left, two of the libraries the estimate was based on have changed, the customer's internal structure has changed, and the integration that was assumed to be straightforward is now the largest single risk in the job. The real cost of the work is ₹5,80,000 taxable.

Now the question, which is the only question this article is really about: is the original estimate wrong, or is it stale? Both are true and they have different remedies. The estimate is wrong in the sense that it did not predict the outcome. It is stale in the sense that the conditions it was priced against stopped existing eleven months ago, and nothing recorded that fact.

Compare the two numbers. ₹5,80,000 − ₹4,00,000 = ₹1,80,000. That is 45% of the original estimate, and we are deliberately not going to present that as a finding or invite comparison against any benchmark. It is one invented job. What is worth noticing is that the loss was not caused by bad estimating. It was caused by an estimate continuing to be treated as current after the basis for it had expired. A different estimate made in February, with the same level of care and the same information available, would have been wrong by almost exactly as much. The March estimate did not fail. It was simply used long after it was meaningful, and no record said so.

An estimate goes stale for reasons that have nothing to do with the work itself, and the reason it goes stale is almost never recorded. These four cover most of what we have seen.

The first is time. Prices change, dependencies change, and the labour market changes. An estimate is a snapshot of a set of conditions, and conditions do not stay still for a year because the document is still in the folder. This is the one everybody half-knows about and nobody writes down.

The second is the person. An estimate carries the judgement of whoever made it, and judgement is not stored anywhere else. When that person leaves, the estimate does not become wrong automatically, but it becomes unreviewable, because there is nobody left who can say what it was based on or how much of it was a considered figure and how much was a round number. The estimate survives the person as a number and loses everything that made it meaningful.

The third is the customer's side of the equation. Scope drift is the usual culprit, and it is covered in detail elsewhere in this cluster. The structural point here is that drift destroys the basis of an estimate specifically, because the estimate was priced against a particular set of assumptions about what the customer would supply, decide, and confirm. When those change, the estimate is not slightly wrong, it is priced against a world that no longer exists.

The fourth is the work itself. The first three change the price. This one changes what the price was for. An estimate produced before a decision about scope, before an integration target was known, or before a compliance requirement was understood, is answering a question that has since been re-asked. It is not wrong. It is answering a different question, and it is filed under the old one.

Out of date is a fact about the calendar. Visible is a fact about the workflow. The two are not the same, and most businesses have the first and not the second: everyone knows the estimate is old, and nobody can point to the moment it became unreliable.

There are four things that have to be recorded, and all four are cheap. The first is the conditions, meaning the assumptions the estimate rests on: what was assumed about the customer, the dependencies, the exclusions, the timeline. Not the reasoning chain, just the assumptions, written short. The second is a review date, which is a deliberate choice rather than a default, and which should be short enough to be useful. The third is the basis, meaning the unit prices or the effort basis, so a later reader can see whether those still apply without asking anybody. The fourth is the trigger, meaning the events that should force a look at it before the date arrives: a change of scope, a change of the person who raised it, a change in the price of something it depends on.

With those four recorded, a stale estimate is a different object from an old one. It is an estimate with visible warnings on it, and a person reading it can tell in seconds that they are about to make a decision rather than read a fact. Without them, the estimate is a number with a date, which is the least useful format available for something that is going to be relied upon.

It is worth being direct about the product boundary, because an expiry feature is exactly the kind of thing a reader assumes exists and it does not work that way here.

NoxOrigin has no change-request record, no milestone record, no deliverable record, no contract editor, and no e-signature. There is no automated staleness flag on a quote, no reminder when a review date passes, and no wizard that walks somebody through re-estimating. What exists is the structure underneath: a quote is a priced record attached to a project, and a revised estimate is a NEW QUOTE raised against that same project. The old estimate stays exactly as it was, and the new one sits beside it.

That structure is not the same as an expiry feature, and we would rather say so than describe a capability we do not have. What it does give you is the thing an expiry feature cannot: the ability to see, later, what the estimate was when it was made and what it became when somebody re-examined it. The visibility described in the previous section is mostly a matter of how a business chooses to use that structure, not of what the software enforces.

Two other boundaries are relevant. Merge policy is a setup decision: if a customer or project record is detected as a candidate for merging, it is flagged and a human reviews it, and nothing merges automatically. And shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches, so the periodic review that would catch a drifting estimate is arranged deliberately with help rather than being a toggle you can throw in an afternoon. It does not file GST returns or any other statutory return, and it has no timesheet record and no payroll module, so an estimate priced on labour cannot be checked against hours worked anywhere in this platform. Expenses are Nox-Billings only; purchasing is in Commerce.

The practical outcome is a small standing work list rather than a report: the estimates that are past their review date, the ones whose assumptions have changed, and the ones whose author has left. Closing those three lists is the whole mechanism, and it works because each item is a small action with a clear end rather than a judgement call about a large number.

The companion failure modes in this cluster are worth reading together, because an unrevised estimate is usually where several of them meet. The quotation that was never a scope is the first article, and an estimate without exclusions is an estimate that will be stale by definition, since nobody can tell what changed it. The concession taken twice is the second, and a stale number re-quoted without comment is a concession granted by inattention. And the work that genuinely cannot be priced in advance is the fourth, because a business that only ever prices work it can scope will invent scope for the work it cannot, and then estimate that invented scope badly.

The related question of whether quoted and invoiced scope can be trusted to correspond at all is covered in the article on scope drift between the agreed scope and the invoiced scope.