Reconciliation is an operations problem first
Most reconciliation breaks are created before anyone in finance sees them. They begin with a product decision or an adjustment made in a hurry, and they reach the finance team days later with the context gone.
Finance still gets asked about them, because finance owns the report where they show up. We think that arrangement is backwards. Unmatched items get resolved sooner, and written off less often, when operations treats them as something it produces and therefore has to clear.
The Synapse case has made the point harder to ignore. Synapse Financial Technologies, a US banking-as-a-service middleware firm, filed for bankruptcy in April, and since then end users of several fintech apps have lost access to their funds while the parties try to work out whose records are right. Few operations teams will ever face that problem at that scale. Most face a small version of it every morning: two sets of records that should agree, and no quick way to say which one is correct when they don't.
Where the breaks start
Say a card program reconciles its ledger against the processor's settlement file each morning, and on a typical day about 40 of 20,000 lines fail to match. The numbers are illustrative, but the pattern is common. Trace those 40 back to where they came from and very few of them began in finance.
Some are refunds that a support agent issued from the admin console. The ledger recorded them straight away and the processor will settle them tomorrow. Some are partial captures, where a merchant settled for less than the authorized amount. A handful are fees on a transaction type that product launched last month, which nobody added to the matching rules. One or two are balance corrections made to calm an unhappy customer, explained in the support ticket and nowhere in the ledger.
Each of those had a sensible reason at the time. The people who made the decision just never see what it does downstream. The reconciliation analyst sees it, usually without access to the processor configuration or the ticket that would explain it.
So the analyst does what anyone would do with a break they can't explain. They park it in a suspense account, add a comment and move on to today's file. Tomorrow there are 40 more, and some of yesterday's are still there.
Who investigates, and who fixes
Three different jobs tend to get blurred together here. Detecting a break is a reconciliation task. Investigating it needs someone who understands the process that produced it, and fixing the cause needs someone with authority over that process, often a product manager or whoever owns the processor relationship. When all three jobs land on the reconciliation team, detection keeps working and the other two stall.
Whoever runs the reconciliation report ends up answering for every break in it, whether or not they can fix any of them.
A workable split looks something like this.
-
Give every break a cause code on the day it appears
The analyst picks from a short list: timing, fee, missing transaction, duplicate, manual adjustment, unknown. Unknown is allowed, but it should be the smallest bucket by the end of each week.
-
Route each cause to the team that can remove it
Fee differences go to whoever owns processor configuration. Manual adjustments go back to the team that made them. Timing differences stay with reconciliation, because someone has to confirm they cleared.
-
Set an aging limit for each cause
A timing break that is still open after three settlement cycles has turned into something else. Reclassify it and send it to whoever owns the cause it turns out to have.
-
Review the counts monthly with product in the room
Look at breaks by cause and by owning team with the people who make the upstream decisions. This is the meeting where fixes get prioritized, so it needs someone who can change a backlog.
Watch the age before the count
Headline counts hide the position. A program with 200 open items, 150 of them less than a week old, is in a very different place from one where 150 are older than 60 days, even though the dashboard shows the same number for both.
Age matters because investigation gets harder every day an item stays open. At two days, the person who made a manual adjustment remembers why. After a month they may have changed teams, the processor's support desk wants a reference nobody kept, and the only way to close the item is a write-off signed by someone senior who has to take the analyst's word for it. Put aging buckets on the weekly operations report (under 3 days, 3 to 10, 11 to 30, over 30). They say more about the health of the process than a match rate, which can sit at 99.8% while old items pile up underneath it.
Suspense accounts deserve the same treatment. A suspense balance that grows a little every month is a set of unanswered questions with a total at the bottom, and sooner or later an auditor or a partner bank will ask what is in it.
Then there is the question Synapse pushed into the open. If you work with a partner bank, you should know which ledger is the ledger of record for customer balances, who reconciles it against the bank's records and how often, and what happens to differences between the two. A backlog of old unmatched items is exactly what makes those questions slow to answer on the day someone needs the answer.
A first pass you can do this month
Take last month's open items, add a cause code and an age to each, and count them by the team that could have prevented them. Share that table with the product and operations leads before it goes to finance. Expect the first version to be uncomfortable to read. It usually points at a few upstream fixes, often in processor configuration or support tooling, that would clear much of the daily noise before it reaches anyone's reconciliation.
Discuss your operations
