Home · Solutions · Other solutions
Solution · Other solutionsThe pattern is never inside one report; it runs across cards, months and people
Split payments and double-claimed meals found with evidence
Expense, card, payables and HR data are joined every night and scored for behaviour, so cases reach an auditor with the evidence already assembled.
Executive summary
Nobody splits a purchase in front of an approver. They split it across three receipts and two weeks.
The first thing we build is not analytics, it is a key.
Patterns that cross systems and months become visible, because the data is joined every night instead of a few times a year.
the consolidated store on Microsoft Fabric or Azure SQL; SharePoint case files; Power BI
Business problem
Spend controls
Expense controls are designed around the report and the approver. Abuse, where it exists, is designed around exactly that: keep each line plausible, spread it across periods, pay through a wallet so the merchant name is generic, split the amount, claim in cash below the receipt threshold, and never give any single approver a reason to look twice. The people best placed to do this are the people who know the policy best.
Internal audit knows the patterns and cannot run them. The data sits in three systems with different keys, the volume is far past what a spreadsheet can join, and every analysis is a one-off that dies with the auditor who built it. When a case is found it is usually through a tip, and the investigation then takes weeks because the evidence has to be reassembled by hand from receipts, statements, calendars and leave records.
The result is a gap nobody owns. Managers see one report at a time and finance sees totals, so behaviour is the one thing no report describes. Coverage of cross-system patterns is close to zero, so the deterrent is weak: people who split transactions learn that splitting works. And when the audit committee asks what is checked, the honest answer describes an intention rather than a process.
How it works today
- PersonLine managers approve expense reports one at a time, each seeing only what is in front of them
- SystemCard transactions are reviewed on monthly statements, in a different system and on a different rhythm
- PersonFinance audits a sample of paid reports, and internal audit exports expense, card and HR data a few times a year
- PersonAn auditor joins the exports in Excel on name and date and runs the queries she can remember
- WaitingAnalysis stops whenever an investigation starts, because the two people who do it are the two people needed
- Risk of errorA case surfaces, usually from a tip, after a long run that no existing report could have shown
- Risk of errorEvidence is rebuilt by hand weeks after the fact, and the workbook is archived when the auditor moves on
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Leakage is the smallest part. Each confirmed case consumes auditor, HR and legal time, and each unconfirmed suspicion costs trust with an employee who did nothing wrong.
- Key-person dependency is close to total, because the analytical knowledge lives in one workbook that one person understands and nobody else can extend.
- Deterrence works on what people believe is checked. When cross-system patterns run twice a year, that belief is accurate and the deterrent is worth little.
- Every acquisition adds employees, cards and a spend population nobody has profiled, so coverage falls each time the group grows.
- Reputational exposure is unrelated to the amount. A case found by a journalist, a regulator or an external auditor costs the same at €4,000 as at €400,000.
Cost of inaction
Detection by tip has a shape: a long run, a late discovery, and an audit committee asking why it took years. Between those events the analysis shrinks whenever an investigation consumes the people who do it, so coverage is lowest exactly when something is already wrong. The few who game thresholds continue, and their monthly totals rise slowly enough to look ordinary to every approver who sees one report.
The cost the rows cannot price is paid by everyone else. After each discovered case the company answers with tighter policies, lower limits and slower approvals, and the honest majority carries that every month for years.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A listed logistics group with 12,000 employees in eleven countries and 5,400 cardholders, running SAP Concur for expenses, an issuer card feed, SAP S/4HANA for payables, SAP SuccessFactors for HR and Microsoft 365 as the workplace.
About 9,000 expense reports and 60,000 card transactions a month, with combined travel, entertainment and card spend of roughly €7.2 million a month.
Internal audit has six people. Two spend around 130 hours a month building and refreshing pattern analyses in spreadsheets, and that work stops whenever an investigation starts. The last three confirmed cases came from tips.
No system holds expense, card, payables and HR data on one key, so the patterns that matter cannot be expressed as a query at all, let alone run every night.
Robots consolidate the four sources nightly into one store in the group's own tenant, a pattern set designed with internal audit scores behaviour rather than lines, and each case arrives in Microsoft Teams with receipts, transactions and a timeline attached.
In the modelled case, cross-system patterns run every night instead of twice a year, and the auditors' data-preparation time moves to judgement. The figures below are a model, not a measurement.
Proposed solution
The first thing we build is not analytics, it is a key. UiPath robots collect expense reports and lines from the expense system, card transactions from the issuer feed, employee vendor payments from SAP and employee attributes, manager, grade, location and leave, from HR, and land them nightly in one store in the client's own tenant: Microsoft Fabric where the group already uses it, Azure SQL where it does not. Everything is joined on employee and date, held under a stated retention period, and pseudonymised, so that the scoring runs without names.
On that store runs a pattern set we design with internal audit and express as rules and thresholds they can read. Split transactions at one merchant inside a short window that together cross a threshold. Claims that sit repeatedly just below the receipt limit. The same bill claimed by two colleagues. A meal claimed on a day that already carries a per diem. Conflicting expenses, a hotel and a per diem for one night, a taxi and a rental car at the same hour. Claims on days recorded as leave. Monthly totals per employee and category against their own history and their peer group. Merchant aggregation, including merchants used by exactly one person. Wallet payments totalled per employee for receipt verification. Negative card transactions traced back to reimbursed claims. Cash share, personal-spend indicators, and a reviewed-individuals list agreed with HR and legal for a defined period. An optional model in Microsoft Foundry, in the client's own Azure subscription, scores behaviour against peers and returns its reasons; optional, because the rules deliver most of the value and a score an auditor cannot explain has no place in a control that touches people.
What reaches a human is a case, not an alert. The robot assembles receipts, transactions, calendar and leave context and a timeline, and delivers it to a named auditor as a UiPath Action Center task in Microsoft Teams with a due date. The auditor closes it with a reason or opens an investigation with HR and legal. Outcomes feed back, so thresholds move on evidence rather than on instinct, and Power BI shows pattern volumes, confirmation rates, case age and exposure by region.
UiPath Orchestrator triggers, queues, credential store and audit log; UiPath Integration Service connectors for expense, payables and HR sources; UiPath Maestro orchestration of the nightly run and the case path; UiPath Action Center tasks with assignment and SLAs, completed in Microsoft Teams; Microsoft Fabric or Azure SQL as the consolidated store
The consolidated data model on one employee and date key with pseudonymisation and retention, the pattern set and its thresholds, the case assembly with its evidence pack and timeline, the outcome capture that recalibrates thresholds, and the Power BI pattern and exposure model
The issuer card feed over SFTP where no API exists; the optional peer-group model in Microsoft Foundry with reason codes
How the automated process works
- AutomationRobots consolidate expense, card, payables and HR data every night onto one employee and date key
- AutomationThe pattern set runs on the store: splitting, double claims, threshold gaming, conflicting expenses, monthly creep, wallet aggregation, cash share
- AutomationWhere it is used, the model scores behaviour against the employee's own history and their peer group and returns reason codes
- AutomationScores above threshold become a case with receipts, transactions, calendar and leave context assembled into a timeline
- PersonA named auditor reviews the case in Action Center and either closes it with a reason or opens an investigation
- PersonInvestigations run with HR and legal, and nothing reaches an employee without a person having decided it
- AutomationOutcomes are written back, thresholds recalibrate, and hit and confirmation rates update per pattern
Human-in-the-loop model
Automation handles
- The nightly consolidation of four sources onto one key, with pseudonymisation and retention applied
- Rule and threshold evaluation across reports, cards, months and people
- Case assembly: receipts, transactions, calendar and leave context, and the timeline
- Outcome capture, threshold recalibration and the reporting on hit and confirmation rates
People decide
- Every case: whether to close it with a reason or open an investigation
- The investigation itself, with HR and legal, and any action towards an employee
- The pattern set, the thresholds, the keyword lists and the reviewed-individuals list
- The proportionality review with the data protection officer, on a schedule rather than on request
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- expense reports and lines
- the issuer card feed
- employee vendor payments from payables
- HR attributes, leave and manager
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Maestro
- UiPath Action Center
Target systems
- the consolidated store on Microsoft Fabric or Azure SQL
- SharePoint case files
- Power BI
Human touchpoints: case review in Microsoft Teams; escalation to HR and legal; the quarterly pattern review with internal audit
Technologies used
nightly consolidation, scheduling, retries, credential store and the log of every run
Aexpense, payables and HR extraction over connectors, with SFTP for the issuer card feed
Athe consolidated store on one employee and date key, in the client's own tenant
Aorchestrates the nightly run, the case path, escalation and the outcome write-back
Aoptional peer-group scoring with reason codes, in the client's own Azure subscription
Athe case reaches a named auditor with the evidence pack and a due date
Apattern hit rates, confirmation rates, case age and exposure by region
Aour design with internal audit: splitting, double claims, conflicts, wallets, creep, cash share
CIllustrative economic model
What it is worth, with the arithmetic shown.
Two auditors do this work in sessions of about two hours, which is the unit the calculator uses: 130 hours a month is roughly 65 sessions, of which 80%, or 52, is the consolidation and scoring a robot takes over, leaving the rest with people as judgement. €58 an hour is an assumed fully loaded senior-auditor cost. The leakage pool is kept out of the calculator, because a share of spend and a quantity of minutes should not be added in the same box.
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
- Patterns that cross systems and months become visible, because the data is joined every night instead of a few times a year
- Investigations begin with the evidence assembled, so they take days rather than weeks and cost less in HR and legal time
- Creep and splitting are caught at the second occurrence rather than the twentieth, which is where most of the money is
- Auditor time moves from data preparation to judgement, and the analysis stops leaving with the person who built it
- The deterrent becomes real, because people know that behaviour is compared and not only lines
- The control is defensible: the pattern set, every case and every outcome are logged, so the audit committee hears what is checked
The management view
- A pattern inventory with hit and confirmation rates, which shows which patterns matter in this company and which only produce noise
- Exposure by region and category, case outcomes and the amounts stopped or recovered, in one view that updates nightly
- Case age, which answers a question no one can answer today: whether the audit team is keeping up with what the analysis finds
- The reviewed-individuals list with its legal basis and expiry dates, so a sensitive control has visible boundaries
Board-level KPIs
Security and governance
Control is not an add-on.
- This is employee monitoring, so proportionality comes first: purpose, patterns, retention period and access list are documented, agreed with the data protection officer and works councils where they exist, and reviewed on a schedule
- Scoring runs on pseudonymised data, and identity is resolved only when an auditor opens a case, which keeps ordinary analysis away from names
- No decision about a person is taken automatically; every case is reviewed by a human being, and that is a design constraint rather than a setting
- Access is limited to named auditors through Microsoft Entra ID groups, HR and legal see a case only once escalated, and the file carries a trail from first signal to outcome
- Robots run under least-privilege service accounts with secrets in the platform credential store, data stays in the client's tenant and the EU region of UiPath Automation Cloud, and any model runs in the client's own subscription with its reasons logged
Why now
Audit committees and regulators now expect continuous monitoring to be a process with evidence behind it, and a description of intent no longer answers the question
Digital wallets and aggregators have made merchant names generic, which weakens line-level audit at exactly the point where behaviour-level analysis still works
Expense, card and HR systems expose APIs, and analytical capacity sits inside the Microsoft tenant, so nightly consolidation and peer comparison no longer need a data science team
Relevant executive roles
Leakage is addressed early, exposure is visible by region, and the audit committee gets a control it recognises
Patterns run nightly instead of quarterly, cases arrive with evidence, and the set outlives whoever wrote it
A lawful, documented monitoring process with proportionality designed in, and conduct issues found early rather than externally
Common questions and objections
It is monitoring and it needs a lawful basis, which the design provides: a documented purpose, defined patterns, pseudonymised scoring, human decisions and limited access. Works councils generally prefer that to spreadsheet analyses nobody governs.
The historical run calibrates thresholds before anything goes live, and confirmation rates are tracked per pattern afterwards, so noisy patterns are tuned or retired.
It scores reports. This joins cards, payables, leave and history to score behaviour over months, which is where these patterns live.
When this is not the right solution
- Spend volumes are small and the population is a few hundred people an auditor can know personally
- No line-level audit exists yet; the per-report and per-card checks come first, because they supply the data this layer consumes
- The organisation cannot commit auditor time to review cases, and signals nobody reviews are a liability rather than a control
- A lawful basis for monitoring cannot be established in a jurisdiction that matters to the group
A question for the next management meeting
If two of our people had claimed the same restaurant bill on the same evening every month for a year, which report in this group would ever have shown it?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- A pattern inventory built with internal audit from their current analyses and past cases, with the data each pattern needs
- The legal-basis and proportionality work with the data protection officer, and the works-council conversation where required
- Integrations and the consolidated data model with pseudonymisation, retention and access rules
- The pattern set and thresholds, and the optional model with an evaluation of whether it adds anything
- A historical run on twelve months for one region, reviewed case by case with internal audit before anything goes live
- Nightly runs, the Action Center case queue, Power BI reporting and auditor training
We need from you
- Read access to expense, card, payables and HR data, and the issuer feed specification
- An audit lead who owns the pattern set, and named auditors with time to review cases
- HR and legal participation for escalation paths and the reviewed-individuals process
- Twelve months of history for the calibration run
Stages
Discovery
Pattern inventory, past cases, data access and the legal-basis review
Historical run
Twelve months for one region, reviewed with internal audit to set thresholds
Build
Consolidation, pattern set, case assembly, Action Center queue and reporting
Go-live
Nightly runs for the first regions, with case review supervised and hit rates watched
Scale
Remaining regions, the optional model and the reviewed-individuals process
Run
Quarterly pattern review on hit and confirmation rates, with threshold changes under control
Departmental. Effort follows the number of source systems and their key quality, the legal preparation each country needs, and how much calibration the first historical run turns out to require.
An auditor left behind a workbook with fourteen tabs and a feeling about the Antwerp depot.
Hand us twelve months of expense and card data, with employee identifiers pseudonymised if you prefer. You get back the ten patterns worth looking at first and what each of them found in your own history.
Score twelve months of card and expense dataThe neighbouring process usually has the same problem
Stop paying nine expense claims in ten on trust because nobody has time to check them against policy.
View solution Legal & complianceSegregation of duties checked weekly, not once a yearThe auditor finds your role conflicts once a year. By then the oldest of them is twelve months old.
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 solutionIndustries we deliver this in most oftenManufacturing & industryServices & ITFinance & insuranceShared services