Blog · Data quality and reconciliation · Finance and FP&A teams
Compare missing fields, duplicate records, and failed checks without counting the same problem twice. This worked example shows source-level measures, a reconciliation, and the effect of changing one input.
Power BI data quality dashboard examples are useful when they show which source records need correction and prove how the counts were built. Put completeness, excess duplicates, failed business checks, and distinct affected rows beside one another, with the same reporting cutoff and an explicit denominator.
Microsoft describes a Power BI dashboard as a single page of highlights, with related reports supplying detail. The layout below follows that business purpose: a short overview supported by the exact exception records. Covirage is not affiliated with Microsoft, the maker of Power BI, Power Query, and Excel.
Consider an illustrative Ohio distributor reviewing finance exports on October 23, 2026. It receives ledger, billing, and customer records. Each source has its own business key, so duplicate matching happens within a source, never across unrelated documents.
The required identifier is the supplier or customer account attached to that record. A blank fails completeness. The business check tests a separate category code against the source owner's approved list. It can pass when the identifier is blank because it evaluates another field. Document each check independently rather than letting a blank silently disappear.
For duplicates, retain the earliest record in the displayed order and flag later occurrences of the same source and key. This is an excess-record measure. A separate investigation can examine every member of each duplicate group before anyone removes records.
Microsoft's Power Query profiling documentation distinguishes valid, error, and empty values. Those field classifications help a review, but your business rules still decide whether the identifier and transaction are appropriate. A filled field is not proof of a correct transaction.
These are the complete exported rows for the example. "Present" means the required account identifier is filled. "Excess" identifies a repeated key after its first appearance. The business check is an independent pass or fail.
| Row | Source | Business key | Identifier | Excess duplicate | Business check |
|---|---|---|---|---|---|
| L1 | Ledger | GL-A | Present | No | Pass |
| L2 | Ledger | GL-B | Present | No | Pass |
| L3 | Ledger | GL-C | Missing | No | Pass |
| L4 | Ledger | GL-B | Present | Yes | Pass |
| L5 | Ledger | GL-D | Present | No | Pass |
| L6 | Ledger | GL-E | Present | No | Pass |
| B1 | Billing | INV-A | Present | No | Pass |
| B2 | Billing | INV-B | Present | No | Fail |
| B3 | Billing | INV-C | Present | No | Pass |
| B4 | Billing | INV-D | Present | No | Pass |
| B5 | Billing | INV-E | Present | No | Pass |
| C1 | Customer | ACC-A | Present | No | Pass |
| C2 | Customer | ACC-B | Missing | No | Fail |
| C3 | Customer | ACC-A | Present | Yes | Pass |
| C4 | Customer | ACC-C | Present | No | Pass |
The duplicate keys are GL-B in the ledger and ACC-A in the customer export. L4 and C3 are the excess records. C2 fails both completeness and the business check; it remains one affected row.
| Source | Exported rows | Missing identifiers | Excess duplicates | Failed checks | Distinct affected rows | Rows passing all checks |
|---|---|---|---|---|---|---|
| Ledger | 6 | 1 | 1 | 0 | 2 | 4 |
| Billing | 5 | 0 | 0 | 1 | 1 | 4 |
| Customer | 4 | 1 | 1 | 1 | 2 | 2 |
| Total | 15 | 2 | 2 | 2 | 5 | 10 |
Keep the raw rows unchanged while measuring them. Removing duplicates before computing the denominator would answer a different question: the quality of the corrected file rather than the quality of the export received.
Use these definitions for the overview:
Completeness = Rows with the required identifier / Exported rows
Excess duplicate rate = Excess duplicate rows / Exported rows
All-check pass rate = Rows passing every stated check / Exported rows
There are 15 exported rows and 2 missing identifiers, leaving 13 complete rows. Completeness is 13 / 15 = 86.7%. The duplicate rate is 2 / 15 = 13.3%, and the failed-business-check rate is also 2 / 15 = 13.3%. Percentages here are rounded to one decimal place after division.
The all-check pass rate is 10 / 15 = 66.7%. It is not found by subtracting the three failure rates from 100%, because C2 appears in two failure counts. The affected-row list is L3, L4, B2, C2, and C3: exactly 5 records.
The reconciliation is 10 passing rows + 5 affected rows = 15 exported rows. The source count also ties: 6 ledger + 5 billing + 4 customer = 15. These identities are the evidence behind the overview, rather than an assumed relationship between unrelated percentages.
For a broader review layout, see the data quality dashboard. A Power BI quality dashboard addresses a neighboring search; keep its operational quality measures separate from the record checks defined here.
Now change only C4's identifier from present to missing. Keep the row, key, and business-check result unchanged. This is a scenario showing the effect of one field becoming blank.
| Measure | Original export | C4 identifier missing |
|---|---|---|
| Exported rows | 15 | 15 |
| Missing identifiers | 2 | 3 |
| Complete identifiers | 13 | 12 |
| Completeness | 86.7% | 80.0% |
| Distinct affected rows | 5 | 6 |
| Rows passing all checks | 10 | 9 |
| All-check pass rate | 66.7% | 60.0% |
Completeness becomes 12 / 15 = 80.0%, and the all-check pass rate becomes 9 / 15 = 60.0%. The customer source now has 2 missing identifiers out of 4 rows, or 50.0%, and 3 distinct affected rows. The reconciliation becomes 9 + 6 = 15. Duplicate and business-check counts stay at 2 each, because their inputs did not change.
The owner can now distinguish a completeness deterioration from a duplicate problem. That distinction determines who gets the exception list and what evidence they need to correct it.
Use the overview for completeness and the all-check pass rate, a source comparison for locating the concentration, and an exception table for assigning the work. Show the rule definition and cutoff beside the figures. Do not bury a denominator in a tooltip that disappears from a meeting handout.
The broader Power BI dashboard examples cover other business questions. If the immediate need is a spreadsheet review, the Excel dashboard guide covers that approach. Keep this page focused on evidence for correcting the records.
Bring a sample of your own finance export with its business keys and required fields. Covirage maps the columns, its tools compute and check the figures, and the external AI model explains the results with every figure traced to its rows. Create a free Covirage account; creating the account takes about a minute, then you set up your business and bring your file.
See Covirage for finance teams for the supporting finance context.
Start with required-field completeness, excess duplicate records, failed business checks, and distinct affected rows. Add the reporting date, source, and rule owner. A missing supplier identifier and an invalid invoice amount need different actions even when they affect the same record.
Define the business key and count records beyond the first retained occurrence of that key. Also keep a separate list of every record in each duplicate group for review. Counting all group members produces a different measure from counting excess records.
No. A field can contain an allowed value and still identify the wrong supplier or customer. Validity checks test a stated rule. Accuracy needs comparison with an authoritative record or confirmation from the business owner responsible for that information.
Assign the correction to the business owner of the source and the rule definition to the person accountable for the reported measure. Finance should resolve financial reconciliation differences, while the source owner investigates the underlying records and documents the correction.