What does Exact Online match on its own, and where does the manual work start? Broken down by payment type, with data from 21,642 Dutch finance vacancies.
Worth stating up front, because cash application usually gets talked about too gloomily. Configure the allocation rules in Exact properly and you get a long way. The point is not that it fails, the point is that the remainder will not yield to one more rule. That remainder is exactly the work a person redoes every week.
And it runs in both directions. On the receivables side you allocate incoming money to sales invoices. On the payables side you match your own outgoing payments and payment batches against purchase invoices. In the vacancy data the split is almost even: 60 percent of payables roles ask for this work, 58 percent of receivables roles, and 70 percent of the roles that do both.
What does Exact Online match by itself?
More than you would expect. The bank feed collects your transactions from the bank daily, and you can import statements manually alongside it. Once a transaction is in, Exact tries to match it to an open item, and allocation rules let you steer that a fair distance: on counter account, on description, on a fixed counterparty.
The situation where it goes without friction is narrower than most people assume, though. One payment arrives, for exactly one invoice, carrying the correct payment reference, for the full amount. The item closes without anyone looking at it. That is not a small category, and for companies with a straightforward flow it covers most of the work.
The Netherlands has an advantage here, because the structured payment reference is widely used. Wherever that reference is passed along, the item clears itself.
Where does it stop?
The problem is that the reference is often not passed along in business-to-business flows, and the amount frequently does not equal a single invoice. These are the forms that end up with a person in Exact Online.
Lump-sum payments. One amount covers dozens to hundreds of invoices. That could be a customer settling their entire open balance at once, your own payment batch to suppliers, or a payout from a provider like Adyen, Mollie or Stripe consolidating thousands of transactions minus fees into a single transfer. The remittance advice is the key document here, and it usually arrives as a PDF or spreadsheet in a separate email. Exact does not know that document exists.
Partial payments. The customer pays € 8,000 against an invoice of € 12,000. Which part that is, why, and what happens to the remainder: a matching rule has no answer for that.
Payment differences. The amount is almost right because something was deducted. Processing fees, bank charges, an early payment discount taken, or a credit note offset. An invoice of € 1,000 settled by a receipt of € 971 is not an error, but someone has to post that € 29 as a cost before the item can close.
Prepayments. The customer pays before an invoice exists. There is nothing to match against, so the amount sits there until the invoice arrives and someone makes the connection. In project work and instalment billing this is normal, not exceptional.
Reversals. A reversed direct debit reopens a matched item, usually weeks later, and usually nobody notices until it surfaces in the ageing report.
Foreign currency. A payment in euros against an invoice in dollars ends up as a manual journal entry through a suspense account, and sometimes as an exchange difference that quietly moves into the profit and loss account.
Whatever does not match lands on the suspense account. It stays there until someone has time, and that someone is usually the same person every month.
Why is the payment reference missing so often?
Because the payer decides whether it travels, not you. A customer running their own books through a payment batch sends their own system's reference, or nothing at all. A payment provider sends its own payout reference. A group payment comes from a different legal entity than the debtor on your invoice, so even the name does not line up.
That is why people at Exact-based companies still match ordinary one-to-one payments by hand. It is not a shortcoming of Exact, it is a property of payment traffic. But it does mean the share of transactions that clears itself is lower than the theory promises.
Cash application or reconciliation: two different jobs
First the scale, because that usually gets talked around. The figures below cover 6,887 Dutch vacancies for payables, receivables and general financial administration: the roles that actually do this work, excluding controllers and roles where finance is only a part. Of those vacancies, 66 percent ask for cash application or allocation work. Two in three.
They just do not call it the same thing, and that is where the confusion starts. In Dutch vacancies, "reconciliation" covers something quite different from "processing bank transactions", and that difference is measurable.
| Term used in the vacancy | Share using this word | Directly automatable |
|---|---|---|
| bank transactions | 11% | 95% |
| reconciliation | 10% | 44% |
| bank statements | 6% | 96% |
| cash application | 3% | 88% |
The middle column counts wordings, not work: many vacancies describe the same task without using any of these four words. What matters is the right-hand column. Where a vacancy says "bank transactions", 95 percent of the listed tasks are directly automatable. Where it says "reconciliation", that drops to 44 percent. Those are different tasks hiding behind the same family of words.
When a Dutch vacancy says reconciliation it usually means balance sheet reconciliation, general ledger and intercompany matching, which is month-end work for a controller. Mature software exists for that, with BlackLine, FloQast and Trintech the best known names. Those tools police your close and your suspense accounts, and they do not apply a single receipt to an invoice.
The same split shows up inside the cash application work itself. The part about doing, processing bank transactions and statements, scores 90 percent. The part about explaining, clearing suspense accounts and specifying differences, comes out at 48 percent. The first is an action, the second is a judgement. Software takes over the action.
What happens with multiple administrations?
This is the gap specific to Exact Online, and it is the one that costs the most time.
Exact Online is organised per administration. Each entity has its own books, its own bank accounts and its own open items. That is a sensible setup, and for most of the work it causes no trouble at all.
Money simply does not respect it. A customer buying from three of your operating companies pays once. A payment provider settling for two web shops transfers one amount. A group paying centrally does so from one account for invoices open in four administrations.
At that point someone has to split the amount, log into each administration separately, look up the right items one by one, and post per administration. It is not difficult, it is just slow, and it is exactly the kind of work that returns every month in the same shape. In conversations with finance teams this is the point where "it actually goes fine" turns into "this is where the time goes".
Is it different on other ERPs?
Yes. Same group of vacancies as above, same measure, broken out by the ERP named in them. The average is 66 percent.
| ERP | Vacancies | Share with cash application work |
|---|---|---|
| NetSuite | 156 | 85% |
| Exact Globe | 199 | 78% |
| Microsoft Dynamics | 385 | 78% |
| Oracle | 152 | 73% |
| Twinfield | 91 | 73% |
| AFAS | 458 | 69% |
| SAP | 694 | 69% |
| Exact Online | 587 | 69% |
Two things stand out, and the first favours Exact. Exact Online sits at the bottom of this list, and the most striking gap is with its own predecessor: Exact Globe sits at 78 percent, Exact Online at 69. Nine percentage points less manual work, purely from moving to the cloud version with its bank feed and allocation rules. That is a decent argument for making the move if you are still on Globe.
NetSuite comes off worst at 85 percent, which matches what we see in practice: its own bank module handles import and simple matching, and the rest comes from an add-on market with mixed results.
The second is that 69 percent is still better than two in three. Even on the system that does relatively well, the large majority of employers write this work explicitly into the vacancy. And they rarely call it reconciliation. It appears as "processing bank transactions", "posting bank statements" and "matching payments". Those are actions, not analyses, and employers write them down because a person is needed.
Visma and Unit4 are not in the table because there are too few vacancies to base a percentage on.
Does the Exact Online bank feed solve this?
Partly, and it is worth knowing which part. The bank feed solves collection: you no longer download and import statements, the transactions are simply there in the morning. That is a real gain and you should always switch it on.
What the feed does not do is decide where an amount belongs when that is not evident from the transaction itself. The feed delivers the line, the matching logic still has to do something with it. A lump-sum payment of € 41,203.17 remains a lump-sum payment of € 41,203.17, even when it arrives automatically.
What are your options besides Exact itself?
Exact Online on its own. Already configured, no extra cost, and sufficient as long as payments arrive one-to-one with correct references. The limit is every form listed above.
Receivables tools such as Payt, Onguard and Mail to Pay. Built around sending reminders and lowering DSO, and good at it. Applying incoming cash is a side feature there or runs through a partner integration. The thousand-line remittance advice, the unexplained partial payment and the split across administrations stay manual.
Balance sheet reconciliation software such as BlackLine, FloQast and Trintech. Mature, and built for the other problem in the table above. They police your close; they match nothing.
An intelligent action layer, such as Claridy. Performs the allocation itself and writes back to Exact Online. What that means concretely, and where it stops, is below.
How does Claridy do this in Exact Online?
The difference is not intelligence, it is where the exception goes. In Exact Online a transaction that does not match sits there until a person picks it up. With Claridy that transaction goes to the agent first, and only reaches your team if the agent cannot resolve it, with the groundwork already done.
Concretely, this happens. The remittance advice is read the way a colleague reads it, whether it arrives as PDF, spreadsheet or CSV and regardless of how the customer laid it out. Its lines are allocated to open invoices. Lump-sum payments are split, including across administrations, so you no longer log into each entity. Partial payments are processed with the remainder left open. Payment differences are separated out and each gets its own destination: processing fees to the cost account you designate, a discount taken to yours, a genuine dispute to your team.
You describe those rules in plain language. Differences up to five euros posted automatically to bank charges, provider fees always to the web shop cost centre, anything above a hundred euros to the credit controller. That description becomes deterministic logic, so the same transaction always produces the same outcome and every step is in the audit trail. The AI reads, the rule decides.
And every correction your team makes becomes a rule itself. Once someone allocates a recurring difference at a given customer, that same exception does not come back a second time. That is the difference with a static rules engine, where whatever is not recognised today is not recognised next month either.
Entries go back into Exact Online, and the same approach runs on NetSuite and Microsoft Dynamics.
Where it stops. The genuine oddity that requires judgement goes to your team, as it should. And below a few hundred bank lines a month the gain is too small to matter: Exact Online on its own is the right choice there.
The question to ask a vendor
Not whether they can do cash application, because everyone says yes. Ask this:
I receive one payment of € 41,203.17 from a customer who buys from two of my operating companies, with a two-hundred-line remittance advice as a PDF in a separate email, of which three lines offset a credit note and one line is a partial payment. What happens to it, and who gets an email?
The answer separates the vendors. "You would set up a rule for that" is not the same as "that gets done".
Frequently asked questions
Yes, and better than its reputation suggests. Allocation rules clear the straightforward flow on their own, and in the vacancy data Exact Online scores lower on manual cash application work than NetSuite, Dynamics and its own predecessor Exact Globe. Lump-sum payments, partial payments, payment differences and amounts that must be split across administrations do end up with a person.
Of the 6,887 Dutch vacancies for payables, receivables and general financial administration, 66 percent explicitly ask for cash application or allocation work. On Exact Online it is 69 percent. So it is not an edge case, it is the norm.
Both. On the receivables side you allocate incoming money to sales invoices, usually called cash application in the market. On the payables side you match your own outgoing payments and payment batches against purchase invoices. Same principle, same pitfalls, two directions. In the vacancies the split is almost even: 60 percent of payables roles and 58 percent of receivables roles ask for it.
Cash application is allocating a received or paid amount to the right open invoice. Reconciliation, in Dutch vacancies, usually means balance sheet reconciliation and general ledger matching at the close. The first is daily operational work, the second is periodic control work, and different software exists for each.
The feed solves collecting the transactions, which helps. Deciding where an amount belongs remains, and that is the part that costs time.
Yes. One lump-sum payment is split and posted per administration without you logging into each entity. That is where most of the manual work sits at companies with several operating companies.
The base is € 499 per month and modules cost € 250. Current figures are on claridy.ai/prijzen, verified on 2026-08-14.
No. Exact Online remains your system of record. Claridy performs the work in between and writes the outcome back, so your books stay in Exact.
Below a few hundred bank lines a month, or when your payments almost always arrive one-to-one with a correct reference. Exact Online already handles that.
To see what the manual work costs you today, run the numbers with the ROI calculator. The general version of this story, independent of your ERP, is in the guide on processing bank transactions and cash application. Why the action layer belongs as a separate layer rather than a feature inside your ERP is in what is a system of action for finance. On NetSuite, read bank reconciliation in NetSuite.