Data you can report honestly.

Define every number before you count it

Most reporting errors are not arithmetic. They are two people counting different things under the same name.

Keep a short data dictionary: one line for every number you report, written so that a new member of staff would count it the same way you do.

The template adds columns for where each number comes from, who owns it, the funder’s definition and a change log.

• People are not visits. Decide whether each measure counts distinct people, contacts or events, and say so in the name.
• Write down the period and the cut-off. “Served in the quarter” needs a start date, an end date and a rule for records entered late.
• Keep the funder’s definition beside yours. When a funder defines a measure differently, record both and map one to the other. Do not quietly change your own.
• Log every change. When a definition changes, note the date and say so in the next report, so this year’s figure is not compared with last year’s as if they were the same.

Download the data dictionary template (CSV)

One source of truth

If the same number lives in three spreadsheets, it has three values.

• Choose one system of record for each kind of information: people, services, outcomes, money. Everything else is a copy or a report drawn from it.
• Count from records, not from tallies kept on the side. A report should be reproducible: the same query over the same period gives the same answer.
• Give every person and every record a unique reference, and use it everywhere. Names are not unique and change.
• Store dates in one unambiguous format, such as 2026-10-18, so 03/04 is never read as two different days.
• When you submit a report, keep the export or query you used, with the date and the name of the person who ran it. If a funder asks next year how you arrived at a figure, you can show them.

Check quality before you report, not after

The UK government’s data quality framework uses six dimensions. They work as a pre-report checklist for any organization.

Fix problems in the system of record, not in the report. A correction made only in a spreadsheet will be lost next quarter.

Using people’s information in reports

People gave you their information to get help. Reporting about them is a different use, and it needs thought.

• Say it at the start. Tell people when you collect their information that you report to funders, what you report and in what form. In the UK, the ICO’s guidance is that personal information may only be reused for a new purpose if that purpose is compatible with the original one.
• Numbers and stories are different. Properly de-identified totals usually tell a funder what they need. Individual stories, case examples, quotes and photographs are personal information and need more care.
• Ask separately for stories. If you want to use someone’s story, ask on its own, in plain words, for that specific use. Under the UK GDPR, consent has to be freely given, specific, informed and unambiguous, and as easy to withdraw as to give.
• Never make help depend on it. People who rely on your service may not feel free to say no. The ICO notes that consent is harder to rely on where there is an imbalance of power. Make sure refusing changes nothing about the service they receive.
• Push back on client-level requests. If a funder asks for names, dates of birth or case notes, check your grant agreement, your privacy notice and the law first, and ask whether totals would do. If you must share, send only the fields needed, under a written agreement, by a secure route rather than an email attachment.

General information, not legal advice. Privacy law differs by country: see privacy duties, country by country.

De-identification basics

Removing names is not the same as making data anonymous.

Direct identifiers name a person on their own: name, address, phone number, email, ID numbers. Indirect identifiers do it in combination: date of birth, postcode, job, a rare condition, the date something happened. Three or four indirect identifiers together can single out one person in a small community.

• Pseudonymised is not anonymous. Replacing names with codes while you keep the key still leaves personal data. The ICO is explicit that pseudonymised information is still personal data and the law applies to it.
• Generalise. Age bands instead of dates of birth, region instead of postcode, month instead of date. The ICO describes generalisation as reducing the precision of data by grouping or rounding it.
• Suppress. Remove rare values and outliers that make one person stand out.
• Apply the motivated intruder test. The ICO asks you to consider whether someone determined to identify people, using information that is reasonably available to them, could do it. Think about who knows the people in your data: neighbours, family, other clients, your own staff.

For larger or public datasets, NIST’s guidance on de-identifying government datasets sets out techniques and governance in detail.

Small numbers

A count of one or two in a small group can identify a person as surely as a name.

“Of our three clients aged over 80 in the village, one disclosed abuse” tells everyone in the village who it was. Statistical agencies deal with this through disclosure control: rules that stop small counts being published. You can do the same.

• Set a threshold and write it down. Choose a minimum count below which you do not show the number, and show “fewer than” the threshold instead. Statistical agencies choose their own thresholds for their own data; ask your funder whether they have a rule, and apply yours every time.
• Protect the totals too. If one cell is hidden but the row total is shown, the hidden number can be worked out. Hide a second cell, or combine categories.
• Combine categories. Merge small groups (age bands, areas, ethnic groups) until each has enough people in it.
• Careful with percentages. “50%” of a group of two is one person. Show the base, and do not publish percentages of very small groups.
• Maps, charts and quotes count. A dot on a map or a distinctive quote can identify someone as easily as a table.

Reporting honestly when the numbers disappoint

Funders tend to trust organizations that explain their numbers, including the bad ones.

• Report against the definitions you agreed, and say plainly when something changed.
• Say what is missing. How many participants you have outcome measures for, out of how many, and why the rest are missing, is more useful than a percentage with no base.
• Keep outputs (sessions delivered) and outcomes (changes for people) apart, and do not claim your program caused a change you cannot show it caused.
• If you find an error in a report you have already sent, tell the funder and send the correction. It is far better coming from you.

Before you press send

Ten minutes with this list catches most of the problems funders find.

1. Definitions matchEvery number in the report has an entry in the data dictionary, and the funder’s definition is mapped where it differs.
2. ReproducibleThe query or export used is saved with the date, the period and who ran it.
3. Quality checkedMissing values, duplicates and late entries counted and either fixed at source or explained.
4. Small numbers suppressedYour threshold applied to every table, chart and map, including totals that could reveal a hidden cell.
5. No client detailNo names, dates of birth, case notes or identifiable stories without specific, recorded consent.
6. A second pair of eyesSomeone who did not prepare the report reads the numbers against the source before it goes.