Autonomous ERP: As Systems Start Making Decisions, Who's Responsible for Testing Them?

Your ERP just auto-approved a purchase order for 50,000 units. It reallocated warehouse stock across three distribution centres. It adjusted next quarter's revenue forecast downward by 8%. Nobody told it to do any of this. It decided on its own, based on patterns in your data. The question isn't whether this is coming — it's already here. The question is: who tested these decisions before they went live?

ERP vendors are racing to embed AI-driven decision-making into their platforms. SAP, Oracle, Microsoft, and every major player now offer features that go beyond simple automation. These aren't rules-based workflows where “if X then Y” — they're systems that observe patterns, weigh probabilities, and take action. And the gap between what these systems can do and what organisations have tested them to do is growing fast.

1. What's Actually Changed

For decades, ERP systems did exactly what they were configured to do. You set up approval workflows, defined routing rules, and created business logic. The system followed the rules. If something went wrong, you could trace the issue back to a configuration decision, a data entry error, or a process gap. Responsibility was clear because the system never made a decision on its own.

That model is breaking down. Modern ERP platforms now include capabilities that make genuine decisions:

• Predictive procurement — systems that anticipate demand and create purchase orders before anyone requests them
• Dynamic inventory allocation — stock moved between locations based on the system's interpretation of demand signals, not a human instruction
• Automated financial adjustments — accruals, provisions, and forecast revisions triggered by pattern recognition in transaction data
• Intelligent approval routing — the system decides whether a transaction needs human review at all, based on risk scoring
• Anomaly-driven exception handling — the system flags, and sometimes resolves, exceptions that previously sat in someone's inbox

The critical difference is agency. These features don't wait for instructions. They observe, infer, and act. And that shift — from tool to agent — changes everything about how these systems need to be tested.

2. The Accountability Gap

When an ERP system auto-approves an invoice that shouldn't have been approved, who is accountable? The finance director who enabled the feature? The IT team that configured the thresholds? The vendor whose algorithm made the call? The project team that tested it before go-live?

In most organisations today, the answer is: nobody has thought about it. Autonomous features get switched on during implementation because they're part of the platform, they appear in the vendor's demo, and the project team assumes they work. The governance structures that exist for human decisions — approval matrices, segregation of duties, audit controls — haven't been updated for decisions made by algorithms.

3. Testing Decisions, Not Just Workflows

Traditional user acceptance testing is built around workflows. A tester follows a defined process — create a sales order, post an invoice, run a payment batch — and confirms the system produces the expected output. The system is a tool; the tester validates the tool.

Autonomous ERP breaks this model. When the system makes its own decisions, you can't just test the workflow. You have to test the decision itself. And decisions are harder to test than workflows because they depend on context, data quality, and boundary conditions that change over time.

Consider a system that automatically adjusts safety stock levels based on demand forecasting. A traditional test would confirm that the system can update safety stock. A decision-focused test would ask:

• What happens when the demand signal is based on a seasonal anomaly the algorithm hasn't seen before?
• Does the system recognise when its own confidence level is too low to act, and escalate to a human?
• If two autonomous features conflict — one trying to reduce stock, one trying to increase it — which wins, and is that the right outcome?
• What is the maximum financial exposure from a single autonomous decision, and has that been approved by someone with the authority to accept that risk?

These are not questions that fit neatly into a spreadsheet with a pass/fail column. But they are exactly the questions that determine whether an autonomous ERP will help or harm your business.

4. The Cascading Risk Problem

The most dangerous characteristic of autonomous ERP is speed. When a human makes a bad decision — approves the wrong vendor, over-orders stock, miscodes a journal entry — the damage is usually contained. Someone spots it in a review. The error affects one transaction, one batch, one period. There's time to intervene.

When an algorithm makes the same mistake, it can propagate across hundreds or thousands of transactions before anyone notices. And because autonomous features often feed into each other — a procurement decision affects inventory, which affects forecasting, which affects financial reporting — a single bad decision can cascade through the entire system.

This is not hypothetical. The history of ERP disasters is full of examples where automated processes amplified errors faster than human processes ever could. The difference now is that autonomous features make the feedback loops tighter and the blast radius larger.

Testing for cascading risk means going beyond individual feature validation. It means testing how autonomous features interact with each other, how they behave when fed unexpected data, and critically — what happens when they're wrong. Does the system have circuit breakers? Are there limits on how many autonomous decisions can execute before a human checkpoint is required? Has anyone tested whether those safeguards actually work?

5. UAT Becomes Continuous

Traditional UAT happens once, before go-live. You test the system, sign it off, and move on. The system doesn't change its behaviour after deployment — it does exactly what it was configured to do until someone reconfigures it.

Autonomous ERP invalidates this model entirely. A system that learns from data will behave differently six months after go-live than it did during testing, because it has six months of additional data shaping its decisions. The test scenarios you validated before launch may no longer reflect how the system actually behaves in production.

This means UAT can no longer be a phase. It has to become a discipline — an ongoing practice of validating that the system's autonomous decisions remain within acceptable boundaries as data evolves, business conditions change, and the models that drive decisions adapt. For consultants supporting clients through this transition, the right UAT tooling becomes essential for maintaining the audit trail that continuous validation demands.

6. A Practical Framework for Testing Autonomous ERP

The good news is that organisations don't need to reinvent testing from scratch. The principles of structured test case management still apply — they just need to be extended to cover decisions, not only workflows. Here's a practical framework: