Bank reconciliation is one of those jobs nobody enjoys and everybody has to do. If you run your finances on NetSuite you'll know the routine well enough: pull the cash account, get the statement, and start ticking things off. The native bank reconciliation screen takes some of the sting out of it, but anyone who has sat in front of it for a busy account at month end knows where it runs out of road. It matches on amount and date, and once you're past the obvious one-to-one lines you're largely back to doing it by eye.
I've spent a fair bit of the last few months building bank reconciliation properly into MatchPoint for a client, and a few ideas have come out of that work which I think are worth sharing. The first is so obvious it's almost embarrassing to say out loud. We were already generating the payment files.
We made the payment, so we know what's on the statement
Here's the bit that I think gets missed. When you pay your suppliers through NetSuite Electronic Payments, NetSuite produces a payment file — a pain.001, in ISO 20022 terms — and you upload that to the bank. The bank takes the file, makes the payments, and a day or two later a single debit lands on your statement for the whole run.
By the time that debit shows up, we already know exactly what it is. We created the file. We know the total, we know every individual supplier payment inside it, and we know which bills those payments settled. So why on earth would we try to guess what that bank line is by matching on amount and date alone?
We don't. MatchPoint reads the same payment file, ties the one bank debit back to the batch, and clears the lot in a single move — file, statement and ledger all agreeing with each other. It's a three-way check rather than a hopeful amount match, and because the data came out of the same system that made the payment, it's right every time. Not "usually right". Right.
That feels like the way it always should have worked. A payment run is the most structured thing on the whole statement; treating it like a mystery debit you have to fish for never made much sense to me.
Certainty first, guesswork last
The payment files are really just the top rung of a ladder. The matching engine works through the statement in order of how sure it can be, and that order matters more than any single clever trick.
It starts with the things it can prove: the payment-file batches I've just described, and a bit of housekeeping for entries that never touch the bank at all — voids, reversals, the month-end currency revaluations that wash through the ledger. Those get cleared out of the way automatically so they're not cluttering the screen.
Then it goes after the straightforward matches, and this is where it earns its keep. Every candidate gets a score. An exact amount is the starting point, but on its own that's weak — round numbers in particular collide all the time. So the score climbs as the evidence stacks up: the dates lining up, a reference that agrees, and the counterparty matching (more on that in a moment). Above a sensible threshold the engine confirms the match on its own. It also insists the match is unique — if there are three lines of the same amount on each side, it won't gamble on which pairs with which, it leaves them for a person.
Below that threshold, nothing is confirmed silently. The weaker candidates are offered as suggestions instead — and this is the part I'm keenest on. The fuzzier matching lives here: descriptions that nearly agree, references that are close, a date that's a day or two out. It also handles the awkward shapes that a one-to-one match simply can't — one BACS debit covering five separate invoices, or a clutch of small receipts that together make up a single ledger posting. The engine works out which lines add up to which, and puts the proposed grouping in front of you with its reasoning attached. You're approving its thinking, not hunting for the answer yourself.
People will want to call some of this "AI", and the learning part below is fair enough on that score. But the matching itself is deliberately not a black box. Every suggestion comes with the why — same counterparty, reference matches, amount ties to the day — because a reconciliation you can't explain to an auditor isn't worth much, however clever it was.
Matching on who, not just how much
The counterparty deserves its own word, because it's doing a lot of the heavy lifting and, as far as I can tell, the native rec doesn't use it at all.
A bank statement line nearly always tells you who the money went to or came from — a payee name, a remittance reference, something. NetSuite knows the customer or vendor on the other side of every transaction too. So we pull the entity through and compare it against the statement narrative, and we're reasonably forgiving about it, because banks love to truncate and mangle names — "1001 - Google LL" still ties to "Google LLC".
I'd be glad to be corrected, but in practice the native reconciliation leans on amount and date and ignores the name that's sitting right there. For accounts with a lot of same-value transactions — and most busy accounts have plenty — knowing who it was is the difference between a confident automatic match and a pile of maybes for someone to wade through. It's also what makes the round-number matches safe: a £100 line on its own is a coin toss; a £100 line to a counterparty you recognise, on roughly the right date, is a match you can stand behind.
It gets better the more you use it
The last piece, and the one I'd happily call adaptive, is that the system learns. Bank fees, FX charges, standing payments — the lines that don't have a neat ledger counterpart and have to be coded by hand — tend to look the same month after month. So we remember how they were handled last time. Code a particular charge to an account once or twice and MatchPoint starts proposing the same treatment when it next sees a line like it. Nothing dramatic, no black box, just the system paying attention so the preparer doesn't keep making the same decision.
What it actually adds up to
I'm wary of throwing percentages around, because match rates depend entirely on how clean the underlying data is. But on real accounts with the ledger properly loaded, we're routinely auto-matching the large majority of lines, and on the supplier payment runs it's the full hundred per cent. That's well ahead of what I've seen the native reconciliation manage on the same data, and the gap is widest exactly where it hurts most — the high-volume accounts.
None of this is about replacing NetSuite. The ledger lives in NetSuite, the payments are made from NetSuite, and that's exactly as it should be. It's about doing the reconciliation itself properly: working from certainty down to judgement rather than treating every line as a guess, never auto-confirming something it can't justify, and leaving a clean audit trail behind either way.
The reconciliation should be the boring part of the month. With a bit of thought about the data you're already sitting on, it genuinely can be.
We build finance-systems tooling like this around NetSuite at Fowlers Consulting — bank reconciliation, the balance sheet close, and the awkward bits in between. If your month end is more manual than it ought to be, get in touch.
Related reading: Introducing Bank Reconciliation in MatchPoint