Price the workflow before it runs.

A document workflow usually gets a cost number after it has run. Finance sees pages, credits, model calls, storage and review time in a monthly summary. Engineering sees a provider bill. Operations sees the queue that still needs people. Every number is useful, and every one arrives after the architectural decision that created it.

A design review needs a different instrument: a workflow cost estimate assembled before execution, while the team can still change the route. It prices the steps, the volume that reaches each step and the uncertainty around both. It is not a promise. It is the budget model attached to the design.

The distinction matters. Measured cost answers “what did this workflow consume?” Estimated cost answers “what are we authorizing, under which assumptions, and what could make it materially different?” Mixing them makes a precise invoice look like proof that the original decision was sensible.

Price the path, not the product

“OCR costs four cents a page” is not a workflow estimate. It is one unit rate for one step. A production path may receive a file, convert it, classify it, extract fields, validate them, retry a failed attempt, route an exception to review, write evidence, deliver a callback and retain the result.

The useful model is deliberately plain:

estimated workflow cost =
  sum(step volume × step unit cost)
  + expected exception cost
  + fixed run cost

The arithmetic is easy. The work is deciding what the units are and how much volume reaches them. Pages belong to rendering and extraction. Documents may belong to classification. Fields may belong to validation. Cases belong to human review. Gigabytes and retention-days belong to storage. Treating every step as “per document” only hides the conversion.

Start with a cost map

Draw the workflow as it will run, including the paths everyone hopes are rare. Then attach a unit, a unit price and a volume driver to every node.

A step with no rate is not free. Mark it unknown, keep it visible and assign an owner to resolve it. Zero means measured zero. Unknown means the total is incomplete. That difference prevents a tidy spreadsheet from silently becoming an approval.

Estimating without history

New workflows do not have retry rates or review distributions. That does not make estimation impossible; it changes the kind of number you are allowed to publish. Use three scenarios and expose their assumptions.

1. Low — clean input, the simplest plausible mix, little review and no unusual backfill.
2. Base — the team's best current assumptions, including ordinary retries and review.
3. High — heavier documents, a weaker straight-through rate and the permitted retry ceiling, without inventing catastrophe.

Do not create the high case by adding 20% to the total. Change the uncertain drivers: pages per document, share of complex classes, retry rate, review rate, review minutes and evidence size. A range built from causes tells the team what to watch. A percentage pad only says someone felt nervous.

When no internal observation exists, take a small stratified sample before deployment. Count pages. Label document classes. Run representative files through the proposed path. Measure how often validation abstains. Time a few review cases. Ten selected examples are not production history, but they replace several guesses with evidence and reveal whether the unit itself is wrong.

A worked estimate, assumptions included

Consider an illustrative monthly intake of 10,000 documents at three pages each. These numbers are examples, not Cogneris rates or a quote. Replace every rate and percentage with the terms of the system you are evaluating.

The extraction line is the largest machine cost, but review is the largest source of uncertainty. Moving review from 12% to 20% adds $560; negotiating a 10% reduction in the extraction rate saves $120. The estimate changes the optimization question before anyone writes a routing rule.

A stronger extraction tier might cost more per page but refer fewer cases to people. A cheaper tier might be a false economy once retries and review enter the same table. That is why inference routing has to be evaluated on accepted output, not model price alone.

The errors belong in the estimate

A cost estimate is credible when it names how it can be wrong. Publish these sources of error beside the total:

• Volume error — files were counted where pages are billed, or seasonality was ignored.
• Mix error — the sample missed long, handwritten, rotated or table-heavy documents.
• Path error — the model omits retries, fallback calls, review, callbacks or retained evidence.
• Rate error — contract tiers, commitments, currency or provider prices change.
• Behavior error — users resubmit files, schemas change and backfills run more often than planned.
• Unknown-price error — an operation exists in the path but has no current catalog price.

Put an owner and refresh date on volatile assumptions. A rate copied into a diagram without its source date becomes folklore. A review percentage without a sample size becomes confidence theatre.

Approval needs a range and a ceiling

The approval artifact should fit on one page: low, base and high totals; the drivers that move them; unknowns; the sample behind the assumptions; and the action taken when actual cost crosses the approved range.

Set two ceilings. The first is per item: maximum attempts, maximum model escalations and a terminal exception state. The second is per run or period: stop, pause or require a new approval above a declared amount. A budget that cannot interrupt execution is reporting, not control.

A design-time estimate does not need to be exact. It needs to make surprise expensive enough to stop.

This differs from the cost section in our guide to continuous document processing. Backfills and reprocessing are one application. The design-time contract applies to any workflow, including the first one, before there is an archive or a monthly bill.

Reconcile after execution

The estimate does not compete with measured cost. It creates the baseline that makes measured cost useful. After the first bounded run, compare planned and actual volume, rate and cost for each step.

Update assumptions with evidence, not with the total alone. If a $2,336 estimate becomes a $2,900 actual, “24% over” is a symptom. “Review was 18%, not 12%, concentrated in two classes” is a decision.

A billing or cost-summary screen records consumption that happened. A cost-per-successful-task measure relates actual spend to accepted outcomes. Neither replaces the estimate. They close its feedback loop.

The five-line design review

1. What are the billable steps and units?
2. How much volume reaches each step in low, base and high scenarios?
3. Which retries, reviews and retained artifacts are included?
4. Which assumptions are unknown, sampled or contract-backed?
5. What stops the workflow when the estimate is wrong?

If the design cannot answer those questions, it does not have a cost estimate. It has a unit price and a hope. Start with the published rates on the pricing page, add the full path, and keep uncertainty visible until the first measured run can replace it.