Data Quality and Governance Checklist for Kenyan Teams

McTaba runs coding and data bootcamps in Kenya. This guide is written to be useful whether or not you ever join one.

Picture the Monday meeting. The sales sheet says 412 orders. The M-Pesa statement says 397 payments. Finance and sales each trust their own file, and the meeting becomes an argument about whose file is right.

Nobody is lying. The sheet has the same customer typed three ways. Two rows share one M-Pesa code. A date reads 03/11 to one person and 11 March to another. These are data quality faults, and they are cheap to find once someone looks for them on purpose.

This checklist is for the person who owns a team report: a finance lead, a branch manager, an HR officer. You do not need code. A spreadsheet filter and a calm half hour per report will catch most faults. If your analysts later want to automate the checks, the M-Pesa statement analysis in Python shows how.

The wider career picture for people who work with this kind of data is in the data science career guide for Kenya.

Run them top to bottom. Each takes minutes on a sheet of a few thousand rows.

1. Completeness: are the blanks where they should be?

Filter each important column for empty cells. A customer phone number blank on 8 rows out of 400 is a problem. A blank "notes" column is not. Decide which columns must never be empty and write them down. Typical must-fill columns: date, amount, customer or staff ID, payment reference.

2. Duplicates: is any row there twice?

Sort by the payment reference or order number and look for neighbours that match. In Excel, use Remove Duplicates on a copy, never on the original. Count what was removed and write the count on the report. Duplicates often arrive when two people export the same week and paste both.

3. M-Pesa reference matching: does every payment have a partner?

Every M-Pesa confirmation carries a transaction code, a ten-character mix of letters and digits. Put your sales list beside the Safaricom statement and match on that code. Three outcomes matter. A sale with no payment may be an unpaid order. A payment with no sale may be money sitting unexplained. A code that appears twice needs a human to look at it.

4. Dates: does every row use one format and one time zone?

Pick one format, such as 2026-11-03, and convert everything to it. Watch for text that looks like a date but sorts like a word. Watch for month-end entries that landed in the next month because a payment cleared after midnight.

5. Totals: do the sums agree with the source?

Add the amount column and compare it with the total on the bank, till or Paybill statement. A gap of a few shillings can be rounding. A gap of 40,000 shillings is a missing batch. Record the gap and its explanation, even when the gap is zero.

6. Ownership: whose name is on this report?

If nobody owns the file, nobody fixes it. The last check is a name and a date in the top corner of the sheet: who made it, from which source, and when it was last checked.

A checklist without owners is a poster on a wall. Use this table as a starting point and rename roles to fit your office.

Check	Owner	How often	Proof to keep
Completeness	Person who enters the data	Every entry day	Count of blanks in must-fill columns
Duplicates	Report owner	Weekly	Rows removed, with reason
M-Pesa reference matching	Finance officer	Weekly, then at month end	List of unmatched codes and their status
Dates	Report owner	Monthly	Format note on the sheet
Totals against source	Finance lead	Monthly	Statement total, report total, gap
Ownership and sign-off	Department head	Monthly	Name and date on the report

Data entry sits at the front for a reason. A blank caught at the till costs seconds. The same blank caught at month end costs an afternoon.

If your team wants to learn to run these checks faster, with SQL and Python instead of filters, our data analytics training for your team is built around reports like these.

Governance sounds heavy. For a small or mid-sized Kenyan team, one page is enough. Write down four things and pin the page where people work.

• Source of truth. For each number, which system wins when two disagree? Usually the bank or Safaricom statement beats the sales sheet.
• Who can change it. Name the people allowed to edit the master file. Everyone else gets a read-only copy.
• Where it lives. One shared folder, with dated file names such as sales_2026-11.xlsx. No "final_v3_REAL" files on personal laptops or WhatsApp.
• What is personal. Customer phone numbers and ID numbers are personal data. Limit who sees them and do not paste them into public chatbots. The legal side is covered in our guide to anonymising personal data in Kenya.

Review the page twice a year. When a new report appears, add a line for it.

Manual checks work until the file passes about ten thousand rows or the report runs weekly. Then the half hour becomes a half day, and people skip steps.

That is the moment to move the same six checks into a short script that runs on every new export and writes a one-line result: "397 payments, 3 unmatched, 0 duplicates, gap 0". The logic does not change. Only who runs it does. A team member who can write that script is worth more than another analyst, and the skills are learnable. See the pandas tutorial with a Nairobi shop's sales data for the first steps.

Once the numbers are trusted, the next problem is showing them well. The data storytelling guide covers that.

If you want your finance, sales and operations staff to share these habits, see our data analytics training for your team. We build the exercises from your own anonymised reports.