Home · Solutions · Other solutions
Solution · Other solutionsA single-use card issued under written rules, and closed when the purpose ends
A virtual card or a limit change within the hour, by rule
Card and limit requests are raised in Teams, checked against your written card policy, issued through the card platform's API and closed automatically on the end date.
Executive summary
Limits go up for an event and never come down, and people pay for company purchases from their own account.
The request begins where the work already happens.
In-policy requests are served within the hour, because the check and the portal work stop waiting for a person who is doing something else.
the bank card platform through its issuing API; the card register; SAP for cost centres
Business problem
Spend management
The card programme has a policy. It says who may hold a card, what limit applies per grade, which merchant categories are blocked. What the policy lacks is a process anyone can find. Requests for a virtual card or a temporary limit arrive as emails to the treasury mailbox, as Teams messages to whoever helped last time, or as a phone call from a corridor.
Treasury then does the same eight things every time: work out who the requester is, guess the cost centre, ask a manager for a nod, sign in to the bank portal, create the card, email the details back, add a line to the tracker, and hope to remember the closing. The requester waits a day or two for a five-minute action, so the fastest route becomes a colleague's card or their own money. Control leaves the card platform and lands in the expense process, which sees the purchase only after it has happened.
The reason nothing changes is size. Each request is small, none justifies a project, and together they belong to nobody. Meanwhile limits go up for an event and stay up, cards issued for one supplier stay live, and the Excel register drifts away from the bank statement one line at a time.
How it works today
- PersonSomeone needs to pay a supplier today and messages treasury, or asks a colleague who holds a card
- PersonTreasury checks who is asking, which cost centre applies and whether the amount looks reasonable
- WaitingA manager is emailed for confirmation and answers between meetings, sometimes the next day
- SystemTreasury signs in to the bank portal and creates the virtual card or raises the limit by hand
- Risk of errorCard details are sent back by email or chat, where payment data then stays in the history
- PersonA line is added to the Excel card tracker, with whatever purpose the requester wrote
- Risk of errorThe limit stays raised and the card stays open until somebody notices, often at the annual review
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Treasury minutes are the smallest part of this. The larger cost is exposure: every limit raised for an event and never lowered is open credit that a phishing email or a careless click can spend.
- Cards issued outside a rule set are policy exceptions nobody approved, invisible until an auditor compares the register with the bank statement and finds two different companies.
- People who pay privately carry the company's cash on their own account for a month, then produce a claim that has to be checked, approved, reimbursed and filed. It exists only because the card was slow.
- Payment details pasted into chat threads are payment data in a collaboration tool, kept as long as the retention policy says and searchable by everyone in the conversation.
- When the specialist who runs the tracker is away, cards are not issued at all, and every week of that grows the workaround economy the policy was written to prevent.
Cost of inaction
Open credit rises here by accumulation rather than by decision. Nobody ever agrees that the company should carry a larger card exposure; it simply grows, one event limit at a time, because raising is a request and lowering is a favour. Card requests follow events, campaigns, freelancers and subscriptions, and all four grow faster than a treasury team does, so the queue lengthens and the private-payment habit spreads with it.
The rows above are the salaried part and the least interesting one. A single phishing incident against a card whose limit was raised for a trade fair and never lowered can cost more than a year of this workflow, while the audit findings repeat themselves: the register does not match the statement, exception approvals are undocumented, cards are not closed. None of it is dramatic on any given day, which is why it survives.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A media and events company with 900 employees in Poland, Germany and Czechia, running a corporate card programme with a bank whose card platform exposes an API for virtual cards and limits. Expenses run through SAP Concur, the ledger is SAP.
Around 380 card requests and limit changes a month, mostly event deposits, advertising accounts, software subscriptions and travel bookings, handled by three treasury staff alongside their other work. About 140 out-of-pocket claims a month are purchases that should have gone on a company card.
Requests arrive by email, chat and phone. Treasury verifies, asks a manager, works in the bank portal, emails the details and updates an Excel register that nobody reconciles.
About 26 minutes of treasury handling per request, plus a wait of a day or two for a five-minute action, and no reliable closing step at all; nobody can say how many virtual cards are open today.
The request is raised in Teams, checked against the written card policy, approved automatically when it fits and by the budget owner when it does not, then issued by a robot through the card platform's API, recorded in a register with an end date, and closed automatically when the purpose ends.
In the modelled case, in-policy requests are served within the hour, every card carries an end date that is enforced rather than remembered, and the register agrees with the bank statement each month. These are modelled figures, not a client result.
Proposed solution
The request begins where the work already happens. An Adaptive Card in Microsoft Teams, served by the Workflows app, asks for purpose, amount, supplier, cost centre, how long the card is needed and whether one use is enough. Rules written from your own card policy check the request against limits by grade, blocked merchant categories, duration caps and the requester's role. Inside the policy, the request is approved on the spot. Outside it, the Teams Approvals app puts it in front of the budget owner, and above a threshold in front of treasury as well, with the reason for the exception on the card.
A UiPath robot then does the portal work. It calls the card platform's issuing API through a connector we build with UiPath Integration Service Connector Builder, creates the single-use card with the approved limit and expiry or applies the temporary limit, and writes the record to the card register in UiPath Data Fabric: purpose, owner, cost centre, limit, end date, approval reference. The requester receives the card in the issuer's own app. Card numbers never travel through Teams or email, and the robot never needs to read them.
The part that today depends on memory becomes a scheduled job. On the end date, or after the single use, the robot closes the card or restores the original limit, tells the owner and updates the register. A monthly extract feeds Power BI and the reconciliation against the bank statement, so open exposure is a number somebody can read. There is no AI anywhere in this: the rules are the policy, written down and versioned.
Adaptive Cards through the Workflows app in Microsoft Teams (Power Automate); Microsoft Teams Approvals app with Purview audit; UiPath Orchestrator queues, time triggers, credential store and job audit; UiPath Data Fabric entities for the card register; UiPath Integration Service Connector Builder
The request card and its validation, the policy rule set with limits, durations, categories and thresholds, the issuing and limit-change robots, the expiry and restore job, the card register model, the reconciliation extract, the Power BI exposure view and the treasury runbook
The card platform's issuing API through a connector built with UiPath Integration Service Connector Builder, scoped to create, set limit and close; cost-centre reads from SAP; the monthly statement extract for reconciliation
How the automated process works
- PersonThe requester fills the card request on an Adaptive Card in Teams: purpose, amount, supplier, cost centre, duration
- AutomationRules check the request against the card policy: limit by grade, merchant category, duration cap, requester role
- PersonOut-of-policy requests go to the budget owner in the Teams Approvals app, and above the threshold to treasury
- AutomationA robot issues the virtual card or applies the temporary limit through the card platform's API
- AutomationThe register is written with purpose, owner, cost centre, limit, end date and the approval reference
- SystemThe requester is notified and collects the card in the issuer's app; no card number passes through Teams
- AutomationOn the end date, or after the single use, the robot closes the card or restores the original limit
- AutomationA monthly extract reconciles the register against the bank statement and feeds the Power BI exposure view
Human-in-the-loop model
Automation handles
- Policy checks on limit, duration, merchant category and requester role
- Approval of requests that sit inside the written policy, with the rule applied recorded
- Issuance, limit changes, closing and limit restoration through the card platform API
- The register, the requester notification and the monthly reconciliation extract
People decide
- Every request the policy does not cover, at budget-owner and treasury level
- Changes to the rules themselves: limits, durations, blocked categories, thresholds
- Revocation where misuse is suspected, at any moment and without a robot
- The exceptions the monthly reconciliation raises
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- the request card in Microsoft Teams
- the treasury shared mailbox in Exchange Online for requests still arriving by email
- the card policy and cost-centre list
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service (Connector Builder)
- UiPath Data Fabric
Target systems
- the bank card platform through its issuing API
- the card register
- SAP for cost centres
- SAP Concur for the expense side
Human touchpoints: the Microsoft Teams Approvals app for exceptions; treasury revocation from the register; the monthly reconciliation review
Technologies used
the request form, the policy answer and status messages
Abudget-owner and treasury decisions on out-of-policy requests, audited in Microsoft Purview
Athe connector to the card platform's issuing API, scoped to create, set limit and close
Aissuance and expiry jobs, queues, retries, credential store and the audited job log
Athe card register: purpose, owner, cost centre, limit, end date, approval reference
Aopen cards, open credit, exceptions by department and the register-to-statement gap
Alimits by grade, duration caps, blocked merchant categories, approval thresholds
CIllustrative economic model
Start by questioning the assumptions.
The arithmetic below is a floor rather than the benefit case, because exposure, fraud losses avoided and employee waiting time are all left out; none of them prices honestly without your own loss history. The calculator counts treasury minutes only, and its volume is the 0.7 automatable share of 380 requests rather than the whole queue, at 26 minutes and €41 an hour fully loaded. Avoided expense claims sit beside it: 140 claims × 14 minutes × 0.6 is about 20 hours a month of accounts-payable work at €33, some €7,900 a year, which takes the combined modelled pool to roughly €64,500. 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
- In-policy requests are served within the hour, because the check and the portal work stop waiting for a person who is doing something else
- Open credit shrinks and stays known, since every card carries an end date and every temporary limit is restored by a job rather than by memory
- Out-of-pocket claims fall, because the company card becomes the fastest way to pay rather than the slowest
- Payment data leaves email and chat entirely: the card is delivered in the issuer's app and the register holds only identifiers
- Exception approvals become evidence, recorded against the request with the rule that was broken and the person who accepted it
- Treasury stops being the human interface between employees and the bank, and can spend the time on cash rather than on card admin
The management view
- Open exposure becomes answerable in a minute: how many cards are live, whose they are, what they may spend and when they expire
- Requests counted by department and purpose show where the policy fits reality and where people are working around it
- The register and the bank statement converge, so the monthly reconciliation turns from an investigation into a check
- Ownership is explicit: treasury owns the rules, budget owners own the exceptions, and the robot does the portal work under both
Board-level KPIs
Security and governance
An auditor should be able to reconstruct every decision.
- Card numbers never leave the issuer's platform. The robot works with a card identifier and the last four digits, and the requester collects the card in the issuer's app
- API credentials sit in the Orchestrator credential store or in Azure Key Vault, scoped to create, set limit and close, with no permission to read full card data
- A requester can never approve their own request, and treasury can revoke any card from the register at any time without waiting for a job
- Every rule change is versioned, and every issuance, limit change and closure is logged in Orchestrator with the approval reference behind it
- Processing runs in the EU region of UiPath Automation Cloud and inside the Microsoft 365 EU Data Boundary; the personal data involved is limited to requester identity and cost centre
Why now
Card platforms that once offered only a portal now expose issuing APIs, which is what makes the request-to-card path automatable; confirm this with your bank first
Auditors increasingly ask for the card register next to the bank statement, and a register kept in Excel cannot answer that question in either direction
The treasury handling alone is about €4,700 a month in the model, and it is the part of the case that matters least; the exposure that accumulates while nothing changes matters more
Relevant executive roles
Card spend becomes rule-based, open exposure is known at any moment, and expense claims for company purchases stop being normal
The team stops doing portal work, the register matches the bank, and every limit has an end date that enforces itself
Small purchases move onto a controlled card path instead of leaving procurement's field of view entirely
Common questions and objections
It does, for the treasury team. The gap is everything around it: the request, the policy check, the approval, the register and the closing. The portal does none of those, so they happen by hand or not at all.
Only requests inside a written policy are approved automatically, with the same limits treasury would apply by hand. Every one is logged with the rule that allowed it, and any card can be revoked in a moment.
Neither do we. Teams carries the request and the approval. The card itself is delivered through the issuer's app and never appears in a chat, which is an improvement on today.
When this is not the right solution
- The card platform offers no issuing API; the portal work would have to be driven through the interface, which is possible but less stable and harder to defend to an auditor
- A spend-management platform with its own request workflow is already licensed and used; the work there is adoption, not a second workflow
- Fewer than a few dozen requests a month, where a written policy and a simple Teams form will already remove most of the waiting
A question for the next management meeting
Would this company notice a virtual card that has outlived its purpose, and if so, in which month and through whose report?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- The card policy turned into a testable rule set, agreed line by line with treasury
- A connector to your card platform's issuing API, built and tested against its sandbox
- The Teams request card, its validation and the exception route into the Approvals app
- The issuing, limit-change and expiry robots, with retries and failure handling
- The card register model, the monthly reconciliation extract and the Power BI exposure view
- A pilot with one department that generates many requests, then extension by rule rather than by code
We need from you
- The card policy in writing, and a treasury owner who can settle rule questions
- API access from your bank, with sandbox credentials and the scopes the robot needs
- One month of card-request emails and the current register
- The cost-centre list and the approval thresholds you want above policy
Stages
Discovery
The policy and one month of requests; most of them turn out to be variations of five purposes
Rules
Limits by grade, duration caps, blocked categories, thresholds and the automatic-approval boundary
Build
Connector, request card, issuing and expiry robots, register, reconciliation extract
Validation
Sandbox testing of issuance, limit change and closing, then acceptance by treasury
Pilot
One high-volume department in parallel with the old route
Rollout
Further departments and countries, adding rules rather than workflows
Quick win. Effort is driven almost entirely by the card platform's API and its sandbox; the Teams and rule work is small, and the policy discussion is usually the longest part.
The limit raised for last spring's trade fair is still raised.
Send us your card policy and last month's card-request emails. We come back with the share that would have been issued within the hour under your own rules, and the ones your policy would have stopped.
Name the cards that should be closed todayThe neighbouring process usually has the same problem
Card spend is matched, coded and checked weeks after it posts, and receipts are chased forever.
View solution Other solutionsRequests raised in Teams, approved and ordered the same dayThe compliant route is slower than a chat message, so people order first and paper it later.
View solution Other solutionsExpense approvals in Teams, policy check includedApprovals wait in email until month end, and the policy question gets answered after the click.
View solutionIndustries we deliver this in most oftenManufacturing & industryServices & IT