How to Split AI Savings Between Time Saved and Errors Avoided

The input for this ledger is elapsed task time before and after the tool, measured rather than estimated. Surveys of what people think they saved are the weakest possible input; the strongest practical method for repetitive work is activity sampling, where you take many observations of what a person is doing at random moments and the proportion of observations in a category estimates the proportion of time spent there (Disney, activity sampling).

Activity sampling is cheap and defensible if you size it properly. Because you are estimating a proportion, the uncertainty behaves like a binomial confidence interval, and the conventional Wald interval performs badly when the proportion is near zero or one. Disney recommends the Clopper-Pearson interval for activity sampling and provides sample size tables for it (Disney). The practical consequence: if you want to say "this task occupies 2% of the team's week" with any confidence, you need a lot of observations, because small proportions need large samples. For a single task with a stable measured duration, the classical task-time sample size calculation applies instead (MeasuringU).

Then apply three deductions before you call anything saved.

1. Supervision time. The time people now spend reviewing, prompting and checking the output. If drafting drops from 60 minutes to 20 but review takes 25, the real saving is 15 minutes, not 40, which is exactly the arithmetic one AI builder uses to explain why gross time savings mislead (Naitive).
2. Correction time. The time spent fixing what the tool got wrong, including work that has to be thrown away and redone.
3. Adoption reality. Seats assigned are not seats used. Idle licenses are pure cost, and the same logic applies to saved hours: an hour freed for someone who never adopted the tool did not exist (Waydev).

Value the net hours at fully loaded cost per hour, meaning salary plus benefits plus overhead, typically modeled at a multiple of base salary rather than base salary alone (Pickaxe). Then be honest about what that value is. In most cases it is capacity, not cash. Waydev's worked model makes the distinction explicit, presenting capacity value as reinvestable engineering time and telling you to show where it went, rather than presenting it as banked savings.

This ledger starts from two rates, both measurable from existing operational data.

The internal defect rate. The share of units (documents, tickets, orders, invoices, claims, pull requests) that require rework before they are accepted. Your quality system, ticketing tool or review queue already records most of this. If it does not, sample a few hundred units and count.

The escape rate. The share of defects that reach the customer or the downstream system without being caught internally. This is the expensive subset, and it is the one teams forget. Escaped defects carry external failure costs that internal rework does not: credits, rework at the customer, escalation handling, and sometimes contractual penalties. Cost of poor quality models conventionally separate internal failure (scrap, rework) from external failure (returns, warranty, complaints) precisely because the external category is several times more expensive per event (Leanmap).

The formula is deliberately plain:

Errors avoided value per period =
  (baseline defect rate - new defect rate) x volume
    x (rework and recheck cost per internal defect)
  + (baseline escape rate - new escape rate) x volume
    x (external failure cost per escaped defect)

Two rules keep this honest. First, measure both rates over comparable periods and at comparable volume; a defect rate measured on easy cases against one measured on hard cases is not a comparison. Second, don't estimate the rework cost from a survey of how bad it felt. Take the actual handling time per rework cycle from the system log or a time study, multiply by loaded cost, and add any material or credit cost.

A small public illustration of the arithmetic: one financial services firm reported cutting data entry errors from 5% to 0.3% across 10,000 monthly transactions, and at $50 saved per error that came to $28,200 a month (Naitive). Whether you believe the $50, the structure is the one to copy, because rate change times volume times cost per defect is auditable line by line.

This is the decision rule the whole article exists to deliver. Run every claimed benefit through it.

The test: look at your time measurement. If the baseline task time already included the rework, rechecking or correction that the error reduction now removes, that rework can only be counted in one ledger. Count it in hours saved, or count it in errors avoided, not both.

A simple way to apply it is to classify each measured task step as either productive work or remediation work.

If your "before" time study measured total handling time including rework and recheck, then your time saving already contains the error benefit, and the second ledger should be limited to the escape rate, which the time study almost certainly did not capture. If your "before" study measured only first-pass work, the time saving excludes rework and the errors ledger can carry all of it.

Decide which convention you are using before you collect data, write it at the top of the spreadsheet, and apply it to every process you measure. Mixed conventions across teams are how a portfolio-level number ends up double counting without anyone intending it.

An accounts payable team processes supplier invoices. Baseline measurement covers 20,000 invoices a quarter.

Hours ledger, net of supervision and correction. Gross time saved is 1.5 minutes per invoice times 20,000, which is 500 hours a quarter. But the tool requires review, so the honest comparison is total handling time including rework. Using the rework shares, first-pass time falls from 4.5 to 4.05 minutes and remediation time falls from 1.5 to 0.45 minutes, giving total handling of 4.5 minutes against 6.0. That is the same 1.5 minutes, so gross and net coincide here only because the review time is inside the measured handling time. If reviewers spend an extra 20 minutes a day outside the process on spot checks, that is 20 minutes times 60 working days, or 20 hours a quarter, deducted before valuing. Net 480 hours at $45 is $21,600 a quarter.

Errors ledger, escape only. Because the handling time above already includes rework and recheck, those cannot be claimed again. The escape rate moved from 0.8% to 0.5%, which is 0.3% of 20,000 invoices, or 60 escaped defects a quarter, at $220 each: $13,200 a quarter.

The double-counting trap, quantified. If the team had ignored the rule, it would also have claimed the internal defect reduction: 5% of 20,000, or 1,000 fewer defective invoices, at $18 each, or $18,000. That would have taken the errors ledger to $31,200 and the total to $52,800, roughly 50% above the defensible figure of $34,800. That gap is the entire argument for the test.

Notice too that the errors ledger here is smaller than the hours ledger. That is common when rework is already inside the measured time. The errors ledger earns its place by capturing the escaped defects that no time study sees.

A quick check on whether your time samples are big enough. Before you present a per-task saving, ask what the confidence interval around it looks like. Estimating mean task time requires a sample size driven by the variability of the task, and the standard approach uses the mean, the standard deviation and a target margin of error (MeasuringU). If task times vary widely, a dozen observations will not support a claim to the minute. Reporting an interval rather than a point estimate is standard practice for survey-based estimates and is a good habit for internal measurement too (ONS, Appinio).

The reconciliation step is where the total becomes trustworthy. Do it in this order.

Step 1: One convention per process. Write down whether the time study is gross of rework or net of it. This single flag determines which ledger owns the internal defect benefit.

Step 2: Cross-check against an independent source. If the errors ledger says rework fell by a certain number of hours, the time study should show a corresponding drop in remediation time. If it does not, one of the two is wrong. This is the same principle as comparing a delivery metric against a quality metric when evaluating AI coding tools, where falling cost per merged pull request only counts as a gain if rework and change failure rate did not rise (Waydev).

Step 3: Separate cash from capacity. Errors avoided usually produces cash or near-cash savings: credits not issued, contractor hours not bought, disputes not handled. Hours saved usually produces capacity. Report them in separate columns and never add them into a single "savings" figure for a budget conversation without labeling which is which. This mirrors the hard versus soft ROI distinction that practitioners draw when valuing AI investments (Techstack, Blue Prism).

Step 4: Check the benefit against cost on both ledgers. ROI is benefits minus costs, divided by costs, where benefits include both time and rework reduction and costs include licenses, tokens, infrastructure, training and the productivity dip during rollout (Pickaxe, Waydev). A model that only works because the errors ledger was inflated is not a model that works.

Step 5: State the measurement window. Early periods are dominated by implementation and the learning curve, and meaningful returns usually need six to twelve months of data before the numbers stabilize (Pickaxe). A 90-day claim on a workflow that took 60 days to integrate is a cost story, not a benefit story.

If you are running several AI workflows and the measurement plumbing is becoming the bottleneck, consolidating model access through one gateway removes a variable from the cost side. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key with prepaid US dollar pricing, which makes the cost line in both ledgers easier to attribute per workflow.

The failure modes are well documented. Only a minority of executives say they can confidently measure AI ROI, according to Deloitte's survey as reported by Pickaxe. Around 42% of companies scrapped at least one AI initiative in a year, up from 17% the year before, per S&P Global data reported by Beam AI, and RAND's interviews with experienced data scientists and engineers put the overall AI project failure rate above 80%, twice the rate for IT projects without AI, with misidentified problems and missing data among the leading causes (RAND).

Most of those causes are measurement causes in disguise. A project whose purpose was never tied to a countable defect or a measured task cannot produce a defensible ledger, which is RAND's first root cause in plain terms (RAND). A baseline that was never taken before rollout cannot be reconstructed afterwards, which is why establishing the baseline is a named step in ROI frameworks rather than an afterthought (Blue Prism).

Three habits prevent most of it. Take the baseline three to six months before deployment, recording labor cost and task time for the specific processes in scope (Naitive). Track outcomes rather than activity, preferring cost saved and errors prevented over documents processed (Naitive). And pick your metric set before you start, because process execution time, error rates and rework are the measures that survive a finance review, while bot uptime and number of automations do not (kyp.ai).

One more discipline: re-run the ledger when the workflow changes. A defect rate that fell because the tool got better and one that fell because the team started routing hard cases around the tool look identical in the errors ledger unless you also track volume and case mix. If you want a second pair of eyes on the design before you commit, Quanta Consulting runs a free 30-minute discovery call to map your goals and recommend an approach, with no obligation.