Approvals Under Automation: AI and RPA in Procurement Before You Deploy

Procurement is where automation meets segregation of duties. Most of the procure-to-pay flow is rules and bounded judgement, and both automate well. The approval steps are different: they are controls, not tasks, and a control automated without redesigning the authority behind it is an audit finding waiting to be written. The ACFE's 2026 Report to the Nations found that the median occupational fraud scheme runs for 12 months before detection, and that schemes caught inside six months carry a median loss of $40,000 while those running past five years exceed $1.1 million. Removing the human from the approval step without replacing the control is how a scheme gets its 12 months. This guide walks the flow step by step, sorts each into rule, judgement, or control, and sets out the practices that keep the controls intact when the bots arrive.

Introduction

The procurement automation business case is usually the easiest one in the building. Invoice volume is high, the steps are repetitive, and the accounts payable team can tell you exactly how many hours they spend matching paper to purchase orders.

What the business case does not say is that three of the steps in that flow exist to stop money leaving the organization without a second pair of eyes. When the bot takes over those steps, the second pair of eyes goes with it, and nobody wrote down what replaces them.

Six months later the process is faster and the internal auditor has a question.

Where do AI and RPA fit in the procure-to-pay flow?

In most of it, and the useful work is deciding which steps they do not fit, before the vendor demo decides for you.

The procure-to-pay flow has roughly nine steps in most organizations: requisition, approval of the requisition, purchase order creation, goods or services receipt, invoice capture, three-way match, exception handling, payment approval, and payment release. Sorted into the three buckets used across this site's automation posts:

Six of the nine steps are rules or bounded judgement. Automate them. The three marked as controls are where the flow exists to prevent something, and the last column says what the automation must leave intact for the control to survive.

Key Takeaway: Nine steps, six automatable outright, three that are controls. The design work is almost entirely about the three.

Scoping a procurement automation and unsure which steps are controls? Our Low-Code & RPA practice maps the flow and the authority behind it first. Book a free consultation.

Why are approvals different from other steps?

Because an approval is not work being done. It is authority being exercised, and authority has rules that predate the automation and outlast it.

Three things are true of every approval step in procurement and of almost no other step:

• It is assigned to a person by a delegation of authority. Someone at a stated level can commit the organization to a stated amount. That assignment is a governance decision, usually approved by a board or an executive committee, and a workflow tool does not have the standing to change it.
• It is separated from adjacent steps on purpose. The person who asks for the purchase is not the person who approves it, who is not the person who confirms receipt, who is not the person who releases payment. Segregation of duties is the control that makes collusion necessary for fraud, and collusion is harder than acting alone.
• It leaves evidence. An approval is a recorded act by an identifiable person at a time. That record is what an auditor reconstructs the transaction from.

Automation threatens all three at once. A bot that approves within a threshold has been given authority nobody delegated to it. A bot that runs under a manager's credentials to speed things up has collapsed two roles into one identity. A bot whose actions are logged as "system" has removed the person from the evidence.

The ACFE's 2026 Report to the Nations, covering 2,402 occupational fraud cases across 143 countries, found that the median scheme runs for 12 months before it is detected, and that duration drives loss: schemes caught inside six months carry a median loss of $40,000 while those running beyond five years exceed $1.1 million.^[1] The same report associates management review and proactive data monitoring with better outcomes. A procurement flow that has automated its approvals without redesigning them has removed management review from the exact steps where it mattered, and given a scheme its first twelve quiet months.

Most automation projects treat the approval matrix as configuration data to be loaded into the tool. It is a governance document, and if the automation changes who can approve what, the governance document has to change first, with the same sign-off it originally had. ID Business Analysis Canada redesigns the delegation of authority matrix and the segregation-of-duties map as deliverables of every procurement automation engagement, with a process analyst producing the revised matrix, the identity model for every bot and AI step, and the evidence each control leaves, before any approval step is touched.

Key Takeaway: An approval is authority, not work. Redesign the authority with the same governance that created it, then automate around it.

What are the best practices for implementing AI in procurement?

Six, and they are controls to satisfy rather than tips to follow. Each one is either in place or it is not.

• Redesign the approval matrix before automating any approval. Decide, at the governance level, which approvals a rule may make within a threshold, which stay with a person, and what the new thresholds are. Get the same sign-off the original matrix had. Then configure the tool to match.
• Give every bot and AI step its own identity. No bot runs under a person's credentials. Every action is attributable to a named automated identity with defined permissions, so segregation of duties holds across human and machine actors alike.
• Keep the three roles separate across identities. Requester, approver, and payer remain distinct whether human or automated. A bot that creates the PO does not release the payment. Design the identity model so the separation is structural, not procedural.
• Put a confidence threshold under every AI step, with a person below it. Invoice extraction and vendor matching are bounded judgement. Below the threshold, a person decides. The threshold is set by finance, versioned, and reviewed against actual error rates quarterly.
• Count and review exceptions. Every case that falls off the automated path is logged, categorized, and reviewed on a schedule by someone other than whoever cleared it. Exceptions cleared quietly are where manipulated invoices go.
• Monitor the flow, not only the transactions. Duplicate vendors, split purchases under thresholds, invoices arriving just below the tolerance, approvals clustered at 4:55 on Fridays. Proactive data monitoring is the control the automation makes possible and most implementations skip.

Robotic process automation in procurement handles the rules-based steps well and is the wrong tool for any of the six above. They are design decisions and governance acts. The tool implements them; it does not make them.

Key Takeaway: Six controls, each in place or not. The automation implements them. Governance decides them.

How does this fit a wider process automation strategy?

As the pattern for every process that contains a control, which is more of them than the automation backlog assumes.

A business process automation strategy that sorts every candidate into rules, bounded judgement, and open judgement, as the workflow automation post on this site described, needs a fourth category for procurement and for any process touching money, access, or compliance: controls. A control is a step whose purpose is to prevent rather than to produce, and it is automated differently. The work is not automated. The routing to the right person and the evidence of their decision are.

Two questions identify a control in any flow. Does this step exist so that one person cannot do the next step alone? Does an auditor reconstruct anything from this step's record? If either answer is yes, the step belongs in the fourth bucket, and the approval matrix redesign applies to it.

Manufacturing organizations tend to find the most of these, because procurement, receiving, and inventory are large and physically distributed, and the receipt control in particular is often a person on a dock rather than a system event. Public sector organizations find the strictest versions, because delegation of authority is frequently set in regulation. In both, the automation strategy that works is the one that identified the controls before the vendor did.

Key Takeaway: Add controls as a fourth bucket to the automation strategy. Two questions find them. The approval matrix redesign applies to every one.

Frequently Asked Questions

Can RPA approve purchase orders or invoices?It can be configured to, and it should not be, unless the delegation of authority has been formally revised to grant that specific rule-based approval within a defined threshold, with governance sign-off. Without that revision, the bot is exercising authority nobody delegated, and the approval will not stand up at audit. With it, the rule approves inside the threshold and a person approves above it, under separate identities, with both logged.

How do we start automating procurement without breaking segregation of duties?Map the current procure-to-pay flow with the person or role at each step and the authority they hold, then mark every step that exists to prevent something rather than to produce something. Those are the controls, and they get redesigned at the governance level before any tool is configured. ID Business Analysis Canada does this as the first phase of a procurement automation engagement, with a process analyst producing the workflow map with control points marked, the revised delegation of authority matrix, and the identity model for every human and automated actor, so the automation is configured against a control design that has already been approved. Tool configuration follows, and it is usually the shorter part.

Is AI in procurement the same as e-procurement?No. E-procurement is the digitization of the purchasing process: catalogues, electronic requisitions, electronic POs and invoices. Most organizations have had it for years. AI in procurement adds steps that need interpretation: extracting fields from invoices in any format, matching vendor names across systems, flagging anomalies in spend. AI steps sit inside an e-procurement flow and are governed by a confidence threshold with a person below it. Neither replaces the approval controls; both route work to them.

What should be monitored after procurement automation goes live?Two layers. Transaction-level: exception rate and category, threshold override rate, approvals per approver per period, and the time approvals wait. Pattern-level: duplicate or near-duplicate vendors, purchases split just under approval thresholds, invoices clustering just below match tolerance, and approvals concentrated at unusual times. The second layer is what the ACFE calls proactive data monitoring, and it is the control automation makes possible that most implementations never switch on.

Conclusion

The business case counted the hours. It did not count the controls. Six of the nine steps in procure-to-pay are work, and automating them is straightforward. Three are authority, and automating them without redesigning the authority behind them removes the control while keeping the appearance of one.

If you are planning procurement automation and the approval matrix is currently a configuration file rather than a governance document, ID Business Analysis Canada's Low-Code & RPA practice produces the workflow map with control points marked, the redesigned delegation of authority matrix, and the identity model for every actor, before a single approval step is automated. Book a free consultation and bring the current matrix.

Sources

1. Association of Certified Fraud Examiners, Occupational Fraud 2026: A Report to the Nations, key findings and press release, 2026.
2. Business Analysis Canada, Before the Bot: AI Workflow Automation and the Analysis It Depends On, business-analysis.ca blog, September 2026.
3. Business Analysis Canada, First Principles: What Is Robotic Process Automation, and What Should It Touch?, business-analysis.ca blog, September 2026.