Home · Solutions · Other solutions
Solution · Other solutionsA request with the budget attached, and an SAP purchase order before the day ends
Requests raised in Teams, approved and ordered the same day
Requests are raised on a Teams card, checked against SAP budget and vendor data, approved under your own authority matrix and turned into a purchase order by a robot.
Executive summary
The compliant route is slower than a chat message, so people order first and paper it later.
We replace the mailbox and the spreadsheet with a request that lives in one place from its first minute.
Catalogue requests reach a purchase order on the day they are approved, because validation.
SAP S/4HANA for requisitions, purchase orders, budget and vendor master; the SharePoint request archive; Microsoft Power BI
Business problem
Procurement
The formal process exists on paper: an authority matrix, a request form, a rule that nothing is ordered without a purchase order. What breaks is the distance between that rule and the tools people have. The form is an Excel file attached to an email. Budget availability is a question to the controller, answered the next day. The chain depends on amount, category and cost centre, so a specialist works it out by hand and chases each approver in turn.
Approvers receive a bare attachment and decide without context. They cannot see what is left on the cost centre, whether the supplier is under contract, or what the same item cost last time. So they approve on trust, or send the request back with a question that starts a new thread and loses the attachment.
The problem survives because every participant has a rational workaround. Managers approve in chat because chat is where they are. Requesters order by phone because the site needs the part on Friday. Procurement raises the purchase order retrospectively because otherwise the invoice cannot be paid. At scale the three copies of one request, in a mailbox, in a spreadsheet and in the ERP, stop agreeing, nobody answers "where is my request" without asking procurement, and commitments become visible only when the invoice lands.
How it works today
This is the shape we find in most groups that have an authority matrix and no system to run it.
- PersonAn engineer asks the line manager for an informal go-ahead in Teams, then fills in the Excel request form
- PersonThe form goes to the procurement mailbox; procurement asks for the missing cost centre, supplier and delivery date
- WaitingThe controller is asked whether budget is available and answers when the day allows, usually the next one
- PersonThe approval chain is worked out by hand from the matrix and collected level by level over email
- WaitingSilent approvers are chased; a request sits for a week because one manager is on a site visit
- SystemRequisition and purchase order are re-keyed into SAP, and the requester is not told the number
- Risk of errorThe invoice arrives with no purchase order to match, so a retrospective one is created to release payment
Why the current process costs more than it appears
Time that disappears before anyone measures it.
- Managers spend part of every approval reconstructing what the request should have carried: the remaining budget, the supplier's contract status, what was agreed last time. That work is unrecorded and repeated 1,650 times a month across 190 approvers.
- Waiting turns a control into paperwork. A requester who learns the official route takes a week orders by phone and files the form afterwards, so the control runs after the money is committed.
- Accounts payable inherits the consequence: every invoice without a purchase order is a small investigation into who ordered this, on whose authority, and whether it may be paid.
- Committed spend stays invisible until invoices arrive, so the forecast runs a month behind and budget owners overspend without knowing it.
- Negotiated prices quietly lose their value, because ordering from whoever answers the phone beats ordering from the supplier with the agreement.
Cost of inaction
Volume here follows activity rather than headcount, which is why the arithmetic worsens on its own. A group that grows a tenth raises a tenth more forms and re-keys a tenth more requests, while the shared-service centre stays the size the budget allows. The queue lengthens, requesters learn again that the official route is slow, and the share of orders placed outside it rises.
Each of those orders arrives later as an invoice with nothing to match and as a commitment nobody forecast. None of it appears as a budget line: it shows up as overspend explained after the fact, a month-end closed on estimates, and an audit finding about approvals that live only in chat threads.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A facilities-management and building-services group of 1,400 employees, working in six European countries on SAP S/4HANA, with Microsoft Teams as the daily tool and Power BI for reporting.
About 1,650 purchase requisitions a month, most below €5,000. Nine procurement specialists handle intake in a shared-service centre; 190 managers hold approval authority under a four-level matrix; roughly a third of invoices arrive with no purchase order.
Requests arrive as Excel forms in a shared mailbox and as Teams messages. The controller confirms budget on request, the chain is assembled by hand, approvals are collected by email, and requisition and purchase order are typed into SAP by a specialist.
Around 24 minutes of requester and procurement handling per requisition, across the form, the missing data, the budget question, the chasing, the re-keying and the status enquiries, plus about 7 minutes of approver time reconstructing context that was never sent.
The request is raised on an Adaptive Card in Teams, validated against SAP by a robot, routed by rules from the authority matrix, approved in the Teams Approvals app with the budget position on the card, and turned into an SAP requisition and purchase order.
In the modelled case, catalogue requests reach a purchase order on the day they are approved, the retrospective purchase order becomes an exception rather than a habit, and committed spend appears in Power BI weeks before the invoice. Every figure here is a model on stated assumptions.
Proposed solution
We replace the mailbox and the spreadsheet with a request that lives in one place from its first minute. An employee raises it in Microsoft Teams on an Adaptive Card served by the Workflows app: catalogue item or free text, cost centre, quantity, needed-by date, supplier if known, justification. Nothing on the card asks the requester to know the approval rules.
A UiPath robot validates the request against SAP before anyone is asked to decide anything: the cost centre exists and is open, the supplier is active and preferred where an agreement exists, budget is available on the line the request will charge. The result goes onto the approval card, so the approver sees a budget position and a supplier status instead of an attachment. Rules from your own authority matrix, held in a SharePoint list owned by procurement, then build the chain: which level, in which order, with which delegate when somebody is away.
Approvers decide in the Teams Approvals app, and every decision is recorded in Microsoft Purview under their own identity. Once the chain is complete, the robot creates the requisition and the purchase order in SAP through the standard BAPI interface, sends the order to the supplier and returns the number to the requester in Teams. UiPath Data Fabric holds the state of every request, so status is a fact rather than an enquiry, and Power BI reads that state for cycle time, pending approvals and committed spend. The stack is small and deterministic on purpose: no document model, no agent, no new portal, because once the authority matrix is written down, routing is arithmetic. Requests that genuinely need judgement reach a procurement specialist with the validation already done, which is the opposite of today.
Microsoft Teams Approvals app with attachments, reassignment and Purview audit; Adaptive Cards served by the Workflows app in Microsoft Teams (Power Automate); UiPath Orchestrator queues, triggers, credential store and job audit; UiPath Data Fabric entities; UiPath Integration Service SAP BAPI and OData connectors
The request card and its validation, the authority-matrix rule set and the SharePoint list behind it, the SAP validation and posting robots with their error handling, the exception route to procurement, notifications and reminders, the Power BI committed-spend report, the procurement runbook
SAP S/4HANA requisition and purchase-order creation plus budget, cost-centre and vendor reads through UiPath SAP activities (BAPI and OData); hand-off from the Teams card to an Orchestrator queue through the Orchestrator API, or the UiPath connector for Microsoft Power Platform where a Preview, premium-tier component is acceptable
How the automated process works
- PersonThe requester raises the request on a Teams card: item or free text, cost centre, quantity, needed-by date, justification
- AutomationA robot validates cost centre, supplier status and budget position in SAP and writes the request to UiPath Data Fabric
- SystemRules read from the authority matrix build the approval chain, with thresholds, categories and standing delegates
- PersonEach approver decides in the Teams Approvals app with the budget line on the card; reminders and escalation run on a timer
- PersonNon-catalogue items, unknown suppliers and over-budget lines reach a specialist with validation already complete
- AutomationThe robot creates the requisition and purchase order in SAP, sends the order to the supplier and returns the number in Teams
- AutomationCycle time, pending approvals per approver and committed spend appear in Power BI on the day of approval
Human-in-the-loop model
Automation handles
- Validation of cost centre, supplier status and budget availability against SAP
- Assembly of the approval chain from the matrix, including thresholds and delegates
- Approval cards with context, reminders, escalation and reassignment
- Requisition and purchase-order creation in SAP, order dispatch, requester notification
- The audit record and the reporting layer
People decide
- Every approval and rejection, at every level of the matrix
- Sourcing for non-catalogue items and for suppliers the group has not used before
- Over-budget requests and anything that conflicts with a policy
- Changes to the matrix, thresholds and catalogue, which stay owned by procurement and finance
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- the request card in Microsoft Teams
- the procurement shared mailbox in Exchange Online for requests still arriving by email
- the catalogue and authority matrix on SharePoint
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Data Fabric
Target systems
- SAP S/4HANA for requisitions, purchase orders, budget and vendor master
- the SharePoint request archive
- Microsoft Power BI
Human touchpoints: the Microsoft Teams Approvals app; the procurement exception queue in Teams; requester status messages
Technologies used
every approval decision, with the budget position and supplier status on the card
Athe request form, status messages and reminders
Avalidation and posting jobs, queues, retries, credential store, audited job log
Abudget, cost-centre and vendor reads; requisition and order creation
Athe state of every request from intake to purchase-order number
Athe authority matrix, catalogue reference data and the request archive
Acycle time, pending approvals per approver, committed spend at approval
Athresholds, cost-centre owners, delegates and category routing, from your own policy
CIllustrative economic model
The arithmetic is open, so it can be argued with.
Only the automatable part of the handling is priced, so the calculator volume is the 0.65 share of 1,650 requisitions rather than the whole queue, at 24 minutes each and €36 an hour fully loaded. Approver time sits outside it on purpose: 1,650 requests × 7 minutes, half avoidable, is 96 hours a month at €74, some €85,200 a year, bringing the combined pool to about €270,600. Nothing here was measured at a client.
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
- Catalogue requests reach a purchase order on the day they are approved, because validation, routing and SAP entry no longer wait for an email to be opened
- Approvers decide better: the card carries the budget position and the supplier's contract status instead of asking them to remember both
- Invoices without a purchase order become rare, so accounts payable matches first time and stops running small investigations
- Committed spend appears in Power BI at approval rather than at invoice, moving the forecast from reconstruction to reading
- Negotiated prices hold, because the catalogue route is now the fastest one rather than the slowest
- Volume growth is absorbed by rules, not by adding specialists to the shared-service centre
The management view
- Requests become a measurable queue by status, age, cost centre, category and approver, with an SLA that can be reported rather than assumed
- Pending approvals are visible by person, so a director sees which manager holds the queue up and for how long
- The authority matrix stops being a signed document and becomes a maintained rule set with a change history
- When an auditor asks who approved a purchase and against which limit, the answer is a record with a timestamp, not a search through chats
Board-level KPIs
Security and governance
The automation holds exactly the rights it needs, and not one more.
- The robot signs in to SAP as a dedicated service user that may read master data and create requisitions and purchase orders, and may not approve, release or pay anything
- Approvals happen only in the Teams Approvals app under the approver's own Microsoft Entra ID identity, so requester, approver and creator are separated by design and each decision carries a name and timestamp in the Microsoft Purview audit log
- Secrets for the SAP and SharePoint accounts stay in the Orchestrator credential store, or in Azure Key Vault where you already run one, never inside a workflow
- The rule set is versioned and changed only by procurement, with a review record: an authority matrix anyone can edit is not a control
- Automation runs in the EU region of UiPath Automation Cloud and the request data stays inside the Microsoft 365 EU Data Boundary
Why now
Approvals, Adaptive Cards and the Workflows app already sit inside the Microsoft 365 tenant the group pays for, so the approval layer needs no new licence, no new portal and no new password for 190 managers
Finance is being asked for committed spend rather than invoiced spend, and a commitment that exists only in a chat thread cannot be reported; at the modelled numbers the handling alone is about €15,400 a month
An S/4HANA programme is the natural moment to fix what happens before the ERP; the alternative is rebuilding the same mailbox habit around a new system
Relevant executive roles
Commitments become visible at approval instead of at invoice, and no-PO invoices stop being an accepted cost of doing business
Specialists stop re-keying and start sourcing; the authority matrix is enforced by a system rather than by memory
Sites get what they ordered faster, which removes the operational reason for working around the process
Approval evidence is a record with an identity and a timestamp, not a screenshot somebody kept
Common questions and objections
It works from the moment the requisition exists, and everything expensive happens earlier. We fix intake, budget check and routing, then feed the release strategy where you keep it.
The Approvals app is inside Teams, where they already spend the day, and the card carries the context they currently have to ask for. It is fewer clicks than the email thread it replaces.
Correct, and we do not try. They route straight to a specialist with the cost-centre, budget and supplier checks already done. The gain comes from the catalogue share, which grows as recurring items are added.
When this is not the right solution
- A few dozen requests a month handled well by one person; process design and a shared list get you most of the benefit for a fraction of the effort
- A source-to-pay suite with self-service requisitioning is already licensed and adopted; the gap there is adoption and data, not another workflow
- The authority matrix is contested or does not exist; rules cannot be automated until somebody owns them
A question for the next management meeting
Where does our authority matrix actually get enforced today, and what evidence could we produce for the requests it stopped last month?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- Analysis of one month of real requests, informal paths included, so the rules come from what happens rather than from the policy alone
- The Teams request card, its validation and the status messages the requester receives
- The authority-matrix rule set: levels, thresholds, categories, delegates, escalation timers
- The SAP validation and posting robots, with handling for the rejections SAP will return
- The exception route into procurement, with the validation attached to the case
- The Power BI report on cycle time, pending approvals and committed spend
- A pilot beside the current process, then rollout with hypercare
We need from you
- The current authority matrix and someone empowered to settle rule questions quickly
- One month of requests from the procurement mailbox with the matching SAP documents
- SAP service users for test and production, scoped to requisition and purchase-order creation
- A procurement process owner and a controller for the budget-check logic
Stages
Discovery
One month of real requests against the SAP documents they became, those without a form included
Rules
The authority matrix as a testable rule set: thresholds, delegates, category routing
Build
Request card, validation and posting robots, exception queue, notifications, reporting
Validation
Replay of historical requests, exception handling, acceptance by procurement and approvers
Pilot
One country or category in parallel, with the old path still open
Rollout
Country by country, extending the rule set rather than the code
Departmental. Effort is driven by the number of approval levels and countries, by how budget availability is held in SAP, and by the catalogue share of the request mix.
Seven weeks passed between a manager's yes and the invoice nobody expected.
Send one month of requests from your procurement mailbox with the matching SAP purchase-order numbers. You get back the share that could have been ordered the same day under your own matrix, and the point in the chain where the days are lost.
Count the days from yes to PO numberThe neighbouring process usually has the same problem
Purchase requests get lost between mailboxes, approvers and buyers. Stop retyping approved requests into the ERP.
View solution Other solutionsInvoices read, coded and routed; people see only exceptionsSomebody still types the PDF into the ERP, guesses the cost centre and chases the approver.
View solution Other solutionsPrice and quantity mismatches resolved the day they appearA variance released under payment-run pressure becomes next quarter's price, and nobody negotiated it.
View solutionIndustries we deliver this in most oftenManufacturing & industryServices & IT