Data quality audit checklist for finance and operations teams
Quick answer
A data quality audit should not end with a vague list of bad records. It should produce a ranked backlog of duplicates, blanks, invalid values, source-system conflicts, missing owners, risky spreadsheets, reporting mismatches and reconciliation gaps, with a named owner and next action for each issue.
Most businesses do not wake up one morning and decide they have a data quality problem. They notice symptoms first.
The stock report does not match the warehouse. The sales dashboard does not reconcile to finance. The customer list has duplicates, but nobody is confident enough to merge them. A Power BI report looks impressive until someone asks why it disagrees with the ERP. An ERP migration workshop stalls because nobody knows who owns product, supplier, customer or finance fields.
That is the moment a data quality audit becomes useful. Not as an academic exercise. Not as a spreadsheet full of red cells that gets parked in a project folder. A good audit gives the business a practical way to find the records, rules and ownership gaps that are making reporting, migration and automation risky.
The output of a data quality audit should be a prioritised cleanup backlog, not a vague complaint that the data is messy.
Start with the decisions the data supports
A lot of data quality work goes wrong because it starts with every field in every system. That sounds thorough, but it quickly becomes too broad to act on.
Start with the business decisions that matter. Which numbers are used in board packs? Which fields control stock, margin, customer service, supplier payment, production planning or credit risk? Which records will move into a new ERP, CRM or finance system? Which fields drive Power BI measures, workflow approvals or automated emails?
For an SME, the first audit scope should usually cover the data that can damage money, customer trust, operational control or project delivery. That means customer, supplier, item, stock, finance, order, project and reporting-definition data before vanity fields or rarely used notes.
If a field does not affect a decision, process, report, migration rule or customer outcome, it may not belong in the first audit wave.
Check duplicates before checking perfection
Duplicate records are often the easiest visible sign that ownership has drifted. They also create real business risk. Duplicate customers can split sales history, credit exposure and delivery addresses. Duplicate suppliers can create payment confusion. Duplicate items can distort stock, purchasing and margin reporting.
A useful audit should look for exact and near duplicates. Exact duplicates are easy: same customer name, same postcode, same email, same supplier VAT number. Near duplicates are harder: abbreviations, old trading names, punctuation differences, branch naming, legacy account codes and records copied across systems with slightly different spelling.
The audit should not simply say "deduplicate". It should answer four questions:
- Which duplicate group is highest risk?
- Which record is the survivor?
- Which transactions, open orders, balances or addresses must be protected before merging?
- Who is allowed to approve the merge?
That last question matters. If nobody owns the decision, duplicates keep coming back.
Find blanks in mandatory business fields
Blank fields are only a problem when the business expects the field to mean something. A blank middle name is usually irrelevant. A blank customer payment term, supplier lead time, stock unit of measure, product category, delivery postcode or tax code can create bad decisions very quickly.
For each data domain, define the mandatory business fields. Not just the fields the system technically requires. The fields the business needs to run, report and migrate safely.
Customer records may need account status, billing address, delivery address, payment terms, credit limit, customer type and owner. Supplier records may need payment terms, currency, bank details status, lead time and approval state. Item records may need unit of measure, barcode, product category, stock policy, costing method and owner. Finance records may need nominal code, tax treatment, reporting dimension and reconciliation status.
The audit should separate harmless blanks from operational blanks. Then it should rank them by impact: what stops migration, what breaks reporting, what creates customer or supplier risk, and what simply needs cleanup later.
Test values against business rules, not just data types
Systems can validate data type and still allow bad business data. A date can be valid but impossible. A postcode can be formatted but wrong. A unit of measure can exist but be inappropriate for the product. A customer can have a credit limit but no active credit-control owner.
This is where a data quality audit needs business rules. Examples include:
- Inactive customers should not have open orders without review.
- Stocked items should have a unit of measure, product category, replenishment rule and stock location logic.
- Supplier lead times should not be zero unless there is a defined reason.
- Open invoices should reconcile to customer and supplier master records.
- Reporting categories should map to the management accounts structure.
- Power BI dimensions should use controlled values, not free-text variants.
This is the difference between a technical export check and a useful data quality consultant review. The audit has to test whether the value supports the way the business actually works.
Compare systems that claim to describe the same thing
Many SME data problems sit between systems. The ERP says one thing, the CRM says another, finance holds a spreadsheet override, and Power BI blends whichever source was easiest to connect at the time.
A data quality audit should identify source-system conflicts. Which system is the master for customer addresses? Which system owns supplier payment terms? Where does product category come from? Which report is the approved version of margin, stock value, open order value or sales by customer?
If two systems hold the same field, the audit should record which one wins, how exceptions are handled, and whether the losing system still needs to be updated for operational reasons.
This matters before data migration. If the business cannot decide which source is trusted before a test load, the migration team ends up making judgement calls that should belong to finance, operations, sales or purchasing.
Audit ownership as seriously as the records
Bad data usually survives because ownership is unclear. People can see the problem, but nobody is sure who has the authority to fix it.
For each critical data domain, the audit should name a business owner, backup owner, source system, update route, validation check and escalation path. If customer delivery addresses are wrong, who owns the correction? If a product category is missing, who decides the right category? If supplier terms are inconsistent, who signs off the update?
This does not need enterprise governance theatre. SMEs need enough ownership to stop decisions bouncing around meetings.
A simple master data ownership matrix is often enough to start. Put the domains down the left, the owners across the columns, and the validation rules beside them. Then use the matrix every time a data issue appears.
Connect the audit to reporting trust
Data quality is not separate from reporting. It is often the reason reports are not trusted.
If Power BI shows a sales number that does not match the ERP, the problem might be a measure, a filter, a refresh issue or a hidden business definition. But it might also be customer duplicates, missing product categories, inconsistent order statuses, bad date fields or spreadsheet overrides that nobody has documented.
For every important report, the audit should ask:
- Which source tables or exports feed the report?
- Which fields drive filters, measures and groupings?
- Which fields are manually corrected before reporting?
- Which numbers should reconcile to finance, stock, sales or operations?
- Who owns the definition if the report is challenged?
If the audit finds reporting risk, link it to a Power BI reporting trust checklist. That keeps the conversation practical: what needs checking, who owns it, and what evidence proves the report can be trusted.
Turn findings into a ranked backlog
The most important part of the audit is what happens after the checks. A long list of defects is not useful unless it is ranked and owned.
Each finding should have a business impact, owner, recommended fix, validation method and target date. I would usually group findings into four buckets:
- Cutover blockers: issues that could stop or damage ERP, CRM or finance-system migration.
- Reporting trust issues: defects that explain why finance, operations or Power BI reports do not reconcile.
- Operational risk: records or rules that create wrong picks, wrong deliveries, payment errors or customer-service failures.
- Cleanup improvements: lower-risk standardisation work that can follow once the urgent risks are controlled.
The backlog should be small enough for the business to act on. Ten high-risk issues with named owners beat 400 unranked rows every time.
A practical checklist for the first audit pass
If you are starting from scratch, use this first-pass checklist:
- List the critical data domains: customer, supplier, item, stock, finance, orders, projects and reporting definitions.
- Name the business owner and backup owner for each domain.
- Identify mandatory business fields for each domain.
- Check exact and near duplicates.
- Check blanks in mandatory fields.
- Check invalid values, impossible dates and inconsistent categories.
- Compare systems that hold the same field.
- Identify spreadsheet overrides and manual correction steps.
- Link data issues to affected reports, workflows, migrations or customer processes.
- Rank findings by business risk and assign the next action.
You can use the editable data quality audit checklist as the working file, but the important discipline is not the file itself. It is agreeing which issues matter, who owns them and how the fix will be proven.
The takeaway
A data quality audit is not a search for perfect data. Perfect data is not a realistic operating target for most SMEs. The useful target is controlled data: the important fields are owned, the riskiest defects are visible, the business rules are written down, and reporting or migration teams can prove what they are relying on.
If your ERP migration, reporting rebuild or automation project is already exposing messy records, do not start by arguing about tools. Start with a focused audit. Find the data that drives decisions, test it against business rules, name the owners and turn the findings into a backlog the business can actually work through.
That is how a data quality checklist becomes more than a tick-box exercise. It becomes the control layer for better reporting, safer migration and fewer surprises when the business starts relying on the numbers.
Need a practical data quality audit?
Digital Adaption helps SMEs turn messy operational data into a ranked cleanup backlog before ERP migration, reporting rebuilds or automation work.
View the readiness review