A Bad Process with AI Is Still a Bad Process

An invoice approval process at a mid-sized company had a well-known problem: invoices took an average of twelve days to get approved, and finance leadership had decided the fix was an AI agent that could read incoming invoices, match them to purchase orders, and route them automatically. The pilot was technically successful. The AI agent read invoices accurately and routed them within minutes. Average approval time barely changed, because the twelve days had almost nothing to do with reading the invoice. It was about how long invoices sat waiting for a manager who reviewed everything personally regardless of value, a habit left over from a fraud incident years earlier that nobody had ever revisited.

Faster waste is still waste

This is the core problem with layering AI onto a process that has not been examined: AI is very good at making a step happen faster, but it has no way of knowing whether that step should exist at all. If an invoice approval process has a redundant review step, a duplicated data entry point, or an approval that adds no real control, an AI agent applied to that step will simply execute the redundant work more quickly. The organization ends up with the same structural waste, now running at higher speed and, in many cases, at a higher ongoing cost because AI capability is rarely free.

There is a specific irony here worth naming directly: speeding up a bad process can make the underlying problem harder to see. When an unnecessary approval step took three days, it was an obvious target for review. When the same unnecessary step takes three minutes because an AI agent handles it, it disappears from anyone's list of things worth questioning, even though it is still adding no value.

Hidden rework does not go away because AI is involved

Rework is one of the most common and least visible sources of waste in a process like invoice approval, and it is a good example of why AI cannot fix a structural problem by itself. If invoices are routinely sent back for correction because the purchase order field was filled in incorrectly upstream, an AI agent that reads and routes invoices faster will also read and route the incorrect ones faster, and they will still bounce back for correction at the same rate. The rework loop is untouched. The organization has simply automated the fast half of a process that still contains a slow, recurring failure.

Fixing that kind of rework usually means going back further than the AI conversation altogether, to whoever fills in the purchase order field in the first place, and asking why the error happens. It might be a form design problem, a training gap, or a system that allows an invalid entry to be submitted. None of those are AI problems, and no AI agent placed later in the process will resolve them.

Automation bias: trusting the output because it came from AI

There is a second, subtler risk that shows up once AI is introduced into a flawed process: people start trusting its output more than they trust their own judgment, even when the underlying process logic is wrong. If an AI agent is matching invoices to purchase orders using a matching rule that has a known blind spot, for example it does not account for partial deliveries, staff may stop double-checking matches because the agent's output looks authoritative. The bad process logic that was previously being caught by a careful human reviewer now goes uncaught, because the human review step has been quietly deprioritized in favor of trusting the tool.

This is not an argument against AI. It is an argument for fixing the process logic first, so that whatever AI is applied on top of it is operating against a sound set of rules rather than inheriting a flaw and giving it a more convincing presentation.

A worked example: two ways to approach the same invoice process

It is useful to compare what happens when AI is applied directly to an unreformed process versus applied after the process has been improved. The table below sets out the same invoice approval process treated two different ways.

Improve before you automate: what this actually requires

Improving before automating does not require abandoning AI ambitions or slowing everything down for months. It requires a short, disciplined pass over the process to answer a small number of questions: does every step still need to exist, is ownership clear at every handoff, where does rework originate and why, and is the bottleneck actually where people assume it is. Answering these honestly, using real data about where invoices actually sit and how often they get sent back, usually takes days, not months, and it changes what an AI project is asked to do.

The invoice approval example above is representative of a pattern that shows up across other processes too. In claims processing, an AI agent that summarizes a claim file faster does nothing to fix a process where three separate teams each request the same supporting document from the claimant because none of them can see what the others already collected. In vendor onboarding, an AI agent that drafts a risk assessment faster does nothing to fix a process where the assessment sits unopened in an approver's queue for two weeks. The technology performs its narrow task well every time. The process problem persists every time, because the two are not the same problem.

How simulation exposes the difference before you commit

The reason this distinction is hard to see in advance, before money and engineering time are spent, is that it is genuinely difficult to predict by inspection alone whether a bottleneck sits where a proposed AI change would help or somewhere else entirely. Running a process through a discrete-event simulation, using a realistic mix of cases rather than a handful of example scenarios, exposes this clearly. A simulation will show whether the constraint is the manager review, the upstream data quality, or the routing logic, and it will show what happens to cycle time and throughput if each of those is addressed in turn, with and without a proposed AI agent in the mix.

This kind of comparison turns a genuinely difficult judgment call, will this AI investment actually reduce cycle time, into something that can be tested against a documented baseline before any implementation decision is made. It also creates a natural, defensible order of operations: fix what does not require new technology, then apply automation or AI to what remains, then measure the combined effect against where the process started.

How Processfix supports improving before automating

Processfix is built around this exact sequence. An invoice approval process, or any other process, can be modeled from a plain-language description or an uploaded SOP, simulated to establish a baseline for cycle time, throughput, and bottleneck location, and then tested with an Improve scenario that removes unnecessary steps or rebalances a review threshold before any AI agent is considered. Only after that improved baseline is established does it make sense to model an Add AI scenario on top of it, using the four typed levers, automate a task, add an AI agent, add capacity, or reduce rework, and compare the result against both the original and improved baselines.

This comparison gives a team an estimate, grounded in the process model and the assumptions they have approved, of what a proposed change is likely to achieve. It is not a verification that any AI agent can be technically deployed against real systems and data, and Processfix does not build, connect, or run the automation or agent itself. That implementation work happens afterward, informed by a process that has already been improved rather than one that was automated as found.