Automating a flawed expense reporting process without standardising the approval rules first doesn't save you time — it just industrialises the chaos. You end up with a faster, more expensive version of the same arguments, the same exceptions, and the same frustrated finance team, except now they're all logged in a system nobody fully understands.
If you're about to roll out an expense management platform, or you've already done it and something feels off, this is probably why.
What actually goes wrong when you automate before you standardise?
The appeal is obvious. Your manual expense process is a mess — spreadsheets, paper receipts in envelopes, someone called Derek who's been approving everything with a rubber stamp since 2009. Automation feels like the answer.
But here's what actually happens: the automation faithfully replicates whatever rules (and non-rules) existed before. If your approval thresholds were inconsistently applied, the system will apply them inconsistently. If your mileage rates varied by department because nobody ever agreed on a standard, the system will encode that inconsistency into every future claim.
You haven't solved the problem. You've given it a login.
According to a 2023 report by the Global Business Travel Association, organisations with poorly defined expense policies spend an average of 20 minutes processing each expense report manually — and automated systems with unclear rules still require significant manual intervention, often approaching 40–50% exception rates. That's not automation. That's a very expensive form of digital paperwork.
Why do organisations keep doing this?
Because fixing the process is harder than buying the software. Software has a demo. It has a vendor who takes you to lunch. Process reform has a steering committee, three competing stakeholders, and a finance director who keeps saying "but that's not how we do it here."
I've sat in enough digital transformation programmes to know that technology is almost always chosen as a substitute for a difficult conversation, not a complement to a resolved one. The expense tool becomes the thing everyone agrees on because it sidesteps the thing nobody can agree on — which is: who gets to approve what, under what circumstances, and why does the Sales team get to expense a client dinner at a Michelin-starred restaurant while everyone else is arguing about whether a £4.50 train ticket needs two signatures.
That is not a hypothetical. I have been in that meeting.
What should you standardise before you touch the technology?
1. Approval thresholds — and who actually owns them
Define the monetary thresholds that trigger different levels of approval. Make them consistent across departments, or deliberately and transparently different with a documented rationale. "Marketing always gets more" is not a rationale. "Client-facing roles have a higher entertainment allowance, approved by the CFO, reviewed annually" is.
Critically, decide whether line managers approve, finance approves, or both. Dual approval sounds thorough. In practice it means everything sits in someone's inbox for a fortnight while they're waiting for the other person to go first.
2. Eligible expense categories — with actual definitions
Most organisations have a list of expense categories. Very few have definitions for those categories. "Travel" means something different to someone booking a cab across town and someone booking business class to Singapore.
Write it down. Spell it out. Yes, it feels pedantic. It will feel considerably less pedantic the first time someone submits a £600 hotel minibar bill under "client entertainment" and your system auto-approves it because the amount was under the threshold.
3. Receipt and documentation requirements
What proof is required? Above what value? For which categories? If your policy says "receipts required over £25" but your system is set to "receipts required over £50" because someone misread the policy during configuration, you have a compliance gap dressed up as a digital transformation.
4. Timeframes and submission windows
When must expenses be submitted? When must they be approved? What happens when they're late? Undefined timeframes create an approval backlog that no software in the world will fix, because the bottleneck is human behaviour, not process speed.
5. Exception handling — before the exceptions happen
Every expense policy has edge cases. The question is whether your organisation decides how to handle them in advance, or improvises at the point of each claim. Improvisation at scale is just inconsistency with extra steps.
Document your exception process. Who escalates? Who decides? How quickly? If the answer is "it depends," then you need to decide what it depends on before you build that into a workflow.
What does a standardised approval framework actually look like?
| Element | Without standardisation | With standardisation |
|---|---|---|
| Approval thresholds | Vary by manager, department, or historical precedent | Defined by policy, consistent across equivalent roles |
| Expense categories | Broad and undefined; open to interpretation | Named, defined, and mapped to accounting codes |
| Receipt requirements | Unclear; applied inconsistently | Explicit thresholds and formats documented in policy |
| Approval chain | Ad hoc; often whoever is available | Role-based, documented, with clear escalation paths |
| Submission timeframes | Vague ("submit promptly") or unenforced | Defined submission and approval windows with consequences |
| Exception handling | Improvised case-by-case | Pre-defined escalation path with named decision-makers |
| Policy review cycle | Whenever someone complains loudly enough | Annual review with documented owner and sign-off |
Doesn't the automation tool help you define the rules?
This is the most common objection I hear, and it's not entirely wrong. Good expense management platforms — SAP Concur, Expensify, Pleo, Spendesk, Webexpenses and others — do prompt you to configure approval rules during setup. Some have sensible defaults. Some have helpful templates.
But here's the thing: a configuration screen is not a policy conversation. Clicking through a setup wizard does not constitute organisational alignment. The finance director, HR, legal, and department heads all need to have agreed on the rules before someone in IT is filling in the fields.
Software can enforce rules. It cannot invent them, and it certainly cannot get your stakeholders to agree on them. That part is still stubbornly, irreducibly human.
How do you actually get stakeholders to agree on the rules?
With difficulty, and ideally before the vendor contract is signed, because that's when you still have leverage. Once the system is live, everyone's incentive is to make the existing configuration work rather than go back and fix the underlying disagreements.
A few things that actually help:
- Run a current-state audit first. Gather a sample of the last six months of expense claims. Look at what was approved, what was rejected, and — crucially — what was approved when it probably shouldn't have been. This gives you evidence rather than opinion.
- Separate the policy conversation from the technology conversation. Hold a dedicated workshop on expense policy before anyone mentions software. The moment a vendor demo enters the room, the conversation shifts to features and away from fundamentals.
- Make the CFO the decision-maker, not the facilitator. Expense policy is a financial governance matter. It needs someone with actual authority to resolve disagreements, not someone who will "take it back to the team."
- Document every decision and its rationale. When someone challenges a rule in six months (and they will), you need a record of why that rule exists. "Because we agreed it in March" is not sufficient. "Because we agreed it in March, based on an analysis of claim volumes and audit findings, signed off by the CFO" is.
- Pilot with one department before going organisation-wide. Not to test the software — to test the policy. See what edge cases emerge. Fix them before you scale.
What's the actual cost of getting this wrong?
Beyond the obvious — wasted implementation budget, frustrated employees, a finance team that has lost all faith in the system — there are some harder numbers worth knowing.
The Association of Certified Fraud Examiners (ACFE) 2022 Report to the Nations found that expense reimbursement fraud accounts for approximately 14% of all occupational fraud cases, with a median loss of $26,000 per case. Poorly defined approval rules are a primary enabler of this — not because people are dishonest, but because ambiguity creates genuine uncertainty about what's permissible, and that uncertainty is exploitable.
A 2022 study by Levvel Research (now Ardent Partners) found that organisations with mature, standardised expense policies process claims at roughly half the cost per report compared to those with ad hoc or inconsistently applied rules. That's not a marginal efficiency gain. Over a year, at scale, it's a meaningful number.
And then there's the audit risk. If your expense system has been running with inconsistent approval rules, your audit trail is inconsistent too. Explaining that to an external auditor is not a conversation anyone enjoys.
Is there a right order to do this in?
Yes. It's not complicated. It just requires discipline.
- Audit your current state. Understand what's actually happening before you decide what should happen.
- Define your expense policy. Categories, thresholds, receipt requirements, submission windows — all of it, in writing, with sign-off from the appropriate authority.
- Map your approval workflows. Who approves what, in what sequence, with what escalation path. Resolve the disagreements before they become configuration decisions.
- Select and configure your technology. Now the software has something coherent to enforce.
- Communicate and train. The best policy in the world fails if nobody knows it exists. This step is chronically underfunded in most implementations.
- Pilot, review, and iterate. Expect edge cases. Build in a review cycle. Don't treat the first configuration as the final word.
This is not a revolutionary sequence. It is, however, the sequence that organisations consistently skip steps three and four of, in that order.
What about AI-powered expense tools — do they solve this?
They solve some things. Several modern platforms now use machine learning to flag anomalies, auto-categorise receipts, and identify potential policy violations. That's genuinely useful — provided you have a policy for the AI to check against.
An AI trained on your historical data will learn your historical inconsistencies. If your previous approvals were erratic, the model's baseline for "normal" is erratic. Garbage in, garbage out — now with a confidence score attached.
AI augments a well-defined process. It does not substitute for one. I have yet to see a machine learning model that can resolve a disagreement between your Head of Sales and your Finance Director about client entertainment limits. That is still, regrettably, a human problem.
A note on the people side of this
I've spent enough time in organisations to know that expense policy arguments are rarely just about money. They're about trust, autonomy, and — occasionally — status. The senior leader who insists on a higher approval threshold for their team isn't always being unreasonable. Sometimes they're carrying institutional knowledge about why a rule was set that way. Sometimes they're just protecting their team's ability to do their jobs without bureaucratic friction.
Listen to the objections before dismissing them. Not all resistance is obstruction. Some of it is useful signal about where your policy has a genuine gap.
The goal is a policy that people understand, trust, and follow — not one that they work around. An expense system that employees actively try to subvert is not a technology failure. It's a policy design failure that the technology has made more visible.
Frequently Asked Questions
Can I automate my expense process and fix the rules at the same time?
In theory, yes. In practice, the pressure to get the system live usually wins, and the rule-fixing gets deprioritised. If you must do both simultaneously, ring-fence the policy work with its own timeline and owner, entirely separate from the implementation project. Otherwise the technology delivery will consume all available attention and the policy will be whatever the default settings are.
What's the minimum viable expense policy before we go live?
At absolute minimum: defined expense categories with clear descriptions, monetary thresholds for each approval tier, receipt requirements by value, submission deadlines, and a named escalation path for exceptions. Anything less than this and you're configuring your system to guess. It will guess wrong.
How do we handle legacy exceptions that are already embedded in our process?
Identify them, document them, and make a deliberate decision about each one: codify it as policy, eliminate it, or create a formal exception process. The worst outcome is migrating undocumented exceptions into your new system where they become invisible and impossible to audit.
Our organisation has multiple divisions with different approval structures. How do we handle that?
Most enterprise expense platforms support multi-entity or multi-division configurations. But the configuration still requires each division to have defined its own rules — and ideally, there should be a baseline policy that applies organisation-wide, with documented divisional variations above that baseline. Completely bespoke rules per division with no common framework creates audit complexity and makes group-level reporting effectively meaningless.
How long should the policy standardisation process take before we start the technology implementation?
For a mid-sized organisation, four to eight weeks is realistic if you have executive sponsorship and a dedicated owner. Longer if you're navigating significant stakeholder disagreement or a complex multi-entity structure. Do not let a vendor implementation timeline dictate your policy timeline. "We need to go live in six weeks" is not a reason to skip the governance work — it's a reason to push back on the go-live date.
What's the difference between an expense policy and an expense approval workflow?
The expense policy defines what is and isn't permissible — categories, limits, eligibility, documentation requirements. The approval workflow defines the process by which a claim is reviewed and authorised — who approves, in what sequence, within what timeframe. Both need to be defined before configuration. Most organisations have a rough policy. Very few have a properly mapped workflow. The workflow is usually where the implementation falls apart.
Is this problem specific to expense reporting, or does it apply to other finance automation?
It applies to essentially any process automation where human judgement has historically substituted for defined rules. Purchase order approval, contract sign-off, recruitment authorisation — the pattern is the same. Automation exposes the absence of rules by removing the human discretion that was compensating for them. Expense reporting is just a particularly visible and personally irritating example.
Nicholas Hodder is a digital transformation and technology leader with over 20 years of experience working across public sector, charity, and commercial organisations. He has led and advised on numerous finance technology implementations and has the steering committee scars to prove it. He speaks regularly on the gap between technology strategy and organisational reality.