Sales brings one total to the meeting. Operations brings another. Accounting has a third, and the first half hour disappears into comparing exports. By the time someone explains the difference, the conversation about what to do next has barely started.
When business reports don't match, start with the records and the rules behind the figures. Different definitions, dates, refresh times, filters, and joins can all produce conflicting numbers. Sometimes a report contains an error. Sometimes two correct reports answer different questions and happen to use the same label.
Data reconciliation means comparing the underlying records, explaining the differences, and correcting the faults you find. The goal is for people to understand what each number means and trust it for the decision at hand.
Start with one disagreement you can reproduce
Choose two reports and one reporting period. Save the versions people are comparing, along with their filters, run times, and the accounts used to view them. If the data keeps changing during the investigation, use an agreed snapshot or cutoff where practical.
Consider a hypothetical equipment maintenance company. Its completed-work report shows $184,200 for September. Its invoicing report shows $176,400. Managers have started adjusting a spreadsheet each month so they can present a single figure.
Write down the $7,800 difference and identify which decision depends on it. Are they measuring work delivered, invoices issued, or money received? That question will guide the investigation. It also prevents the team from treating the preferred report as automatically correct.
Begin with this one disagreement. Trying to reconcile every report in the business at once makes it harder to establish a method and show what has actually been fixed.
Agree on what the metric counts
Ask the people responsible for each report to explain its total in ordinary language. “Revenue” might mean the value of completed jobs in one system and posted invoices after credits in another. Booked orders, delivered work, invoiced amounts, and collected cash describe different events.
For the maintenance company, a useful definition could be “the value of jobs completed during September, before invoice credits, excluding tax.” Another might be “invoices posted during September, less posted credits, excluding tax.” Those definitions give someone a way to check the records.
Settle the treatment of cancellations, discounts, partial completion, returns, tax, and currency where those apply. Also decide whether customer counts mean accounts, locations, or individual contacts. A familiar label can hide a different unit of measurement just as easily as a different calculation.
Have the business owner of the metric approve the definition. A developer can explain how a total is calculated, but the business has to decide which calculation answers its question.
Check the dates and the reporting cutoff
An order can have a creation date, a completion date, an invoice date, and a payment date. Selecting September on two screens does not establish that they use the same one.
Look at the actual date field behind each filter. Include the timezone, the start and end boundaries, and the handling of entries made after the period closed. An event shortly after midnight in one timezone can still belong to the previous day in another.
Distinguish activity during a period from a balance at a point in time. September's transactions and the balance as of September 30 cannot be compared as though they were the same calculation. Stock snapshots and outstanding balances also need care: adding daily balances usually does not produce a meaningful monthly balance.
Decide how corrections affect earlier periods. If someone updates a job in October, should September's operational report change? A report calculated from today's records can differ from the version saved at month end. Both the historical reporting rule and the handling of corrections need to be explicit.
Compare the last successful data updates
One report might read directly from the operational application. Another might use an overnight copy. A third might be an export someone downloaded before a late import finished.
Check the last successful load for each source, the period it actually covered, and whether any records were rejected. A job can finish while leaving exceptions behind. An apparently current report can also contain one fresh source and one source that has not updated for days.
In Power BI, reloading the browser page does not necessarily refresh imported data from the source systems. Examine the model's storage mode and refresh history. For other reporting tools, trace the equivalent path through extracts, staging tables, and caches.
Agree on how much delay the decision can tolerate, and show a useful “data through” time where appropriate. If the problem lies in records failing to move between applications, our systems integration service covers investigation of those connections and their exceptions.
Look for missing records and duplicated amounts
Once definitions and cutoffs align, compare counts as well as totals. How many jobs or invoices appear on each side? How many distinct identifiers are there? Which identifiers exist in only one report?
Pay attention to what one row represents. A job, a job line, an invoice, and an invoice line are different levels of detail. Combining tables at different levels can multiply amounts even when the source records are correct.
Suppose a $900 job has three labor entries. Joining the job to those entries produces three rows containing the $900 job amount. Adding that repeated amount gives $2,700. The repair belongs in the query or reporting model, with a clear decision about the level at which each amount is calculated.
Missing rows deserve the same care. A report might exclude jobs without an assigned category, unmatched customer records, or transactions rejected by an import. Check blank values and failed matches rather than assuming every record found its way into the report.
Our article on database table naming and business meaning explains why understanding the records matters when investigating an unfamiliar database.
Check filters, permissions, and spreadsheet changes
Compare the report as the affected people see it. A branch manager may be restricted to one location, while a finance user can see the whole company. Hidden or saved filters can also survive after someone changes the reporting period.
Review status selections, inactive customers, excluded locations, and security rules that limit which rows a person can see. Correctly restricted access can explain different totals. Do not remove those restrictions just to produce a match; establish which authorized view the comparison requires.
For spreadsheet exports, inspect formulas, lookup ranges, manual adjustments, and pasted values. A new month's rows might sit below the end of a total's formula. A lookup might match a customer name that has changed. An old workbook may contain a correction nobody has carried into the next copy.
Keep a record of those adjustments during the investigation. If a manual change is necessary, it needs an owner and an explanation so the next report does not quietly recreate the same dispute.
Reconcile the difference at record level
Build a comparison using stable business identifiers, such as job and invoice IDs, plus an explicit mapping where the two systems use different identifiers. Separate records found only in the first source, records found only in the second, and matched records whose amounts or relevant attributes differ.
For the hypothetical maintenance company, suppose the investigation identifies three separate groups. There is $4,200 of September work that has not yet been invoiced, $2,400 of credits included in the invoicing total, and $1,200 of completed work invoiced outside September. Together, those explain the $7,800 difference: $184,200 minus $4,200 minus $2,400 minus $1,200 equals $176,400.
That explanation shows why these two reports should differ under their current definitions. It also gives management useful follow-up work, including checking the uninvoiced jobs. If the comparison instead finds an invoice imported twice, that is a fault to correct and verify in the affected systems.
Retain the identifiers and reasons behind the reconciliation, with access appropriate to the data. Keep unexplained exceptions visible. A small unexplained net difference can conceal larger missing and duplicated amounts that offset each other.
Fix the cause where it belongs
A definition problem needs an agreed calculation and clear labels. A duplicate import needs a change to the integration. A repeated amount needs a corrected query or model. A missing customer mapping needs an owned process for resolving unmatched records.
Choose an authoritative source for each important fact. The service application might own job completion, while accounting owns the posted invoice and credit. Reporting can combine those facts without pretending that a single application owns every part of the business.
Where several reports should use the same metric, consider a shared calculation in a database view, reporting model, or other maintained component. Record its definition and owner. Check which existing reports will change before replacing their logic.
Our reporting and dashboard development service includes the data preparation and calculations behind the screen. Once the figures are understood, our Power BI vs. custom dashboard guide can help with the separate choice of how people should use them.
Make the next reporting cycle easier to verify
Keep a small set of meaningful checks based on the faults and exceptions found. For the maintenance company, those might include completed jobs with no invoice, duplicate invoice identifiers, unmatched customer records, and an import that has missed its expected cutoff.
Verify the repair against a known period and the next live reporting cycle. Include difficult cases such as a partial invoice, a credit, a cancelled job, and an entry corrected after month end. Check both individual records and totals. QA and test automation can help preserve those calculations as integrations and applications change.
Give each exception an owner and a route to resolution. A daily warning that nobody reviews does little to improve trust. The team should be able to tell whether a difference is expected, awaiting investigation, or confirmed as a defect.
What to bring to a reporting review
Start with two conflicting reports, the period and filters used, a few example records, and the decision the figures are meant to support. Include any existing definitions, known manual adjustments, and information about where the reports get their data.
A useful review should leave you with an explanation of the discrepancy, a record of any remaining unknowns, and a practical scope for correcting the causes. Some differences can be resolved by clarifying a label. Others require changes to queries, integrations, historical data, or reporting ownership.
Honor Tech can help trace conflicting business reports back through the applications and data behind them. Tell us which figures your team cannot reconcile, and we can help establish what they count and what needs to change.