You get handed a table you did not build. Someone says the numbers are in there somewhere, and you are expected to have an answer by Thursday.
Most reporting mistakes do not come from bad math. They come from trusting a dataset that was never worth trusting in the first place.
Here are the checks worth running before a table becomes the basis of a real decision.
Start With Where the Numbers Came From
Follow the table back to its origin
Every table is the end of a chain. Something raw came in, something happened to it and what you are querying is whatever came out the other side.
If you do not know what that chain looks like, you are trusting the table on faith. Ask which source systems feed it and what happens to the data between arrival and the version sitting in front of you.
Teams that maintain automated Data Lineage across their stack can follow that path from raw source to final table without reading through pipeline code. If you do not have that, the fallback is finding whoever wrote the transformation and asking them directly.
Watch for joins and filters that changed the population
This is the one that catches people out. A filter applied three steps upstream can quietly remove an entire category of rows.
The table is still accurate. It just answers a slightly different question than the one you think you are asking.
Check whether anything upstream excluded test accounts, refunded orders, internal users or a specific region. Those exclusions are usually sensible, but you need to know they are there.
Look at How Recently It Was Refreshed
Separate the load timestamp from the event timestamp
These two get confused constantly. One tells you when the row landed in the warehouse. The other tells you when the thing actually happened.
A report can look completely current and still be describing last week. Make sure you know which one you are filtering on before you write the query.
Find out what the refresh cadence is supposed to be
Then check whether it is actually holding. A broken pipeline rarely announces itself. The table still returns rows; they are just old ones.
Row count is the easiest tell. If it has not moved in two days on a table that loads daily, something upstream has stopped, and nobody has noticed yet.
Find Out Who Is Responsible for It
Look for a named owner, not a team inbox
Datasets without a clear owner drift. Nobody updates the logic, nobody spots it when it breaks, and nobody can tell you what a particular field means.
If you cannot find a name attached to the table, treat that as information in itself. It usually means the thing has been running unattended for a long time.
Check whether it is still being maintained
Deprecated tables have a habit of sticking around well past their retirement date. You will often find three versions of the same dataset sitting next to each other with nothing to indicate which one won.
Ask which one is current before you build anything on top of it. The newest name in the list is not always the right answer.
Confirm the Definitions Match What You Assume
Read the column descriptions before writing the query
Field names are shorthand. They tell you roughly what a column holds, not the business rule sitting behind it.
Take a field called active_user. One team counts anyone who logged in this month. Another counts anyone who completed a core action, and both columns carry the same name.
Ask which version of a metric you are looking at
Revenue is the classic example. Finance calculates it one way, the product team calculates it another, and both are correct within their own definition.
The same thing happens with operational numbers, which is why any decent guide to performance metrics starts by pinning down what each one actually measures. Skip that step and two teams end up reporting different figures for what looks like the same thing.
If your number is going to sit next to somebody else's number in a deck, work out which definition yours uses first. That conversation is much easier before the meeting than during it.
Test It Against Something You Already Know
Cross-check one small slice
You do not need to validate the entire table. Pick a period or a segment where you already know the right answer and see whether the data agrees with you.
Last month's total for a single region is usually enough. If that lines up, your confidence in the rest of the table goes up fast.
Look at the shape, not just the totals
Totals hide a lot. Check null rates on the columns you care about, look for duplicate rows, and scan how the distribution moves over time.
It is unglamorous work. Cleaning and validation take up most of the data analytics process, and shape problems tend to surface there long before anyone questions the totals.
A metric that jumps sharply on one specific date is worth a closer look. In my experience, that is almost always a pipeline change rather than something real happening in the business.
Wrapping Up
None of this takes long. Most of it is a handful of quick queries and a few minutes spent reading metadata that somebody already wrote.
The payoff is that you never have to walk back a finding in front of a room full of people. And when someone questions your number, you can explain exactly where it came from and why it holds.
That is a far better place to be than quietly hoping the table was fine.
