The final balance does not explain where the difference started

A card transaction is not an event. It is a crossing.

It passes through capture, authorisation, scheme files, product rules, processing windows, fee calculation, the financial schedule and settlement. At every handover, something can be lost, duplicated, arrive out of order, or be transformed by a rule nobody remembered existed.

At the end of the path there is a number. And when that number does not match, the expensive part begins.

The problem is not detection. It is location.

Almost every operation has reconciliation. What is frequently missing is what comes before it: controls between the stages that feed the final result.

Without them, the team knows there is a difference and does not know where it started. The investigation becomes manual cross-checking of spreadsheets across systems, burning days of senior people and often ending in a partial explanation.

Eduardo, who has more than 30 years in mainframe, cards and acquiring, describes an episode that illustrates the materiality of the risk: a code failure in a complex financial flow produced an undue payment. The point of the story is not the amount involved — it is the time lost hunting for the rupture when there is not enough visibility between stages.

The lesson is direct: reconciliation has to allow investigation along the path. When a difference appears, the operation should be able to tie it immediately to the processing point, the data source and the set of affected transactions.

Five layers of control

In practice, controlling the integrity of a financial flow means checking five different things, and confusing them is what makes investigation slow.

Identity. Relate the same transaction across different sources through agreed identifiers and matching rules, preserving the reference to origin and processing. Without this, nothing else is comparable.

Completeness. Identify expected records that never arrived, records without a match and duplicates — handling resends and reprocessing, which are normal and should not trigger an alarm.

Amount and rule. Check gross and net amounts, instalments, fees, refunds and chargebacks. This is where the most important distinction lives: separating a rule difference, which is legitimate, from a data difference, which is a failure.

Time and status. Account for movement date, settlement date, cut-off and transaction status, with explicit tolerance for events that arrive at different moments. A lot of investigated discrepancy is just lateness.

Exceptions. Record the evidence, classify materiality, route it to the owner and follow it through to resolution, keeping a history of decisions. Without this, the same exception is rediscovered every month.

Start with one flow, not the whole operation

Trying to cover everything at once is the most reliable way to deliver nothing. One possible starting point is the integrity of merchant settlement: relating the records that feed the schedule, the applicable adjustments, the expected net amount and the payment confirmation.

The path we use has three moments:

Diagnostic. Map of the flow, sources, control points and business rules. Inventory of known discrepancies and a pilot proposal, with responsibilities and acceptance criteria defined before anything starts.

Pilot in parallel. Integration of the agreed sources, checking rules, evidence and exception routing — running alongside the current process, with read access and alerts only. Nothing touches payments at this stage.

Operation and expansion. New flows and rules, exception follow-up and evolution of the controls, based on what the pilot showed.

One warning usually missing from commercial proposals: any block or automatic action on payments requires its own scope, homologation and formal approval. Detecting and acting are different decisions, with different risks.

The sign that it is worth looking

If any of these sentences sound familiar, a layer of integrity is probably missing:

• Differences show up at closing and require manual cross-checking between systems.
• Teams struggle to explain where a transaction or an amount changed.
• Reprocessing, duplicates or delays drive recurring investigation.
• Reconciliation exists, but controls between the stages feeding the result do not.

The goal is not to eliminate discrepancy — it will always exist, because the ecosystem is distributed and asynchronous. The goal is that, when it appears, the answer takes minutes instead of days.