AI in an ERP, Minus the Theatre
An assistant that writes a confident paragraph about your stock position is worth less than a rule that catches a duplicate invoice. Here is the line we draw between the two, and what we automate first.
Most ERP vendors now have an AI story, and most of those stories are a chat box bolted to a reporting layer. You type a question, a model writes a fluent paragraph, and nobody can tell you where the number came from. It demos beautifully. It is close to useless for a finance team that has to sign something.
We build iSKEL AI ourselves and it runs inside every product we ship, so this is a line we have had to draw carefully: what deserves a language model, and what must stay arithmetic.
The line: rules decide, language explains
Anything with a right answer should be computed, not generated. Tolerances, ageing buckets, tax rates, reorder points, duplicate detection, three-way matching — these are rules. They are auditable, they are repeatable, and they give the same result twice on the same data. A language model asked to do that work will usually be right, occasionally be confidently wrong, and never be reproducible. In an ERP, "usually right" is a defect.
What a language model is genuinely good at is the layer on top: reading an unstructured document, turning a question in plain English into a query, drafting the email a human will approve, and explaining in a sentence why a deterministic rule fired.
Keeping that separation has a practical benefit beyond correctness: when something goes wrong you can tell which half failed. A rule that fired wrongly is a configuration bug with a fix. A model that paraphrased badly is a prompt problem. Systems that blur the two are systems nobody can debug.
Four things worth automating first
Ranked by how much time they give back per unit of risk, in our experience of turning this on inside live ERPs:
1. Document capture
Supplier invoices, delivery notes, prescriptions, resumes, bank statements — anything that arrives as a PDF and leaves as typing. Read on arrival, fields extracted into the right doctype, matched against the purchase order or the master record, and held for review where the match is imperfect. The deterministic part is the match and the tolerance; the model's job is only reading the page.
This is where the hours are. A purchase clerk keying forty invoices a day is the single most automatable role in most businesses, and the automation is boring and verifiable.
2. Chasing and follow-up
Receivables ageing is arithmetic. Deciding who to chase today is a rule. Writing the fourth polite-but-firm reminder of the week is drudgery a model handles well — as a draft, queued for a human to send. The value is not the prose, it is that the chase happens at all on a week when everyone is busy.
3. Anomaly detection
Duplicate payments, price variances against the last purchase, a stock adjustment larger than any in the previous quarter, a payroll component that moved when nothing else did. These are statistical and rule-based, and they are worth far more than a chat box because they surface things nobody thought to ask about. Every one we raise carries the evidence — the two documents, the two numbers, the rule that fired.
4. Reporting in plain language
"Show me last quarter's top customers by margin, excluding intercompany." The model turns that into a query against your own doctypes; the numbers come from the database, not from the model. Done this way it is a faster report builder, which is a real thing to want. Done the other way — model summarising model-retrieved figures — it is a machine for producing plausible numbers.
The guardrails we insist on
These are not optional extras, they are the reason the thing can be deployed in a business that gets audited:
- Scoped reading. Which documents and masters the engine may read is agreed in writing during Solution Design, per module. "All your data" is not a scope.
- Existing permissions apply. The assistant sees what the logged-in user's role sees. An AI layer that bypasses your role permissions has quietly become your biggest access-control hole.
- Nothing posts unreviewed. Drafts, queues and holds. Anything that creates or approves a financial document waits for a person until you explicitly decide otherwise, document type by document type.
- Every capability is a switch. Per module and per role, off by default. An ERP that only does what you configured is still the point.
- Corrections are the feedback loop. When someone fixes an extracted field or overrides a suggestion, that is signal — captured, not discarded.
What we will not claim
It does not replace your team. It removes retyping, chasing and hunting for numbers; the judgement and the accountability stay exactly where they were. Anyone selling headcount reduction from an ERP assistant is selling the part they cannot evidence.
It is also not a data strategy. If your item master has four spellings of the same product and your customer master has duplicates, an assistant will answer questions about four products and two customers. That work comes first, and it is unglamorous — which is why it tends to get skipped and then blamed on the AI.
Where to start
Pick one process that wastes a week of someone's month and has a verifiable output — invoice entry is the usual candidate. Automate that end to end, with a review queue, and measure the time it actually gives back before switching on anything else. Capability by capability, each with an owner, is how this ends up trusted rather than switched off after a fortnight.
That is how iSKEL AI is deployed on the products in our suite, and how we would approach it on an ERPNext instance you already run. If you want to see it against one of your own processes rather than a sample dataset, bring that process.