Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Data accuracy is how closely a value matches the verified real world fact it describes. What it means, how it differs from completeness, and why it matters.
Updated on
Data accuracy is the degree to which a stored value matches the verified real world fact it is supposed to describe. A postal code is accurate when mail sent to it arrives. A stock level of 42 is accurate when there are 42 units on the shelf. A revenue figure of 4.1 million is accurate when the invoices behind it add up to 4.1 million under the definition of revenue your finance team uses.
That last example is why data accuracy is harder than it sounds. Accuracy is always accuracy against something. The value has to be compared with a reference that is treated as true, and if no such reference exists, the word accurate has no meaning in that sentence. Most arguments about whether a number is right turn out on inspection to be arguments about which reference counts.
The working definition to keep is therefore in two parts. A value is accurate when it corresponds to the real world fact it names, and you can only say so by checking it against a source outside the dataset that holds it.
If you need a single sentence to quote: data accuracy is how closely the values in a dataset match the verified facts they represent, measured by comparing them against an independent source of truth.
Three conditions have to hold at once, and a value that misses any one of them is not accurate even if it looks fine.
Accuracy is expressed as a rate. Take a sample of records, compare each one against the reference, and divide the number that match by the number you checked.
Accuracy rate equals records matching the reference divided by records checked, times 100. Check 200 customer addresses against the signed contract, find that 6 of them differ, and the accuracy rate of that field is 194 divided by 200, or 97 percent. The number on its own means nothing until you say what the reference was, how the sample was drawn and which field it applies to, because accuracy is a property of a field against a reference, never a property of a database.
That is also why an accuracy number cannot be borrowed from anywhere else. A vendor claiming an accuracy figure for your data has either agreed a reference with you or is measuring something other than accuracy. The measurement work itself, the sampling, the reconciliation and the checks that keep the rate from sliding, sits on the sibling page on how to ensure data accuracy, with the rule level detail on data validation practices.
The second question, once you can measure it, is what rate is good enough. There is no universal answer, because the cost of being wrong differs by use. The table below is the set of starting thresholds we recommend to Decube customers. It is our judgment rather than an industry standard, and the point of it is to force the conversation before a number is used, not to be copied without argument.
| Use of the data | Reference you check against | Accuracy rate before you act | What you do below it |
|---|---|---|---|
| Regulatory or statutory report | The source system of record, reconciled line by line | 100 percent on the reported fields | Do not file. Escalate, correct, and restate if it has already gone out. |
| Customer billing and invoicing | The signed contract terms and the payment record | 99.9 percent | Hold the billing run, fix the affected accounts, rerun. |
| Revenue and board reporting | The finance close, under the glossary definition of the metric | 99.5 percent | Report the figure with the measured error stated beside it. |
| Sales territory, quota and commission | The CRM record against the signed order | 98 percent | Flag the segment and do not pay commission on it until it is reconciled. |
| Marketing segmentation and outreach | A hand verified sample against the customer record | 95 percent | Keep going, widen the segment, and expect the bounce rate to carry the error. |
| Training data for a model | A labeled reference sample | Measured and disclosed, no fixed number | Record the measured rate in the model documentation and treat it as a known limit. |
Note what the first row costs. A supervisor does not accept an accuracy rate on a regulatory return, which is why banks reconcile rather than sample. BCBS 239, the Basel Committee standard on risk data, is explicit that measurement is expected rather than assumed.
Supervisors expect banks to measure and monitor the accuracy of data and to develop appropriate escalation channels and action plans to be in place to rectify poor data quality.
Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting, January 2013, paragraph 40.
Most confusion about accuracy comes from treating it as a synonym for quality. It is one dimension among several, and the dimensions fail independently. A column can be complete, consistent, valid, unique and still wrong.
The distinction that does the work is in the third column below. Every dimension except accuracy can be tested from inside the dataset. Accuracy cannot, because there is nothing in the data itself that tells you whether a value corresponds to the world.
| Dimension | The question it answers | Testable without an external reference | What a failure looks like |
|---|---|---|---|
| Accuracy | Does this value match the real world fact it names? | No | A customer address that is correctly formatted, present, unique and not where the customer lives. |
| Completeness | Is everything that should be here present? | Partial | Required fields are all populated, but three months of transactions never landed and nothing in the table says so. |
| Consistency | Does the same fact agree everywhere it is stored? | Yes | The CRM says the account closed in March and the billing system is still invoicing it. |
| Validity | Does the value conform to the rule or format it must follow? | Yes | A date of birth of 30 February, or a country code that is not in the code list. |
| Uniqueness | Is this the only record of this thing? | Yes | The same customer appears four times with four spellings, so every count is inflated. |
| Timeliness | Is the value current enough for the decision being made? | Yes | Yesterday closing stock used to promise same day delivery this afternoon. |
| Integrity | Do the relationships between records still hold? | Yes | An order line pointing at a product identifier that no longer exists in the product table. |
The full set and the way each one is measured are covered on our page on the six dimensions of data quality. For the neighbouring dimensions specifically, we have longer pieces on data consistency, on data completeness, and on the difference between data integrity and data security. Validity is largely a matter of what the schema allows, which is easier to see through worked database schema examples.
The practical consequence is a sequencing rule. Validity, consistency and uniqueness can be tested automatically today, on data you already hold, with no external dependency. Accuracy cannot, so an accuracy program starts by deciding what the reference is and who owns it. Teams that skip that step end up automating the cheap checks and calling the result an accuracy program.
Four rules that bind different kinds of organization all carry an accuracy requirement, and they word it differently enough that the differences are worth reading. Each row below quotes the instrument itself, not a summary of it.
| Rule | Who it binds | What it requires, in its own words | When it applies |
|---|---|---|---|
| GDPR, Article 5(1)(d) | Anyone processing personal data in scope of the Regulation | Personal data shall be "accurate and, where necessary, kept up to date", and inaccurate data must be "erased or rectified without delay". | In application since 25 May 2018 |
| Fair Credit Reporting Act, 15 U.S.C. 1681e(b) | United States consumer reporting agencies | The agency shall "follow reasonable procedures to assure maximum possible accuracy of the information concerning the individual about whom the report relates". | In force, and the standard behind the Equifax settlement below |
| BCBS 239, Principle 3 | Large banks supervised under the Basel framework | A bank should be able to "generate accurate and reliable risk data", aggregated "on a largely automated basis so as to minimise the probability of errors". | Published January 2013 |
| EU AI Act, Article 10(3) | Providers of high risk AI systems placed on the EU market | Training, validation and testing data sets shall be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose". | High risk obligations apply from 2 December 2027 for standalone systems and 2 August 2028 for systems embedded in regulated products |
Two things stand out. The first is that no regulator asks for perfect data. The GDPR asks for accuracy "where necessary" and for rectification without delay once an error is known. The AI Act asks for data sets free of errors "to the best extent possible". The obligation is to know the error and act on it, not to have none.
accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay
Regulation (EU) 2016/679, Article 5(1)(d), the accuracy principle, read on EUR-Lex.
The second is that the strictest wording in the four sits on consumer credit data, where the standard is not accuracy but the procedures used to reach it.
Whenever a consumer reporting agency prepares a consumer report it shall follow reasonable procedures to assure maximum possible accuracy of the information concerning the individual about whom the report relates.
15 U.S.C. 1681e(b), the Fair Credit Reporting Act, read on the Cornell Legal Information Institute.
For Decube customers, the same pattern shows up under OJK in Indonesia, APRA in Australia, MAS in Singapore and the NAIC model rules for United States insurers. The wording changes and the expectation does not: know your error rate, and have a route to correct it.
The case for accuracy is usually made in the abstract, with a large annual cost figure attached to no particular event. The two events below are the opposite. Both are documented by the authority that acted, both name the error, and both show the same thing: the damage does not scale with the number of wrong values.
On 2 May 2022 a Citigroup Global Markets trader intended to sell a basket of equities worth 58 million US dollars. An inputting error created a basket worth 444 billion US dollars instead. That is 7,655 times the intended size, which is 444,000 divided by 58. Internal controls blocked 255 billion of it. The remaining 189 billion reached a trading algorithm, and 1.4 billion US dollars of equities were sold across European exchanges before the trader cancelled the order, coinciding with a short drop in several European indices.
Failures in the firm’s systems and controls led to US$1.4bn of equities being sold in European markets when they should not have been.
Financial Conduct Authority, FCA fines CGML £27,766,200 for failures in its trading systems and controls, 22 May 2024. The penalty was 27,766,200 pounds after a 30 percent settlement discount, from 39,666,000 pounds without it, and the Prudential Regulation Authority imposed a further 33,880,000 pounds the same day. The Final Notice sets out the control failures in detail.
The interesting part for a data team is the FCA finding on the controls. There was no hard block that would have rejected the basket outright, and the alert the trader saw could be dismissed without scrolling to the end of it. Real time monitoring was too slow to escalate. An accuracy control that a human can wave through is a suggestion.
In March 2022 Equifax introduced a code change to a scoring model. For three weeks it returned lowered credit scores. The company estimated that the scores of more than 77,000 New Yorkers wrongly declined during that window, and lenders and insurers priced loans and policies off those scores before the fault was resolved on 8 April 2022. On 14 January 2025 the New York Attorney General announced a settlement of 725,000 US dollars, restitution to affected consumers, and a requirement that Equifax monitor customer reported error incidents at least weekly.
Office of the New York State Attorney General, Attorney General James Secures $725,000 from Equifax for Harming Consumers Through Inaccurate Credit Scores, 14 January 2025.
No record was missing. No format was invalid. No duplicate existed. Every automated quality check of the kind most teams run would have passed, because the values were well formed, present and unique. They were simply not true, and the only way to have caught that was to compare the model output against a reference.
Accuracy pays in four places, and each of them can be measured rather than asserted.
The word "trust" belongs at the end of that list rather than the start. Trust is what you get when the four measurable things above have been true for long enough that people stop checking. It is a consequence of accuracy, not a substitute for measuring it.
Inaccuracy has a small number of recurring causes and they enter at different points, which matters because a control placed at the wrong point catches nothing. Here are six, with where each one enters and what actually catches it.
| Cause | Where the wrong value enters | What catches it |
|---|---|---|
| Manual entry error | At the point of capture, from a person typing into a form or a trading screen | A hard block on out of range values at entry, not a dismissible warning. This is the Citigroup failure. |
| Stale records | Nowhere. The value was correct when written and the world moved on | A freshness rule on the field, plus a scheduled recheck against the source of record. |
| Integration and mapping errors | In transit, when two systems disagree about units, currency, timezone or code lists | Reconciliation of totals between source and destination after every load. |
| A change to a calculation | In the transformation layer, when a model or a rule is edited | A regression check that runs the new logic against a reference period. This is the Equifax failure. |
| Ambiguous definitions | In the meaning, when two teams compute the same named metric differently | One written definition per term in a business glossary, bound to one owner. |
| Silent upstream schema change | At the boundary, when a producer renames, retypes or drops a field without telling anyone | Schema monitoring on the source, with an alert that reaches the consuming team. |
Three of those six are caught by a person rather than a rule, which is why the route from an alert to a fix matters as much as the detection. We have written separately about why incident workflows matter for data quality, because an accuracy check that nobody owns produces a dashboard rather than a correction.
A number cannot be judged accurate until somebody has written down what it is supposed to mean. That is the ambiguity cause from the table above, and it is the one that automated checks never catch, because two differently computed versions of "active customer" are both valid, both complete and both unique. Three artefacts do this job and they are routinely confused with each other.
| Artefact | What it defines | Who owns it | A single entry looks like |
|---|---|---|---|
| Business glossary | The agreed business meaning of a term, in plain language | A named business owner or data steward, not the platform team | Active customer: an account with at least one paid transaction in the trailing 90 days, excluding refunds. |
| Data dictionary | The technical description of a field in a specific system | The data engineering or platform team | dim_customer.is_active, boolean, set by the customers model, refreshed daily at 02:00 UTC. |
| Data catalog | The searchable inventory that binds the two to the actual assets | The platform team, used by everyone | dim_customer: owner, freshness, upstream lineage, quality monitors, and the glossary term each column implements. |
Said plainly, the difference between a business glossary and a data dictionary is the difference between meaning and implementation. The glossary says what "active customer" means to the business and who decided. The dictionary says which column holds it, what type it is and which job populates it. The glossary entry survives a migration; the dictionary entry does not. A term with no glossary entry cannot be checked for accuracy at all, because there is no statement to check it against.
We compare all three side by side on our page on the business glossary against the data catalog and the data dictionary.
The failure mode for a team of five to twenty on Snowflake is trying to define everything and abandoning the glossary in month three. A narrower sequence works better.
Decube ships a business glossary bound to the catalog for this reason: the definition and the asset it describes sit in the same place, so a term cannot quietly stop matching the table that implements it.
The method belongs on its own page and this one deliberately does not repeat it. In outline: agree the reference for each field that matters, measure the accuracy rate against it, set a threshold from the table above, monitor the fields that carry the most consequence, and route every failure to a named owner. The step by step version, with the reconciliation and sampling detail, is on how to ensure data accuracy, and the rule level techniques for catching a wrong value before it lands are on data validation practices for accuracy.
Decube is a data trust platform, and the parts of it that bear on accuracy are the ones that hold a reference and watch for drift away from it. The catalog is a searchable inventory of assets with their metadata, so an analyst can find the certified table rather than the copy of it. The business glossary binds each term to the asset that implements it. Data quality monitors watch the fields you nominate and raise an incident when a value moves outside the rule you set, and lineage shows which reports consume the field so you know who to tell. The data observability side of the platform is where the monitoring and the alert routing live.
What no platform does is decide what the reference is. That decision is yours, it is a business decision rather than a technical one, and it is the step teams most often skip. If you want to see how the glossary, the monitors and the lineage fit together on your own tables, request a demo.
Data accuracy is the correspondence between a stored value and the fact it names, and it is the only quality dimension that cannot be tested without looking outside the dataset. That one property explains most of what is difficult about it: why automated checks pass on wrong data, why arguments about accuracy are usually arguments about definitions, and why an accuracy program has to start with a reference and an owner rather than a tool.
The cost of getting it wrong does not scale with the number of bad rows. One mistyped basket cost Citigroup Global Markets a 27,766,200 pound fine from the FCA and a further 33,880,000 pounds from the PRA. Three weeks of a bad scoring model cost Equifax a 725,000 US dollar settlement in one state alone. Neither was a data volume problem.
The practical move is small and it is not a purchase. Pick the three fields that carry the most consequence in your business, write down what each one is supposed to mean and what it will be checked against, measure the accuracy rate once by hand, and decide what rate you would act on. Everything else in an accuracy program follows from those four answers.
Data accuracy is the degree to which a stored value matches the verified real world fact it is supposed to describe. A postal code is accurate when mail sent to it arrives, a stock level of 42 is accurate when there are 42 units on the shelf, and a revenue figure is accurate when the invoices behind it add up to it under the definition of revenue your finance team uses. Accuracy is always accuracy against a reference, so it can only be established by comparing the value with a source outside the dataset that holds it.
In practice it means somebody has named a source of truth for a field and compared the field against it. Data accuracy is how closely the values in a dataset match the verified facts they represent, measured by comparing them against an independent source of truth. Without that reference the word accurate has no meaning in the sentence, which is why most disagreements about whether a number is right turn out to be disagreements about which reference counts.
Because the damage from a wrong value does not scale with the number of wrong values. On 2 May 2022 a single inputting error at Citigroup Global Markets turned an intended 58 million US dollar basket of equities into a 444 billion US dollar one, 1.4 billion US dollars of stock was sold that should not have been, and the FCA fined the firm 27,766,200 pounds on 22 May 2024. A three week coding error at Equifax lowered the credit scores of more than 77,000 New Yorkers and cost the company a 725,000 US dollar settlement with the New York Attorney General in January 2025. In both cases the data passed every format and completeness check that could have been run on it.
Because every decision, every invoice, every regulatory return and every model takes the data at face value. Accurate data means decisions do not have to be redone, money stops leaking through wrong addresses, rates and quantities, regulatory reporting stops being reconciled by hand, and models behave the way the test set said they would. Regulators also require it directly: the GDPR says personal data shall be accurate and rectified without delay, and the Fair Credit Reporting Act requires reasonable procedures to assure maximum possible accuracy.
Three conditions have to hold at once. The term is defined, so that two people computing it separately would produce the same answer. A reference exists and is reachable, so the value can actually be compared with a source of record. And the value still corresponds today, because a value that was correct when it was written and has since gone stale is inaccurate now even though nobody made a mistake. A value that misses any one of the three is not accurate, however well formed it looks.
Through four measurable channels. Fewer restated reports, which you can count per quarter. Less money leaking through wrong addresses, rates and quantities, which is already visible in the ledger and can be attributed to a field. Less manual reconciliation before a regulatory return, where the cost of inaccuracy is the salary of the people doing the reconciliation. And models that behave in production the way they behaved in testing. Trust is the result of those four holding for long enough that people stop checking, rather than a benefit in its own right.
The documented cases are the honest answer, because generic annual cost figures circulate widely without a source that states them. The FCA fined Citigroup Global Markets Limited 27,766,200 pounds on 22 May 2024, reduced from 39,666,000 pounds by a 30 percent settlement discount, and the Prudential Regulation Authority added 33,880,000 pounds the same day, all following one mistyped order. The New York Attorney General secured 725,000 US dollars from Equifax on 14 January 2025 over a three week coding error, alongside consumer restitution paid through lenders and insurers.
Customers experience inaccuracy directly rather than statistically. A wrong address means a delivery that does not arrive, a wrong rate means an invoice that has to be disputed, and a wrong credit score means a loan priced higher than it should have been, which is what more than 77,000 New Yorkers experienced in the Equifax case. Each of those is a single customer having a bad experience for a reason they can see, which is why accuracy failures damage trust faster than outages do.
Because the reference is a person and the consequence of a mismatch is clinical. An incorrect identity match merges two patients into one record, an out of date medication list omits an interaction, and a mistyped dose is a valid number in the wrong place. None of those fail a format check. Healthcare also sits under strict record accuracy duties in most jurisdictions, so an error carries a regulatory consequence on top of the clinical one.
A business glossary defines meaning and a data dictionary describes implementation. The glossary entry says what a term means to the business and who decided, for example that an active customer is an account with at least one paid transaction in the trailing 90 days excluding refunds, and it is owned by a named business steward. The dictionary entry says which column holds it, what type it is and which job populates it, and it is owned by the data engineering team. The glossary entry survives a platform migration and the dictionary entry does not. A term with no glossary entry cannot be checked for accuracy at all, because there is no statement to check the value against.
Narrowly, and with an owner on every term. Define only the metrics that appear in a board pack, a customer facing report or a regulatory return, which is usually 20 to 40 terms rather than 400. Bind each term to exactly one certified Snowflake table or view, named in the entry; if a term maps to three objects it is not defined yet. Put a named business owner on every term and refuse to add one without an owner. Keep the glossary beside the data rather than in a separate wiki, so it is where people already look the table up. And review quarterly, which a team of five to twenty can sustain, rather than monthly, which it cannot.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)