Two reports show “successful payments” for the same day. One says 81%, the other 84%. Both may be technically correct.

That situation is common when a metric has grown across teams, tools and manual reporting steps. The fastest response is not to redesign the dashboard. It is to identify exactly where the two calculation paths stop describing the same population.

Start with a reproducible comparison

Choose one small period, one market or business unit and one KPI. Export the underlying records or intermediate totals from both reports. Write down:

  • the exact report names and run times;
  • every active filter;
  • the displayed numerator and denominator, not only the final percentage;
  • the source tables or files, if known;
  • the person or team responsible for each output.

This creates a controlled example. Without it, the discussion usually drifts between several dates, filters and interpretations.

1. Check whether the population is actually the same

“All transactions” can mean initiated, submitted, processed, settled or only currently visible transactions. A management report may exclude test traffic, internal accounts or very small markets. An operational view may include them because the team needs to investigate every event.

List the inclusion and exclusion rules for both reports. Compare record counts before comparing percentages. If the populations differ, the KPI will differ even when both formulas are correct.

2. Check time zone and date logic

A calendar day in UTC is not the same set of events as a calendar day in Malta or Serbia. Differences also appear when one report groups by initiation time and another groups by final status time.

Confirm:

  • the time zone used by each source and report;
  • which event timestamp assigns a record to a period;
  • how late-arriving events are handled;
  • whether the latest day is complete when the report runs.

A small disagreement concentrated around midnight or the newest period is often a timing issue rather than a business change.

3. Compare status definitions

Operational systems frequently contain more states than the business label suggests. “Successful” may include authorised payments in one report and only captured or settled payments in another. Declines, cancellations, reversals and retries may also be grouped differently.

Create a simple mapping from raw statuses to reporting categories. Keep the mapping visible and version-controlled. A label without a documented status set is not a reliable KPI definition.

4. Test joins and duplicate handling

A one-to-many join can multiply rows. A retry can appear as a new attempt in one model and as part of the original customer journey in another. Deduplication may keep the first event, the final event or the most recently updated record.

Check row counts before and after every important join. Then test several known identifiers end to end. Aggregate totals are useful for locating the gap, but record-level traces usually explain it.

5. Check data freshness and refresh order

Two reports can use the same definition and still disagree because one source is newer. A dashboard might refresh every hour while a spreadsheet uses yesterday’s extract. A transformation may run before an upstream table is complete.

Display the data-through timestamp and last successful refresh where users can see it. For recurring workflows, monitor the expected sources and stop or flag the output when critical inputs are late.

6. Separate a calculation difference from a presentation difference

Rounding, hidden filters, default date selections and cached extracts can create visible differences even when the underlying calculation matches. Compare raw numerator and denominator values before changing business logic.

The goal is to locate the first stage where the values diverge:

  1. source records;
  2. filtering and status mapping;
  3. joins and deduplication;
  4. aggregation;
  5. refresh timing;
  6. display and rounding.

What to document after the issue is found

A repaired report can drift again unless the decision is made explicit. Record the KPI owner, business definition, numerator, denominator, exclusions, event time, time zone, source, refresh expectation and known limitations.

For an important metric, add a small control that compares record counts or totals at key stages. The control should identify a meaningful change, provide enough context to begin an investigation and have a clear owner.

When the problem should become a system

A one-off analysis is appropriate when the disagreement is new or the process is still changing. Automation becomes valuable when the same reconciliation repeats, several people rebuild the same checks or stakeholders regularly receive a report before anyone notices incomplete data.

At that point, the useful deliverable is more than a corrected dashboard. It is a repeatable data flow with visible definitions, validation, refresh monitoring and documented ownership — which is what a reporting or BI implementation is for. On payment data specifically, the same reconciliation usually sits across several providers, which is covered on the payment analytics page.

The practical rule is simple: first make the metric explainable; then make the process repeatable.