Article summary
Financial data quality checks establish whether the information is suitable for a defined calculation or decision. A file can be complete enough for one purpose and unsuitable for another. Before modelling a company, comparing research evidence or matching transaction records, identify the source, population, period, units and expected relationships. This checklist uses fictional examples across analysis and operations; it is not an audit opinion or regulatory standard.
Define the question and preserve the source
A financial forecast, an investment research note and an operations dashboard have different questions. For each, preserve the original export or statement, record its date and version, and describe any transformation. A reviewer should be able to trace a result to a specific source field. Changing the only source copy to make a result agree destroys that traceability.
| Check | Question | Evidence to retain |
|---|---|---|
| Population and grain | Does a row represent a transaction, event, position or period? | Scope note, source row count and any aggregation rule |
| Completeness | Which required records and fields are missing? | Missing-record list and source-scope confirmation |
| Identifiers | Are keys unique and preserved in the intended text format? | Duplicate counts and documented mapping |
| Units and currency | Do amounts, shares and rates use compatible scales? | Data dictionary and explicit conversion basis |
| Period and cut-off | Are date, time zone and reporting period consistent? | As-of date and definition of the comparison window |
| Type and validity | Is an amount numeric, a date valid and a status recognised? | Type checks and a quarantined exception list |
| Reconciliation | Do source populations and control totals agree after transformation? | Before/after counts and totals by currency |
| Provenance and review | Who supplied, changed and reviewed the data? | Version history, source notes and review record |
Example 1: a unit error changes a valuation
Suppose fictional equity value is INR 1,360.39 lakh and the share count is 10 lakh shares. The simplified value per share is INR 136.039, or INR 136.04 rounded. If the model mistakenly divides by 10 shares rather than 10 lakh shares, it reports INR 13,603,900. The arithmetic engine has not failed; the model has mixed scales. Label both values, show the bridge and check whether changing the unit representation changes the underlying result.
Example 2: a research comparison needs aligned periods
A fictional company reports revenue of USD 100 million for twelve months; a peer reports USD 90 million for nine months. The numbers do not establish that the first company is larger on a like-for-like annual basis. Dividing 90 by nine and multiplying by twelve produces a mechanical run-rate of 120, but seasonality or a business change may make that run-rate unsuitable. Record period coverage, accounting basis, source date and missing evidence before drawing a conclusion.
The same caution applies to consolidated versus standalone accounts, nominal currencies and revised statements. A formatted table with two company names is not necessarily a comparable dataset. Keep a column for what the source actually says and another for the analyst's assumption. That makes a research note easier to challenge and update.
Example 3: duplicate keys hide inside a clean-looking lookup
If a source has two R202 payment rows, a lookup can return one amount while hiding the second candidate. Count the candidate keys before calling the result a match. Keep text identifiers as text where their exact representation matters; losing leading zeros may destroy information even if the new value looks numeric. Document any normalisation and review collisions rather than overwriting identifiers automatically.
Reconcile the population after each join or filter. A one-to-many join may multiply rows and inflate a dashboard even when individual columns look sensible. Conversely, filtering blanks without recording them may remove exceptions. State whether the final report counts source rows, unique references or cases, and make those populations reproducible.
Make a reviewer checklist you can use again
- Record the purpose, source versions and the meaning of a row.
- Count the original population and total numeric amounts by currency or other compatible unit.
- List missing fields, duplicate keys, invalid types and stale dates explicitly.
- Trace one normal record and one exception from source to output.
- Check key assumptions independently, including units, periods and the denominator of each percentage.
- Document unresolved limitations, the next request and the authorised reviewer rather than claiming the data is perfect.
For a public portfolio, use synthetic or appropriately authorised public data. Do not include customer information, proprietary exports or a hidden worksheet containing confidential details. If AI or automation helped clean the data, show the checks and preserve a before/after record. An attractive result becomes credible when another person can reproduce the relevant reasoning.
Apply the checks to Power BI finance projects
Explore the full finance programme and practice resources
Editorial review: 28 October 2026. Examples, amounts and checklist are original educational material. They illustrate why a conclusion needs compatible inputs; they do not value a real security, certify data quality or replace an organisation's approved review process.