Why the Process Exists

What does a manager's approval on a supplier invoice actually do?

The obvious answer is that it checks the invoice. Look closer and it does at least three things. It checks that the spend was expected. It keeps the manager aware of what the team is buying, invoice by invoice, month after month. And it puts a named person's signature on the decision to pay. Only the first of those is visible on the process diagram. The other two are done as a side effect, and nobody wrote them down.

Now give that process to an AI system that can read an invoice, match it against the purchase order and propose a payment in seconds. The invoice then waits four days for the manager's approval and another week for the payment run. The temptation is obvious: automate the fast parts and delete the slow ones.

Some of the slow parts deserve to go. Others are slow because they're doing a job nobody can see. So here is the rule I'd put on the wall of every automation project:

Every step in a process was put there to do a job, and the job is often different from the step you can see. Automate the steps. Preserve the functions.

The useful first question about any step sounds the least technical: what would break if it vanished tomorrow, who would notice, and when?

Two old answers, both partly right

The argument is older than computers, and two classic positions still frame it.

The first is Chesterton's fence. G. K. Chesterton imagined a reformer who finds a fence across a road and wants it cleared because he can't see what it's for. The wiser reply is that he may take it down only after he has gone away, found out why it was put up, and come back able to say. Applied to a process: a step whose purpose you can't name probably has one you haven't found yet.

The second is Michael Hammer's 1990 Harvard Business Review article, "Reengineering Work: Don't Automate, Obliterate". Companies, he argued, had spent heavily computerizing processes designed for paper and slow communication, so they automated the delays along with the work. The right move was to redesign the work around what the new technology made possible, and many steps would simply disappear.

Both are right, about different steps. Chesterton is right about steps that carry a hidden function. Hammer is right about steps whose only job was compensating for slow people and paper.

AI raises the stakes on both sides at once. It makes Hammer's move far cheaper, because rebuilding a flow no longer needs a large software project. And it makes Chesterton's mistake far easier, because an agent can perform a step's visible motions while dropping its invisible job, at a volume no person would ever reach.

An agent can do every visible motion of a step and none of its job.

What a step actually does

The way to see the hidden job is to ask which of a small set of functions each step performs. The list is a working lens, and the categories overlap. Its value is that it makes you ask about each one.

• Transform. Change the item itself: enter data, compute a total, draft a reply, match three documents.
• Check. Catch errors or abuse before they cost anything: a second pair of eyes, a reconciliation, a threshold that triggers review. Many checks exist to manage incentives, and say nothing about anyone's competence. Segregation of duties, for example, means the person who starts a payment can't also approve it, so fraud needs two people to collude.
• Coordinate. Line things up in time: a weekly payment run that matches the cash forecast, a handoff that tells the next team work is coming.
• Inform. Let someone learn something by doing the step. The manager who approves every invoice knows what the team spends and notices a supplier creeping up.
• Sign off. Put a person's name, and responsibility, on a decision. Regulators, auditors and courts care who decided.
• Signal. Show care or compliance to a customer, a regulator or an internal stakeholder. Sometimes it matters. Sometimes it's theater.
• Fossil. Survive because nobody removed it. The reason expired years ago.

Here's an ordinary invoice process mapped that way.

Scroll sideways to see the whole figure

The map changes the conversation. "Key data into the ERP" is pure transformation: automate it and check the output. "Print and file a copy" looks like a fossil from the days of paper audits, a candidate for removal once someone confirms that no retention rule still depends on it. "Manager approves" is the interesting one. It carries a check, an information flow and a signature, and auto-approving it removes all three at once, when the project team was only thinking about the first.

The approval, taken apart

Make it concrete. A 300-person company processes 2,000 supplier invoices a month, approved by 14 budget-holding managers, about 140 each. An AI system now extracts, matches and codes them accurately. The finance lead proposes auto-approving every matched invoice under €1,000, which is 70 percent of the volume. Managers would see only the rest. (The numbers are illustrative; the reasoning isn't.)

Go through the functions one at a time.

The check mostly survives on its own. Under €1,000, with the purchase order and the goods receipt already matched, much of the checking has happened upstream: someone approved the purchase when the order was raised, and someone confirmed the goods arrived. The match catches billing errors, such as a wrong price, a wrong quantity or a duplicate. What it can't catch is a purchase that should never have been ordered, if ordering is loosely controlled, or a receipt entered by the same person who placed the order. So the real question is whether those leftover risks, at that size, are worth a manager reading every invoice. Often they aren't. A periodic sample review plus a rule that whoever orders can't also confirm receipt covers them more cheaply.

The information flow is the one that silently disappears. Managers who saw about 140 invoices a month had an ambient sense of their spending. After the change they see about 40, all of them larger. The small creeping costs, a subscription renewed without anyone deciding, a supplier whose prices drift up, become invisible. Nothing breaks, so nobody notices.

The fix is to keep the function and change its form: a monthly digest per manager of everything auto-approved, grouped by supplier, with anything unusual highlighted. Because it groups and compares, it can show a drift that is invisible one invoice at a time, which makes it better than the approval queue at this job. It has one weakness the queue didn't: nothing forces anyone to read it. So track whether managers open it, and put the two or three anomalies that need a reply at the top, where ignoring them is a visible choice.

The signature becomes a policy. Someone has to own the decision that small matched invoices are approved by rule. That becomes a written policy with a named owner and a date to revisit it, in place of 1,400 individual signatures a month. Settle the threshold with the auditors before the change. A written rule, a named owner and evidence that the rule is monitored make that conversation easy. An approval that quietly stopped happening, with nobody having decided, makes it very hard.

The coordination stays where it is. The weekly payment run two steps later exists to line up payments with the cash forecast and the bank's batches. Faster approval doesn't change that. It just means more invoices are ready in time. Removing the weekly run would be a cash-management decision in its own right, to be made on its own merits.

Done this way, the project keeps every function the approval carried, delivers the speed, and has a clear answer when an auditor or a manager asks what happened to oversight.

How to find the reason

The inventory is only as good as what you learn about each step, and the reasons are rarely in the process documentation. Four places tend to have them.

The people who do the step. They know which parts matter and which are ritual, and they usually remember the incident that created a rule. They will also be the first to notice when the automated version gets it wrong. Treat them as the first critics of the new design. That is both more accurate and more likely to work than treating them as an obstacle.

The incident behind the rule. Many checks were added after something went wrong: a duplicate payment, a fraud, a fine. Find the incident and you know what the check protects against, which tells you whether the risk still exists and whether something cheaper would cover it.

The decision record, if there is one. Organizations that wrote down why they made a choice, and when to revisit it, make this trivial. Most didn't. Start writing those records for the changes you make now (Write for the Model That Doesn't Exist Yet).

A reversible experiment. When nobody can name the function, remove the step in a way you can put back, for a set period, and watch the specific things it might have protected. A quarter without the printed copy will show whether anyone needed it. A month of auto-approval with the digest will show whether managers miss what they used to see.

What AI changes about the answer

Good operations people have always done some version of this. AI changes how it comes out in four ways, and they don't all point toward "remove more".

Once transformation is cheap, everything else is the bottleneck. When extraction, matching and drafting take seconds, the checks, decisions and handoffs are most of the elapsed time. That's where the scrutiny belongs (Where the Saved Time Goes).

Some checks need to grow. More output means more to check. And a model's errors look different from a person's: fewer typos, and occasional confident mistakes that look entirely plausible. A check designed to catch human slips can miss model failures, while a check that only existed because humans were slow may no longer be needed. Each one has to be judged on its own terms.

Information functions get lost without anyone deciding. When people did the work, they learned from it as a side effect. When an agent does it, nobody learns anything unless the system is built to surface what matters. This is the easiest function to lose and the hardest to notice.

Steps that compensated for slow people can finally go. Status meetings that exist because information moved slowly, re-keying between systems that couldn't talk, approvals that existed to batch work for a busy reviewer. Hammer's argument applies with more force now than in 1990. My bet is that this is where the larger gains are, because removing a step saves all of its time, while speeding it up saves only part.

There's one more point for anyone building agents. A check that matters shouldn't depend on the agent remembering an instruction. If the rule is that payments over €10,000 need a second approver, the payment system itself should enforce it, whatever the agent was told (Same Model, Different Results calls these walls). The function inventory is how you find which rules deserve that treatment.

What to do

Before you automate or delete a step, ask what would break if it vanished, who would notice, and when. If nobody can answer, find out before you delete anything.

Map every step by function. Automate transformation freely. Keep checks, information flows, signatures and coordination, in a new form if the old one no longer fits.

Watch the information function above all. It disappears silently the day people stop doing the work. Replace it with something that groups, compares and puts the anomalies on top.

Get the reasons from people, incidents, records and reversible experiments, in roughly that order.

Spend the speed on redesign. Remove the steps whose only job was waiting for slow people. And put the checks that really matter into the systems themselves, where no agent can talk its way past them.

Check yourself

Why is auto-approving small matched invoices riskier than it looks?

The approval carried a check, an information flow and a signature. Removing it drops all three at once, while the project team was only thinking about the first.

How do you keep the information function after automating an approval?

Replace it with a monthly digest per manager, grouped by supplier, with the anomalies on top. Track whether managers open it, because nothing forces anyone to read it.

Why is removing a step that only compensated for slow people better than speeding it up?

Removing it saves all of its time, while speeding it up saves only part. Status meetings, re-keying and batching approvals are examples that can finally go.