Which payments cost the most time, why does reconciliation stay manual, and which software solves it? Per ERP and per vendor, with figures from 21,642 Dutch finance job postings.
Reconciliation is the least automated part of finance administration in the Netherlands. Any tool can scan an invoice. The payment that arrives as one amount covering forty invoices, with a thousand-line remittance PDF, is still worked through by hand almost everywhere.
The analysis Claridy made of 21,642 Dutch finance job postings shows how much manual work sits here. The figures below cover the 6,887 postings for payables, receivables and general financial administration, so the roles that actually do this work, excluding controllers and roles where finance is only a part. Of those postings, 66 percent explicitly ask for clearing or cash application work.
And it does not go away as you grow. Under fifty employees it is 62 percent, between fifty and a hundred 71 percent, and above two hundred and fifty 68 percent. More people and heavier systems do not solve this, they at most spread it across more hands.
Two different jobs behind one word
Reconciliation is an umbrella term, and it covers two jobs that have little to do with each other. Dutch job postings show how sharp the split is, because Dutch uses separate words for the two halves and English does not.
| Term used in the posting | Share using this word | Directly automatable | Who writes it |
|---|---|---|---|
| bankmutaties (bank transactions) | 11% | 95% | generalist 74%, AP and AR 26% |
| reconciliatie (reconciliation) | 10% | 44% | generalist 59%, AP 17%, AR 14% |
| bankafschriften (bank statements) | 6% | 96% | generalist 67%, AP and AR 33% |
| afletteren (clearing) | 3% | 88% | generalist 41%, AR 28%, AP 14% |
| bankboekingen (bank postings) | 2% | 92% | generalist 73%, AP and AR 26% |
The second column counts wordings, not work: many postings describe the same task without using any of these words. What matters is the third column. Where a posting says bank transactions, 95 percent of the tasks named are directly automatable. Where it says reconciliation, that drops to 44 percent. That gap is not noise. Those are different tasks behind the same word.
When a Dutch posting says reconciliation, it usually means balance sheet reconciliations, general ledger and intercompany work: a controller's month-end close. Mature software exists for that, with BlackLine, FloQast and Trintech the best-known names. It is a different product for a different problem, and it will not clear a single bank line for you.
The operational work this article is about goes by another name in those same postings. The most common wording is "verwerken van bankmutaties", processing bank transactions, written out verbatim in 2.8 percent of these postings, followed by "verwerken van bankafschriften" and "boeken van bankafschriften", processing and posting bank statements. And afletteren, the Dutch verb for clearing an item, belongs to the receivables side: 28 percent of the postings using it are AR roles, against 5 percent for bank statements.
That clearing works in both directions. On the receivables side you apply incoming money to sales invoices, usually called cash application. On the payables side you clear your own outgoing payments and payment batches against purchase invoices. Same principle, same traps, two directions.
Which payments cost the most time
The shape of the money flow determines the work.
One-to-one. One payment, one invoice, a clean reference. Most accounting packages handle this well, as long as the reference is actually there.
Bulk payments and bulk payouts. One amount covers dozens to hundreds of invoices. That can be a customer paying forty invoices at once, your own payment batch to suppliers, a PSP payout from Adyen, Mollie or Stripe summarising thousands of transactions minus fees in one deposit, or a credit-card settlement. The remittance advice is the key document here: not a separate kind of reconciliation but the evidence you crack the bulk item with, usually delivered as a PDF or Excel next to the payment itself.
Partial payments. The customer pays €8,000 against a €12,000 invoice, or pays in instalments. Which part, why, and what happens to the remainder: a rule has no answer to that.
Prepayments and deposits. The customer pays before an invoice exists. There is nothing to clear against, so the amount sits until the invoice arrives and someone makes the link. On projects and staged billing this is not an exception, it is the normal course of business.
Payment differences. The amount is just off, because something came out of it: PSP transaction fees, bank charges, an early-payment discount taken, or a credit note netted. The classic case turns up at every PSP: a €1,000 invoice is closed by a receipt of €971, because the fee has already been taken. That €29 is not an error, it is a cost, and someone has to post it before the item can close.
Cross-currency. A payment in euros against an invoice in Canadian dollars. Without automated handling this ends as a manual journal through a suspense account, and sometimes as an FX difference quietly sliding into the P&L.
Reversals. A returned direct debit reopens an item you already cleared, usually weeks later and unnoticed until it surfaces in the ageing.
No reference. No invoice number, a mangled reference, a payer named differently from the debtor. The Netherlands has a structured payment reference for exactly this, and where it is used the item clears itself. The problem is that a large share of B2B payments arrive without one. What is left lands on the suspense account until someone works out where it belongs.
Why reconciliation stays manual
The import is solved. Every package reads a CAMT.053 or MT940 file without trouble. That is not where it breaks. It breaks at what has to happen to the line afterwards, and that starts earlier than you would think: even a one-to-one payment without a usable reference already needs a person.
We see remittance files of up to a thousand lines allocated invoice by invoice by hand; at one of our customers this was a full-day task for the credit controller before switching. We see groups paying from one account for sixteen billing locations that each exist as a separate debtor, so every receipt must be split manually before the work can even start. And we see the currency and difference cases end up on the suspense account, month after month.
What your ERP can do, per system
Exact Online. The bank feed pulls the transactions in cleanly, and the rules do their work as soon as the reference is right. In practice that is a smaller share than you would expect: plenty of ordinary one-to-one payments still get cleared by hand because the reference is missing or written slightly differently. Where it stops entirely: partial payments, remittance files, and anything crossing administrations. That work appears in job postings as "verwerken van bankmutaties" and shows up at Exact companies as often as ever.
NetSuite. The gap is largest here, and it is measurable: 85 percent of NetSuite postings in this group ask for clearing or cash application work, the highest of any ERP. For comparison: Exact Globe 78 percent, Dynamics 78 percent, Oracle and Twinfield 73 percent, and AFAS, SAP and Exact Online all three at 69 percent. NetSuite's own bank module does import and simple matching. Beyond that sits an add-on market (Zone, Nolan, Netgain NetCash, FiSpan) with mixed results: the rules you configure stay static, and a customer we took over saw the promised automation remain largely manual in practice. Remittance files were still processed line by line by hand, and the same correction came back every month. More on this: alternatives to ZoneReconcile on NetSuite.
Microsoft Dynamics. Business Central and F&O have bank reconciliation on board, and within BC, Continia Banking brings it into the native workflow. The manual work sits in group payments that must be split across entities and in everything that leaves the standard path.
AFAS. A strong bank feed for the straightforward work, with the same limits at remittances and partial payments.
What software exists, and where each option stops
Your accounting package itself. Free, already configured, and sufficient as long as payments arrive one-to-one with clean references. Limit: every shape above.
Receivables tools (Payt, Onguard, Mail to Pay). Built for sending reminders and lowering DSO, and good at it. Onguard, for instance, ships PolicyManager and CaseControl, both on the policy and communication side. Applying incoming money is at most a side function, or runs through a partner integration. The thousand-line remittance PDF, the partial payment with no explanation and the split across administrations stay manual with a receivables tool too.
NetSuite add-ons (Zone, Nolan, Netgain NetCash, FiSpan). Closer to the problem, mixed in results, and the rules you configure stay static: what the tool does not recognise today, it will not recognise next month either. Mind the categories: Zone, Nolan and NetCash do reconciliation and matching inside NetSuite, FiSpan does the bank connection. Those are different problems.
Balance sheet reconciliation software (BlackLine, FloQast, Trintech). Mature, and built for the other job in the table above. These control your close and your suspense accounts. They will not apply a receipt to an invoice.
The intelligent action layer (Claridy), measured by the same standard. Claridy reads the remittance the way a person would, in any format, allocates lines to open invoices, splits bulk receipts and group payments across administrations, handles partial payments, and books currency and fee differences back to the ERP (Exact, NetSuite, Microsoft Dynamics) according to your rules. Every correction your team makes becomes a rule, so the same exception never comes back, and every posting is traceable in the audit trail. Where it stops: the odd case that genuinely needs judgement goes to your team, with the preparation done, and below a few hundred bank lines per month the gain is too small to matter.
How to choose
Tally one week of the work. How many lines, how many one-to-one, how many via remittances, partial payments or currency. Under ten exceptions per week: your package is enough. Above that, the calculation starts.
Convert it to hours, then add the rest. A credit controller working through remittances daily is not a clearing problem but a capacity problem. Work it out with the ROI calculator, which uses the automatable shares per task category from the same job posting dataset. But the hours are not the whole bill. Your month-end close takes longer, because the suspense account is only emptied on working day four. Your DSO looks worse than it is, because money already received has not been applied. You send reminders to customers who paid weeks ago, which costs you the relationship and your team an angry phone call. Your cash position is wrong on the day you need it. At the annual audit, a suspense account that does not tie out is a finding, and you clear it anyway, only then under time pressure. And the work hangs on one person: if they are ill, allocation stops.
The question is not what the software costs, but what the manual work costs, all in.
Frequently asked questions
Pulling the bank lines in from your bank feed or your CAMT.053 file, then applying those lines to the right open items or ledger accounts. The applying itself is what the Dutch call afletteren. In Dutch job postings this work is usually described as "verwerken van bankmutaties", processing bank transactions.
Clearing closes an open item against a transaction, at transaction level. Reconciling compares two sources to see whether they agree, for example your bank balance against your books. Tying out proves a balance against a schedule, which is what you do at close with your suspense accounts. This article is about the first two, not the third.
Applying incoming payments to open sales invoices: the receivables side. The payables side, clearing your own payments and batches, follows the same principle in the other direction.
NetSuite's own module covers simple matching; add-ons like Zone, Nolan, NetCash and FiSpan go further but run on static rules. Claridy executes the full job, including remittances and splits across administrations, and learns from corrections. See also: alternatives to ZoneReconcile on NetSuite.
A receivables tool (Payt, Onguard) is built around dunning. Cash application software applies incoming money to invoices. They are two sides of the same process, and most companies have the second problem and buy the first tool.
Yes, but almost no standard Dutch tool does it. It requires software that reads the remittance the way a person does and decides per line, instead of matching on one reference.
Where it is used, yes, and the item clears itself. The problem is that a large share of B2B payments arrive without one or with it mangled, and you cannot force a customer to fill it in correctly.
Do the maths for your own team: a thousand-line remittance costs an experienced employee a day. At ten such files per month, that is half an FTE doing nothing but allocating money that has already arrived. Add the longer close, the distorted DSO, the reminders sent in error, and the suspense account your auditor will ask about.
Source: Claridy analysis of 21,642 Dutch finance job postings, 2026, tasks classified by AI against our own rubric. The percentages in this article cover the subset of 6,887 postings for payables, receivables and general financial administration, because those are the roles that do this work. Last checked: 2026-08.