The hidden risk of manual reconciliation is in your people, not your processes

Most manual reconciliation processes I’ve managed or seen start with a daily list of exceptions. Someone on the finance or ops team works through it each morning, drawing on what they know about how each bank and processor behaves.

As payment volume grows, teams usually hire more staff to stay on top of the list. In theory, more people means more capacity to handle exceptions. But the knowledge needed to resolve the hardest ones often stays with one or two people on the team. That’s the hidden risk of a manual recon process.

The bus factor for manual recon (or, what happens when Jody takes a vacation)

The bus factor idea comes from software development teams. It measures how many people could disappear (i.e. get hit by a bus) before the project in question stalls. That seems harsh, so I prefer a gentler version: what happens when your most experienced recon person takes two weeks off?

For my team at Modern Treasury, that person was Jody. When we were reconciling a trillion dollars a year, she handled the most complicated exceptions.

Consider what happened if an outage held up a batch of payments for a few days. Once it cleared, the bank might post the whole batch by hand, and none of it would map nicely to the rules we’d already written. Jody knew how to piece it back together and which items would sort themselves out if we waited a day. When she was out, those exceptions mostly waited for her return.

Since starting End Close, I’ve met so many versions of Jody on other teams. And the more I see it, the more I realize what a risk factor this is for businesses that move money at scale.

This risk can present itself differently depending on your team structure and recon processes. It may look like:

• A spreadsheet or script only one person maintains. Recon tooling often starts as a quick spreadsheet build or SQL script. As edge cases pile up, it can grow into a thousand-line script or a workbook full of nested formulas that only its builder understands. When a bank upgrades its core system and changes delimiters in its files, the original owner may be the only one who can safely make an update.
• Exception rules that aren’t written down. An analyst knows a processor can hold part of your balance in reserve, and that the reserve amount can change several times a day. So a payout that arrives short may be expected. If that knowledge isn’t documented, whoever’s covering may chase a break that doesn’t exist or miss one that does.
• Recurring manual fixes nobody has automated. Some exceptions follow the same pattern every day, and one person clears them each morning. A rule could handle them, but nobody has written one, so they wait when that person is out.
• Data sources only one person can access. Some processes depend on someone logging into a bank or processor portal to download a file. The person who set up that access may have left years ago.
• Matching rules nobody can explain. Teams tend to add a new rule when conditions change and leave the old ones in place. Over time, nobody remembers why many of them exist, which makes the whole rule set harder to trust.

What all these scenarios have in common is that they stay hidden while the person who holds the knowledge is around. Most of this linchpin’s work shows up as a short exception list and totals that match, so it’s easy to forget how much of your process depends on her.

The recon breaks that can easily go unnoticed

When the person who handles your most complex exceptions is out, it’s easy for breaks to slip past whoever is covering. While some exceptions can be obvious, many sit within numbers that look fine at first glance.

Take a processor that sends a single $50,000 payout covering 1,000 payments of $50 each. If one customer’s payment failed and another customer was charged twice, the payout still totals $50,000.

Your recon lead has probably seen that pattern before and knows when a clean total deserves a closer look. Someone filling in, or squeezing recon in around their usual work, will often stop once the totals tie. The problem then surfaces only when a customer complains or the balances drift.

Data that’s missing altogether can hide breaks just as easily. Say your process depends on someone downloading a settlement report from a bank portal each morning. If nobody does it, there’s nothing to reconcile, so nothing shows up as an exception. Your exception list actually gets shorter.

One of the best-known examples of missing data causing breaks happened outside payments. In 2020, Public Health England left nearly 16,000 Covid cases out of its daily figures. Test results had gone into an old Excel format with a row limit, and Excel dropped the overflow without any error. A bank file that only partly loads could do the same thing to your recon.

Watching your inputs as closely as your outputs catches many of these early. An alert for a file that arrives late or incomplete surfaces the gap the same day.

Without that, you’ll often find out about these breaks weeks later, when the money is much harder to recover. By then, many teams don’t bother chasing them. They declare bankruptcy on the backlog and write the breaks off as a promo credit or a cost of doing business.

Why it’s getting harder to write off manual recon breaks

For a long time, writing off aged breaks was a reasonable trade. The amounts were usually small, and chasing them likely cost more than they were worth.

The trends reshaping payments are making that trade harder to justify.

Payments companies keep adding rails and banking partners, often faster than recon can adapt. When product launches a real-time rail like RTP, recon inherits a new set of edge cases that someone on the team has to learn. More volume across more rails means a growing backlog of exceptions that can cost the business in different ways:

• Leakage that’s tolerable at tens of thousands of payments a month adds up quickly at millions. I’ve spoken with providers losing eight figures a year to exceptions the team didn’t have capacity to address.
• ACH returns only give you 1-2 days to act depending on the return reason code. When a backlog makes you miss it, money you could have recovered becomes a writeoff (or, in one worst case scenario I’ve seen, you end up in litigation with your own customer).
• Unexplained writeoffs cost you at audit time. Auditors want to see the reasoning behind your manual matches along with the results. When they can’t follow it, they tend to expand their testing, which means more fees and more hours from your team.

Regulators are pushing in the same direction. In 2024, the FDIC proposed a rule that would require banks holding custodial accounts for fintech partners to reconcile those balances daily. The rule hasn’t been finalized, but it’s still on the FDIC’s regulatory agenda. If it takes effect, banks would need daily transaction-level data from their partners, which leaves little room for exceptions that wait on one person.

Plenty of reconciliation vendors promise to fix this for you. But most of them are matching tools. They clear the straightforward transactions and hand you a list of exceptions, which leaves you with the same recon problem you had before. Actively addressing the bus factor of manual recon requires more than just matching.

Codify what your recon team knows, then automate it

Reducing your recon bus factor starts with documenting and codifying how your team resolves exceptions. Everything your version of Jody knows should move out of her head and into something the rest of the team can use when she’s not there.

I got a clear look at how much knowledge that is when I sat down with one team’s recon lead to document a single monthly process. Every time a line didn’t match, she knew why. One customer, for example, was never billed for a particular line item, and she simply knew to skip it. By the time we finished writing down every step of her thought process, the document ran to ten pages.

Most recon teams probably have a similar document waiting to be written. You can start documenting and codifying processes by:

1. 1.Documenting every manual touch and the reason behind it. For a week, record each step you or your team takes and why, including steps that happen outside your formal system. A note explaining which contract term causes a recurring mismatch is worth more than the fix itself.
2. 2.Fixing root causes as you find them. Documenting often shows that an exception shouldn’t exist at all, such as a billing system that produces the same error every month. Fix those at the source so they stop showing up in recon.
3. 3.Turning repeatable judgments into rules. If someone makes the same call every day, a deterministic rule can make it for them, with the same result every time.
4. 4.Creating playbooks for the remaining judgment calls. Some exceptions need real investigation, so document how they actually get worked, step by step.
5. 5.Testing it with a ‘vacation.’ Have whoever knows the process best, maybe you, step back for a week and see which exceptions still get resolved.

Once the knowledge is written down, automating is much simpler.

Deterministic rules can take over the repeatable calls and handle them the same way every time. An AI agent can then follow your plain-English playbooks to work the remaining exceptions and log its reasoning for your team to review.

Whatever tool runs your rules and playbooks, make sure you can export them along with the decision logs. Otherwise, you’ve only moved the bus factor from Jody’s head into a vendor’s system.

Five questions to evaluate your own recon risk level

Codifying your recon process takes time, so it helps to know how exposed you are before you start. These questions won’t give you a score, but answering them honestly shows how much of your recon depends on one or two people:

1. 1.If your most experienced recon person were out for two weeks starting tomorrow, which exceptions would wait for them?
2. 2.How many open exceptions do you have right now, and how old is the oldest one?
3. 3.Could a new team member explain why each of your matching rules exists?
4. 4.If a bank changed its file format or a daily file stopped arriving, how quickly would you find out?
5. 5.Could you show an auditor the reasoning behind last month’s manual matches, along with the results?

It’s normal for the answer to many of these questions to be “it depends.” That would have been the case for my team at Modern Treasury even though I like to think we were ahead of the curve in terms of automating and standardizing our recon processes.

What we didn’t have then was a way to hand those hardest exceptions to something other than another team member. That’s what we built End Close to do. It runs the rules and playbooks your team documents, and its agents log every decision so your team can review each one.

If you want to see how that works on your own process, send us your historical unreconciled data, and we’ll show you how we can automate your process end to end.