Home · Solutions · Other solutions
Solution · Other solutionsThirty-eight audit rules, and no evidence about which of them ever caught anything
Which expense rules create work and which catch anything
Expense, card, audit and HR data are joined every night, so every rule, cap and approval step can be ranked by what it costs and what it finds.
Executive summary
Reviewers close 2,100 exceptions a month and nobody measures which rules ever found anything.
The analytics layer runs on what the group already owns.
Reviewer effort falls because rules that generate exceptions without findings are tuned or retired on evidence rather than defended on instinct.
Microsoft Fabric lakehouse; Power BI semantic model; audit rule configuration and policy caps, changed only by people
Business problem
T&E analytics
Travel and expense produces a great deal of data and very little insight, because the data never sits in one place. Report headers and lines live in the expense system, transactions in the card issuer's portal, rule outcomes in the audit queue, negotiated rates in the travel manager's files, and team structure in the HR system. Joining them is a manual exercise repeated every time somebody asks a new question, so nobody asks many.
Policy is therefore tuned by anecdote. A cap is raised because a senior person complained about a hotel in Copenhagen. A rule is added after an incident and never looked at again. A second approval level survives because removing it feels risky, and nobody can show it has ever changed an outcome. Some rules fire constantly and close without a finding, which teaches reviewers to click through them, and the rules that do matter get clicked through in the same rhythm.
Managers approve without context. They do not know that their team's average hotel night is well above the company's, or that one traveller books every flight inside a week of departure. The travel manager negotiates rates in twelve cities without knowing whether travellers use them. The problem persists because analytics here is nobody's deliverable: every source has an owner, and each owner reports only their own piece.
How it works today
This is what the quarter looks like in most groups of this size, whatever the expense system.
- WaitingExpense reports and card transactions accumulate through the quarter, unexamined as a set
- PersonAudit rules fire, reviewers open each exception and close most without a finding, at roughly seven minutes each
- PersonTwo analysts export reports, lines and the issuer's card file into Excel and join them by name and date
- PersonCost centres and merchant categories are cleaned by hand, then the same three slides are rebuilt
- WaitingThe meeting asks a question the slides cannot answer; the follow-up lands about three weeks later
- Risk of errorA cap is raised because a senior traveller complained; a rule is added after an incident and never revisited
- Risk of errorNobody measures findings per rule, so a rule that never caught anything costs as much attention as one that has
Why the current process costs more than it appears
The cost grows where nobody is looking.
- Reviewer hours spent on rules that never produce a finding are the largest visible waste, and they hide inside a queue nobody counts by rule, so no case for retiring one can be made with evidence.
- Caps that lag prices cost twice: too generous in cheap cities they invite quiet overspend, too tight in expensive ones they generate justified exceptions managers still have to read.
- An approval step that has never changed an outcome still adds days to reimbursement, and the employee waiting for the money is the one who notices.
- Without benchmarks a manager can approve spend but cannot manage it, so the teams that spend most never hear about it.
- Rates negotiated city by city are worth whatever compliance with them is worth, and nobody measures compliance, so each negotiation starts as blind as the last.
Cost of inaction
Rules accumulate in one direction only. Each incident adds one, no review removes one, and the queue grows faster than the spend behind it, so reviewers spend a larger share of every month clicking through noise. Caps set years ago drift further from prices; the justified exception becomes the normal path in expensive cities while cheap ones quietly overspend.
The quieter loss is authority. A finance function that cannot show which controls work cannot defend the ones that do, and when the audit committee asks whether the control environment is proportionate, the honest answer describes an intention. Meanwhile the travel manager negotiates rates the company does not use, and the teams with the highest cost per night are the last to hear about it.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
An insurance group with 4,800 employees in five countries. Travel and expense runs on SAP Concur with 38 configured audit rules; Microsoft 365 is the workplace and Power BI is already used elsewhere in finance.
About €14 million of travel and expense spend a year, mostly hotels, flights, meals and mileage. A small audit team reviews around 2,100 exceptions a month; the card issuer delivers a feed daily.
Two finance analysts spend roughly 30 hours each a month rebuilding the monthly and quarterly packs in Excel. The travel manager has negotiated hotel rates in twelve cities and has no data on whether travellers book them.
Every question not already on a slide needs a fresh manual join, so policy moves on the loudest complaint, and the rule set has never been reviewed as a portfolio.
Robots extract reports, lines, rule outcomes, approval timestamps, card transactions, HR structure and negotiated rates into a Microsoft Fabric lakehouse each night; a Power BI model presents spend, compliance and rule performance; a monthly recommendation run proposes which rules to tune, which caps to move and which transaction types are safe to auto-approve.
In the modelled case, reviewer effort falls by about a third once the weakest rules are retired, pack production stops consuming most of two analysts, and a one percent effect on annual travel spend becomes reachable. Arithmetic on stated assumptions, not a measurement.
Proposed solution
The analytics layer runs on what the group already owns. UiPath robots read expense reports, lines, categories, rule outcomes and approval timestamps through UiPath Integration Service, collect the issuer's daily card file, pick up rate sheets from SharePoint and pull team, grade and cost-centre structure from HR. Everything lands in a Microsoft Fabric lakehouse in the group's own tenant. Nothing is written back to a system of record: the robots read, and people decide.
On that store sits a Power BI semantic model in Direct Lake mode. It answers what the three slides could not: spend by team, category, city and supplier; compliance with negotiated rates; exceptions raised and findings confirmed for each of the 38 rules; approval time by manager; and benchmarks comparing cost per trip, per night and per meal across peer teams and roles. Row-level security means a manager sees their own team, which is what makes the model safe to distribute.
The part that changes behaviour is the recommendation run. Once a month it produces a ranked, evidenced list: transaction types with no rejection in twelve months, proposed for auto-approval; types always rejected, proposed for return at submission; rules ordered by exceptions against findings, with a threshold change or retirement proposed for the worst; caps compared with prices actually paid in each city; approval steps that have never changed an outcome below a stated amount; and anomalies such as a team's meal spend doubling, with the lines attached. Finance accepts, defers or rejects each item, and every decision is recorded with its reason. Managers receive a monthly digest in Microsoft Teams. UiPath GenAI Activities draft the quarterly narrative, and an analyst reads it before anyone else does.
UiPath Integration Service connectors for SAP Concur, Microsoft Teams and Microsoft OneDrive & SharePoint; UiPath Orchestrator scheduling, credential store and audit; UiPath GenAI Activities under the UiPath AI Trust Layer; UiPath Insights; Microsoft Fabric lakehouse and Power BI semantic models in Direct Lake mode with row-level security
The lakehouse data model and nightly join; rule-performance and cap-versus-price metrics; peer benchmarks by team, role and city; the recommendation set and its evidence packs; the change-control record for accepted changes; the Teams digest; report design
The card issuer's daily file over SFTP, and the HR extract where no connector exists
How the automated process works
- AutomationRobots extract reports, lines, rule outcomes, approval timestamps, card transactions, HR structure and negotiated rates every night
- AutomationThe lakehouse refreshes and the Power BI model rebuilds spend, compliance, rule performance and benchmarks before the working day starts
- AutomationThe monthly run ranks rules by exceptions against findings, compares caps with prices paid, and lists auto-approval candidates with twelve months of outcomes behind each
- PersonFinance reviews each recommendation with its evidence and accepts, defers or rejects it, recording the reason
- SystemAccepted changes to caps, thresholds and approval steps are made under change control and version-stamped
- AutomationEach manager receives a Teams digest covering their team's benchmarks, outlier lines and unusual patterns
- PersonThe quarterly narrative is drafted from the model and checked by an analyst before it goes anywhere
Human-in-the-loop model
Automation handles
- Nightly extraction and joining of expense, card, audit, HR and rate data
- Benchmarks, rule-performance metrics and the comparison of caps against prices paid
- The monthly recommendation run and the evidence pack behind each proposal
- Manager digests in Teams and a first draft of the quarterly narrative
People decide
- Whether each recommendation is accepted, deferred or rejected, and on what reasoning
- Every change to a policy cap, an audit threshold or an approval step
- The conversations with managers and travellers that a benchmark or outlier starts
- Whether a drafted narrative is accurate enough to distribute
Before and after
Systems and integrations
The stack is deliberately short: one engine, one execution layer, one place where a person decides.
Inputs
- SAP Concur reports, lines, rule outcomes and approval timestamps
- the card issuer's daily feed
- HR team, grade and cost-centre data
- negotiated rate files on SharePoint
- the expense policy
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath GenAI Activities
- UiPath Insights
Target systems
- Microsoft Fabric lakehouse
- Power BI semantic model
- audit rule configuration and policy caps, changed only by people
Human touchpoints: the monthly recommendation review with finance; manager digests in Microsoft Teams; the analyst's review of each drafted narrative
Technologies used
nightly extraction; scheduling, credential store and audit trail
Areads reports, lines, rule outcomes and approval timestamps; posts digests; collects rate sheets
Aone governed lakehouse for expense, card, HR and rate data in your own tenant
Aspend, compliance, rule performance and benchmarks, with row-level security per manager
Athe monthly manager digest and the thread where an outlier is discussed
Adrafts the quarterly narrative from the model's numbers, for an analyst to review
Arun status, extraction failures and refresh timing for the automation itself
Aranks rules, caps, approval steps and auto-approval candidates on twelve months of history
CIllustrative economic model
Numbers you can check against your own data.
The largest of the three figures below is also the softest: a one percent effect on €14 million of travel spend depends on decisions finance takes, not on anything a robot does, and it belongs here only because tuned caps, booking lead times and rate compliance are what the analytics make decidable. The labour figures are firmer: 60 analyst hours a month on packs with 70% absorbed, and 2,100 exceptions at seven minutes each with 35% released once weak rules go and safe types are auto-approved. The €44 and €43 rates are illustrative fully loaded Central European costs, and every input is an assumption rather than a measurement.
Business benefits
- Reviewer effort falls because rules that generate exceptions without findings are tuned or retired on evidence rather than defended on instinct
- Low-risk transaction types are auto-approved on a defensible basis: twelve months of outcomes, reversible the moment the data changes
- Caps follow real prices, so quiet overspend in cheap cities and exception floods in expensive ones both shrink
- Reimbursement gets faster wherever an approval step is shown to have changed nothing
- Managers manage spend rather than approve it, because their benchmarks and outlier lines arrive every month
- Negotiated rates get used, because non-compliance is visible by city and supplier before the next negotiation opens
The management view
- Policy stops being a matter of opinion: every proposed change arrives with the exceptions, findings and prices behind it
- Rule performance and auto-approval share become metrics with a trend, so the control environment can be shown to be proportionate
- The travel manager negotiates with compliance by city and supplier in hand, not a spend total
- Analyst capacity moves from assembling the pack to answering the questions it raises
Board-level KPIs
Security and governance
The automation holds exactly the rights it needs, and not one more.
- The layer reads and never writes, so robots run under read-only service accounts whose secrets sit in a credential store, never in a workflow
- Lakehouse, semantic model and reports stay in the group's own Microsoft Fabric tenant inside the Microsoft 365 EU Data Boundary, with the robots running from the EU region of UiPath Automation Cloud
- Access follows Microsoft Entra ID groups, and row-level security limits each manager to their own team; the full traveller view stays with finance and the audit team
- Traveller-level benchmarks are personal data: purpose documented, use limited, and reviewed with the data protection officer and works councils before anything is published
- Accepted and rejected recommendations are versioned with their reasons, so every threshold traces back to a dated decision; generative drafting runs under the UiPath AI Trust Layer with an allow-list and full logging
Why now
Audit committees increasingly ask whether controls are proportionate to risk, and that question can only be answered by measuring the controls themselves, which is what a rule-performance ranking does
Travel prices moved sharply in recent years and most policies did not, so caps and prices have drifted apart and the gap is producing exceptions that are not findings
The join that used to take an analyst weeks is now a nightly refresh: expense systems expose rule outcomes and approval timestamps through APIs, issuers deliver daily feeds, and Direct Lake models read the lakehouse without a copy step
Relevant executive roles
A pack that answers follow-up questions in the meeting, and a route to lower travel spend that does not start with a memo about booking economy
A ranked list of changes with the evidence attached, fewer hours on exceptions that were never going to be findings, and a documented rationale for every policy change
Compliance with negotiated rates by city and supplier, which changes the next negotiation and the conversation with the teams that ignore them
Common questions and objections
It reports its own data well. Rule performance against findings, negotiated-rate compliance, workflow value and peer benchmarks need card, HR and rate data joined to it, and that join is what this adds.
The proposal covers only transaction types with twelve clean months behind them, it is a recommendation for finance to accept rather than a change the system makes, and the monthly run reports the moment the pattern changes.
Those analysts are building the pack. Roughly 42 of their 60 hours a month go into assembly the model absorbs, which is where the capacity comes from.
When this is not the right solution
- Travel and expense spend is small enough that a single Power BI report over the expense system answers every question worth asking
- There are no audit rules or policy caps in place yet, in which case designing the audit comes before measuring it
- Finance is unwilling to change policy or thresholds on evidence, or expense and card data cannot be exported or reached by API; either way, that comes first
A question for the next management meeting
Three of our thirty-eight audit rules probably produce half the exceptions and almost none of the findings: can anyone in this room name them, and say what they cost us last quarter?
Implementation approach
A scope without ambiguity, before anything is signed.
We deliver
- An inventory of the current packs, the 38 audit rules with twelve months of outcomes, the caps and the rate sheets
- The lakehouse data model and the nightly extraction robots, with card feed and HR structure joined to expense data
- The Power BI semantic model, benchmark definitions and reports, with row-level security agreed with HR and the works council where required
- The recommendation set, its evidence packs and the monthly cadence with change control on caps and thresholds
- Manager digests in Teams, the optional narrative draft, and Insights monitoring on the extraction
- Testing against the last two quarterly packs so the model reproduces numbers finance already believes
We need from you
- Read access to the expense system, card feed, HR structure and rate files
- Twelve months of audit rule outcomes, including which exceptions produced a finding
- A named owner in finance for the policy and rule set, with authority to change thresholds
- The travel manager's participation and time in the monthly cycle to decide
Stages
Discovery
Packs, rule inventory, caps, rates and data access mapped with finance and the travel manager
Model
Lakehouse, joins, benchmarks and rule-performance metrics on twelve months of history
First run
The recommendation set presented as a workshop; the rule ranking usually settles the business case
Scale
Manager digests, benchmarks by role, the narrative draft, the monthly and quarterly cadence
Run
Recommendation review each month, policy review each quarter, thresholds changed under control
Quick win. Effort follows the number of source systems to be joined and the state of the cost-centre and category data, not the reporting itself.
Thirty-eight rules fired 1,842 times last quarter and the findings fit on one slide.
Share last quarter's exception list with its outcomes, your policy caps and your rate sheet. We return a ranked rule table, a cap-versus-price comparison by city, and a shortlist of transaction types that could be auto-approved.
Rank your audit rules on last quarterThe neighbouring process usually has the same problem
The board pack should not depend on which analyst merged which spreadsheet on which day.
View solution Other solutionsEvery expense report audited before the money leavesA sample checked after payment finds errors it cannot recover and misses the duplicates entirely.
View solution Other solutionsSplit payments and double-claimed meals found with evidenceNobody splits a purchase in front of an approver. They split it across three receipts and two weeks.
View solutionIndustries we deliver this in most oftenManufacturing & industryServices & ITFinance & insuranceShared services