How approval in Exact Online is meant to work, the four places it stalls in practice, and what you can do about it without replacing your ERP.
What Exact Online does itself
The core is an approval flow: a booked purchase invoice is queued for someone who has to approve it, that person sees it, and once approved the invoice moves on to payable. You can set threshold amounts and record a default approver per supplier.
That covers the case it was designed for: an invoice that adds up, from a known supplier, with one clear approver. In practice that is far from every invoice.
The four places it stalls
1. The rule lives in someone's head
The thresholds that decide whether approval is needed differ per company and are rarely fully in the system. At a manufacturer on Exact Globe the rule is: if the purchase order is matched, nothing under five thousand euro needs approval. At a fractional CFO practice running several sets of books, the rule is simply that an order above a certain amount has to go past the client.
Rules like that automate fine, but only once somebody writes them down. That is step zero of every approval project and it is nearly always skipped.
2. Approval is only possible after something else happens
This is the nastiest one, because it is invisible until you hit it. At a food brand on Exact, a project code had to be assigned by hand before anything could be approved at all. The result was double work and confusion among the approvers in sales, who did not understand why they were seeing something that was not finished.
An approval flow that waits halfway on another process is not an approval flow. It is a queue with a button on it.
3. What you need is not always readable
During a pilot on Exact, the default approver at supplier level turned out not to be readable through the connection, simply because Exact has no API for it. The information is in Exact; you just cannot reach it from outside.
That is not a criticism of Exact, it is a property you need to know. Undocumented limits like this only surface during the build, and they decide what an external layer can and cannot take over. Ask about it per process step before you sign, not after.
4. Approval happens outside the system
At an aviation company on Exact, purchase order approval runs entirely by phone or verbally. Not because nobody can operate the system, but because a part is needed and the aircraft is on the ground.
That is the pattern behind almost every bypassed process: the process is too slow for the pace of the work. A stricter gate makes it worse. What helps is making the action small enough that the detour stops paying off, and automating the clean-up for the cases where it is taken anyway.
What agentic software adds
Not a second approval screen. Finance departments often prefer keeping approval inside the ERP, because then they do not have to train colleagues on an extra tool or manage extra licences. That is a good argument, and a layer that goes along with it beats one that imposes its own screen.
What can be added:
Working out the right approver instead of following a fixed route. Based on supplier, amount, cost centre and what happened with comparable invoices before.
Presenting it with the investigation attached. The order, the receipt, the deviation and what the system found out about it. An approver who has to go looking first does not approve any faster. This is where most of the time is won, and it has nothing to do with the button.
Handling the precondition up front. If that project code is missing, it is derived and proposed, so the invoice reaches the approver complete rather than half done.
Applying the rules without re-entering them per invoice. You write them down once in plain language, after which they run deterministically.
Exact Online versus an agent on top
| Approval in Exact Online | Agent on top | |
|---|---|---|
| Determining the approver | Fixed route, default approver per supplier | Derived from supplier, amount, cost centre and history |
| Threshold amount | Configurable | Configurable, plus the conditions around it in plain language |
| What the approver sees | The invoice | The invoice plus order, receipt, deviation and the investigation |
| Invoice deviates | Enters the route anyway, or sits there | Investigated first, presented after |
| Missing precondition | Blocks approval | Derived and proposed, so the invoice arrives complete |
| Where it happens | In Exact | In Exact, or outside it if you prefer |
| The posting | Fixed rules | Fixed rules too: deterministic code, not a model's judgment call |
Where it stops
What Exact does not offer, an external layer cannot pull out of it. The default approver is the clearest example. Ask per action whether it works through the connection, because the answer differs per field.
An agent cannot invent an approval. If something was ordered by phone and nobody recorded it, the only route is to ask. The agent can do that, with the invoice and the line attached, but it stays a question for a person.
Below fifty invoices a month it still works, but the question is whether it earns its keep. There is no technical floor. The calculation is whether the time saved outweighs the price and the setup.
How to start
- Write down your thresholds. Under what amount can it clear, and on what condition. Those rules already exist, they are just not written anywhere.
- Measure how long an approval round takes and where it stalls. Usually not at the clicking but at the investigation before it.
- Find the preconditions that block approval. A mandatory field that has to be filled by hand first is a hidden delay.
- Ask per action whether it works through the connection. Not in general.
- Run it supervised first. Every proposal past your team, then you move the threshold.
Frequently asked questions
Exact Online can present invoices for approval through a fixed route with a threshold amount, and record a default approver per supplier. What it does not do is work out who the right approver is when the situation deviates, or investigate the deviation before presenting it.
Almost never because of the approving itself, but because of what precedes it: the approver gets an invoice without the order, the receipt and the reason for the deviation, and goes looking. So measure the cycle time of the exception, not the number of clicks.
Preferably not. Finance teams often prefer keeping approval inside Exact. An agent can do the preparation and queue the invoice inside Exact, so the approver has nothing new to learn.
The patterns are the same, the connection options differ. Ask per action whether it works.
At Claridy €499 per month flat, with modules at €250 per entity, cancellable monthly.[^bron1]
Processing inside the EU, read-only where possible, and an exportable audit trail per action. The SOC 2 programme is under way. In more depth on security and in is AI safe for your books.
On the rest of the payables chain: AI agents for accounts payable. What goes wrong before the invoice: AI agents in procure to pay. Other Exact actions: capture in Exact Online and reconciliation in Exact Online. On another ERP: invoice processing in NetSuite.
Last checked: 2026-08.