Before You Build a Dashboard: A Data Quality Checklist

A dashboard can make business figures easier to read. Before those figures can support a decision, you need to know what they represent, where they came from and which checks they have passed. A repeated order, an unresolved status or a different reporting period can change a total even when the chart looks convincing.

This data quality checklist is for business owners, administrators and managers preparing spreadsheets for reporting. It follows the practical approach in Before You Build a Dashboard, our standalone e-book on clean, reliable business data.

Start with one report and one question. Work through the checks below, keep a record of unresolved issues and make the limitations visible to the person who will use the result.

1. Define the question and what one row represents

Write down the decision the report needs to support. For example, “How many verified completed orders were placed in September?” is more specific than “Show us sales performance.” It tells you that the order date and completion status matter.

Next, confirm what one row represents. An order register, an order-line table and a delivery history contain different kinds of records. Three product lines on one order should not automatically become three orders in the dashboard.

Agree the identifier at that level. An order table might use an order ID; an order-line table may require an order ID plus a line ID. Confirm the rule with the source owner before counting or removing records.

2. Preserve the source and confirm its coverage

Keep an unchanged export and work on a separate copy. Record the source, owner, extraction time, applied filters and reporting coverage. A file named “all orders” may already exclude archived entries or a particular branch.

Check that the expected columns are present. Note the data-row count and date range before making corrections. These controls give you a starting point for explaining what changed.

Also ask whether the source process changed. A new form, optional field or renamed status can create an apparent business trend. If one month covers three branches and the next covers four, the totals require that context before you compare them.

3. Investigate duplicates before removing them

Repeated values are a reason to investigate. Two orders can share a customer name, and one order can have several delivery events. Neither observation proves that a record should be deleted.

Compare repeated keys at the agreed row level. An exact copied order may be a duplicate export entry. The same order ID with different amounts or statuses is a conflict that needs evidence about which record is authoritative.

Record the affected source rows, the confirmation you received and the effect of any exclusion. Keep the preserved source intact. A later reviewer should be able to follow the decision without relying on the preparer’s memory.

4. Keep missing values separate from measured zeros

A blank amount is not evidence of a zero-value order. It might mean the value was not collected or is awaiting confirmation. Filling every empty cell with zero can change the meaning of a calculation.

Consider four measured response times of 2, 4, 6 and 8 hours. Their average is 5 hours. If a fifth response time is missing, inserting zero changes the average to 4 hours and makes the service look faster without supporting evidence.

Use field-specific rules. An optional note may remain blank, while an unresolved amount may block a value total. If an order has no verified status, keep it in an exceptions list and decide explicitly how that uncertainty affects release.

5. Check dates, data types and units

Confirm which event date the report uses. Orders placed in September, deliveries completed in September and payments received in September are different populations. The date when you downloaded the file does not determine the period of each event.

Inspect ambiguous dates, records at the period boundaries and unexpected future dates. For timestamped systems, agree the reporting timezone. For date-only data, document the calendar-date rule.

Check amounts and identifiers too. An amount must have the expected numeric representation and a known currency. A customer code with leading zeros may need to remain text. Changing how a cell looks does not establish that its underlying value or meaning is correct.

6. Write metric definitions and check table relationships

A metric needs a definition covering its population, units, date basis, calculation, exclusions, source and owner. A measure called “completed-order value” should not quietly become “revenue” or “cash received” in the chart title.

For percentages, define both the numerator and denominator. If one branch completes 8 of 10 eligible orders and another completes 1 of 2, the combined rate is 9 out of 12, or 75%. Averaging the branch percentages gives 65%, which answers a different question by giving both branches equal weight.

When combining tables, check matching keys and record counts. Adding three delivery events to one order can repeat its amount three times. Reconcile before and after the join so additional detail does not silently inflate the total.

7. Reconcile the result and approve unresolved exceptions

Explain how the source becomes the reporting result. Reconcile row counts, distinct identifiers and relevant amounts. State the order of your rules so that the same record is not excluded twice in the explanation.

Assign each unresolved issue an owner and a next action. Decide which problems block release and which can be disclosed in a provisional report. That decision depends on the report’s purpose and the possible effect of the issue.

This approach is consistent with the emphasis on fitness for purpose, documented quality issues and communication in the UK Government Data Quality Framework. It is a useful reference for the underlying concepts; applying this checklist does not certify a dataset or replace specialist review where required.

A worked example from Before You Build a Dashboard

The e-book follows a fictional order register for Cedar Office Supplies. Adding all eight source rows produces ZAR 6,750. The question, however, concerns verified completed orders placed in September.

After checking the records and confirming the rules with the fictional source owner, the reporting bridge is:

• Start with the sum of all source rows: ZAR 6,750.
• Exclude one confirmed duplicate copy: minus ZAR 1,200.
• Exclude an order dated in October: minus ZAR 900.
• Exclude a cancelled order: minus ZAR 600.
• Hold an order with an unresolved completion status outside the verified subset: minus ZAR 450.
• Report ZAR 3,600 across four verified completed orders, with a provisional status because the unresolved order remains outstanding.

The excluded categories do not overlap in this teaching example. The eight source rows are accounted for as four included rows and four other outcomes: duplicate, outside the period, cancelled and unresolved.

If the unresolved order is later verified as completed, the measure becomes ZAR 4,050 across five completed orders. That change needs a recorded correction and a revised report version.

These figures are fictional teaching data. They are not a client result, an accounting revenue calculation or evidence that business performance improved. The lesson is to make the population and corrections explainable before visualising the result.

Explore the complete 37-page e-book

Before You Build a Dashboard: A practical guide to clean, reliable business data develops this method across seven chapters. It includes original teaching tables, the full fictional case, exercises with worked answers, checklists, a glossary and references.

It is written for business owners, administrators and managers who want a clearer foundation for reports. No coding or dashboard software is required to read it. You can use your own spreadsheet application if you want to practise the examples.

The e-book is available for a one-time base price of R149. It is delivered as one searchable, bookmarked PDF. The purchase does not include a workbook, software licence, live data connection, automated cleaning tool or consulting time.

You can read the free four-page sample before deciding whether the book fits your task. The product page explains its contents, requirements and licence.

Questions about the e-book

Is this an Excel or Power BI course?

It is a standalone PDF e-book about preparing business data for reporting. Its methods can inform spreadsheet and dashboard work, but it is not a software course and does not include a workbook or dashboard template.

Do I need a separate store account?

Your existing website account works in the store. After payment confirmation, use the same account to open My downloads and access the PDF. An already signed-in visitor can continue using that session.

Can I buy it outside South Africa?

The store offers ZAR, USD, EUR and GBP display options. Foreign-currency displays are approximate reference conversions; Payfast confirms the final payment currency and amount. Foreign-currency payments require a credit card.

Who may use the purchased copy?

The licence is for the purchasing individual. You may keep a personal copy, print a personal working copy and apply the methods at work. The book may not be resold or publicly redistributed. Contact The Spokesdude Network about team or classroom copies.

Choose your next reporting step

If you are preparing a report yourself, explore Before You Build a Dashboard and use the sample to assess the approach. For broader context, read our article on why trusted reporting starts with clean data.

If your organisation needs help resolving its source data, definitions or reporting process, discuss the reporting task with The Spokesdude Network. Start with the question you need to answer and the issues you have identified.