Bringing AI into your ERP without breaking it
by Quolo, Web App Development & Consulting
ERP systems are the most consequential pieces of software a business owns. Finance posts to them. Inventory lives in them. Payroll runs through them. When they go wrong, the kind of wrong they go is the kind that ends up in board reports.
Adding AI to that environment is genuinely interesting work, and it carries proportionate risk. Done badly, it puts your most sensitive operational system at the mercy of a non-deterministic component nobody fully understands. Done well, it removes hours of repetitive work, surfaces patterns nobody had time to look for, and makes the ERP feel like it actually fits the business. The difference comes down to the patterns you choose from the start.
Start read-only
The single best decision you can make on an ERP-AI project is to begin with features that read but never write. There is real value in natural-language search across line items, customers, or transactions; summarisation of long contracts or multi-month service histories; classification that flags unusual, late, or incomplete records; and question-answering over policy documents attached to the system.
None of these touch the data. None of them can post a journal, change an invoice, or move stock. They give you a chance to learn how AI behaves inside your specific data, with your specific users, before you give it any power to change anything.
Top tip
Most of the value of AI in an ERP is in surfacing what is already there. Writing comes later, and only for workflows where you have evidence it works.
When you do let it write, write through humans
Eventually, read-only stops being enough. Someone wants the AI to draft the journal entry, propose the credit note, suggest the bill of materials. That is a reasonable next step, and the right shape for it is almost always AI proposes, human approves.
This means the AI's output lands in a draft state, never in the live record. A person sees the proposal, with the inputs and reasoning surfaced clearly. They approve, edit, or reject. The system records what was proposed, what was approved, and who approved it. The cost is one extra click for the human. The benefit is that you can deploy AI into write workflows without giving up the audit trail your finance team needs.
Audit trails are not optional
Every AI-driven change inside an ERP needs a trail you could hand to an auditor. At minimum, that means capturing the input that triggered the action, the model and prompt version used, the full output the AI returned, the human who reviewed it if any, and the final action taken in the system.
Build this from day one. Retrofitting it later is significantly harder, and you will not get good answers when something goes wrong six months in. It is the kind of infrastructure that feels like overhead until the moment it is not.
Build the rollback before the launch
Anything that changes data needs a rollback story. For AI-assisted writes, that usually means soft deletes rather than hard ones, reversible transactions wherever the underlying system supports them, a documented procedure for identifying and undoing a batch of AI-influenced changes, and a kill switch that disables the AI features without taking the rest of the ERP down.
That last one matters more than it might seem. The first time you need to turn off an AI feature in production while keeping the ERP running, you will be glad you do not have to redeploy to do it.
Treat the model as the smallest replaceable part
Models change. Providers change. Pricing changes. The AI features inside your ERP will outlive whichever model you started with, so architect accordingly.
Wrap model calls in an internal interface so swapping providers is a configuration change rather than a refactor. Keep prompts in source control with version numbers, so you can correlate behaviour changes with prompt changes. Run an eval suite on every prompt or model update, against the same fixed dataset. When the next, better, cheaper model arrives, you want to be able to switch on a Tuesday afternoon rather than committing to a quarter of integration work.
Pick the integration boundary deliberately
There are usually three places to put the AI relative to the ERP. Inside the ERP uses vendor extension points or AI features the vendor ships; it is the lowest friction option, but you inherit the vendor's pace and limits. Alongside the ERP is a separate service that talks to the ERP through its API, which gives you control of the AI lifecycle and isolates risk. Above the ERP is a layer that fronts the system for end users, with the AI living in that layer, which works best when user experience matters more than deep integration with internal processes.
For most situations, starting alongside the ERP is the right call. It keeps the AI experimentation off your most critical system while still letting it act on real data with proper integration.
Where projects go wrong
A few patterns tend to end badly. AI integrations that bypass the ERP's permissions model "just for now" often stay that way for years, and audit becomes painful. Generative features that write directly into financial records without a review step, because the demo went well. Vendor AI add-ons enabled across the business without an eval, leading to silent quality regressions on routine work. Custom AI workflows built without thinking about what happens when the underlying ERP version is upgraded.
Each of these is avoidable, but none of them is avoidable by accident.
A reasonable first ninety days
If you are bringing AI into your ERP for the first time, a reasonable shape for the work looks like this. In the first three weeks, pick one read-only feature, build it, deploy it to a small group, and measure usage and quality. Over the following month or so, expand to two or three more read-only features, build the audit trail and observability, and set up evals. In the final stretch of that first quarter, introduce the first AI-proposes, human-approves write workflow with full audit and rollback in place.
By the end of that, you have a working AI capability inside the ERP, evidence of where it earns its keep, and the operational scaffolding to expand safely. ERP integrations are the kind of work where doing it carefully looks slow up front and saves an enormous amount of effort later. If you are about to start, plan for the audit trail before the feature.
If you are working through an ERP integration or evaluating the right approach for your system, feel free to reach out at tim@quolo.io.