Measure accepted work, not claimed hours saved

Hours saved are the beginning of a finance question

A manager says an AI assistant saves four hours a week. Finance cannot put four hours into an ROI model until it knows what task changed, whether the output was accepted, who verified it, how much correction followed, what the tools cost, whether another team absorbed the work, and whether the result arrived in time to change a decision.

Current professional discussion is skeptical for a reason. An August 3 Hacker News discussion titled “The AI Productivity Gap” drew 140 points and 110 comments. In current FP&A discussion, practitioners question whether personal time savings become organizational value. One recent community comment jokes that a CFO may be publicizing AI use to protect the role rather than demonstrating a measured outcome. The joke lands because activity and value are still routinely presented as the same thing.

There is credible evidence of gains, but the detail matters. A 2026 field study summarized by Stanford Graduate School of Business analyzed survey responses from 277 accountants, 79 small and medium-sized businesses, and more than 200,000 transaction records. AI use was associated with productivity and reporting-quality improvements. The study also found that following non-consensus AI recommendations could increase error risk. Faster work and stronger judgment are not automatically bundled.

Finance should therefore measure the complete workflow. OpenAI's July scorecard usefully proposes useful work, cost per successful task, dependability, and value at scale. Those are vendor-authored measures, not independent proof of a specific deployment, but they point in the right direction: define “done” in the system where work happens and count outcomes people can use.

Write the measurement contract before the pilot produces a result

A measurement contract prevents the team from choosing convenient metrics after seeing the data. Name one workflow, one task unit, one start event, one accepted outcome, the relevant population, a baseline period, the comparison method, owners, stop rules, and the decision the pilot will inform. Also state what the study cannot prove.

“Monthly forecasting” is too broad. “Prepare one business unit's driver-based revenue forecast package from approved source extracts through controller-accepted scenario commentary” is measurable. The task starts when the complete approved inputs are available. It ends only when the package meets accuracy, reconciliation, evidence, timing, confidentiality, and approval criteria.

workflow_id: revenue-forecast-package-v1
task_unit: one business-unit forecast package
start_event: approved actuals and driver inputs available
accepted_outcome:
  - reconciles to approved control totals
  - material assumptions have owners and sources
  - reviewer corrections stay below threshold
  - no confidentiality or control breach
  - approved before scenario decision deadline
comparison: matched pre-pilot packages from prior 3 cycles
stop_triggers:
  - material error
  - untraceable source
  - verification time exceeds baseline total labor
  - unsupported workforce or customer impact
owners: [fp_and_a, controller, workflow_owner, ai_product_owner]

Freeze the definitions. If leadership later decides that a “successful” task may contain unreconciled figures as long as it produced a useful discussion, that is a new workflow and a new risk decision. Do not rewrite the denominator to rescue the business case.

The baseline needs more than average completion time. Record volume, complexity, seasonality, input completeness, hands-on labor, elapsed time, waiting, rework, exceptions, service levels, quality, control failures, user experience, and cost. A quarter-end process cannot be compared with a quiet month without adjustment. A new data warehouse, policy change, or team reorganization must be disclosed as a concurrent change.

Count the work that moved, not only the work that disappeared

AI often redistributes labor. A senior analyst drafts a forecast faster while a controller spends longer verifying sources. A shared-services team resolves more exceptions. IT supports connectors. Procurement monitors consumption. Risk and privacy teams review new data paths. The original user experiences a gain while the organization does not.

Build a task ledger with separate timestamps for preparation, AI interaction, occupied waiting, verification, rework, exception handling, approval, and downstream correction. Keep elapsed time and hands-on time separate. Faster cycle time can be valuable even when labor is unchanged because the result arrives before a pricing, inventory, hiring, or capital decision. Conversely, saved hands-on minutes have little value when the forecast still misses the decision deadline.

Technology cost should include model or platform consumption, licenses, integration, implementation, data preparation, testing, training, support, observability, security, governance, and allocated infrastructure. Separate fixed setup from variable run cost. Show both pilot economics and expected steady state. Do not spread a large setup cost over an optimistic future volume without a sensitivity range.

Use a metric stack that can disagree with itself

No single percentage should decide whether to scale. Use a stack that shows throughput, labor, economics, quality, dependability, decisions, controls, and distribution. A pilot can improve speed while worsening quality. It can reduce average cost while creating unacceptable tail risk. Those disagreements are findings, not inconveniences.

accepted_task_rate = accepted_tasks / all_started_tasks

first_pass_acceptance =
accepted_without_material_correction / all_started_tasks

dependability =
tasks_meeting_every_acceptance_and_control_rule / all_started_tasks

net_hands_on_time =
preparation + ai_interaction + verification + rework +
exceptions + approval + downstream_correction

cost_per_successful_task =
total_attributable_labor_and_technology_cost / successful_tasks

decision_timeliness =
accepted_outputs_before_decision_deadline / decision_relevant_tasks

Show the numerator and denominator. “Accuracy improved to 96%” is not reviewable without the unit, sample, class balance, materiality, and treatment of unknowns. “Cost per task fell 30%” can hide a lower acceptance rate. “The team saved 400 hours” can be a survey estimate without observed outcomes.

McKinsey's July 24 FP&A article argues that continuous planning can create value by surfacing risk sooner and giving leaders more choices. It reports a telecommunications example where forecasting became three times faster and describes an environment with more than 1,000 Excel models and roughly 70% of FP&A time spent cleaning, reconciling, and producing reports. Use such examples as hypotheses for what to measure, not as a benchmark automatically transferable to another company.

The decision layer is where finance can add rigor. Record the decision deadline, accepted output time, options considered, action taken, and a bounded description of impact. Some benefits will remain qualitative or weakly attributable. Mark confidence as high, medium, low, or not estimable, and explain why. False precision is not better than an honest range.

Worked example: an apparent 60% time saving becomes 18%

Assume a weekly forecast commentary takes five analyst hours in the baseline. In the AI pilot, draft preparation falls from three hours to one hour. A slide announcing “67% faster drafting” would be technically true and economically incomplete.

If the package arrives before a pricing meeting that the baseline missed, the shorter cycle may matter more than the 0.9 hours. If two of ten packages require material correction, cost per successful task must include all ten attempts. If the analyst used saved time on scenario analysis, record the new accepted output. Do not assume that released capacity automatically becomes value.

Now add cost. Suppose attributable labor is priced through an approved standard rate, AI and platform consumption is known, and setup cost is amortized over a conservative volume range. Calculate cost per successful package for the pilot and baseline. Run sensitivity for volume, reviewer effort, error rate, and model price. Present the range, not one point estimate.

Separate observed change from causal ROI

Most enterprise pilots are not randomized experiments. Teams volunteer, models improve, training increases, data changes, and leaders pay more attention to the pilot than the baseline. A pre/post improvement is useful operating evidence but does not automatically prove the AI caused all of it.

Use the strongest feasible design. Match tasks by complexity and input completeness. Compare parallel teams when process and context are similar. Alternate AI-assisted and baseline paths on a fixed task bank. Use repeated time periods. Pre-register the metrics and stop rules. Preserve all failures. When sample sizes are small, report exact cases and ranges rather than a significance claim.

OpenAI's current Economic Research Exchange explicitly asks researchers to study task-level time savings, avoided costs, quality-adjusted output, and durable productivity gains, and encourages designs that move beyond descriptive correlation when causal claims are intended. That is a useful standard even when a finance pilot is not academic research: match the strength of the claim to the design.

Distribution matters. The average may improve while new users struggle, reviewers burn out, or high-complexity tasks deteriorate. Break results out by user experience, task class, data quality, period, language, exception type, and risk tier where lawful and appropriate. Investigate who received the gain and who inherited the work.

The Financial Reporting Council's July research offers an external caution for finance: AI use in corporate reporting remains cautious and uneven, especially in areas requiring significant professional judgment. Preparers identified trust, data quality, governance controls, and legal, reputational, and stakeholder risk as barriers. A productivity model that excludes those controls will overstate value precisely where consequences are highest.

Failure modes that produce a confident but unusable ROI

A 30-day pilot should support one scale or stop decision

1. Days 1-4: select one repeatable workflow; map inputs, users, systems, data class, controls, accepted outcome, decision deadline, and consequence of error.
2. Days 5-8: freeze baseline definitions and capture volume, mix, labor, elapsed time, verification, rework, exceptions, quality, service, controls, and full cost.
3. Days 9-11: approve the comparison design, task ledger, acceptance criteria, cost allocation, stop triggers, privacy limits, and workforce-purpose restrictions.
4. Days 12-22: run the bounded pilot; preserve every started task, version, timestamp, outcome, correction, exception, cost, reviewer, and downstream event.
5. Days 23-25: reconcile labor and spend; calculate accepted-task rate, first-pass acceptance, dependability, full time, cost per successful task, and decision timeliness.
6. Days 26-27: analyze task and user distribution, control events, staff experience, concurrent changes, attribution strength, and sensitivity to volume, price, and error rates.
7. Days 28-29: close or assign every exception; test whether unfavorable cases change the recommendation; document what the pilot cannot prove.
8. Day 30: finance, workflow, control, and affected-professional owners choose SCALE, REDESIGN AND RETEST, HOLD, or STOP for the exact workflow and conditions.

Reapproval is required when the model, tool, integration, task definition, data source, control, user population, price, or consequence changes materially. AI economics can improve quickly, but yesterday's pilot does not automatically validate tomorrow's workflow.

Frequently asked questions

How should finance measure AI productivity?

Measure one workflow from complete input to accepted outcome. Include total hands-on labor, elapsed time, verification, rework, exceptions, technology spend, quality, dependability, controls, user distribution, and whether the result supported a timely decision.

Are self-reported hours saved useless?

No. They help identify candidate workflows and user experience. They become stronger evidence when reconciled with observed task timing, accepted outcomes, corrections, reviewer labor, and costs. Do not treat them as cash savings without a demonstrated use of released capacity.

What is cost per successful task?

It is full attributable labor and technology cost divided by tasks that meet every pre-defined acceptance and control criterion. Keep failures, abandoned work, and materially corrected attempts in the numerator.

When should the pilot stop?

Stop or redesign when a zero-tolerance event occurs, verification removes the gain, quality or dependability falls below threshold, the workflow shifts harm or work elsewhere, costs cannot be attributed, or the evidence cannot support the intended decision.