Financial Data Quality: Checks, Reconciliation, and a Worked Example - Yenra

Check completeness, uniqueness, consistency, timeliness, validity, and accuracy using a fictional transaction file and documented corrections.

An orderly navy tray of ivory record tiles has an empty slot, with two matching teal tiles in a review area beside a glass magnifying lens and amber markers.
Conceptual illustration of record review; the blank tiles are not actual customer data or a technical validation system.

Financial data quality means having records fit for a particular decision. A file can open cleanly, contain valid numbers, and still omit a payment or assign it to the wrong customer. Begin with the intended use and the evidence that would make the result trustworthy.

Use several checks rather than one quality score

The UK Government Data Quality Framework identifies six useful dimensions: completeness, uniqueness, consistency, timeliness, validity, and accuracy. They test different properties; a complete record can still be wrong. See the framework and its dimension definitions.

Scroll sideways to read all columns. Keyboard users can focus the table and use the arrow keys.

Original examples of applying the six dimensions
DimensionExample question
CompletenessDid every expected settlement arrive, and does each record have its required identifier?
UniquenessIs the same source event represented twice?
ConsistencyDoes the amount and currency agree across the payment and ledger records?
TimelinessWas the file available before the cash forecast's cutoff?
ValidityIs the date possible and the currency code allowed by this data contract?
AccuracyDoes the record match the underlying transaction evidence?

For a banking context, the Basel Committee's risk-data aggregation principles connect data to governance and risk reporting. They were developed particularly for systemically important banks; this small-business exercise is an illustration, not a claim of regulatory compliance.

Define the unit of a record before checking duplicates. A customer ID can legitimately repeat across payments. An invoice can have several installments or a later refund. For an event file, a key might require source system, transaction ID, and event type together. A repeated amount alone proves very little.

An invented file with seven rows

Fictional teaching data: the file represents one source's settled payment events for August 31, 2026. Each transaction should appear once, with a transaction ID, a valid event date, a currency, and a signed amount. Positive means a receipt; negative means a refund. The source's separate control says there should be six events totaling USD 200.00 and EUR 20.00. These are separate currency totals, not an exchange-rate conversion.

Scroll sideways to read all columns. Keyboard users can focus the table and use the arrow keys.

The raw import deliberately contains errors; do not use it as a clean ledger
RowTransactionEvent dateCurrencyAmountObservation
R1T1002026-08-31USD100.00Receipt
R2T1012026-08-31USD50.00Receipt
R3T1012026-08-31USD50.00Same event payload as R2
R4Missing2026-08-31USD25.00Identifier missing
R5T1032026-08-31EUR20.00Separate currency
R6T1042026-02-30USD30.00Impossible date; amount needs source comparison
R7T1052026-08-31USD−10.00Refund; negative value is permitted

Download the raw example (CSV), fictional source-of-record evidence (CSV), and review decisions (CSV). All identifiers and values are invented. The reference file supplies the facts for this exercise; it is not produced by guessing from the raw file.

Six of seven rows contain a transaction ID, so field completeness is 6 ÷ 7, or about 85.71%. That is not an overall accuracy score. R6's amount is a perfectly valid decimal but differs from the reference. R7 is negative because it records a refund; a blanket “reject negatives” rule would remove a legitimate event.

Fixing one problem does not prove the total

  1. Preserve the raw file. Attach a batch ID and keep the import unchanged for investigation.
  2. Flag R3 as a candidate duplicate. The fictional source confirms there was only one T101 event. Retain the decision record when excluding R3 from the working set.
  3. Hold R4 and R6 for review. Do not invent the missing ID or choose the nearest plausible date.
  4. Compare with source evidence. It supplies T102 for R4, and August 31 plus USD 35.00 for T104 in R6.
  5. Recheck the corrected result. Compare counts, identifiers, dates, and amounts by currency against the reference.

The raw USD total is $245, with EUR 20 separately. Removing the confirmed $50 duplicate leaves USD 195. It still misses the USD 200 control by $5. Correcting T104 from $30 to its evidenced $35 closes that difference. Restoring R4's identifier fixes traceability without changing its $25 amount.

Before those two records are resolved, the accepted subtotal is only USD 140 plus EUR 20; USD 55 remains in review, and the extra USD 50 is the duplicate. Report that separation rather than describing the accepted subset as the complete day's activity. After documented correction, six distinct events reconcile to USD 200 and EUR 20.

Do not add 245 and 20 and call the result “265 dollars.” Different currencies require separate totals or an explicitly documented conversion. Even a correct grand total can conceal offsetting errors, so reconciliation should also inspect identifiers and individual amounts.

Make quality work repeatable

Assign a business owner for definitions, a technical owner for ingestion, and a reviewer authorized to resolve exceptions. Record the rule, failed rows, evidence, correction, reviewer, and date. Track unresolved issues by their effect on the report, not only their count.

Trace each reported value back through transformations to its source. The Basel Committee's January 2026 implementation newsletter identifies data lineage and timely ad hoc reporting as continuing challenges; it explicitly does not establish new supervisory expectations.

AI can suggest validation rules, summarize exceptions, or propose candidate matches. Test suggestions against known examples and keep them separate from accepted corrections. A model cannot establish a missing transaction ID by making the table look consistent. Use non-sensitive samples for experimentation and authorized systems for actual financial records.

Connect quality checks to a decision: a cash forecast needs current, reconciled balances; a collections list needs the right customer and open invoices. The financial-workflow guide places those records in the wider process, while payment reconciliation shows how fees and refunds change a bank deposit.