Before Hiring a Power BI Consultant, Define the Report Acceptance Test

A dashboard shows $1,000. The source export shows $1,000. Everyone agrees the report is ready.

That agreement can survive a missing invoice, a duplicate and an incorrect location assignment. A matching total is useful evidence, but it leaves several ways for the report to be wrong.

Before buying Power BI consulting services, choose one report and define what would make it acceptable. The first deliverable should define the metric, included records, reporting cutoff and approver.

Decide which question the report must answer

“Sales by location” leaves too much open. Orders, invoices and cash receipts measure different events. An invoice date and a payment date put the same customer activity into different periods.

Write a short contract for the first report. Name the metric, included statuses, date field, time zone, currency, source population and person who approves the definition. State what one row represents. If that row is an invoice, document how credits, corrections and line items affect the result.

Microsoft's Power BI modeling guidance explains why fact tables need a consistent grain. For an operating owner, the practical question is whether joining another table changes what a row represents or causes an amount to be repeated.

The source report also needs scrutiny. A familiar spreadsheet can contain a manual adjustment or an undocumented exclusion. If neither side has an approved definition, agreement between them establishes consistency with an unknown rule.

Test the records behind a matching total

Consider this synthetic example. These are invented invoices in USD, all eligible under the same reporting contract. The example is a worked comparison, not a Better customer result.

North should show $600 and South $400. Now introduce three separate errors into copies of those records.

We checked these outcomes with a small offline Python fixture using integer cents. No Power BI model was executed. The exercise establishes the arithmetic and comparison outcomes shown here; it does not validate a connector, DAX measure or deployed report.

The acceptance test should therefore compare approved record identities and relevant fields as well as totals. Check duplicates before building a lookup that could silently overwrite them. Retain missing, unexpected and changed records as an exception list with an owner.

The engineer should provide a detail extract or reconciliation query at the agreed grain, even when the report displays only aggregates. For this example, acceptance means each approved invoice appears once, its location and amount match, and no unexplained exceptions remain.

For large populations, ask the engineer to show how the comparison covers the agreed scope. A sample can help investigate a discrepancy, but it cannot establish that every record matches. Where stable identities are unavailable, record the alternative matching rule and its ambiguity.

Do not force every total to equal the sum of visible rows. Microsoft documents many-to-many examples with non-additive customer balances. Define the expected calculation before deciding that a different total is a defect.

Keep time and access in the acceptance criteria

An export produced at noon and a report using yesterday's imported data can disagree without either calculation being broken. Retain the source extraction time, reporting cutoff, time zone and model refresh evidence with the comparison.

Microsoft's refresh documentation distinguishes imported data, which needs refreshing to reflect source changes, from DirectQuery, which sends queries to the source. Ask which mode the actual report uses and what freshness it can demonstrate. A successful refresh is evidence about that operation; it does not establish the metric's business meaning.

Test the intended user's view too. Two people may legitimately see different populations. Microsoft states that row-level security applies to workspace Viewers and does not restrict Admin, Member or Contributor roles. An administrator's successful test cannot stand in for a restricted user's acceptance.

Buy the scope that the evidence requires

If the source records and definitions are stable and the gap is one measure or visual, a bounded specialist engagement may be sufficient. If teams disagree about the metric, resolve ownership and definition before commissioning dashboards. If source feeds repeatedly miss or change records, include the upstream engineering work in the scope.

Ask the proposed consultant to demonstrate a representative model, explain a discrepancy at record level and show how the report will be maintained. Agree who owns refresh failures, changed source schemas, access tests and metric revisions after handover. A report inventory and training plan matter when the project includes conversion of an existing reporting estate.

Better's Apex Dental Partners case study describes custom reporting and operations software across a dental group. That is relevant operations engineering experience. It does not establish Power BI, DAX or Microsoft partner credentials. Those capabilities should be verified for the people assigned to a Power BI engagement.

If the project also replaces a spreadsheet process, use a separate parallel-run plan for the transition. Report correctness and operational cutover are related decisions with different acceptance evidence.

Bring one disputed report, its source and the decision it supports to a conversation with Better. The useful next step is to establish the scope, required specialist skills and evidence for acceptance before committing to a wider build.