Purchase Requisitions: Automating a Bottleneck or the Wrong Work
A manufacturer processes 2,400 purchase requisitions a month. Requisitions under EUR 500 make up 31% of volume but follow the same six-level approval route as EUR 50,000 orders. Average end-to-end time is 9 working days; 18% of requisitions are rejected, most often because the cost center is wrong or the budget code is missing. Approvers act in a workflow tool, but the finance ERP and the supplier portal are not integrated, so clerks re-key data. A vendor proposes an RPA robot that will copy data between the three systems and eliminate the approval bottleneck. The CFO wants faster cycle time and fewer clerks. Internal audit is concerned about segregation of duties, robot credentials, and what happens when the ERP screen changes. The process owner has no inventory of exceptions, and the IT team supports only two RPA releases a year.
1. Evaluate the vendor's RPA proposal. Which parts of the requisition process are suitable for automation, and which are not? Justify with process characteristics.
Read the worked answer
RPA is suitable for high-volume, deterministic, rule-based steps with stable interfaces, such as copying validated data between the ERP, workflow tool and supplier portal. It is not suitable for judgement-based approval, budget-priority decisions, or resolving ambiguous master-data errors. The proposal to eliminate the approval bottleneck with RPA is therefore misdirected: the bottleneck is largely caused by a six-level route for low-value requisitions and by master-data errors, not by a lack of screen scraping. Automating the current six-level route would make the wrong control faster. The first move should be to redesign the approval tiers and validate cost center and budget code at submission. RPA may then handle the remaining rekeying, but only where an API or workflow integration is not available. The fragile interface risk is real: ERP screen changes can break robots, and IT supports only two releases a year. A robot that copies bad data faster does not improve first-time-right; it may increase the 18% rejection rate if validation is not fixed upstream. The business case should compare RPA with workflow and ERP integration, not assume RPA is the only option.
2. Design a to-be approval workflow that reduces cycle time while preserving control. Specify routing, human tasks, and exception handling.
Read the worked answer
The to-be workflow should start with guided submission that validates cost center, budget code, supplier status and required attachments against master data. Invalid submissions should be returned immediately, before routing. Approval should be risk-based: for example, under EUR 500 auto-approve if budget and supplier checks pass; EUR 500 to EUR 10,000 require one budget owner; above EUR 10,000 require two approvers, with additional approval for high-risk categories or new suppliers. Independent approvals can run in parallel rather than sequentially. A timer should escalate an approval that is idle beyond its service target, and a delegate should be named in advance. Human tasks should be reserved for exceptions, high-value decisions and supplier disputes. An exception desk should handle master-data errors with a clear reason code and a target resolution time. Segregation of duties must be enforced in the workflow, not left to the robot. The workflow should record who approved what, when, with which evidence. The design should also define what happens when the ERP is unavailable, so the process does not depend on a single interface. The aim is fewer approvals for low-risk spend, not fewer controls where risk is real.
3. Internal audit asks for controls over the robot and the workflow. List four controls and explain the risk each addresses.
Read the worked answer
First, use a unique robot identity with least-privilege access and include it in regular access reviews. This addresses the risk that a shared or over-privileged account could change or approve transactions without accountability. Second, enforce segregation of duties in the workflow and test that the robot cannot approve its own transactions or alter approval limits. This addresses the risk that automation collapses the maker-checker control. Third, apply change management to robot scripts and ERP interfaces, with regression testing before release and monitoring for screen or field changes. This addresses the risk of silent failures, duplicate postings or data corruption when the ERP changes. Fourth, maintain an immutable audit log and perform periodic reconciliation between requisitions, approvals, purchase orders and payments. This addresses the risk that exceptions or duplicate payments are not detected. A fifth control would be a business continuity plan for robot failure, including a manual fallback and an exception queue, so that invoices or requisitions do not accumulate without control. Audit should also see an exception inventory with reason codes, because the process owner currently has none. Without that inventory, the organization cannot distinguish robot errors from upstream master-data errors.