Making Sense of a Spreadsheet Without Knowing SQL

Before you trust a number, find out whether the tool computed it or described it. One of those is arithmetic you can check; the other is a sentence about your data that happens to contain a figure.

Two very different things called analysis

The distinction is the most useful thing on this page. Ask the tool directly: “did you calculate that by running code, or by reading the data? Show me the code if there was any.” If no code was run and the file has more than about fifty rows, treat every number as a guess.

A quick test that settles it: ask for the exact row count and the sum of one numeric column. Check both against your spreadsheet’s own COUNTA and SUM. A computed answer matches exactly. A described one is close, which is worse than being obviously wrong, because close numbers get used.

Preparing the sheet

Most wrong answers are caused by the file rather than the tool. Ten minutes here changes the reliability of everything downstream.

1. One header row, at the top, with real names. No merged cells, no title banner above the headers, no second header row halfway down. Order date beats Column F because the model uses the name to decide what the column means.
2. One kind of thing per column. A column holding “120”, “120 units” and “n/a” is three columns badly stored. Anything non-numeric in a numeric column silently changes what a total means.
3. Dates in one format, ideally 2026-08-04. Mixed British and American dates in one column is the most common silent corruption in spreadsheets: 03/04 and 04/03 are both valid and nothing warns you.
4. Remove the totals row. A totals row at the bottom gets counted as data, which doubles every sum. Rename it or delete it before you upload.
5. Export to CSV if you can. Formulas, hidden sheets, filters and formatting do not survive the trip, and what you see is not necessarily what gets read.

Asking a question that has an answer

“Analyse this data” produces a paragraph of observations, none of which you asked for. Ask something with a definite answer, and define the terms, because the definitions are where the disagreement lives.

Using the attached file, answer this by running code and showing me
the code:

Question: what was the total value of completed orders placed in
Q2 2026, by sales region?

Definitions:
- "completed" means the Status column is exactly "Complete".
  Do not include "Complete - returned".
- "placed" uses Order date, not Dispatch date.
- Q2 2026 is 1 April to 30 June 2026 inclusive.
- Value is the Net column. Ignore Gross entirely.
- Exclude rows where Region is blank, and tell me how many you
  excluded.

Report: the table, the total, the number of rows used, and the
number of rows excluded for any reason.

The row counts are not pedantry. They are the check: if 4,000 rows went in and 1,200 were used, either your definitions are narrower than you thought or something went wrong in parsing, and either way you want to know before the number reaches a meeting.

The verification step

Three checks, two minutes, every time. Skipping them is how a wrong number gets into a board pack, and no amount of prompt quality substitutes for them.

1. Reconcile the counts. Rows used plus rows excluded must equal total rows. If they do not, the analysis silently dropped something — usually a date it could not parse.
2. Recompute one cell yourself. Pick the smallest group, filter the spreadsheet by hand, and sum it. If the smallest group matches, the method is probably right; if it does not, nothing else in the table is worth reading.
3. Sanity-check the shape. Does the total look like your business? Is the biggest region the one you would expect? A result that contradicts what you know is either a genuine finding or an error, and it is an error far more often.

If code was produced, read the filter lines even if you cannot read code in general. status == "Complete" is legible to anybody, and a wrong filter is the single most common defect.

Five questions worth asking of most data

If you do not know what to ask, these five apply to almost any table of business records and each has a definite answer. Ask them one at a time, with the definitions spelled out as above.

Ask outliers and missingness first. Both are quality checks disguised as analysis, and both regularly reveal that the answer to the question you originally cared about would have been wrong.

Getting a chart worth showing

Charts are generated eagerly and badly by default: a pie chart of nineteen categories, or a line chart of unsorted dates. Specify.

Chart the result as a horizontal bar chart, regions sorted by value
descending. Axis labels with units. No legend - the categories are
on the axis. No colour gradient. Include the underlying numbers as
a table underneath so I can check the chart against them.

Always ask for the numbers alongside the chart. A chart is a claim about data and it is very hard to audit visually; the table under it is what makes it checkable.

Six ways the answer is wrong

• Silent filtering. Rows dropped because a date would not parse or a number contained a currency symbol. The stated total is arithmetically correct over a subset nobody chose. The row-count reconciliation catches this.
• The wrong column. Gross taken for net, list price for sale price, order date for dispatch date. Caused by columns whose names do not distinguish them clearly.
• Duplicates counted. Exported systems repeat header rows and export line items as separate rows. A count of “orders” is often a count of order lines.
• Category strings that differ. “North”, “north” and “North ” with a trailing space are three regions. Ask for the list of distinct values in any column you group by, before grouping.
• Date ambiguity. Covered above and worth repeating: it is the failure that produces a wrong answer with no symptom at all.
• Causal language. The analysis is descriptive and the prose around it will not be. “Sales fell because of the price change” is not supported by a table showing sales fell after a price change, and the sentence will appear anyway.

Where to stop

Descriptive questions — how much, how many, which is largest, how has this changed — are well within reach with the checks above. Statistical inference is not. Significance tests, forecasts, seasonal adjustment and anything with a confidence interval will be produced on request, competently formatted, and you will have no way to tell whether the assumptions behind them hold for your data. The errors here are subtle and consequential; the common ones are catalogued in statistics people get wrong about AI, and they are the same errors.

Stop also where the data is about identifiable people. A spreadsheet of customers, patients or staff is personal data and uploading it is a decision with legal consequences, not a technical convenience. Aggregate or pseudonymise first, and if that is not possible, do the analysis in your spreadsheet.