Validating Numbers, Tables and Calculations

Numbers carry authority. A paragraph of prose invites scepticism; a table of figures with two decimal places does not, and that is exactly why numerical output deserves a dedicated check. This lesson covers how Claude handles arithmetic, where numerical errors creep in, and a reconciliation routine that takes minutes rather than hours.

Two ways Claude produces numbers

It matters a great deal whether a number came from Claude reasoning in prose or from Claude running code.

In prose, Claude estimates. It is reasonable at mental arithmetic and much better than earlier models, but it can slip on multi-step calculations, percentages of percentages, and anything involving many rows. A total produced by "reading" a 200-row table in a PDF should be treated as an estimate.

With analysis enabled, Claude writes a small program, runs it in a sandbox, and reports the result. When it sums a column this way, the arithmetic is as reliable as a spreadsheet. The Claude apps expose this capability (its exact name and the settings toggle have changed over time; business-plan administrators can also enable or restrict it). When you see Claude show code or say it has run a calculation, the figures are computed rather than estimated.

The exam expects you to know the distinction and to prefer computed figures for anything consequential. If you are unsure which happened, ask: "Did you calculate that by running code, or estimate it?"

Where numerical errors come from

Even computed results can be wrong, because the computation can be applied to the wrong thing.

• Wrong column or filter. Claude sums "Revenue" when you meant "Net revenue", or includes cancelled orders.
• Unit and scale mix-ups. Thousands versus units, pence versus pounds, fiscal versus calendar year.
• Date handling. Ambiguous formats (03/04/2025) read as the wrong month.
• Duplicate or missing rows. A spreadsheet export with a subtotal row included in the sum.
• Percentages. A change from 20% to 25% is five points or 25%, and Claude will pick one unless told which.
• Rounding drift. Rounded components that no longer sum to the rounded total.
• Transcription. Numbers copied from a chart image or scanned PDF can be misread.

Notice that most of these are specification errors, not arithmetic errors. The prevention is the same as elsewhere: describe the data, state the question precisely, and ask Claude to show its working.

The reconciliation routine

For any set of figures you intend to use:

1. Anchor to a known total. Pick one number you already know (last month's total, the headcount, the invoice total) and confirm Claude's figure matches. If the anchor is wrong, everything downstream is suspect.
2. Recompute one figure independently. Open the source and check a single row or sum yourself.
3. Check internal consistency. Do the parts add up to the whole? Do the percentages sum to roughly 100? Does the trend direction match the narrative?
4. Sanity-check magnitude. Is a 340% increase plausible, or is it a scale error? Would a colleague believe this number at a glance?
5. Confirm the definition. Ask what was included and excluded, and compare to how your organisation defines the metric.

Five steps, usually under ten minutes, and they catch the overwhelming majority of real-world problems.

Prompting for checkable numbers

Attached is the Q3 sales export. Column definitions: "Amount" is in
GBP excluding VAT; "Stage" is the deal stage; "Close date" is
dd/mm/yyyy. Ignore rows where Stage is "Cancelled" or "Duplicate".

Calculate total closed-won revenue by region. Run the calculation
rather than estimating. Show: the filter you applied, the number of
rows included and excluded, and the result as a table. Then state the
grand total so I can reconcile it to our finance figure of £2.41m.

Every one of the common error sources is pre-empted: units, dates, exclusions, method, and an anchor for reconciliation.

Tables, charts and generated files

Claude can produce tables in the chat, create downloadable spreadsheets and build charts. Three cautions. A chart inherits every error in the data behind it, so validate the data first. A generated spreadsheet may contain values rather than formulas unless you ask for formulas, which matters if colleagues will update it. And a polished layout is not evidence of correctness; evaluate the numbers with the same rigour whether they arrive as plain text or a formatted file.

Scenario: the pricing slide

A marketing manager asks Claude to calculate the saving customers make on the annual plan versus monthly. Claude, working in prose, states "customers save 20%". The manager checks: monthly is £25, annual is £240, so the saving is £60 on £300, which is 20%. Correct. Then she asks for the same for the premium tier, and Claude reports "15%". She checks: £45 monthly, £460 annual, saving £80 on £540, which is 14.8%. Claude rounded, which is fine for a slide but not for a contract. She adds "to one decimal place and show the calculation" to her prompt and uses the computed version. Small example; the habit is what matters.

Exam focus

• Numbers Claude produces in prose are estimates; numbers it produces by running code are computed, and the latter should be preferred for anything consequential.
• Most numerical errors are specification errors (wrong column, filter, unit, date format or definition), not arithmetic errors.
• The reconciliation routine: anchor to a known total, recompute one figure, check internal consistency, sanity-check magnitude, confirm the metric definition.
• State units, date formats, exclusions and the metric definition in the prompt, and ask Claude to show rows included and excluded.
• Charts and formatted files inherit data errors; polish is not evidence of correctness.