Home · Solutions · Other solutions

Solution · Other solutions

The clause exists and the cap exists; what is missing is anything that applies them

Your expense policy executed line by line, automatically

Every line of every expense report is tested against the written policy at submission, so approvers decide only the exceptions the rules cannot settle.

Quick winMicrosoft TeamsHuman in the loopAI where it earns its place
396,000euros of expense claims are paid every month by this illustrative research organisation, against a policy nobody reads at the moment of approval.

Executive summary

Challenge

Your policy names the caps. The approver sees a total, a category and thirty other reports.

What changes

We turn the written policy into an executable rule set and run it on every line at submission.

Business value

The policy is applied identically to every line, because it runs as rules rather than as an approver's recollection on a Friday afternoon.

Systems involved

decision and rule-reference fields in the expense system; grant and project accounting; SharePoint policy and gift forms

Business problem

Travel & expense

An expense policy is a set of conditional rules: this category, up to this amount, for these people, with this document, booked this far ahead. Applying conditional rules to thousands of lines is precisely what people are bad at and software is good at, and yet the policy lives in a PDF while the check lives in an approver's head. That approver sees a total and a category. They do not see line items, do not know who the attendees were, and do not know what the grant terms allow.

The failures are predictable enough to list. Alcohol on internal meals and on restricted funding. Meals whose attendee lists are missing, padded, or claimed twice by two colleagues. Sub-type caps for taxis, breakfasts and per diems exceeded by amounts too small to notice one at a time. Purchases coded to a category that carries a higher cap than the right one. Gifts without the approval form. Flights booked three days out at three times the fare. Rental extras nobody authorised. Merchants the policy names as excluded.

What keeps this in place is the review model. Finance audits a sample after payment, so the policy is enforced by occasional example rather than by design. People compare notes and discover that the same request produced different answers in two departments, which costs the policy its authority. Each revision adds clauses that nobody executes, and the document grows further away from the spend it describes.

How it works today

  1. PersonThe employee builds the report at month end and picks the categories that seem closest
  2. SystemReceipts are attached as images, so line items never become data that a rule could test
  3. PersonThe manager approves on the total, thirty reports at a time, without the policy in front of them
  4. WaitingThe report is paid, and finance reviews a sample some weeks later
  5. Risk of errorAlcohol on a grant, a missing attendee list, a flight booked two days out and a gift without its form pass unless the sample happens to reach them
  6. PersonFindings after payment become recovery emails for amounts too small to pursue and too many to ignore
  7. Risk of errorExceptions are granted by whoever answers, so two employees get different answers to the same question
PersonSystemWaitingRisk of error

Why the current process costs more than it appears

Time that disappears before anyone measures it.

  • Recovery after payment rarely works. The money has left, the employee disputes it citing what a colleague was allowed, and finance spends more on the conversation than the line is worth.
  • Unallowable costs on grants and public funding are repaid, usually with an overhead charge, and one finding invites a wider sample at the next audit.
  • Managers are asked to be policy experts, which they are not and were never trained to be, so approval becomes a formality and the control on paper is not the control in practice.
  • Inconsistency is its own cost. Once people see that caps are enforced unevenly, the policy stops being a rule and becomes a negotiation.
  • On regulated relationships, an undocumented gift or a meal with a public-sector attendee is a compliance event rather than an expense event, and it is discovered by someone outside the company.

Cost of inaction

One year of a policy applied by sample≈ €81,000
Three audit cycles at the same coverage≈ €243,000
If grant-funded work lifts reports to 1,400 a month (per year)≈ €103,000

Repayment, not analyst time, is where this becomes expensive. A grant auditor who found hospitality issues once samples more widely the next time, and unallowable costs come back with an overhead charge attached and a question about what else was not checked. None of that is in the rows above, because its size depends on the funder rather than on the company.

Meanwhile the spend grows with headcount and travel while the sample stays the same size, so the share of lines ever tested falls every year. A few people learn which caps are enforced and stay just inside them, everyone else keeps following rules that are applied to them and not to their colleagues, and the gap between the document and the spend widens quietly.

Illustrative scenario

A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.

Organisation

A research and education organisation with 1,900 staff, funded by a mix of public grants, industry contracts and core budget, with a cloud expense system, grant accounting beside the ledger and Microsoft 365 as the workplace.

Volume

About 1,100 expense reports a month averaging €360, so roughly €396,000 of monthly spend; the policy caps alcohol per head for external hospitality, bans it on grant cost objects, requires attendee lists and gift forms, and asks for flights fourteen days ahead.

Current process

The expense system captures categories and totals; receipts stay as images. Two finance analysts review a sample after payment, and managers approve on the total.

Bottleneck

Line items are never turned into data, so no rule can run on them. Grant auditors have queried hospitality costs in two of the last three audits.

Solution

Decision tables written from the policy run on every line at submission. Lines that pass go on untouched; lines that break a clause become a task in Microsoft Teams for justification, correction, or an approval by someone entitled to give it.

Potential outcome

In the modelled case three quarters of today's checking effort is absorbed by the rules, and the out-of-policy share is stopped before payment instead of chased afterwards. Illustrative, not a client result.

Proposed solution

We turn the written policy into an executable rule set and run it on every line at submission. A UiPath robot retrieves each submitted report through UiPath Integration Service. UiPath Document Understanding reads the receipts and returns line items: dishes and drinks on a restaurant bill, extras on a rental agreement, booking and travel dates on an itinerary. That is the only place where a model is used, and it exists because without knowing what was ordered, an alcohol rule or a per-head rule cannot run at all.

The policy itself runs as DMN decision tables in UiPath Maestro, which matters more than it sounds: the finance team can read a decision table, change a cap in it and see the effect in the next day's reports, with the change versioned alongside the process. Alcohol lines are identified from item descriptions and merchant type, allowed within the per-head cap for external hospitality and never on a grant cost object. Meals are checked for attendee names, organisations and per-head amounts by attendee type, and the same attendee on two claims for one meal is flagged. Sub-type caps are applied by city and date. Category mismatches are recoded for review. Gifts are checked for the approval form and the recipient, with public-sector recipients routed to compliance. Flights and hotels booked inside the lead time are flagged with a repeat count per traveller, rental extras are read from the line items, and excluded merchants are blocked while grey-listed ones go for justification.

Lines that pass continue with the policy confirmed. Lines that fail become UiPath Action Center tasks in Microsoft Teams showing the clause, the line and the amount: the employee justifies or corrects, and the manager or compliance approves the exception with a reason. Every decision is written back with its rule reference, and Power BI shows breaches by rule, team and funding source, which is what tells the policy owner where the policy is unclear rather than ignored.

Native capabilities used

DMN decision tables and user tasks in UiPath Maestro; UiPath Document Understanding line-item extraction; UiPath Action Center tasks completed in Microsoft Teams; UiPath Orchestrator queues, versioning and audit log; UiPath Integration Service connectors for the expense, HR and accounting systems

What we build

The decision tables for each policy chapter, the exception paths and who may approve what, the write-back of decisions with rule references, the funding-source check against the cost object, and the Power BI breach model

Custom integration

Cost-object and grant-terms lookup where the accounting system exposes no standard connector; the travel booking tool for booking dates

How the automated process works

  1. AutomationSubmission triggers the robot, which retrieves the report, its lines and its images
  2. AutomationDocument Understanding returns line items: dishes and drinks, rental extras, booking and travel dates
  3. AutomationDecision tables apply the policy clause by clause against the category, the cost object and the traveller's own history
  4. AutomationLines that pass continue to approval with the policy confirmed and the rule references recorded
  5. PersonLines that break a clause become a Teams task where the employee justifies or corrects, with the clause and the amount in front of them
  6. PersonExceptions are approved by someone entitled to approve them, which for gifts and public-sector recipients means compliance rather than the line manager
  7. AutomationDecisions are written back with the rule reference, and the breach view updates by rule, team and funding source
AutomationPerson

Human-in-the-loop model

Automation handles

  • Line-item extraction from receipts, rental agreements and itineraries
  • Alcohol, attendee, sub-type, category, gift, lead-time, rental-extra and merchant rules on every line
  • The funding-source check against the cost object before anything reaches a grant
  • Task creation with the clause and the amount, and the write-back of every decision

People decide

  • The justification or correction, which stays with the employee
  • Exception approvals, with a reason recorded, by the role the rule names
  • The content of the policy: caps, attendee definitions, merchant lists and thresholds
  • What happens on repeat breaches, which is a conversation with HR and not a rule

Before and after

BeforeAfter
Share of lines tested against the policythe sample finance reachesevery line of every report
When a breach is foundafter paymentbefore approval
Who applies the clausethe approver, from memorythe decision table, identically
Effect of a policy changea memo and a reissued PDFthe next submission

Systems and integrations

Where a rule suffices we do not use a model. Where judgement is needed, a person decides.

Inputs

  • submitted reports and receipt images
  • travel booking dates
  • HR grade and cost centre
  • the funding source on the cost object

Automation layer

  • UiPath Orchestrator
  • UiPath Robots
  • UiPath Document Understanding
  • UiPath Maestro
  • UiPath Action Center

Target systems

  • decision and rule-reference fields in the expense system
  • grant and project accounting
  • SharePoint policy and gift forms
  • Power BI

Human touchpoints: Action Center tasks in Microsoft Teams; compliance approval for gifts and public-sector recipients; the policy owner's quarterly rule review

submitted reportsUiPath OrchestratorUiPath RobotsdecisionAction Center tasks in Microsoft Teams

Technologies used

UiPath Maestro (DMN decision tables)

the policy runs as tables the finance team reads and changes, versioned with the process

A
UiPath Document Understanding (IXP)

line items from restaurant bills, rental agreements and itineraries

A
UiPath Action Center in Microsoft Teams

justification and exception approval with the clause and the line shown

A
UiPath Integration Service

submission trigger, report retrieval, HR and cost-object lookups, decision write-back

A
UiPath Robots + Orchestrator

execution, queues, rule versioning and the log of every line tested

A
Microsoft Entra ID

resolves who may approve which exception, keeping compliance apart from line management

A
Power BI

breach rate by rule, team and funding source, and exception approvals by approver

A
Policy decision tables

our design: alcohol, attendees, sub-type caps, gifts, lead time, rental extras, merchants

C
Averified product capability (vendor documentation)Cillustrative model — the figures on this page

Illustrative economic model

Start by questioning the assumptions.

Illustrative model
820 reports a month × 6 minutes of policy checking= 82 h / month
82 h × €39 fully loaded analyst cost= €3,198 / month
× 12 months≈ €38,376 / year
Annual analyst capacity released (illustrative)≈ €38,376

Sampling is what the six minutes a report actually buys today, and the calculator prices only the part a rule set takes over, about three quarters of that effort, so the volume is 820 of the 1,100 reports rather than all of them. €39 an hour is an assumed fully loaded cost for a finance analyst in Central Europe. The out-of-policy pool is worked out separately below, because spend stopped is not time released and the two should not be added inside one calculator.

Run the numbers on your data

hours released per month
of annual capacity released

An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.

Business benefits

  • The policy is applied identically to every line, because it runs as rules rather than as an approver's recollection on a Friday afternoon
  • Unallowable costs never reach a grant, because the funding check runs before approval rather than at the audit
  • Out-of-policy spend is stopped before payment, so the recovery conversation mostly disappears
  • Approvers decide only genuine exceptions, with the clause, the line and the amount in front of them
  • A policy change takes effect on the next submission, not after a memo, because the table is the policy
  • Auditors receive a rule set, a log of every line tested and every exception approved, which is a stronger position than a sample

The management view

  • Breach rate by rule, team and funding source separates two different problems: a policy people ignore and a policy people cannot understand
  • Exception approvals by approver show who waves things through, which is a management conversation nobody can have today
  • Every gift, every meal with external attendees and every public-sector recipient appears on one list with its approval attached
  • The rules are readable artefacts owned by the policy owner and versioned, so a cap change is a decision with a date rather than an email

Board-level KPIs

breach rate by ruleout-of-policy spend stopped before paymentexception approval rate by roletime from submission to decisionshare of lines tested

Security and governance

Security is designed with the process, not after it.

  • The rule set is the control, so it is versioned, signed off and changed only by the policy owner, and every line tested is logged against the rule version that tested it
  • The robot reads reports and writes decisions and rule references; it holds no approval right, which keeps the decision with a person in every case
  • Approval roles are resolved from Microsoft Entra ID groups, so a compliance approval cannot be given by the line manager who is also the budget holder
  • Attendee names and gift recipients are personal data: they stay in the expense system and are referenced by the task rather than copied into it, and extraction runs under the UiPath AI Trust Layer in the EU region of UiPath Automation Cloud
  • Uniform application matters legally as well as morally, so thresholds and merchant lists are documented and reviewed with the works council where local law requires it

Why now

01

Funders and regulators have moved to data-driven audits of hospitality, gifts and unallowable costs, and a sample-based control answers a data-driven question badly

02

Line items on receipts became readable by pre-trained models, which supplied the one input the policy rules were always missing

03

Decision tables let finance own the rules directly, so the cost of executing an existing policy is now lower than the cost of reissuing it

Relevant executive roles

CFO

Out-of-policy spend stops before payment, and the policy becomes demonstrably executed rather than published

Compliance Officer

Gifts, hospitality and public-sector recipients are checked on every line, with approvals recorded against a rule

Finance Director

Analysts handle exceptions instead of samples, and a cap can be changed without a project

Common questions and objections

Our expense system already has audit rules.

It has caps by category on totals. Alcohol on a receipt, attendee counts, booking lead time and rental extras are line-item facts it never sees, which is why those clauses have never actually run.

People will argue with the robot.

They argue with finance today, after payment, when nothing can be undone. A task that cites the clause and the line, with a justification path, produces a shorter argument and a recorded outcome.

Our policy has too many grey areas.

The translation exercise surfaces them and the policy owner decides each one once. For most organisations that is the first time the policy has had that attention since it was written.

When this is not the right solution

  • The policy is a page of principles without caps or conditions; the rules have to be written before anything can execute them
  • Receipts are not captured as images, so line items cannot be read and most of the rule set has no input
  • Volume is a few hundred reports a month and finance already reads every one of them
  • The organisation is not willing to enforce consistently, and a rule set that is routinely overridden is worse than none

A question for the next management meeting

For any other financial control, would we accept that the rule is applied by whichever manager happens to be clearing a queue on a Friday afternoon?

Implementation approach

We start with one slice of the process and extend only once it is proven.

We deliver

  • A translation of the policy into testable rules, with every clause that turns out to be unexecutable listed for the policy owner to decide
  • A historical run of those rules on three months of paid reports, which produces the breach rate the organisation has been paying
  • The decision tables, reviewed and signed off by finance and compliance, with the exception paths and approval roles
  • Line-item document configuration and the integration with the expense, HR and accounting systems
  • An advisory pilot in one division, then Teams tasks live, then the remaining divisions and the merchant lists
  • Training for the policy owner on changing a table, and a quarterly rule review using breach data

We need from you

  • The current expense policy, including the annexes and the rules that exist only as practice
  • Three months of paid reports with receipts, and the cost-object and funding data behind them
  • A policy owner with authority to decide the ambiguities the translation surfaces
  • Access for a service account that reads reports and writes decisions, but cannot approve

Stages

Translation

Policy to rules, with gaps and contradictions written down for decision

Historical run

The rules applied to three months of paid reports, with the results reviewed line by line

Build

Decision tables, extraction, Teams tasks, write-back and the breach model

Advisory pilot

Live submissions in one division tested without stopping anything, and thresholds tuned

Rollout

Tasks switched on, remaining divisions, funding rules and merchant lists, with a quarterly review

Quick win. The rules are small and the platform is standard; effort follows how many clauses need a decision before they can be executed and how much line-item detail the receipts actually carry.