Extract and Calculate vs Extract Then Formula
The Real Cost of a Two-Step Workflow

The Two-Step Habit We All Inherited

The standard document processing workflow has barely changed in two decades, even as the extraction technology underneath it has transformed:

Steps 1 and 2 have gotten dramatically faster. Steps 3 and 4 have not. This two-step habit — extract first, calculate later — exists because extraction tools were built to extract, not to compute. The calculation step was considered "your job," the part you handle in your spreadsheet. And for a long time, that division made sense. Extraction was the hard part. Formulas were the easy part.

That division stopped making sense around the time extraction became fast enough that formula creation became the bottleneck.

Where the Gap Actually Lives

Let's put numbers on what the formula step costs, because it is easy to underestimate when you do it one document at a time.

A 30-line item invoice with a single computed column — Line Total = Qty × Unit Price — requires 30 formula cells to create and verify. Add a verification column to compare against the billed total, and that's 60 formula cells. The formulas themselves take seconds each. The verification — scanning each cell to confirm the reference didn't shift — takes longer.

Now scale that. Thirty invoices per week, averaging 12 line items each, with two computed columns:

Formula errors compound with volume. The European Spreadsheet Risks Interest Group (EuSpRIG) has tracked spreadsheet error rates in business environments for over two decades, consistently finding that even professionally maintained spreadsheets contain formula mistakes — wrong cell references, broken ranges from insertions, copy-paste errors — that go undetected until a downstream number doesn't reconcile. A single misaligned reference in a dragged formula propagates the error across every row.

The deeper problem is that formulas are layout-dependent, not meaning-dependent. An invoice from Vendor A puts Qty in column B and Unit Price in column C. Vendor B uses columns D and F. The formula that works for Vendor A produces nonsense for Vendor B. Every new document layout means adjusting cell references. Ten vendors means ten formula templates to maintain. This is why "save as template" rarely works in practice — the template references cell positions, and cell positions change with every document source.

The gap isn't that formulas are hard to write. It's that they're fragile at scale. At five documents a month from one supplier, formula overhead is trivial. At fifty documents a week from fifteen suppliers, formula management becomes the dominant time cost — and the step most likely to introduce errors that no one catches. Computed columns close this gap by moving the calculation to where the data is first read.

What "Extract and Calculate" Actually Means

Computed columns reverse the sequence. Instead of extracting first and calculating later, the calculation happens inside the extraction pass. You describe the computation in plain English — not formula syntax — and the AI produces the answer alongside the raw data.

The difference is easiest to see side by side:

The mechanism that makes this possible is not formula execution — it's AI reasoning about document context. When you define Line Total (Qty × Unit Price), the AI vision model reads the document, identifies which values are quantities and which are unit prices (by understanding column headers, table structure, and field semantics), and computes the product for each row. It does not reference cell B2 or C2 — it references "the quantity value on this row" and "the unit price value on this row." That semantic understanding is what makes the same instruction work across any document layout from any vendor.

ImageToTable.ai provides two ways to define computed columns:

Both approaches produce the same output — a Line Total column with every value already calculated. The difference is workflow fit. Use column names for quick tests and one-off extractions. Use Rule Format for recurring workflows where clean column headers and detailed computation instructions matter.

This is fundamentally different from tools that try to replicate spreadsheet formulas inside an extraction interface. Those ask you to write something like @MULTIPLY(qty, unit_price) — still a formula, just in a different wrapper, and still fragile when field positions change. Computed columns rely on meaning, not position. "Multiply Qty by Unit Price" works on any invoice because the AI understands what those terms refer to, regardless of where they sit on the page.

Four Dimensions That Decide When the Old Way Breaks

No workflow is universally better. The value of combining extraction and calculation depends on your volume, variety, and complexity. Below is a dimension-by-dimension comparison — not to declare a winner, but to identify the conditions under which the two-step approach stops being the right tool for the job.

The inflection point isn't a clean threshold. It's the combination of volume × variety × complexity that makes formula creation go from "part of the job" to "the part that consumes the time meant for analysis." For someone processing five invoices a month from one supplier, the formula step is a few minutes — and the traditional workflow is fine. For someone processing 30 invoices a week from ten suppliers with cross-row calculations and conditional checks, the formula step is where the afternoon disappears — and what suffers is not just speed, but thoroughness. When formulas take too long, verification gets skipped.

Most teams don't cross this threshold suddenly. The formula overhead creeps up as the business grows — more suppliers, more document types, more people touching the spreadsheet. The moment you notice is usually when a formula error causes a payment discrepancy that someone catches weeks later. By then, you've been over the threshold for months.

Three Scenarios Where the Difference Compounds

Abstract comparisons are useful for framing the problem. Concrete scenarios show where the gap actually surfaces in daily work. Each scenario below contrasts both approaches step by step.

Scenario 1: Invoice Line-Item Verification

A supplier sends an invoice with Qty, Unit Price, and a Billed Total for each line. You need to verify that Qty × Unit Price matches the billed amount — and flag every discrepancy before payment. This is the most common AP calculation in existence, and the one most likely to be skipped under time pressure.

See a full walkthrough in our guide to invoice line-item verification with computed totals.

Scenario 2: Quote Batch Comparison with Section Subtotals

Three subcontractors submit quotes for a project. Each organizes line items differently — one groups by trade section, another by material type, a third by construction phase. You need Line Amount (Qty × Unit Rate), Section Subtotals, and Grand Total for each quote to compare costs.

For the full setup including cross-section aggregation, see scanning subcontractor quotes with computed line amounts.

Scenario 3: Conditional Checks on Irregular Documents

A restaurant receives supplier invoices where volume discounts apply inconsistently. Items with Qty ≥ 10 should get a 5% discount. You need to identify every line where the discount was misapplied — wrong rate or not applied at all — across invoices from six food suppliers, each with different formats.

The same conditional computation applies to food cost analysis. See computing food cost percentages from invoice photos for a related use case.

When the Old Way Still Works (And When It Doesn't)

Computed columns are not a universal replacement for spreadsheet formulas. They solve a specific problem: the calculation bottleneck that appears when extraction volume outpaces formula-building capacity. For many situations, the traditional two-step workflow is still the right choice.

The traditional workflow is perfectly adequate when:

• You process fewer than 10 documents per week from a handful of sources
• Documents share an identical or near-identical layout (single supplier, standardized forms like utility bills)
• Calculations are limited to simple row arithmetic — multiplying two adjacent columns, adding a fixed tax rate
• One person owns the entire workflow, and formula verification is part of their routine

The two-step workflow starts to fail when:

• Document volume exceeds 15–20 per week with layouts that vary by source
• Calculations involve cross-row aggregation, conditional logic, or multi-step derivations where formula complexity grows faster than volume
• Multiple people touch the spreadsheet, raising the risk of accidental formula corruption
• Formula errors carry financial consequences — overpayment, missed billing, compliance gaps
• The person building the formulas is also the person who should be analyzing the results — formula creation consumes the time meant for judgment

What tips the balance is rarely a single factor. It's the combination: volume × variety × complexity. Any one alone is manageable. All three at once is the point where formula management stops being a minor nuisance and becomes the primary constraint on how much work gets done.

The pragmatic approach is not to replace every formula with a computed column. It's to identify which calculations repeat across every batch, which ones break when layouts change, and which ones are complex enough that verification matters — and move those into the extraction step. Leave the one-off calculations and ad-hoc analyses in Excel where they belong. Job sheets with billable amount calculation and payslip net pay computation are examples of calculations that repeat identically across every document — the ideal candidates for moving into the extraction pass.