Home · Solutions · Procurement
Solution · ProcurementRequested in Teams, approved in Teams, created in SAP by a robot, visible to everyone
Purchase requests and PO approvals no longer lost in email
Employees request in Teams, budget owners decide in the Approvals app with reminders and deputies built in, and a robot creates the SAP purchase order and returns its number.
Executive summary
Purchase requests get lost between mailboxes, approvers and buyers. Stop retyping approved requests into the ERP.
The user journey never leaves Microsoft Teams.
Request-to-PO time shrinks to the approver's decision time, modelled at one to two working days instead of five to nine.
SAP S/4HANA (purchase orders via BAPI); SharePoint request register (Microsoft Lists)
Business problem
Purchase-to-pay
A purchase request exists so that someone with budget responsibility says yes before money is committed. The rule is sound; the tooling rarely is. The request is an Excel form, the approval a reply in Outlook, and a buyer types the purchase order into the ERP. Between planner and PO number the request changes hands four to six times, always by email.
Requesters wait and call the buyer. Approvers get requests between meeting invitations, without knowing the budget left. Buyers chase decisions in the morning and retype them in the afternoon. Finance sees the commitment when the invoice lands.
At scale the cracks widen: three plants read the limits three ways, holiday deputies are agreed by chat, and "who approved this, when and within which limit" is answered by a mailbox search. Urgent parts are ordered by phone, and the purchase order created after delivery is one accounts payable cannot match.
How it works today
- PersonThe requester fills in an Excel request form, attaches a quote and emails it to the cost centre owner
- WaitingThe request sits in the approver's inbox for days; above the manager's limit it is forwarded to the plant manager and waits again
- PersonThe approver replies "OK" or asks a question; the answer starts a new thread and the attachment gets lost
- PersonThe buyer collects approved emails in a folder and retypes each into SAP ME21N
- Risk of errorRequests approved above a limit or by an unappointed deputy surface when the invoice arrives, if at all
- WaitingThe requester asks for the PO number by chat; urgent parts are ordered by phone and the PO is created afterwards
Why the current process costs more than it appears
The most expensive part of this process has no cost line.
- Retyping is the visible waste; chasing is the larger one. A buyer handling fifty requests a week spends part of every day chasing approvers, unrecorded.
- Late purchase orders become late deliveries: a gearbox approved on Thursday instead of Monday is a line stopped over the weekend or an express freight surcharge.
- Commitments stay invisible to finance until the invoice, so the monthly cost review looks at what was spent, not at what was promised.
- Approval limits live in a signed policy, but a mailbox does not enforce them; breaches are found by the auditor's sample, and phone orders produce after-the-fact purchase orders that fail the match.
Cost of inaction
Buyers keep chasing, plants keep paying express freight for parts approved too late, and after-the-fact purchase orders keep landing in accounts payable. The next growth step is answered with a seventh buyer, who inherits the same folder.
The exposure that grows quietly is control. The policy exists as intent; the actual control is whoever reads the thread. A request approved above a limit by the wrong person goes unnoticed until the auditor's sample, and the remediation costs more management time than the flow would have.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A packaging manufacturer with three plants in Central Europe, 900 employees, SAP S/4HANA, Microsoft 365 E3, and six buyers in central procurement.
1,100 purchase requests a month: about 70% spare parts, consumables and services below the departmental threshold, 25% above it with a second approval level, 5% capital items out of scope; a third concern catalogue items under contract.
An Excel form travels by email, approvals come back as replies, buyers retype approved requests into ME21N, and one buyer keeps an Excel list of open requests.
Around eighteen minutes of handling and chasing per request across requester, approver and buyer; five to nine working days from request to PO number; in the modelled case a fifth of purchase orders are created after the goods were ordered.
A request form in Teams fed with SAP master data; the approval matrix executed by Power Automate approvals in the Teams Approvals app with sequential levels, deputies and escalation; a UiPath robot that creates the purchase order in SAP and returns the number; a request register as a Teams tab.
In the modelled case request-to-PO time falls to the approver's decision time, typically one to two working days; retyping disappears and the buyers' time goes into sourcing. The numbers describe a model, not a delivered project.
Proposed solution
The user journey never leaves Microsoft Teams. The requester opens the request app in a Teams tab (a Power Apps canvas app, or Microsoft Forms for simple requests), picks cost centre, item, quantity, needed-by date and supplier, attaches the quote and submits. The request gets a number and a status in the register, a SharePoint list shown in the same tab.
A Power Automate cloud flow reads the approval matrix, a small table owned by finance: cost centre to owner, threshold to second level, deputy per approver. It creates the approvals in sequence: the cost centre owner first, the plant manager above the threshold. Approvers see the request in the Teams Approvals app and in an Outlook actionable message, with attachment, amount, budget line and four responses: approve, reject, send back with a question, route to procurement. If nobody responds in time, the flow reminds and then hands the request to the deputy; an approver can also reassign it. Every decision is stored in Dataverse and written to the Microsoft Purview audit log.
Approved requests go to UiPath: the flow adds a queue item through the UiPath connector for Microsoft Power Platform (Preview, premium tier), or the robot collects approved items from the register through UiPath Integration Service, which keeps the flow on standard connectors. The robot checks vendor, item, cost centre and price against SAP master data, creates the purchase order through SAP's standard BAPI, writes PO number and approver to the register and messages the requester in Teams. SAP rejections go to the buyer. The stack is deliberately small: no document AI, no agent, no new portal; the tenant you already pay for, one unattended robot and Orchestrator.
Microsoft Teams Approvals app (attachments, reassignment, Purview audit); Power Automate approvals (sequential, custom responses, Teams and Outlook) and timers; Power Apps and Microsoft Forms in a Teams tab; Microsoft Lists as a Teams tab; UiPath Orchestrator queues, triggers and audit; UiPath Integration Service SAP BAPI and Microsoft OneDrive & SharePoint connectors; UiPath connector for Microsoft Power Platform (Preview)
The request app and its SAP reference lists, the approval-matrix flow with thresholds, deputies, reminders and escalation, the register and its views, the PO-creation robot with validation and error handling, notifications, spend views, the runbook
SAP S/4HANA purchase-order creation and master-data lookups through UiPath SAP activities (BAPI, or SAP GUI where your SAP team prefers it); nightly master-data extract
How the automated process works
- PersonThe requester opens the request app in Teams, picks cost centre, item, quantity, date and supplier, attaches the quote and submits
- AutomationThe flow numbers the request in the register, reads the approval matrix and creates the first approval with amount, budget line and attachment
- PersonThe cost centre owner approves, rejects or sends the request back in the Teams Approvals app; above the threshold the second approver follows
- AutomationIf an approver has not responded within the agreed time, the flow reminds and then moves the request to the named deputy
- SystemThe robot takes the approved request from the Orchestrator queue, checks vendor, item, cost centre and price against SAP master data, creates the purchase order through the standard BAPI and writes PO number, approver and timestamp back to the register
- AutomationThe requester gets a Teams message with the PO number; the buyer sees only SAP rejections and procurement routings; the tab shows the rest by status
Human-in-the-loop model
Automation handles
- Numbering, routing and the approval sequence from the matrix
- Reminders, deputy hand-over and the audit record of every decision
- SAP master-data checks, purchase-order creation and status updates in Teams
People decide
- Whether to buy: the cost centre owner and, above the threshold, the second approver, in Teams
- Requests routed to procurement or rejected by SAP: non-catalogue items above a limit, new suppliers, master-data errors
- The matrix itself: thresholds, owners and deputies stay with finance and procurement
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- Power Apps request form in Teams (or Microsoft Forms)
- quote attachments
- SAP master data
Automation layer
- Power Automate cloud flows
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service (SAP BAPI, OneDrive & SharePoint)
Target systems
- SAP S/4HANA (purchase orders via BAPI)
- SharePoint request register (Microsoft Lists)
Human touchpoints: Microsoft Teams Approvals app; Outlook actionable messages; requester chat messages; request status tab in Teams
Technologies used
the whole user experience: request, decision, register, status
Aapproval matrix, sequential levels, custom responses, reminders, escalation
Athe request form with cost centre, catalogue and supplier lists
Acreate the purchase order in SAP through the BAPI; queue, retries, credentials, audit; list-item trigger as the licence-neutral hand-off
Adirect hand-off from the flow to Orchestrator; premium tier
Asystem of record for purchase orders and master data
AIllustrative economic model
The arithmetic is open, so it can be argued with.
Eighteen minutes per request is what the three roles add up to in the mid-sized manufacturers we work with, quoted as an illustrative range and not as a client measurement: about five for the requester, four for the approver, nine for the buyer to chase, check, retype in ME21N and answer questions. €28 an hour is a blended fully loaded cost for buyers, planners and managers in Central Europe. We show time released, not headcount removed.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Request-to-PO time shrinks to the approver's decision time, modelled at one to two working days instead of five to nine
- Buyers stop retyping; their time goes into sourcing and supplier performance
- Approval limits, deputies and second-level rules are applied by the flow every time
- Requesters see status and PO number in Teams without asking; committed spend is visible per cost centre at approval
The management view
- One register with every request, approver, timestamp and PO number, filterable in Teams, ready for the auditor
- Approval discipline that survives holidays and reorganisations, because the matrix is a table
- Commitments known before invoices: the cost review looks at approved spend, not only booked spend
Board-level KPIs
Security and governance
An auditor should be able to reconstruct every decision.
- The robot uses a dedicated SAP account limited to purchasing; its credentials sit in the Orchestrator credential store (Azure Key Vault where you have it), never with a person
- Approvals are stored in Dataverse and audited in Microsoft Purview: who approved, when, after which reassignment
- Approver identities come from Microsoft Entra ID; the matrix has an owner in finance, a threshold change is itself an approval, nobody approves their own request, the robot approves nothing
- Nothing here is reachable from outside your directory: requests, attachments and the register sit in your Microsoft 365 tenant under the EU Data Boundary, Orchestrator on an EU-region tenant of UiPath Automation Cloud; no AI model is involved
Why now
Running approvals by email costs the modelled €9,240 a month in time alone, before express freight and after-the-fact purchase orders
With mandatory e‑invoicing in Poland (KSeF), invoices arrive as structured data; automatic matching only pays off when a purchase order exists before the invoice, which this flow guarantees
The Approvals app, Power Automate approvals and the UiPath hand-off (Power Platform connector in Preview, or Integration Service triggers) leave the SAP posting logic as the only coded piece
Relevant executive roles
Commitments become visible at approval rather than at the invoice, and the approval policy is enforced, not assumed
Buyers stop retyping and chasing, and the register shows every open request and who is sitting on it
Parts are ordered when the plant needs them, and the PO number reaches the planner in Teams, not on the invoice
Common questions and objections
Keep it. The decision is taken once, in Teams; the robot then performs the release step in SAP with its own release code and writes the approver's name and timestamp into the purchase order. SAP stays the system of record, Teams becomes its front end.
A request in the Approvals app cannot be buried under a thread; it carries the attachment and the budget line and escalates by itself when the agreed time passes. Approvers see their pending queue; procurement sees every escalation in the register.
Not for the form, the approvals or the register, which run on the rights included with Microsoft 365. The UiPath connector for Microsoft Power Platform is premium and in Preview; without it, the robot collects approved requests from the register through UiPath Integration Service and the flow stays on standard connectors.
When this is not the right solution
- Requesters already work in SAP (ME51N or Ariba Guided Buying) with a working release workflow; the issue is adoption, not a missing front end
- Fewer than a couple of hundred requests a month in one location, where an Approvals template without the robot is enough
- The approval policy is unsettled: thresholds, owners and deputies must be decided first
A question for the next management meeting
Who can tell us, without a mailbox search, which requests are waiting for whom, and how many days pass between a request and its purchase order in our plants?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- Discovery of request types, thresholds, approval matrix and deputies
- The request app in Teams with its SAP reference lists, and the approval flow: sequential levels, custom responses, reminders, deputy escalation, audit trail
- The PO-creation robot with validation, SAP error handling and the PO number returned to Teams
- The register with status and spend views, a pilot in one plant, then rollout with hypercare and a runbook
We need from you
- The signed approval policy: thresholds, cost centre owners, deputies
- A process owner in procurement and one cost centre owner willing to pilot
- SAP accounts for the robot, the master-data extract, and a Microsoft 365 administrator
Stages
Discovery
Request types, volumes, approval matrix, deputies and exceptions
Design
Form, register, thresholds, escalation times, hand-off to UiPath, SAP validation rules
Build and validation
Request app, approval flow, robot and SAP integration; replay of last quarter's requests, timers and deputies exercised, user acceptance
Go-live
One plant first, buyers supervising the robot's purchase orders, then the others
Quick win. Effort depends on the number of approval levels, the state of the SAP master data behind the form, and whether SAP purchase orders carry a release strategy that must be kept.
Purchase requests live in inboxes until a buyer retypes them into SAP.
Send us your approval policy and one month of requests from one plant: count, values, approvers. We come back with a draft approval matrix in Teams and the cycle times it should produce.
Map your approval matrix with usThe neighbouring process usually has the same problem
Stop paying your finance team to move numbers from PDFs into the ERP.
View solution Finance & accountingThree-way match exceptions resolved before the payment runStop chasing price and quantity differences by email while supplier payments wait for weeks.
View solution ProcurementP2P process mining: maverick spend and real touchless rateNobody knows what share of purchases bypass contracts and POs, or how often an invoice is touched. Measure it monthly.
View solutionIndustries we deliver this in most oftenManufacturing & industryServices & IT