How to Write a Travel and Expense Policy That Software Can Actually Enforce

The Policy Everyone Has and Nobody Can Enforce

Open almost any corporate travel and expense policy and you will find sentences like these:

“Employees should exercise good judgement and incur only reasonable and necessary expenses.”

“Travel should be booked at the most economical fare consistent with business requirements.”

“Entertainment expenses must be appropriate to the business relationship.”

Every one of these is unobjectionable, and every one is unenforceable. There is no subject a system can read, no threshold to compare against, and no defined outcome when the condition fails. They are statements of intent wearing the grammar of rules.

The practical consequence is that enforcement falls entirely to approvers, who are the claimant’s own managers, who see these people daily, and who are being asked to adjudicate “reasonable” on a S$180 dinner. Enforcement becomes a function of individual temperament. The same claim is approved in one department and questioned in another, and neither approver is wrong, because the policy gave them nothing to be right about.

This is not an argument for a stricter policy. It is an argument for a testable one. A policy that software can evaluate produces consistent outcomes without asking any manager to have an awkward conversation — and consistency, more than severity, is what changes behaviour.

What Makes a Rule Enforceable

A rule a system can act on has four components. Miss any one and the rule degrades into guidance.

1. A subject held as data. The thing being tested must exist as a field: claim amount, expense category, city, employee grade, attendee count, days since expense date. “Reasonableness” is not a field. “Amount per attendee” is.

2. A comparison. Greater than, less than, equal to, within a set. Explicit and unambiguous.

3. A threshold, and the dimensions it varies on. A single number, or a number that varies only along dimensions the system also holds — grade, city tier, category, entity. A threshold that varies on “circumstances” is not a threshold.

4. A defined outcome. What happens when the condition fails: block the claim, flag it for review, or route it to a higher approval level. “Should not” is not an outcome.

Compare:

The right-hand column is longer. That is the cost, and it is the whole point. Each of those rewrites can be evaluated by a system in milliseconds, applied identically to everyone, and reported on afterwards.

The Eight Sections a T&E Policy Needs

Most policy templates you will find online are structurally similar and equally vague. Structure is worth borrowing; the values are yours to set.

1. Scope

Who it applies to — employees, contractors, interns, board members, candidates travelling for interview — and which entities. In a group with multiple legal entities this section does real work, because it determines which limit table applies to someone seconded across entities.

2. Pre-approval

Which spend requires approval before it is incurred, and at what threshold. Typically all travel, plus entertainment above a value. This is the highest-leverage control in the entire policy, because it is the only one that operates before money is committed.

Pre-approval is also where the most common process failure lives: the request is approved on an estimate and the booking comes in higher, triggering a full re-approval. Setting an explicit tolerance band in policy — “actuals up to 10% above the approved estimate do not require re-approval” — removes a large volume of rework, which we cover in detail in why travel requests get re-approved from scratch.

3. Category limits

The core of the policy. A limit per category, varying by the dimensions you have decided matter. More on how to set these below.

4. Documentation requirements

What evidence is required, at what threshold, and in what form. Be specific: a card slip is not a tax invoice, and in most jurisdictions only the latter supports input tax recovery. Singapore’s IRAS GST rules and the UK’s VAT invoice requirements both set out minimum fields; your documentation rule should reference the standard that applies to each entity.

5. Reimbursement model

Per diem, actual cost, or a mix — and which categories use which. Covered in its own section below.

6. Submission deadlines

How long claimants have. Thirty days is a common and workable default, with escalating exception requirements beyond 60 and 90 days. This is not administrative fussiness: late submission is what creates the unrecorded liability that distorts month-end, a problem we unpack in travel and expense analytics.

7. Approval chain

Who approves what, at which threshold, and what happens when they are unavailable. Delegation needs to be explicit in policy or it will be improvised in practice — see approval delegation and fallback approvers.

8. Non-compliance consequences

What actually happens. Most policies stop at “may result in non-reimbursement”, which everyone correctly reads as “will not result in anything”. State the sequence: first occurrence, repeat occurrence, deliberate misstatement. A policy with no stated consequence is a suggestion, and the Association of Certified Fraud Examiners consistently finds that perceived likelihood of detection and consequence is the strongest deterrent available.

How to Set Limits That Actually Bind

This is where most policies go wrong, and the error is almost always the same: limits set by country.

A single national meal limit is wrong in both directions simultaneously. Set it for the capital and it is generous everywhere else, quietly becoming a target rather than a ceiling. Set it for the national average and it is unworkable in the largest city, generating constant exceptions that train everyone to treat the limit as advisory.

Use city tiers instead. Three or four tiers covering the cities your people actually travel to, with a limit per tier per category. This is more work to set up and dramatically less work to run, because the exception rate collapses.

Apply grade bands sparingly. Seniority-based limits are defensible for accommodation and flight class, where the business rationale is real. They are harder to defend on meals, where the effect is to tell junior staff that their lunch is worth less. Use grade where it corresponds to a genuine difference in requirement, not as a general status marker.

Set thresholds from your own data, not benchmarks. Pull the last twelve months of claims by category and city. Look at the distribution, not the average. A limit set at the 85th percentile of historical compliant spend will bind on genuine outliers while passing normal behaviour — which is exactly what you want. A limit set from an industry benchmark will either never bind or constantly misfire, because it was calibrated on someone else’s travel pattern.

Then watch the exception rate. This is the feedback loop most organisations never close. If a rule generates exceptions on 30% of claims, the threshold is wrong. It is not a compliance problem and it will not be fixed by reminding people about the policy. Fix the number.

Per Diem or Actual Cost?

The reimbursement model is a genuine decision with trade-offs in both directions, and policies frequently adopt one without ever having compared them.

Per diem pays a fixed daily allowance regardless of what was spent. It eliminates receipt collection for the covered categories, makes trip cost predictable before departure, removes a large volume of small-value audit work, and is generally popular with travellers.

Its costs: it overpays on cheap trips and underpays on expensive ones, and it can create taxable income where the rate exceeds the local tax-free allowance. Published government rates — such as the US GSA per diem tables — are a useful reference point for setting rates, but the taxable threshold that matters is the one in each employee’s own jurisdiction.

Actual cost reimburses what was spent, against receipts. It is precise, it supports input tax recovery, and it produces the line-level data that makes supplier negotiation possible. It also generates receipt volume, verification work, and a great deal of small-value adjudication.

The common resolution is to split by category: per diem for meals and incidentals, where the amounts are small and the verification cost is disproportionate, and actuals for accommodation, flights and ground transport, where the amounts are large, the tax recovery matters, and supplier data has analytical value.

Whichever model you choose, write the rule with the same four components. “Per diem of S$55 per full day in Tier 2 cities; partial days at 50%; no receipts required; no additional meal claims permitted on a per diem day” is enforceable. “Per diem may be claimed where appropriate” is not — and the last clause of that rule is the one that matters, because per diem plus individually claimed meals on the same day is one of the most common leakage patterns there is.

Writing for the System and the Human at Once

A policy has two audiences with genuinely different needs, and trying to serve both in one document is why so many policies end up serving neither.

The system needs unambiguous conditions. It does not need context, rationale or tone.

The employee needs to know what they can spend, what evidence to keep and when to submit. They will not read fourteen pages, and the fact that they did not read it is not a defence you want to rely on.

The practical answer is to separate the layers. Maintain a rules table — category, dimension, threshold, outcome — as the authoritative source, which is what gets configured into the system and what gets reviewed annually. Then write a short employee-facing summary, ideally one page, that states the handful of numbers most people need and points to the full table for the rest.

The best version of this does not rely on reading at all: the rules surface at the moment of submission, showing the claimant the applicable limit for their city and category before they submit. A policy communicated at the point of action is one people follow without ever having memorised it, and it converts policy from something enforced after the fact into something that shapes behaviour during it.

How Peakflo Helps

Peakflo’s travel and expense management module is designed around a rules table rather than a policy document. Limits are configured per category across city tier, employee grade, entity and attendee count, so the same policy can express “S$60 per person in Tier 1, S$40 in Tier 2, Grade 5+ multiplier on accommodation only” without custom development — and each rule carries its own outcome, whether that is a hard block, a soft flag or routing to a higher approval level.

Because limits are evaluated at submission, claimants see the applicable cap for their city and category before they submit rather than discovering it after rejection, and pre-approval tolerance bands stop small overruns from triggering full re-approval. Per diem and actual-cost models can run side by side across categories, with mutual-exclusion rules preventing a per diem day from also carrying individually claimed meals. Exception volume is reported by rule, so an over-tight threshold shows up as data at the annual policy review instead of as accumulated frustration.

If you want to see your own policy expressed as configured rules rather than a PDF, request a demo and bring your current document.

Our Verdict: Is a Policy Rewrite Worth the Effort?

Rewrite now if:

• Your policy contains the words “reasonable”, “appropriate” or “good judgement” as operative terms
• Limits are set by country rather than by city tier, and you operate in more than one major city per country
• Exception volume is high and nobody is reviewing which rules generate it
• Approvers apply the policy differently across departments and everyone knows it
• You are implementing or replacing expense software — configuring a vague policy into a rules engine is where the vagueness becomes visible and expensive

Lower priority if:

• Your policy is already expressed as a rules table and the exception rate is under roughly 10%
• Your travel footprint is single-city and single-entity, where a flat limit genuinely is correct
• Your real problem is that rules exist but nothing evaluates them, which is a systems problem rather than a drafting one — start with pre-payment screening coverage instead

A note on sequencing: rewriting the policy and implementing the software should happen together, not in series. Policies rewritten in isolation tend to encode rules the chosen system cannot express, and systems configured against an unrewritten policy simply automate the ambiguity. Guidance from bodies such as the Institute of Management Accountants on control design makes the same point — the control and its evidence mechanism are one design, not two.

Conclusion

The gap between a policy that works and one that does not is rarely strictness. It is testability.

A rule that names a field, a comparison, a threshold and an outcome can be applied identically to everyone, evaluated before payment, and reviewed against its own exception data a year later. A rule that asks people to be reasonable delegates the decision to whoever is least comfortable saying no, produces different outcomes in different departments, and cannot be reviewed at all because there is no data about it.

Start with the eight sections. Set thresholds from your own distribution rather than a benchmark. Split per diem and actuals by category where the verification cost justifies it. Then watch the exception rate and treat a high one as a signal about your number, not about your people.

The document gets longer and less quotable. What you get in return is a policy that operates.

Frequently Asked Questions

What should a travel and expense policy include?

Eight sections cover it: scope and who it applies to, pre-approval thresholds, category-by-category limits, documentation requirements, the reimbursement model for meals and incidentals, submission deadlines, the approval and escalation chain, and the consequence of non-compliance. Anything else is commentary.

Why do most expense policies fail to get enforced?

Because they are written as prose for humans rather than conditions a system can test. A rule like “expenses should be reasonable and necessary” has no testable subject, threshold or outcome, so no software can evaluate it and every approver interprets it differently.

What makes an expense policy rule machine-enforceable?

Four components: a subject the system holds as data, a comparison operator, a threshold that varies only on known dimensions, and a defined outcome. “Meals in Tier 1 cities are capped at 60 per person per day; above this the claim requires director approval” has all four. “Keep meals reasonable” has none.

Should a travel policy use per diem or actual cost reimbursement?

Per diem removes receipt handling and makes cost predictable, but overpays on cheap trips and can create taxable income if rates exceed local allowances. Actual cost is precise but generates receipt volume and audit work. Many organisations use per diem for meals and incidentals and actuals for accommodation and transport.

How many expense categories should a policy have?

Between eight and fifteen for most organisations. Fewer and the categories cannot carry different rules or GL mappings. More and claimants choose wrongly, which corrupts reporting and makes category-level limits unenforceable because the same spend lands in different buckets.

How should expense limits vary across a global organisation?

Vary limits on city tier and employee grade, not on country alone. A single national limit is wrong in both directions within the same country. Define three or four city tiers with a limit per tier per category, then apply a grade multiplier where seniority genuinely justifies a different standard.

What submission deadline should an expense policy set?

Thirty days from the expense date works for most organisations, with claims older than 60 to 90 days requiring an exception approval. The deadline matters for period accuracy: expenses submitted months late land in the wrong accounting period and distort departmental cost comparisons.

Should exceptions to expense policy be allowed?

Yes, but they must be a defined path rather than an informal one. Build an explicit exception route that requires a stated reason and a higher approval level, then report exception volume by rule. A rule with a high exception rate is a badly set threshold, not a compliance problem.

How often should a travel and expense policy be reviewed?

Annually for limits, which drift against inflation and local prices, and immediately after any structural change such as an acquisition, a new entity or a significant shift in travel patterns. Exception-rate data should drive the limit review rather than benchmarking alone.

Is an expense policy template enough to start from?

A template gives you structure, which is useful, but the values are the policy. Limits, city tiers, grade bands, deadlines and approval thresholds all have to be set from your own spend data and organisational structure. A template adopted without calibration produces either constant exceptions or caps that never bind.