How to measure data quality

Your automation is live, your AI model is trained, your integration is connected — and the results are wrong. Leads get routed to the wrong sales rep, invoices go out with missing VAT numbers, and the AI recommendation engine confidently suggests products you stopped selling two years ago. The culprit is almost never the software. It's the data feeding it. This article walks you through exactly how to measure data quality across all five critical dimensions, so you know what you're actually dealing with before you automate, integrate, or hand decisions over to an algorithm.

Why does measuring data quality matter before you automate anything?

Most organizations discover data quality problems the hard way — after they've already built the automation. A warehouse management system goes live and immediately starts generating wrong pick lists because product codes in the ERP don't match product codes in the WMS. An AI churn model gets deployed and flags the wrong customers because half the "last purchase date" fields haven't been updated in 14 months. These aren't edge cases. They're the norm.

The fix isn't to clean data reactively after every broken output. It's to measure first, understand the scope of the problem, and then clean deliberately. Measurement gives you a baseline — a number you can track, improve, and report on. Without it, "data quality" stays a feeling, not a fact.

What are the five dimensions of data quality you need to measure?

Every serious data quality framework — from the DAMA-DMBOK to ISO 8000 — organizes quality around a small set of dimensions. These five are the ones that matter most in practice:

1. Completeness — Are all required fields filled in?
2. Accuracy — Does the data reflect reality?
3. Consistency — Does the same data mean the same thing everywhere it appears?
4. Timeliness — Is the data current enough to be useful?
5. Uniqueness — Is each real-world entity represented exactly once?

Each dimension has its own measurement method. Let's go through them one by one.

How do you measure completeness?

Completeness measures the percentage of required fields that actually contain a value. It sounds simple — and the calculation is — but the hard part is agreeing on what "required" means in your context.

Formula:

Completeness (%) = (Fields with a value ÷ Total expected fields) × 100

Practical example: You export your CRM contact records. Out of 4,200 contacts, 1,890 have no phone number, 640 have no company name, and 210 have no email address. If phone, company, and email are all required for your outbound sales automation, your completeness score for that workflow is not 100% — it's closer to 55%, and your automation will silently skip or mishandle nearly half your records.

How to measure it:

1. Define a field-level completeness requirement for each table or object (e.g. "for the Contacts table, these 6 fields are mandatory for sales automation").
2. Run a query or export that counts NULL, empty, or placeholder values ("TBD", "unknown", "0") per field.
3. Calculate a per-field completeness score and an overall record-level score (what % of records are fully complete across all required fields).
4. Flag records that fall below your threshold as "not automation-ready."

Watch out for: Fields that look filled but contain garbage — a phone number field full of "000-000-0000" entries passes a completeness check but fails an accuracy check. Always combine completeness with validity rules.

How do you measure accuracy?

Accuracy is the hardest dimension to measure programmatically because it requires comparing your data against an external source of truth. You can't know from the data alone whether a customer's address is real, whether a product weight is correct, or whether a contract end date was entered correctly.

Practical approaches:

• Address validation: Run postal addresses through a validation API (e.g. PostNL's address API for Dutch data, or Google Maps API) and flag records where the street, city, or postcode don't resolve to a real location. In a dataset of 3,000 customer records, it's not unusual to find 8–12% with non-deliverable addresses.
• Cross-system comparison: If your ERP and your CRM both store a customer's company name, compare them. Differences reveal at least one inaccuracy — even if you can't always tell which system is wrong.
• Sample-based manual audit: For fields where no API validation is possible (e.g. contact person names, product descriptions), pull a random sample of 100–200 records and manually verify them against the source document, the customer portal, or a phone call. Then extrapolate the error rate to the full dataset.
• Business rule violations: Define rules that should always be true (e.g. "invoice date cannot be after delivery date", "a customer with status 'active' must have a contract end date in the future") and count violations.

Formula:

Accuracy (%) = (Records with no detected errors ÷ Total records audited) × 100

How do you measure consistency?

Consistency measures whether the same data, stored in multiple places, says the same thing — and whether values follow the same format, coding, or vocabulary across your systems.

This dimension is where integrations die. An order gets entered into FileMaker with country code "NL", but the logistics API expects "Netherlands". Every single order, every single day, either fails silently or maps incorrectly. Nobody notices until packages start going to the wrong country — or until a dashboard aggregating orders by country shows NL and Netherlands as two separate markets.

What to measure:

• Format consistency: Date fields stored as DD-MM-YYYY in one system and YYYY-MM-DD in another. Currency amounts with and without VAT mixed in the same field. Phone numbers with and without country codes, with and without spaces.
• Value list consistency: "Active", "active", "ACTIVE", "Actief" all meaning the same status — but stored differently. Measure the number of distinct variants for each controlled vocabulary field.
• Cross-system field matching: For every field that exists in more than one system, measure the percentage of records where the value matches exactly across all systems.

Formula:

Consistency (%) = (Records where all cross-system values match ÷ Total records compared) × 100

How to measure it step by step:

1. Map every field that appears in more than one system (a "field inventory" or data dictionary).
2. For each shared field, export the values from both/all systems and join on a common key.
3. Flag mismatches and calculate a per-field consistency score.
4. For format consistency within a single system, run regular expressions or pattern checks against each field and count violations.

How do you measure timeliness?

Timeliness measures whether your data is current enough to be useful for the decision or process it's meant to support. Stale data is one of the most underrated quality problems — particularly for AI models, which are only as good as the recency of their training and inference data.

Practical example: A customer churn prediction model is trained on customer activity data. The "last login date" field for 34% of users hasn't been updated since the CRM migration 18 months ago. The model treats those users as highly engaged (they were, 18 months ago) and assigns them low churn risk. Your customer success team ignores them. Three months later, 40% of them churn.

What to measure:

• Data freshness: For time-sensitive fields (last contact date, stock level, contract status), calculate the average and maximum time since last update. Define an acceptable freshness threshold per field (e.g. stock levels must be updated within 24 hours; contact records must be reviewed at least annually).
• Update frequency vs. expected frequency: If your integration is supposed to sync every hour but records show gaps of 6–8 hours, your timeliness score is failing even if the data itself is accurate.
• Time-to-availability: How long does it take from when an event happens in the real world to when it's reflected in your system? For real-time automation, even a 4-hour lag can be a critical failure.

Formula:

Timeliness score = % of time-sensitive records updated within the defined freshness threshold

How do you measure uniqueness (and detect duplicate records)?

Uniqueness measures whether each real-world entity — a customer, a product, a supplier — appears exactly once in your dataset. Duplicate records are one of the most damaging data quality problems in practice, particularly for automation and AI, because they cause double-counting, split histories, and conflicting updates.

Why duplicates are so destructive: Imagine a customer has two records in your CRM — one from a trade show lead import and one from a manual entry by sales. The automation sends them a welcome email twice. The AI model splits their purchase history across two profiles and misclassifies both as low-value customers. The account manager doesn't know which record to update, so both stay incomplete.

How to detect and measure duplicates:

1. Exact matching: Count records with identical values on a key field (email address, VAT number, IBAN). Any duplicate on a theoretically unique field is a clear data quality violation.
2. Fuzzy matching: Use string similarity algorithms (Levenshtein distance, Jaro-Winkler) to find near-duplicates: "Acme B.V." and "ACME BV" are almost certainly the same company. Tools like OpenRefine, Python's recordlinkage library, or built-in fuzzy matching in FileMaker scripts can automate this.
3. Composite key matching: Compare combinations of fields (first name + last name + postal code, or company name + city + phone) to catch duplicates that don't share any single unique field value.

Formula:

Uniqueness (%) = (1 − Duplicate records ÷ Total records) × 100

Deduplication rate benchmark: In most B2B CRM and ERP datasets that haven't been actively deduplicated, duplicate rates of 10–25% are common. Anything above 5% should be treated as a blocker for automation.

What does a practical data quality measurement process look like?

Here's a step-by-step approach you can actually run:

1. Define scope: Choose the specific dataset and the specific use case (e.g. "customer records used for the order confirmation automation"). Don't try to measure everything at once.
2. Build a field inventory: List every field in scope. For each field, define: Is it required? What's the expected format? What's the acceptable value range or list? What's the freshness threshold?
3. Export a representative sample (minimum 500–1,000 records, or the full dataset if under 10,000 rows).
4. Run automated checks for completeness (null counts), consistency (format violations, cross-system mismatches), uniqueness (exact and fuzzy duplicate detection), and timeliness (last-updated timestamps vs. thresholds).
5. Run a manual accuracy audit on a random sample of 100–200 records.
6. Score each dimension using the formulas above. Combine them into a single Data Quality Score if you need one number to report upward — a simple average across dimensions works, or weight by business impact.
7. Document findings in a data quality report: per-field scores, worst offenders, estimated business impact (e.g. "14% of orders will fail the integration because of missing VAT numbers").
8. Set improvement targets and a re-measurement date. Measurement without a feedback loop is just a snapshot.

Data quality measurement checklist

Use this before any automation, integration, or AI project:

• Field inventory completed for all in-scope tables
• Required fields defined per use case
• Completeness score calculated per field and per record
• Accuracy validated via API, cross-system comparison, or manual audit
• Format consistency checked (dates, phone numbers, country codes, status values)
• Cross-system value matching performed for all shared fields
• Timeliness thresholds defined and freshness checked per time-sensitive field
• Duplicate detection run (exact + fuzzy matching)
• Per-dimension scores documented
• Minimum quality thresholds set before go-live
• Re-measurement scheduled after cleanup

FAQ

What's a "good" data quality score? There's no universal answer — it depends on the use case. A human browsing a CRM can tolerate 80% completeness; an automated billing process cannot. As a rule of thumb: for automation and AI, target 95%+ completeness and uniqueness, 90%+ consistency, and define timeliness thresholds per field. Accuracy below 95% should block go-live for any financial or compliance process.

How often should you measure data quality? At minimum: before any new automation or integration project, and after any major data migration. Ideally: continuously, with automated monitoring that alerts you when scores drop below threshold. For live production systems feeding automation, monthly spot-checks are the bare minimum.

Can you use AI to measure data quality? Yes — and increasingly, this is becoming practical. Large language models can be used to detect semantic inconsistencies (e.g. spotting that "Managing Director" and "CEO" likely refer to the same role), flag anomalous values, and generate validation rules from examples. But AI-assisted quality measurement still requires a human to define what "correct" looks like for your specific data and business context.

What's the difference between data quality and data governance? Data quality is the measurable state of your data at a point in time. Data governance is the set of policies, roles, and processes that keep quality from degrading over time. You need measurement to know your quality level; you need governance to sustain it. This article covers measurement — governance is the next step.

Do I need special tools to measure data quality? Not necessarily. A well-structured SQL query or a FileMaker script can catch most completeness, consistency, and uniqueness issues. Python (pandas, recordlinkage) is useful for fuzzy matching and large-scale analysis. Dedicated data quality tools (Talend, Great Expectations, Monte Carlo) add monitoring and alerting but are usually overkill until you're managing multiple production pipelines. Start with what you have.

---

Measuring data quality is always step one — but knowing your scores is only useful if you then act on them. If your measurement reveals widespread missing fields, format mismatches, or a duplicate rate above 5%, the practical guide on how to improve data quality before automation or AI walks through the cleanup and governance steps that follow. If you're facing a specific integration, automation, or AI project where data quality is the blocker, Loggix can help you measure, clean, and connect your data — whether that means building a custom FileMaker solution, developing API integrations between your systems, or mapping out the right data architecture before you build anything.