---
title: "Checking data for a review: part 3 (accuracy)"
description: How we check that values in a data extract match the source systems, what causes differences, and why the same matters for day-to-day reports and models.
---

[Articles: algorithm integrity in FS | Risk Insights Blog](https://riskinsights.com.au/blog)

# [Checking data for a review: part 3 (accuracy)](https://riskinsights.com.au/blog/the-checks-we-run-before-using-data-for-a-review-part-3)

 Written by [Yusuf Moolla](https://riskinsights.com.au/blog/author/yusuf) | 22 Oct 2026

**TL;DR**

• The third in a series on checking data before using it for a review.

• Accuracy: checking that values in the extract match the values in the source systems.

• Similar field names and out-of-date mapping tables can create inaccuracies in the extract.

 

This is the third article in a [series on the checks we run](https://riskinsights.com.au/blog/the-checks-we-run-before-using-data-for-a-review-part-1) before using data for a review.

 

## Why this is relevant day to day (not just in a review)

This is similar to [completeness](https://riskinsights.com.au/blog/the-checks-we-run-before-using-data-for-a-review-part-2). Models, dashboards and reports are often built from the same extracts we use for a review, so they can have the same problems.

 

## What we check, and what it can find

For a review, we take a sample of records from the extract and look them up in the source system. We compare key fields like statuses, amounts, rates, dates and codes.

This check is limited to whether the extract matches the system. If, for example, the review is about whether fees were [calculated correctly](https://riskinsights.com.au/blog/accuracy-outcome-focused-approach), that testing is the review itself, not part of checking the data.

We often find differences. Reasons for these include:

- source fields with similar names
- mapping tables that haven’t been updated
- a delay in refreshing the table used for the extract
- amounts that include or exclude tax.

A loan system may have a standard product rate and a discounted customer rate. If the extract is based on the standard rate, and we're testing whether interest was charged correctly, we may find what look like errors in accounts with discounted rates.

A claims system might add a new status, such as "withdrawn by customer", after a system change. If the mapping table used to build the extract isn't updated, that new code can end up grouped with whatever the default mapping is. For example, if the default is declined claims, we will have an overstated decline rate. If some groups of customers are more likely to withdraw their claims, a fairness analysis based on that extract will show a higher decline rate for those groups than they actually had.

 

Disclaimer: The info in this article is not legal advice. It may not be relevant to your circumstances. It was written for specific contexts within banks and insurers, may not apply to other contexts, and may not be relevant to other types of organisations.

 

 

[View full post](https://riskinsights.com.au/blog/the-checks-we-run-before-using-data-for-a-review-part-3)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Yusuf Moolla"
  },
  "dateModified" : "2026-10-22T05:43:09.762Z",
  "datePublished" : "2026-10-22T05:43:09Z",
  "headline" : "Checking data for a review: part 3 (accuracy)",
  "image" : {
    "@type" : "ImageObject",
    "height" : 1260,
    "url" : "https://44032070.fs1.hubspotusercontent-ap1.net/hubfs/44032070/checking-data-part-3.png",
    "width" : 2240
  },
  "mainEntityOfPage" : "https://riskinsights.com.au/blog/the-checks-we-run-before-using-data-for-a-review-part-3",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60.0,
      "url" : "https://confidecs.com/hubfs/Risk%20Insights%20-%20r%20and%20eye.png",
      "width" : 66.25593
    },
    "name" : "Risk Insights Blog"
  }
}
```