When I built the ING Open Banking integration into Exact Online, one of the first decisions was where the transactions land.

Not directly in the GL. In a staging layer first — a queue where entries accumulate and get reviewed before they post.

It felt slower. It is slower. But I’ve seen what happens when you skip that step.

Transactions flow in continuously. Rules match them automatically. The interface looks clean. And then at month-end you can’t reconcile cash, and you trace the problem back to something that posted six weeks ago, already covered by forty other entries, and the only way to fix it now is to create more noise than the original error was worth.

The general ledger was designed for reviewed journal entries. Not raw transaction streams. Old accounting systems assumed a human would validate data before it touched the books — in a subledger, a staging file, a review queue. Somewhere with a checkpoint.

Bank feeds removed that checkpoint. So did most “automated” integrations.

I’m not saying automation is wrong. I’m saying automation without a review layer is just faster chaos.

The workflow I’ve settled on: transactions land in a normalized staging layer. 78% match automatically and close. 14% get routed to a short human review — usually two minutes of work. The rest go to exceptions.

That 14% is the part most people want to automate away. But it’s also the part where the errors are. And it’s the part that, if you get wrong, costs you the close.

The review step is not overhead.

It’s where accountability lives.

Remove it and you have a system that produces numbers without a record of who verified them. Fast numbers. Clean interface. No idea what to trust when something looks off.

---

If you’re building a bank reconciliation workflow — or evaluating one — this is the first question to ask: where does the transaction land before it posts?

If the answer is “directly in the GL,” that’s where the risk is.