Four versions of the same top-up
A top-up has four versions: what was requested, what was delivered, what was recorded and what was charged. The problem does not end when the provider responds, or when the customer receives their balance. It ends when you can show that all four belong to the same operation.
In the note on the top-up nobody knows went through the timeout was left as a third state: nobody knows whether the top-up was applied. What settles it is reconciliation. In the integrations we have handled, it depended on information from the carriers or providers: a file of operations roughly every 24 hours, matched against our transactions, and sometimes a difference had to wait for the next cycle to be resolved.
The figures in the examples are illustrative: they come from a tool with synthetic top-ups and assumptions you can change, not from our operations.
Three states, not one
A top-up does not have one state. It has three, and they tend to end up mixed together:
- Technical: what happened in the communication. Successful, rejected, no response.
- Operational: whether the top-up was really applied.
- Financial: whether the charge was acknowledged and reconciled.
A transaction can fail in the communication and still have been applied and created a financial obligation. If the system keeps a single state, that difference has nowhere to live.
That is why the most delicate difference is this one: our platform has no confirmation of success, but the provider did apply the top-up. If the uncertainty is read as a rejection, it triggers a second attempt on something that was already applied. The reverse is delicate too: our system records a success and the provider does not acknowledge applying it. In both cases, the difference is investigated before any financial adjustment.
With an identifier and without one
When both systems share a unique, unambiguous identifier, matching is simple: each row of the file says which operation it belongs to. I cannot say for sure that every provider returned it in their files. Without it, you have to match by phone number, amount and how close the times are, and that brings ambiguity: two legitimate top-ups can share those three values without being the same one.
A clear case is the cashier who got no response and sends the same top-up again a few minutes later. Same phone, same amount, almost the same time. If both were applied, the file has two rows, and without an identifier there is no way to tell which is which.
That leads to a rule: if there is no shared identifier, a match by phone, amount and time does not authorize moving money. It can be a candidate match, but it needs evidence to be considered final.
Thirty days, twice
To see what it costs, we built a reconciler with thirty days of synthetic top-ups: about 2,000 a day, 1 % with no response, 60 % of those actually applied, and half of them sent again by the cashier. Every morning the previous day’s file arrives and is matched against what is pending. Whatever does not match goes to a person with eight hours a day. A difference matched by identifier already carries its evidence: it is reviewed and authorized in five minutes. One without evidence has to be investigated: thirty. Each case has seven days to be handled. All of those are assumptions, and you can change them in the tool.
The same run, 60,034 top-ups, is computed twice:
| No identifier | With identifier | |
|---|---|---|
| Matched by identifier | 0 | 57,953 |
| Match by attributes, not final | 57,151 | 0 |
| Top-ups in ambiguous groups | 703 | 0 |
| Cases with evidence | 0 | 402 |
| Cases to investigation | 959 | 255 |
| Person-hours needed | 480 | 161 |
| Cases that expire unattended | 288 | 0 |
| Amount of the expired cases | $31,950 | $0 |
With the identifier, reconciliation needs 161 of the 240 available hours and nothing expires. Without it, it needs 480: the queue grows from the first day, the person handles the oldest first, and 288 cases reach the deadline unattended. With twice the person-hours, none would expire: the cost of not having the identifier is paid in hours.
How many hours depends on the assumptions. If investigating took fifteen minutes instead of thirty, the 240 hours would be just enough without an identifier. And if a difference with an identifier also took thirty, the run with the identifier would need 329 and 49 would expire. What does not change is the shape: without the identifier there are almost four times as many cases to investigate, 959 against 255.
And without the identifier, not even what matches is settled: 57,151 top-ups match by attributes with no money to move, but none of them is final.
In this run, no match by attributes paired the wrong top-up, but in others some did. Over fifty runs there were 27, almost always from the cashier’s retry: the first top-up is applied late, outside the window, and the retry takes its row. Of those 27, 25 involved money, and because of the rule they went to investigation instead of moving money. The other two were left as matches that were not final, with nobody seeing them. The tool can count them because the data is synthetic; in reality, that number is invisible. That is why the rule matters: it does not prevent the wrong match, it prevents it from moving money.
Missing is not lost
The date a top-up was requested, the date it was applied and the provider’s cutoff date are not necessarily the same moment. A top-up applied late, or after the cutoff, shows up in the next file.
That is why an operation missing from one day’s file should not be assumed lost or failed. In the tool, whatever is missing waits one more file before going to investigation. If the provider’s cutoff moves to 23:00, whatever was applied in the last hour of the day arrives in the next file and is reconciled there, with nobody investigating it.
Settling the state is not settling the money
Changing an operation’s state in the database is not enough. You have to determine whether the service was delivered, whether there was a charge, whether a balance adjustment is due and whether there is enough evidence to file a claim with the provider.
Differences cannot always be resolved automatically. When there is uncertainty, the operation stays under investigation until there is evidence. But it cannot stay there forever either: the system has to know since when each difference has existed, when it must be resolved and when the chance to claim it expires. A difference with no owner and no follow-up is money lost in silence.
What gets automated and what does not
Our platforms have evolved toward recording every transaction with its states, references and processing times, and that makes it possible to automate more and more checks. I would not claim we have removed human intervention from all of reconciliation. What I am clear about is the split:
- Automatic reconciliation settles the unambiguous matches.
- Differences with enough evidence are classified and their resolution is prepared.
- Ambiguous differences, or those with financial impact, go through a controlled process of investigation and authorization.
Automation should reduce repetitive work, not replace financial decisions made without evidence.
What I would do today
The reconciliation rules, before the first operation. Not once differences have piled up.
From the provider, by contract, five things:
- A unique operation identifier that is the same in the request, the response, later queries and the reconciliation file.
- A way to query a transaction’s final status, without depending only on the daily file.
- A reconciliation file or interface with a documented structure, time zone, cutoff time and rules for operations processed outside the period.
- Explicit deadlines for disputes, a way to submit evidence and a procedure for financial adjustments.
- Guarantees of the file’s integrity, and a way to detect missing, duplicated or modified operations.
On our side: reconciliation independent of transaction processing. Each operation with an immutable internal identifier and its history of states, communications, confirmations and adjustments. And the three states, technical, operational and financial, kept separate and in plain view.
To try it with other volumes, another cutoff, another deadline or your own files, there is the reconciler: it runs in the browser, matches the same run with and without an identifier, and if you open your two CSV files, they are sent nowhere.
The problem of a top-up does not end when we get a response from the provider. It does not end when the customer receives their balance either. It ends when we can show that what was requested, delivered, recorded and charged belong to the same operation. And when those four things do not match, we need a procedure to determine what happened, who has to answer for it and how to fix it without causing a second loss.
Reconciliation should not be the process that finds our mistakes the next day, but the mechanism that continuously shows the integrity of our operations.
Israel Negrete Lepe is an electronics engineer. Twenty-five years making different systems work together under real conditions: from the sensor, the vehicle or the transaction to the backend, the data, security and operations. Today, increasingly, edge AI.