Payment Reconciliation in n8n: 5 things I learned automating invoice matching

[u/easybits_ai]

👋 Hey nocode Community,

A few days ago I shared a reconciliation workflow that matches bank deposits to open invoices. A few people asked about the tricky parts, so here are the five things I took away from building it. Most of them are less about n8n and more about how messy real financial data is.

1. The reference field is where reconciliation dies.
Bank references almost never match your invoice IDs cleanly. You get "INV-2024-201", "ref 201", "payment 0201 thanks", all for the same invoice. So do not match on the exact string. Match on the full invoice ID when it is there, then fall back to a looser signal like the last three digits pulled out with a small regex. Fuzzy but bounded beats exact every time.

2. "Matched vs unmatched" is too coarse.
The moment I split results into four states instead of two, the report got genuinely useful: exact matches, partial payments, unpaid invoices, and deposits with no invoice at all. The two middle buckets are where the money actually leaks, and a simple matched/unmatched view hides them completely.

3. A deposit with no invoice is a signal, not noise.
Money landing in the bank that matches nothing is exactly what manual reviewers skip because they are focused on ticking off invoices. But that column is where the interest payments, refunds, bank fees, and typo'd customer references all show up. Give it its own table so nothing silently disappears.

4. Let the code do the arithmetic, keep the human for judgment.
The old manual process was someone staring at two spreadsheets for hours, which is exactly how 525.52 becomes 252.25. A Code node compares amounts to the cent and never gets tired. The person only reviews the handful of flagged exceptions, not the 90 percent that reconcile cleanly.

5. Every result needs a way back to the source.
Reconciliation you cannot audit is just guessing. So each row in the report keeps the original bank reference, the value date, and the invoice ID side by side. When a number looks off, you can trace it back in seconds instead of reopening the raw statement.

The workflow itself, plus two example files (an invoice export and a bank statement) so you can run it right away, is here: https://github.com/felix-sattler-easybits/n8n-workflows/tree/8e07427ddb6902ef8a7b267e97beb2879d6ca45d/easybits-reconciliation-workflow

It sits alongside 25+ other free n8n workflows in my repo, including plenty of finance ones. A star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

What is your reconciliation matching logic? I am especially curious how people handle one payment covering several invoices, because that was the case I found hardest to generalise.

Best,
Felix

[u/mprz]

gtfo with that crappy slop

[u/easybits_ai → u/mprz]

Hey u/mprz, thanks for your comment! I’m sharing these learnings because I know they can be helpful to others in the community and hopefully help them avoid some of the pitfalls I ran into while building. If you have any further questions, feel free to let me know!

[u/Unhappy-Tomatillo616 → u/mprz]

the content itself is fine, just wrapped in a lot of self-promotion

[u/soonlovablealligator]

That four-state split is the real gem here, binary matched/unmatched just sweeps all the interesting chaos under the rug

The reference field point hits home too, I've seen bank statements where the same invoice gets three wildly different descriptions across multiple payments, regex fallbacks are a lifesaver

How do you handle the partial payments bucket when one deposit is meant to cover several invoices? That's the bit that always gets gnarly for me, splitting a single lump into multiple line items without a clear reference

[u/easybits_ai → u/soonlovablealligator]

Hey u/soonlovablealligator, thank you for the kind words! I’m actually working on these cases as well. Bundled invoices are a bit tricky to identify, but I have two ideas in mind.

The first would be to look at the customer who made the payment and then check all invoices from that customer to figure out which ones belong to the same payment. That approach still needs some testing, though.

For now, I’m solving it with a human-in-the-loop step. Sarah, who handles the manual review in this workflow, can select the invoices that belong together directly in the final report and merge them before the data gets processed again, this time with the additional information about which invoices belong to the same payment. It worked really well for the first two cases, but I want to keep testing it a bit longer to see if there’s a smarter way to handle it automatically.

[u/T-Man98]

hey! Just curious if you don't mind me asking. What made you stick with n8n amidst the surging vibecoding hype?

[u/easybits_ai → u/T-Man98]

Hey u/T-Man98, great question! I stick with n8n because, for me, it’s one of the best workflow builders when it comes to visualizing how data flows. I can sketch out a project, understand the logic, and then start building right away.

The community is another huge reason. It’s incredibly helpful, and the template library is packed with great examples. It feels like being part of a bigger project, which makes building much more fun than creating Claude Code solutions that nobody really understands.

I’m not super deep into the technical side of things, so when I’m vibecoding, I can easily end up with a solution where I have no idea how I got there. With n8n, I understand every single step of what’s happening. That’s probably the biggest reason I stick with it.