Your ERP stores what happened. Your invoice processing software gets data in. Neither does the work. What a system needs in order to do it, why one system cannot be both, and why reliability is the hard part.
An accounting system is an archive. It records what happened, in a form an auditor can check. That is exactly what you want from a system of record, and it is why ERPs last for decades.
In front of it sits your invoice processing software. That is a system of intake: it takes the invoice out of the mailbox, reads the fields off it, links it to the right supplier and sends it to whoever has to approve it. Twenty years of software development sits in that step, and it works. Retyping is a solved problem.
What neither of them does is the work.
What is a system of action?
A system of action is a system that executes the work rather than recording it or queueing it up: it understands documents, fetches the context it needs, and acts within rules you defined, inside your existing systems, with every action in an audit trail.
The work in question sits between the two existing layers. The invoice does not match the order and someone has to find out why. The supplier emails to ask whether invoice 24019 has been paid. An amount lands on the bank account covering fourteen invoices, with the remittance advice as a PDF in a separate email. A cost has to be booked to a project that is not named on the invoice.
That is not data entry and it is not archiving. It is work that needs judgement, and it is precisely the part that remained after the retyping was automated. It is also systematically underestimated, because it falls between the systems: it is in nobody's job description, and nobody ever bought software for it.
The three layers side by side
| Layer | What it does | Example | What happens when something is wrong |
|---|---|---|---|
| System of record | Record what happened | Exact, NetSuite, Microsoft Dynamics | The item stays open until a human resolves it |
| System of intake | Get documents in and queue them up | Blue10, Basecone, Zenvoices, TriFact365 | An exception appears in a list for a human |
| System of action | Execute the work within your rules | Claridy | The agent tries first; if it cannot, it goes to a human with the preparation done |
That last column is the whole difference. Not what the system can do, but where the work lands when it goes wrong.
An example that actually happened
A food brand on Exact Online buys from a supplier that prices to six decimals. Exact works to two. They order 5,200 units at € 12.96, they receive them, and the invoice arrives at € 12.955678 per unit.
Now their books show € 67,392.00 of stock, and the supplier bills € 67,369.53. Twenty-two euros and forty-seven cents of difference on an invoice where nobody did anything wrong. The supplier billed correctly, the order is right, the receipt is right.
And still it does not close. The receipt put € 67,392.00 onto the interim account and the invoice takes € 67,369.53 off it. Whatever is left, stays there.
Here is how that looks across the three layers.
The ERP records both numbers and flags nothing. That is not its job.
The invoice processing software sees a difference and checks whether it falls inside the tolerance. Inside: it lets it through and the difference stays in the books. Outside: it puts the invoice in a list of exceptions. Either way the next action is a human working out whether this is a rounding or a pricing error, because a tolerance percentage cannot tell the two apart.
A system of action does the arithmetic, establishes that the unit price is right and that the difference comes from the number of decimals, and creates the line needed for the posting to close. A human only gets involved if it turns out not to be a rounding.
That is not a cleverer system. That is a system taking the next step instead of showing it to you.
Why one system cannot be both
The temptation is obvious: if you are already reading the order, the receipt and the invoice, why not store them yourself?
Do not do that, and do not accept it from a vendor either. Not because it is technically impossible, but because they are two incompatible engineering problems.
A system of record has to be stable and predictable. The same balance, every time, for years, checkable by someone from outside. A system of action has to cope with the randomness of the real world: an invoice laid out differently, a supplier who reads the agreement differently, an email that explains a deviation. The first calls for rigid rules that catch every edge case. The second calls for a system that interprets and still acts deterministically at the moment it has to be deterministic. Those are different disciplines, and teams attempting both end up good at neither.
There is a practical objection too. The moment the action layer keeps its own version of the truth, you have two sets of books that can drift apart. Your auditor checks one, your team works in the other, and you discover the difference at year end. On top of that, adoption changes from "we put something next to it" into "we migrate", which is exactly the project nobody wants.
So the distinction is not that the action layer runs alongside your ERP, because everyone in this category says that now. The distinction is that it deliberately has no memory of truth. It reads from your ERP, it writes back to it, and what it remembers itself is rules and decisions, not balances. The archive stays one archive.
Why you have to be able to stop
That has a useful consequence. Switch the action layer off and your books are exactly as they were. No migration back, no export, no conversion. You turned a layer on a month ago and you turn it off again.
With a system that keeps its own ledger you cannot. There your truth now sits in two places, and leaving has itself become a project.
That is the difference between a layer and a lock-in, and it is the question to put to every vendor in this category who says they run alongside your ERP: if I stop in a year, what do I have to do?
Why doesn't your ERP just build this?
They will try, and a shareholder who does not demand it is not doing their job. But there is a reason it does not solve the problem, and it is a matter of arithmetic.
You never have one system of record. You have an accounting system, a CRM, a document system, an HR system, a data warehouse somewhere. If each of those builds its own agent, then your accounting system's agent needs access to your mail, your Drive, your CRM. And your CRM's agent needs access to your books and your documents. That is no longer a list of integrations but a web that grows quadratically with the number of systems.
Look at it from security and the question answers itself. Do you want twenty systems each holding access to the other nineteen, with twenty permission models to maintain? Or do you want one point where access comes together, the way it does with an employee, where a single audit trail shows what was done and why?
That is why the action layer belongs as a separate layer rather than as a feature inside every system.
What this means for your ERP
As a growing share of usage comes from an agent rather than a person, what makes a good system of record changes. Screens matter less, and reachability becomes the criterion: well-documented APIs, few exceptions, no certification programme before you are allowed to build an integration.
That favours systems with a mediocre user interface but a good API. We see teams that were about to move to a heavier ERP postpone that move once the work inside the existing system actually gets done. The reason to switch was rarely the system itself, it was the hours it took to work in it.
One technical note worth making: we work directly against the ERPs' APIs rather than through the standard MCP integrations vendors offer. That abstraction sits too high for this work. You need access to the fields where things actually break, such as the reference field on a purchase order where the buyer typed the supplier's own order number.
"But my software already does this"
That is the first reaction, and it is often fair. Booking invoices is a solved problem, and if your software does it well, you should not buy something else for it.
The better question is not what your software can do, but where your team spends the day. We now ask that as a matter of course, and the answer almost never concerns the step the software performs. It concerns the step before or after it. Before the invoice goes to processing, someone first checks by hand whether the order was actually approved, because the system cannot. That is four hours a week, from one person, and it appears in no demo.
We went through 21,642 Dutch finance job postings and looked at every task named in them to see whether it is directly automatable.
The further you get from the data entry, the less of it happens by itself, and that is precisely the work nobody bought and everybody does.
Why is this not simply "AI on top"?
This is where the discussion usually goes wrong, and not without reason: plenty of established vendors have bolted an AI layer on and promised the earth. Anyone burned by that is right to be sceptical.
The difference is reliability. A system that is right 95 percent of the time sounds excellent. In a set of books it is unusable. Five percent of two thousand invoices a month is a hundred wrong bookings, and finding them all again takes longer than booking them yourself would have. Worse still: a system that is usually right teaches your team to stop checking. Then those hundred errors stay invisible until the auditor trips over them.
So the shape that works is not "AI that decides" but a separation: the AI reads, the rule decides. That sounds contradictory for an AI product, but it is not. The less AI sits in the actual execution, the more predictable the work becomes. The AI does what it is good at, which is understanding language and context: which invoice line belongs to which order line, what the supplier means in their email, which project is being referred to. What happens next is deterministic logic that you defined and that runs identically every time.
Once you have explained how your payables process works, you do not want the system getting creative the following month. It has to stay the same, with interpretation only where interpretation belongs.
That is also what separates it from a rules engine of the previous generation. There, you had to think of every situation in advance and enter it as a rule. Here you describe in plain language how things should be processed, including your exceptions, and that becomes code. When your team corrects a booking, the correction itself becomes a rule. You do not maintain a rule library, you onboard someone.
Supervised first, autonomous later
A system of action should not run autonomously on day one, and a vendor promising that deserves suspicion. The order that works: first the system proposes every action and your team approves. You see where it is right and where it is not. Then you set a threshold: above a certain confidence the system executes, below it the item goes to your team. You move that threshold, based on what you have watched happen, not on what the vendor promised.
The useful part is that the risk of trying is low, and structurally lower than with the previous generation. You are not entering a migration. You put something beside it that takes over one job. If it works, you expand. If it does not, you switch it off.
What this means for pricing
This category also changes what you pay for, and that is not a side issue.
A system of record is priced per user. Reasonable: it is an archive people look into. A system of intake is priced per document, because it processes units.
For a system of action neither fits. Per user makes no sense, because the whole point is that fewer people need to be in the screen. Per document is odd too, because an invoice that passes fully automatically and an invoice where the system fetches three sources and emails the supplier are not the same product.
What is left is paying for completed work. That comes with one honest caveat classical software did not have: there are real variable costs underneath. Having more work done costs more, and a vendor who hides that recovers it somewhere else later.
We translated that into a flat monthly fee per volume band rather than a price per processed unit. Not because outcome-based pricing is wrong, but because for a finance team the value often sits in predictability. Anyone who has to hit a budget would rather pay slightly more with certainty than slightly less with a bill that can spike. Other vendors in this category deliberately charge per completed task, and that is just as defensible. What you no longer have to accept is a per-user price for software whose purpose is to take users out of the process.
Where it stops
A system of action does not remove the exception, it prepares it. The invoice that genuinely needs a decision, the supplier who reads the agreement differently from you, the cost nobody budgeted: those reach a person. The difference is that they arrive with the investigation done, rather than as a line in a queue.
And the strategic work stays human work. Explaining why a choice was made, running an investor conversation, making the judgement nobody can write into a rule: this is not about that. What it is about is all the preparatory work up to that point.
At low volumes none of this applies. Below roughly a hundred invoices a month there is too little repetition to learn from.
The question to ask a vendor
Not whether there is AI in it. Everyone says that now. The question is: what happens to the invoice that does not match? Does it appear in a list, or does the system first try to work out why itself, and only reach my team when it cannot?
The answer to that is the difference between software that shows you your work and software that does it.
Frequently asked questions
A system that does not merely record or ingest data but executes the work: understanding documents, fetching the context, and acting within defined rules inside your existing systems, with every action in an audit trail.
A system of record, like your ERP, stores what happened. A system of action makes it happen. They do not replace each other: the action layer writes to the record, and your books stay where they are. The practical distinction: with a system of record every exception goes to a human, with a system of action it goes to the agent first.
Technically yes, sensibly no. A system of record has to be stable and predictable, a system of action has to cope with everything that deviates. Those are different engineering problems, and a system keeping its own truth also leaves you with two sets of books that can drift apart.
They are trying. The problem is that you never have one system of record. If every system gets its own agent, every system needs access to all the others, and that web grows quadratically. One layer with one auditable access point is manageable, twenty agents with mutual access is not.
Agent is how it is built, system of action is what it has to deliver. The distinction that matters is not whether there is an agent inside, but whether the AI decides or only reads. With us the AI reads and the rule decides.
Not on its own, and it does not need to be. Run supervised first, with every action as a proposal, then set the threshold above which the system executes by itself. Every posting stays traceable to the rule and the source it was based on.
That is precisely why the decision has to be deterministic. A posting that follows from a rule can be explained and repeated. A posting that follows from a prediction cannot.
No, and that is the point. You put something beside your systems that takes over one job. If you do not like it, you switch it off and nothing about your books has changed.
More on how the three generations of technology relate: the comparison guide to accounts payable software. The rounding example is worked out in the article on 3-way matching. To find out what the manual work costs you today: the ROI calculator.
Source: Claridy analysis of 21,642 Dutch finance job postings, 2026. Last checked: 2026-08.