How to Analyse Sales Data: getting a straight answer out of your own numbers

Start with one question you already argue about, not a dashboard. Pull the smallest table that answers it, check the total against something you trust, then ask why. AI can now write the query for you. It cannot tell you whether the number it returned is the number you meant.

Most sales data never gets analysed. It gets exported, looked at, and closed again. Not because owners are lazy about it, but because the job is usually framed backwards: build the reporting first, find the insight later. That order rarely survives a busy month.

Here is the order that does, what changed in the last two years about the machine's half of the work, and the check that stops a confident wrong answer from becoming a decision.

Start with an argument, not a dashboard

Every business has two or three recurring arguments that never quite resolve. Which product actually makes money once you count the time. Whether the quiet month is seasonal or a trend. Whether discounting brought in customers who came back.

Those arguments are the analysis brief. They are specific, someone cares about the answer, and the answer changes a decision. A dashboard built before you have one of those is a screen nobody opens twice.

Pick the one that costs you the most to keep arguing about. Then pull the smallest set of columns that could settle it. For most sales questions that is date, customer, item, quantity, value, and the person or channel it came through. Six columns settles more arguments than sixty.

The machine can write the query now, and that moved the hard part

The most useful public measure of how well software can answer a question about a real business database is the Spider 2.0 benchmark, built by a group of academic and industry researchers. It is not a vendor study. It sets language models against real enterprise data environments, some with more than 3000 columns, across dialects like BigQuery, Snowflake and SQLite, and scores whether the answer produced is actually correct.

When Spider 2.0 was published in November 2024, the results were bleak. The strongest model tested, o1-preview, solved 17.1 percent of the tasks. GPT-4o solved 10.1 percent, against 86.6 percent on the older and much tidier Spider 1.0. The conclusion at the time was obvious: asking software a question about your real data did not work.

Those figures get quoted constantly. They should not be, and not only because they are old. On 22 May 2025 the maintainers removed the original Spider 2.0 setting entirely and replaced it with a repository level task called Spider 2.0-DBT. The test that produced the 17.1 percent no longer runs. There is no current score for it, and there cannot be one.

What exists instead is three tracks, read directly from the public leaderboard on 9 September 2026:

Track	What it asks of the system	Best score
Spider 2.0-Snow	547 questions against databases with prepared metadata and documentation	96.70%
Spider 2.0-Lite	547 questions across BigQuery, Snowflake and SQLite	76.23%
Spider 2.0-DBT	68 project level tasks requiring the system to read a real codebase and hold long context	65.6%

Read the spread, not the top line. Roughly 31 points separate the best result on the tidiest track from the best result on the messiest one. These are not identical tasks, and the DBT track is a smaller set of 68 examples testing project code work rather than a single question, so the comparison is directional rather than exact. But the direction is the whole point, and it is consistent: the same class of system, pointed at data that is documented and prepared, answers almost everything, and pointed at a real working environment it misses about a third.

Which means the honest summary is not "AI got good at this". It is narrower and more useful than that. On data that has been prepared, documented and kept consistent, this problem is close to solved. On data that has not been, it is not. Those are the same systems. The difference is the preparation.

The variable that moved is not the intelligence of the model. It is the state of the data underneath it. That is good news for a small business, because the state of your data is the part you control.

Three questions worth asking of your sales numbers

These are the ones that tend to change behaviour rather than confirm it.

1. What does the same customer do in month two? Total revenue hides whether you are selling to new people every month because the old ones did not come back. Group by customer, then by the month of their first purchase, and look along the row rather than down the column.
2. Which line items are busy rather than profitable? Sort by volume and by value separately. When the top of one list is nowhere near the top of the other, you have found where the effort goes and the margin does not.
3. How long does a sale actually take? The gap between first contact and payment is usually longer than anyone in the business believes, and it is measurable from records you already keep. It is also the number that most directly explains a cash flow that feels worse than the sales figures suggest.

None of these need a new system. They need the records you already have to sit in one place, with dates that are real and a customer identifier that is consistent.

What has to be true of your data first

This is the part that decides whether any of the above works, and it is the part that gets skipped.

An answer is only as good as the record it reads. If the same customer exists three times because the name was typed three ways, no model and no analyst will give you a correct month two number. If a sale is captured in a quoting document, retyped into an invoice, and retyped again into a spreadsheet, then you have three versions of one fact and no way to tell which one the answer came from.

The fix is structural and it is dull. Capture each fact once, at the point it first exists, and let every downstream step read from that record instead of a copy of it. A sale entered once in NexCRM carries its own date, customer and value into the invoice and the report without anyone retyping it. Costs photographed once into NexSync arrive already categorised, so the margin question has both halves of its arithmetic. The prompt to look comes from the system, not from someone remembering on a Sunday.

That is the difference between the tidy track and the messy one, in the only version of it that matters to you. We have written separately about finding the places your team types the same fact twice, and about producing the recurring report without rebuilding the spreadsheet. This post is the other half: not producing the report, but interrogating what is in it.

Where AI data analysis helps, and where it quietly does not

AI data analysis genuinely helps with the mechanical translation. Describing what you want in plain language and getting a working query or a correct pivot back is now reliable enough to use daily, and it removes the skill barrier that kept most owners out of their own numbers.

It does not help with the two things on either side of that. It cannot tell you which question is worth asking, because it does not know which argument is costing you money. And it cannot tell you that an answer is wrong in a way that looks right, which is the failure mode that matters. A query can run perfectly and still count cancelled orders, or double count a customer, or silently drop the rows with a missing date.

So keep one habit: before you act on a number, check its total against something you already trust. Bank deposits for the month, the VAT return, the invoice count. If the two disagree, the disagreement is the finding. This is the same discipline that separates the AI projects that survive contact with a real business from the ones that quietly get abandoned.

Frequently Asked Questions

Do I need a data warehouse to analyse sales data?

No. Most small businesses have fewer rows than a spreadsheet handles comfortably. A warehouse solves a scale problem you probably do not have. Consistency of records solves the problem you do have.

Can AI analyse my sales data accurately?

It can translate a question into a correct query with high reliability when the underlying data is documented and consistent. On messier real world environments, published benchmark results still show roughly a third of tasks answered incorrectly.

How often should I actually look at sales numbers?

Monthly for trend questions, weekly only for something you would genuinely act on within the week. Looking more often than you can act creates noise and, in practice, makes people trust the numbers less.

What is the first report to build?

Do not build a report first. Answer one live argument with a single table, then keep only the tables that changed a decision. Reports built that way get read, because someone already wanted the answer.

Why do my system totals not match my bank?

Usually timing or duplication. Sales recorded on invoice date against money received on payment date will never match within the same month, and one customer captured twice inflates both counts. Check those two before assuming a deeper problem.

The short version

The software half of this problem got solved while most people were not watching. Asking a question of your own numbers no longer requires a specialist, and the benchmark evidence for that is public and recent. What remains is the part that was always yours: one fact captured once, a consistent customer record, a real date, and a question somebody actually wants answered.

If you want to know which of your numbers currently exist in three places at once, that is what a Business Autopsy looks for. We map where the same fact gets entered more than once, and what it would take to stop.

Sources: Spider 2.0 benchmark and public leaderboard, spider2-sql.github.io, read directly on 9 September 2026. Baseline figures from Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows, arXiv:2411.07763, November 2024.