The Manual Reconciliation Problem: Staff It First, Then Automate It

Somewhere in most established businesses there is a spreadsheet that exists because two systems will never speak to each other. Someone exports from one, exports from the other, matches rows, investigates the ones that do not match, and posts the corrections. It takes two days a month, or two days a week, and it has taken that long for years.

Everybody agrees it should be automated. It usually is not, and the reason is worth being precise about.

Why the automation project keeps not happening

It is not budget, and it is not the technology — the matching logic in most reconciliations is not hard. What blocks it is that the only people who understand the process are the people currently doing it, and they are fully occupied doing it.

So the specification gets written by someone else. It captures the happy path: export, match on invoice number, flag the exceptions. It does not capture that three clients always pay in consolidated batches so the invoice numbers never match one-to-one, or that the legacy system truncates references over sixteen characters, or that anything from the German entity needs a currency adjustment applied before comparison, or that one supplier's credit notes arrive as negative invoices rather than credits.

Those rules are not written down. They live in the head of whoever has been doing the reconciliation for six years, and they surface one at a time during user acceptance testing — at which point the automation is 70% built against the wrong model, and the project acquires a reputation.

A different sequence

Staff the manual process first. Automate it second.

That sounds like the opposite of progress. It is not, and here is the mechanism: when a team takes over the manual process, they have to learn every one of those undocumented rules in order to do the work at all. Not from a workshop — from encountering an exception, asking why, and being told. Within a couple of cycles they have reconstructed the actual process, including the parts nobody thought to mention.

Now the people writing the automation specification are the people doing the work. The exception list is not a guess; it is a log of what genuinely happened over three months. And critically, the business case is now built on measured volumes rather than estimated ones — you know exactly how many exceptions occur, of what type, and how long each takes.

What you get from the intermediate state

The staffed-but-not-yet-automated phase is not dead time. It delivers on its own:

• The bottleneck clears immediately. Whoever was spending two days a month on this gets those days back, from the first cycle, without waiting for a build.
• The process gets documented as a by-product. Handover requires it. You end up with a written process you did not have before, whether or not you automate.
• You find out what is actually worth automating. Frequently, 80% of the volume is a straightforward match and 20% is judgement-heavy exceptions. Automating the 80% and leaving the exceptions staffed is cheaper, faster, and more robust than trying to encode judgement.
• The business case becomes defensible. "We measured 340 exceptions a month across nine categories" is a different conversation with a CFO than "we think this could save some time."

Where this approach does not fit

Two situations where staffing first is the wrong call, and worth saying plainly:

The process is genuinely simple and fully documented. If the matching rule really is one field to one field with no exceptions, you do not need three months of observation. Build it.

The data cannot leave your jurisdiction. Some regulated financial and healthcare processes cannot be handled by an offshore team regardless of contractual protections. That is a hard constraint, not a preference, and it needs establishing before anything else. Where the constraint is about access control rather than geography, it is sometimes addressable — restricting access by location, device, and time window is exactly what an identity and access management implementation does — but where the rule is jurisdictional, it is jurisdictional.

What this looks like as an engagement

Typically one or two people take over the manual process, working your systems under your access controls. They run it, log every exception, and after two or three full cycles produce a written process document and a categorised exception analysis. That document becomes the automation specification — and because the same team then builds against it, nothing is lost in translation between the person who understands the process and the person coding it.

The cost comparison that makes this viable is the one on our staff augmentation page: the budget for one domestic back-office hire generally funds a small offshore team, which is what makes "staff it while we work out whether to automate it" an affordable answer rather than an admission of defeat.