Insights

Useful data work starts with useful questions

Short, practical notes on reporting, data quality and the systems behind dependable numbers.

Reporting · 5 minute read

Why do two reports show different numbers?

When teams disagree on a number, the cause is often a difference in definitions, timing or source data.

Before comparing totals, write down what each report counts. “Sales” might mean orders placed, invoices issued, cash received, or deliveries completed. The same label can hide different business events.

Trace the difference in four steps

  1. Align the definition. Name the event being counted, the date field used, and how refunds, cancellations and adjustments are treated.
  2. Align the time window. Confirm the timezone, start and end dates, and whether the report includes late-arriving transactions.
  3. Check the grain. Determine whether a row represents an order, invoice line, payment, customer or daily summary. Joining different grains can duplicate values.
  4. Reconcile a small sample. Follow a few records from source to report and explain each difference before comparing the full totals.

Once a metric has a shared written definition and a traceable source, teams can spend meetings discussing the decision instead of reconstructing the spreadsheet.

Data foundations · 4 minute read

Starting a data warehouse? Pick one report first.

A small, well-defined first delivery is easier to validate and maintain than an attempt to model every system at once.

Begin with one recurring report that takes meaningful effort or supports an important decision. Identify who uses it, when they need it, what sources feed it and what they do when a number changes.

A focused first release can include

  • A written definition for the report’s key metrics.
  • A scheduled extract from the agreed source systems.
  • A clean, documented table shaped around the business concepts in the report.
  • Checks for missing data, duplicate records and unexpected changes.
  • A comparison against the current report, with differences explained before the new output becomes the source of truth.

After that report is trusted, the same source connections and definitions can support the next use case. The aim is a foundation that grows with real needs and that the team can operate.

Data quality · 4 minute read

Five checks every scheduled data load should make

A pipeline is not reliable just because it ran. It should tell you whether the data it produced is usable.

  1. Did the load arrive? Track the last successful run and the latest source date. Alert when expected data is late.
  2. Did row counts change unexpectedly? Compare current counts with a reasonable baseline and investigate large jumps or drops.
  3. Are required fields present? Check keys, dates and values that downstream reports depend on.
  4. Are records unique at the expected grain? Flag duplicate keys before they inflate totals.
  5. Do important values stay within plausible bounds? Check amounts, dates and categories for impossible or unfamiliar values.

Checks should be tied to an owner and a response. A useful alert identifies which source or rule failed, where to inspect the records, and whether reports should be held until the issue is resolved.

In the medicine ETL example, rejected rows are saved for review instead of disappearing silently.

Want to make one report more dependable?

Tell us where its data comes from and what is difficult about producing it today.