When systems don’t match

One system shows an amount.

Another system shows a different one.

So an investigation begins that may involve files, reports, interfaces, manual entries and several people trying to explain where the difference came from.

In many organizations this happens again and again.

And although the problem shows up between two systems, its origin isn’t necessarily in either of them.

A difference is a symptom

Systems are part of a wider flow of information.

Before a number reaches a final report, it may have gone through:

source data → business rules → interfaces → transformations → files → manual processes → controls → reporting.

A difference can be created at any of those points.

For example, two systems may use different cut-off dates.

An interface may fail to process certain transactions.

A rule may have changed in one system and stayed the same in another.

A manual file may introduce an extra transformation.

A transaction may be left pending processing.

Or two teams may be applying different criteria to the same information.

That’s why comparing only the final result can tell us that a problem exists, but not necessarily explain why it exists.

Follow the data back to its source

When a difference keeps coming back, a useful question is:

Can we rebuild the data’s journey end to end?

That means identifying:

• where it originated;
• which system recorded it first;
• what transformations it went through;
• which interfaces it crossed;
• which rules were applied;
• what manual intervention took place;
• which controls were run;
• and how it ended up in the final result.

This traceability lets you stop chasing differences one by one and start understanding the pattern that creates them.

Reconciling shouldn’t mean investigating the same thing every month

A reconciliation is a fundamental control.

But when much of the monthly effort goes into explaining the same categories of differences over and over, the problem may not lie only in the reconciliation.

There may be an opportunity to redesign the process that happens before it.

A good reconciliation shouldn’t just detect that something doesn’t match.

It should also help tell apart:

• expected differences;
• real exceptions;
• processing errors;
• structural problems;
• and situations that need investigation.

The better the process is designed, the more the team can focus on the exceptions that matter instead of manually reviewing the whole population.

From symptom to cause

At GUBLAN we start from one premise:

where a problem shows up isn’t always where it started.

That’s why we analyze:

Source → journey → process → systems → controls → result.

The goal isn’t simply to make two numbers match.

It’s to understand why they should match, under what conditions they might not, and which controls should make it possible to explain any difference.

Trusting the numbers requires traceability

An organization can have sophisticated systems and still struggle to fully trust certain information.

Trust doesn’t depend only on technology.

It also depends on being able to answer:

• Where did this number come from?
• What happened to the data before it got here?
• Which controls ensure its integrity?
• Can we explain its differences?

When those questions have clear answers, Finance gains something more important than a correct reconciliation:

it gains control over its information.