AI Agents in Your ERP: What Is Real and What Is Still a Demo
· 11 min read · Faceela
The demo lasts four minutes and it is genuinely impressive. Somebody types a sentence into a chat box — "the Jebel Ali warehouse is short on the 40mm bracket, sort it out" — and the system finds the shortage, picks the supplier with the best lead time, drafts a purchase order, and asks whether to send it. The room makes the noise rooms make.
What the demo does not show is the fourth supplier, the one whose lead time in the master data has been wrong since 2023 because nobody maintains it. It does not show the bracket that exists under two item codes because a stores clerk created a duplicate during a rush in April. It does not show what happens on the two hundredth run, when the agent does the same confident thing on a request that happened to be an internal transfer rather than a shortage, and nobody notices for eleven days.
That gap — between a task performed once under observation and a task performed continuously without it — is the whole subject. It is not a gap in model quality. It is a gap in exception handling, data quality and accountability, which are the three things ERP projects have always been about.
This piece is a sorting exercise. What works in production now, what is still a stage act, and what has to be true about permissions and ownership before you let any of it near a ledger. If the prior question for you is whether to add AI to an existing system at all, the argument for adding branches rather than burning the tree down is the place to start; this is the more specific follow-on.
What an agent is, stripped of the marketing
An agent is a model with three additions: a set of tools it may call, a memory of what it has already done, and permission to act without being asked again each step. Remove the tools and you have a chatbot. Remove the permission and you have an assistant that drafts.
That third addition is the entire risk surface. Everything else is a user interface question.
Vendors have shipped this into the products a UAE mid-market company actually runs, and the shipping is recent and real rather than theoretical. Odoo 19, released at Odoo Experience in September 2025, added configurable AI agents, an "Ask AI" facility that turns a typed question into a query over your own records, and AI-populated fields, with OpenAI and Google models as the providers behind them. SAP has been bringing Joule agents to general availability through 2026, starting with cash management early in the year and extending across procurement products by mid-year. Microsoft's 2026 release wave one put autonomous agents into Dynamics 365 Finance and Business Central, including agents aimed squarely at payables and payment runs.
So the capability is not vapour. The question is narrower and more useful: for which tasks does it survive contact with a real month, and who is answerable when it does not.
The honest sorting
The test I apply is not "can a model do this" — models can do a great deal. It is four questions, asked in order.
Is the output checkable in less time than doing the task took? Is the failure loud or silent? Is the action reversible? And is there ground truth the agent can be measured against tomorrow, without a human sitting down to construct it?
Tasks that pass all four are ready. Tasks that fail the second and third are where careers go quiet.
| Task | What the agent is actually doing | Failure mode | Where it honestly stands |
|---|---|---|---|
| Reading supplier invoices and delivery notes | Extraction from PDF, scan or photo into structured fields | Loud: the field is wrong and the match fails | Production. This is the strongest case in the whole list |
| Proposing the three-way match | Ranking candidate POs and receipts against a bill | Loud, if you require a human release | Production, as a proposal queue |
| Suggesting account, cost centre, project or tax code | Pattern-matching against your own posting history | Quiet: a plausible wrong code posts and nobody reads it until audit | Production only with sampling and a monthly variance review |
| Anomaly detection on transactions | Flagging drift in prices, margins, payment behaviour, quantities | Both: false positives are loud, missed drift is silent | Production, with the caveat that it produces work rather than saving it |
| Answering questions over a governed data model | Turning a question into a query against defined, owned fields | Quiet and dangerous: a confident wrong number | Production only where the model underneath is already trustworthy |
| Drafting correspondence, summaries, specifications, minutes | Writing text a human sends | Loud, because a person reads it before it leaves | Production |
| Raising and sending purchase orders without review | Selecting supplier, quantity, price, terms and committing | Quiet, contractual and expensive | Demo |
| Reconciling a bank statement without a human release | Matching and posting clearing entries unsupervised | Quiet: reconciles to the wrong thing, cleanly | Demo |
| Posting journals, accruals or adjustments unsupervised | Writing directly to the ledger | Quiet and audit-visible eighteen months later | Demo |
| "Running the close" | Orchestrating a sequence of the above | All of the above, compounded | Demo |
The pattern in that table is not sophistication. Every one of the tasks in the bottom half is technically easier than natural-language querying, which sits in the top half. The dividing line is whether a wrong answer announces itself.
Where it genuinely earns its keep
Document extraction is the one with no serious argument against it. Supplier invoices, delivery notes, packing lists, certificates of analysis, subcontractor claims. A person retyping a PDF into a bill screen is doing work that has no judgement in it, and when the extraction is wrong the downstream match fails immediately. The error is caught by a control you already have. This is also the case with the clearest arithmetic: count the documents per month, count the minutes, and the business case writes itself without anybody having to believe anything about the future.
The one caveat is that extraction accuracy is a function of your suppliers' document quality, not the vendor's benchmark. A supplier who sends a photographed thermal print will defeat any engine. Sample fifty of your own worst documents before you sign anything.
Matching and coding suggestions work as a queue, not as a decision. The agent proposes, a human releases, and the release is one click rather than a form. The important design detail is that the human must be able to see why — which PO, which receipt, which prior transaction the coding was inferred from. An agent that shows its working gets reviewed properly. One that shows a green tick gets rubber-stamped within a fortnight, and then you have automated the mistake instead of the task.
Anomaly detection is real and oversold in the same breath. A model watching your transaction stream will surface a supplier's slow price creep, a margin drifting away from standard, a customer's payment behaviour deteriorating quietly. These are genuinely hard for humans, who notice sudden movements and not gradual ones. What nobody says at the conference is that anomaly detection does not save labour. It creates a queue of things somebody now has to investigate, and if no one owns that queue it becomes another unread report. Deploy it only when you can name the person who will work the list on a Tuesday.
Natural-language reporting is real where the data model is already governed, and actively harmful where it is not. If "revenue" means three different things in three subsidiaries, an agent will answer the revenue question quickly, confidently and differently each time depending on the phrasing. That is not a model defect; it is the same defect that makes your existing dashboard lie to you, delivered faster and with more authority. The prerequisite is a defined set of fields and measures with named owners. Companies that have that get real value in weeks. Companies that do not are buying a more persuasive version of their existing confusion.
Drafting is the quiet winner. Method statements, scopes of work, customer replies, meeting minutes, first-pass specifications, translation between Arabic and English. Nothing is committed, a person reads every word, and the time saved is real. It attracts no attention because it does not look like transformation. It is the highest return per dirham of anything in this article.
Where it is still theatre
Autonomous purchasing. A purchase order is a contract. Committing money to a third party on the basis of master data that your own buyers do not fully trust is not an AI problem, it is a governance problem wearing new clothes. There is a narrow, defensible version — replenishment inside a pre-agreed contract, from a pre-agreed supplier, within a value ceiling and a quantity band, where the "agent" is really a rule with better inputs. Call it what it is. The version demonstrated on stage, where the agent chooses the supplier, is not something a mid-market company should run unattended.
Unsupervised reconciliation. Reconciliation is not a matching problem, it is a truth problem. The value is not in clearing the ninety per cent that matches cleanly; a rule set did that already. The value is in the ten per cent that does not, and that ten per cent is exactly where a model's confidence is least correlated with its correctness. An agent that reconciles the easy items and escalates the hard ones is useful and unremarkable. An agent that reconciles the hard ones is generating audit findings on a delay.
Anything that writes to the ledger without a human release. This is not caution for its own sake. It is that a posted entry is the thing your auditor, your tax authority and your bank rely on, and reversing it leaves a trail that requires explanation. Under the UAE corporate tax and e-invoicing regimes, the transaction record has become a filed artefact rather than an internal one — which raises the cost of a quiet error considerably, as anyone who has worked through the questions in an FTA audit will recognise.
The orchestrated close. Every vendor roadmap now contains a version of this. Treat it the way you treat every roadmap item: as a statement of intent by a company that will not be sitting in your finance meeting explaining the variance.
The governance frame, which is the actual work
Here is the sentence that should govern the whole programme: an agent is a user, and it needs everything a user needs, plus two things a user has by default.
A person joining your company gets a role, a set of permissions scoped to that role, a manager, an induction, a probation period during which their work is checked more closely, and a name attached to everything they do. An agent needs the same. What it does not automatically get, and must be given, is an immutable record of what it did and a human being whose appraisal is affected when it goes wrong.
| Control | What it means for an agent | The failure if you skip it |
|---|---|---|
| Identity | Its own account, never a shared or admin account, never a human's credentials | Nobody can separate the agent's actions from a person's in the audit trail |
| Permissions | Scoped to the same role design as a person doing that job, and no wider | It reads salary data because it was given read on everything "to be safe" |
| Write boundary | An explicit list of what it may create, and what remains draft until released | It posts, and the first person to notice is external |
| Value and volume ceilings | A cap per action and per day, enforced by the system rather than the prompt | One bad inference becomes two hundred bad records overnight |
| Audit trail | Every action logged with the input, the output, the model version and the time | You cannot answer "why did it do that in March" in June |
| Named owner | One person, by name, accountable for its behaviour and its retirement | Everyone owns it, so nobody reviews it |
| Review cadence | A sampling regime with a defined rate and a written finding | Accuracy degrades as your data and suppliers change, silently |
| Off switch | Documented, tested, and usable by the owner without a vendor ticket | You discover during an incident that turning it off is a change request |
Two of those deserve emphasis because they are the ones skipped most often.
The first is the shared account. It is the fastest way to make an agent operationally convenient and the fastest way to destroy your ability to investigate anything. If the agent posts under the finance manager's login, then in any dispute the finance manager posted it. That is not a hypothetical inconvenience; it is a person's professional record.
The second is the review cadence. Model behaviour does not stay still, because your inputs do not stay still. New suppliers, a new invoice template, a new product family, a change in the vendor's underlying model. An agent validated in March and never sampled again is an unmonitored control, and unmonitored controls are what audit findings are made of. Deciding the sampling rate, who reviews, and what the finding triggers is precisely the work that AI governance exists to do, and it is unglamorous enough that it gets deferred until something goes wrong.
What the vendor should be asked
Six questions, and the tone of the answers tells you more than the content.
Where does this run and where does the data go? A model hosted by a third party means your invoices, prices and customer names leave your database. That may be perfectly acceptable — say so deliberately, in writing, having checked it against your own contracts with customers who imposed confidentiality terms.
What identity does it act under, and can I see its actions separately from a person's? If the demonstration cannot show you that screen, it does not exist yet.
What can it write, and what stays in draft? Get the list, not the reassurance.
How is it metered and what does a busy month cost? Most of these features are consumption-priced in some form. A pilot with fifty documents tells you nothing about a month with four thousand.
What happens when the provider changes the model underneath? Behaviour you validated can change without a release note on your side.
And, most usefully: show me the last three customers where this went wrong, and what the wrong looked like. A vendor with a real answer is a vendor with real deployments.
Where to start, in order
Start with extraction on supplier documents, because it is checkable, the volume is countable, and failure is loud. Run it for a full month and measure the correction rate rather than the accuracy claim.
Then add drafting, which costs almost nothing and needs no integration. Then matching as a proposal queue, with the working shown. Then, only if you have a governed set of fields and owners, natural-language querying — and if you do not have that, spend the same money on getting it, because it is the prerequisite for everything else and it also fixes your reporting.
Leave anomaly detection until somebody has agreed to work the queue. Leave anything unsupervised until you have run the supervised version long enough to know its error rate as a number rather than an impression.
The uncomfortable finding in most of this work is that the constraint is rarely the model. It is that item masters have duplicates, that lead times are decorative, that three people define margin differently, and that no one owns the customer record. Those were the constraints before any of this arrived. An agent does not remove them; it industrialises whatever they produce. Which is why the older argument — that data problems kill more projects than software does — has not been repealed by any of this, only made more expensive to ignore.
If you want the permissions design, the audit requirements and the ownership map written down before the first agent is switched on rather than after, that is a fortnight of work and it is where we would start.