Will AI Replace Traditional ERP Systems?

AI will change how companies interact with operational software. Whether it can replace the system that records the business itself is another matter — and the answer decides how much of what it recommends you can trust.

Evan KazakovEvan KazakovCo-founder, marql
·9 min read

Key takeaways

  • AI will take over much of what users see in an ERP — the menus, the standard reports, the routine queries. It will not take over the layer that records that a sale happened, stock moved or an invoice was posted, because a system of record needs consistency, permissions and an audit trail, and AI is probabilistic by design.
  • The useful test of an operational system is not whether it shows a deviation but whether it follows a decision to its result: observation, hypothesis, action, evidence. Most software stops at the first step.
  • Once data drives actions rather than reports, errors get more expensive and less visible — an agent's explanation stays coherent while being coherent about the wrong version of the business.

Over the past two decades I have worked on ERP rollouts, operational data and retail businesses at very different stages of maturity. One pattern has been remarkably persistent: a company can invest heavily in an ERP system and still prepare the owner's weekly report by combining several Excel files by hand.

The problem is rarely that software is missing. More often, different systems hold different definitions, processes and versions of the same business reality. Someone has to bring them together, decide which numbers to trust and explain the result to management. Information is lost or reinterpreted on the way, people repeat the same work every month, and tracing a questionable figure back to its source becomes hard. I have written separately about what that costs a business day to day.

For many retail and hospitality businesses this basic reporting problem is not solved yet. Expectations, meanwhile, have moved well past reporting. Companies now want a system that notices a meaningful deviation, offers an explanation, starts a response, and eventually says whether that response produced a measurable result.

When analysis turns into action

Imagine category margin beginning to slide across several stores. A traditional BI system puts the change on a dashboard. Someone still has to notice it, investigate the cause, decide what to do, communicate the decision, and come back later to see whether it worked.

A more capable system would examine the structure of the decline: whether the share of low-margin products rose, whether a promotion performed differently than planned, whether purchase prices moved, whether key products were unavailable, whether the sales mix shifted. It could then propose an action — check placement, move stock between stores, adjust the next order, change a promotion, assign the task to the right manager — and a week or a month later revisit that decision against revenue, margin, stock turnover, waste and cash.

Observation, hypothesis, action, evidence of the result. Most business software is reasonably good at showing what happened. Far less of it can follow a decision through to its economic outcome.

I call that sequence a proof loop; the label matters less than the last step. Once it is there, reporting stops being only a way to observe the business and becomes part of how the business responds — the shift I argued for in from accounting to navigation, and the reason marql keeps an impact ledger of what each acted-on recommendation did to the numbers.

There are several possible levels of response, and they are not interchangeable. A system may put a recommendation in front of a manager and stop. It may create a task and track its completion. For a narrow, repetitive process it may act on its own within limits agreed in advance. It might prepare a stock transfer between locations but require an operations lead to approve it; it might raise an order inside an agreed range but escalate a larger purchase. Decisions that touch prices, significant purchasing commitments or a large share of inventory need a different level of control from routine adjustments.

The objective is not to hand over as many decisions as possible. The difficult work is deciding which actions are reversible, which limits can be set in advance, and where the cost of an error still justifies human approval.

The same applies to the popular idea of chatting with your business. A conversational interface is genuinely useful, but not because owners were waiting for another way to request a report. They want to know which deviation matters, what may have caused it, who needs to respond, and whether the decision paid off. Natural language makes that process easier to reach. It does not make the information underneath it more reliable.

The part of ERP that AI cannot replace

The question of whether AI will replace ERP tends to fold together two quite different functions.

The first is everything users see: menus, forms, standard reports, approval screens, built-in analytical workflows. Much of this will change. People will spend less time hunting for a particular report or clicking through a long sequence of screens, and agents will take over many routine queries, checks and workflow steps.

The second is less visible. ERP, POS, accounting and warehouse systems record business events. They establish that a sale took place, that stock was received, that a product was written off, that goods moved between locations, that a price changed, that an invoice was posted. Those events do not originate in the AI layer. They still have to be captured, connected and stored according to defined rules.

An accounting system cannot conclude that a transaction probably happened. It has to record what happened, keep the supporting documents and preserve a history someone can review later. A retailer needs to know not only the current stock balance but which receipts, sales, transfers, returns and write-offs produced it. AI is probabilistic by design, which is useful when a task involves interpretation, incomplete information or a range of plausible answers. A system of record has a different responsibility: consistency, repeatability, permissions, an audit trail. Adding AI does not make those requirements go away.

The boundary is not absolute, though. AI can make entry and control inside ERP considerably better without becoming the system of record itself. A targeted agent can read an invoice, purchase order or delivery note and prepare the fields for review, match a supplier or SKU against existing master data, spot a missing detail and flag a likely error before the transaction is posted. Other agents can watch what has already been recorded, looking for duplicates, missing records, unusual values, inconsistent product classifications, or transactions that do not reconcile with related operations. Instead of surfacing at month end, those problems can be handled close to the moment they occur.

Not every capability in this belongs under the word AI. If a required field is empty or a value falls outside a known range, a conventional rule catches it more reliably and more cheaply. Statistical methods and traditional machine learning are good at finding unusual patterns across large volumes of transactions. Generative AI and agents earn their place where the system has to read an unstructured document, interpret context, explain an anomaly or propose what should happen next. A practical architecture uses all three, and picks by the nature of the problem. The market often works in the opposite order: everything is described as AI first, and the problem is defined later.

Poor data becomes more expensive

When data is used only for reporting, an error damages a report. Once the same data starts driving recommendations and actions, the consequences change. An incorrect stock balance leads to an unnecessary purchase. A duplicate SKU distorts category performance. Inconsistent classifications affect assortment decisions, and late postings make the system respond to a situation that no longer exists. The same problems undermine any later attempt to calculate what a decision returned.

AI can make this risk less visible, because its output sounds convincing. An agent may answer an owner's question with confidence, identify a plausible pattern and recommend a reasonable course of action. If the source data is incomplete or inconsistent, the explanation will still be coherent. It will simply be coherent about the wrong version of the business.

A Porsche 911 can have exceptionally sophisticated engineering, and none of it removes the need for fuel. In an AI-driven business system, that fuel is accurate, structured, timely data.

This is also why I am not convinced AI will automatically make ERP implementations cheaper. It will reduce the cost of individual tasks — document processing, master-data matching, anomaly detection, integration documentation, first-line diagnosis. But companies are asking more of their data at the same time: more detail, available sooner, consistent across a growing number of systems. The nature of the work changes; the work does not disappear. In some cases implementation becomes more demanding, because the output is no longer meant only for a management report. A human analyst can look at an unusual number and decide something is probably wrong. An automated process needs that uncertainty detected before it adjusts an order or reallocates stock — which is the argument for treating reporting as something you keep running rather than a project you finish.

A practical place to start

For an owner, the sensible starting point is neither the most impressive AI product nor an attempt to replace the whole accounting environment. It is one recurring management decision where a better and faster response would create measurable value — category margin, waste, out-of-stocks, stock allocation, purchasing.

Once the scenario is defined, you can ask what data it needs, where that data comes from, how reliable it is, what the system should be allowed to do, and how the result will be measured. That usually exposes the real state of the infrastructure quite quickly, and it stops the project from becoming a general AI initiative with no operational owner and no economic outcome.

For most established retail chains and hospitality groups, replacing the POS, ERP or accounting platform is not the first step. The more practical route is to work with the systems already in place. The POS usually provides the base data; ERP, accounting and warehouse systems add purchasing, cost, stock and financial information. Connecting them is only the beginning — products, categories, locations, transactions, prices and balances still have to be reconciled into one model that stays comparable across stores, systems and periods.

That is the part of marql that attracts the least attention and decides the most. It connects read-only to the systems a chain already runs, hosted in the EU, normalises them into a single model, and answers the second question about a number in the same conversation as the first. Some of the reconciliation is automated; the exceptions still need people who understand the business. Pricing starts from EUR 200 a month.

I do not expect AI to eliminate ERP and accounting systems in the foreseeable future. It will make their interfaces less central, take over routine analytical work, simplify data entry and strengthen data controls. The responsibility to record business events correctly stays where it is. Over the years I have repeatedly watched new analytical tools expose weaknesses in operational accounting rather than remove the need for it. AI will expose them faster, and in some cases will act on the information before a person has reviewed it.

See it on your own data

Pick the one decision you make every week and would rather make on evidence. We'll connect the systems you already run and show what your own data can and cannot answer about it.

marql.one

Record what happened. Decide what to do. Then check whether it worked.

AI and ERPSystem of recordData qualityAgentic automation
Evan Kazakov

Written by

Evan Kazakov

Co-founder, marql

Blog

Frequently asked questions

Not the part that matters most. AI will take over much of the interface and the routine analytical work inside an ERP, but the layer that records business events — sales, receipts, transfers, write-offs, price changes, postings — needs consistency, permissions and an audit trail that a probabilistic system cannot provide.

Observation, hypothesis, action, and evidence of the result. Most business software stops after the first step by showing that a number moved. The loop closes when the system returns to a decision weeks later and reports what it did to revenue, margin, stock turnover or cash.

Where the action is reversible and the limits are agreed in advance — a stock transfer inside a range, a routine reorder. Decisions touching prices, significant purchasing commitments or a large share of inventory should stay with a person, because the cost of an error justifies the approval step.

No. marql connects read-only to the POS, accounting and stock systems a chain already runs and normalises them into one model. Nothing is written back to the source systems, and the existing workflow stays as it is.

Ready to see
the euros it found?

Connect your tills, stock and accounting in a day. Read-only access, no POS replacement, €200 a month per location and less as you grow.

0
Replacement of stack
1
Chat. Whole business.