Employee Spending

Every company that gives employees the ability to spend has made a judgement about trust, autonomy and the cost of asking permission. Finance owns the mechanism, but it does not own the judgement.

Treating employee spending purely as a controls problem produces a predictable outcome: rules get tightened until the friction is high enough that people work around them. The workaround is always the same — the purchase happens on a personal card and arrives later as a reimbursement claim, with worse evidence, timing and coding than if it had run on a company card.

The real question is therefore not "how do we stop people spending" but "how much authority does each role need in order to work, and what do we ask for in return". That is a delegation question, and the answer differs by culture as much as by size — growing businesses covers how it shifts as headcount rises.

One note on what this site is: an independent, non-commercial reference project. We are not Brex, not an issuer and not affiliated with any provider. There is no application, account or login here, and we publish no amounts, thresholds or eligibility rules — the right numbers depend entirely on your company, and the available features depend on your provider.

Two models exist for letting employees buy things. They are often presented as equivalent options with different administrative overheads. They are not equivalent, and the difference falls almost entirely on the employee.

The last two rows are the ones that get overlooked. Reimbursement pushes a working-capital problem onto individuals. Someone books a flight, waits, and absorbs the cost meanwhile. For a senior employee that is an irritation. For a junior employee, or anyone without savings, it is a genuine barrier — and it produces a quiet inequity where the people least able to float costs are the people least able to do parts of their job.

This is why the company card model is usually better for employees, not merely for finance, and it is worth saying so when a policy is introduced. Cards presented as a control measure are received as a restriction; presented as removing personal outlay, they are received very differently. Employee cards covers issuance, and Brex Corporate Card covers the company-liable structure that makes broad distribution practical.

Reimbursement does not disappear entirely: new joiners before a card arrives, situations where a card cannot be used, and genuinely personal-then-recharged costs will always exist. The goal is for it to be the exception rather than the operating model, and for that path to be fast enough that nobody carries a cost for long.

A spending policy has two audiences with incompatible needs. People need to know what to do in a specific situation; systems need rules that can be configured. A single document trying to serve both usually serves neither.

Separate them. A short, readable policy tells people what is expected, in language a new joiner understands on first reading. A configuration mapping records which statements are enforced, by what mechanism, at what moment — spending controls covers that mapping; what follows is the human half.

• Say what the card is for in one sentence, before any rules appear
• State the ceiling and the documentation threshold plainly, rather than requiring people to infer them
• Name the escalation route, with a person or role and an expected response time
• Describe what is not permitted, and why, so the rule is comprehensible rather than arbitrary
• Explain what happens when something goes wrong, so a mistake is a process rather than a fear
• Keep it short enough that it is actually read, and revise it rather than appending to it

The "and why" is not decoration. A rule with a stated reason is applied sensibly to situations the author did not anticipate; a rule without one is either followed literally into absurdity or ignored. Since no policy can enumerate every case, the reasoning is what makes the policy usable at the edges.

Communication matters as much as content. Policy shared once at onboarding and never mentioned again is functionally unwritten by the second year. The practical minimum is: explained at issuance, referenced when a control acts, and reviewed with the team whenever it changes materially.

Documentation policy is where good intentions meet human behaviour. The rule that works is simple, uniform, and enforced by the system rather than by reminders from whoever noticed.

A program with excellent controls and poor documentation produces an auditable-looking system that cannot actually be audited. Business expenses and expense controls cover what the evidence is used for once it is collected.

Documentation requirements and tax treatment vary by jurisdiction, entity type and company. This page describes general practice, not a compliance standard; your accountant or adviser sets the actual rule.

Travel is the category where spending policy is most tested, because the purchases are unpredictable, time-sensitive, made under fatigue and often in another currency. It is also where over-tight controls cause the most damage, since the alternative to a working card is an employee stranded with a personal one.

The structural complication is that travel merchants frequently authorise for an estimated amount. A hotel or vehicle hire reserves headroom on presentation, and that reservation can persist and can exceed the eventual charge, so a ceiling sized to the expected cost of a trip can bind unexpectedly mid-trip — see card limits.

Meals attract disproportionate attention relative to their share of spend: individually small, numerous, socially charged and frequently the subject of policy that costs more to administer than the amounts involved. A stated expectation plus the standard documentation threshold handles most cases; case-by-case approval mostly generates work.

The largest structural change in employee spending over the past decade is that individual contributors can now buy production software with a card and a work email address. This is a genuine productivity gain and a genuine control problem, and treating it as only one of the two produces bad policy.

The characteristic pattern is a small recurring charge that begins as an individual trial, becomes a team dependency without anyone deciding it should, and appears in the ledger as an unrecognised merchant descriptor. Nobody can say who owns it, what it costs in aggregate, or what breaks if it is cancelled.

• Permit small software purchases rather than blocking them, since blocking mostly relocates them to personal cards
• Issue a vendor-locked credential per subscription so attribution is automatic rather than investigated
• Record an owner and a purpose at the moment the credential is created
• Set a threshold above which a purchase becomes a procurement conversation
• Review recurring charges on a schedule, since subscriptions never announce that they are no longer needed

The vendor-locked credential is the highest-leverage mechanism here, because it converts an attribution problem into a naming problem: the card is the answer to "what is this charge". Virtual cards covers issuance patterns and the virtual card guide the full lifecycle. For early-stage companies where software is most of the spend, the startup card guide is more specific.

The moments when spending authority begins and ends are the moments most likely to be handled by nobody, because they sit between finance, IT and the hiring manager.

On joining, no new employee should have to spend their own money because their access was not ready. The card is issued from the role template on or before day one, and — equally important — the person is told what their authority is. Handing someone a card without explaining the ceiling, the documentation threshold and the escalation route guarantees that their first encounter with the policy is a decline or a chase.

On leaving, authority should end when employment does, without leaving orphaned obligations behind. The step most often missed is not cancellation but reassignment: closing a departing person’s vendor-locked credentials without transferring ownership converts an orderly handover into failed renewals weeks later. Outstanding receipts should be collected while the person still has access.

Both belong in checklists that already exist rather than in a separate finance process. The instrument-level mechanics are on employee cards; the principle here is that access should never outlive the reason it was granted.

Something will eventually be bought that should not have been. How a company handles the first few of these sets the tone for everything afterwards, and the instinct to respond with across-the-board tightening is almost always wrong. The useful first move is to classify what actually happened, because four different situations arrive looking identical in a review queue.

Only one row of that table is a conduct issue. Responding to the other three as though they were teaches people to hide spending, which removes the visibility that would have caught the next problem. Reactive tightening after a single incident is the same mistake at scale: it pushes spend off-card for everyone in response to one person’s error.

Genuine disputes — a charge the company does not recognise, a duplicate, a subscription that continued after cancellation — are a different process, run with the provider and the merchant rather than internally. Freezing the instrument, recording the timeline and preserving evidence are the sensible first steps; what happens next depends on the provider’s process, which is theirs to define.

Most companies measure compliance, which tells you how well people follow the rules and nothing about whether the rules are right. A small set of better signals is available and mostly ignored.

Read as a set, these answer a question compliance rates cannot: is the policy helping people do their jobs, or is it something they navigate around? A program with perfect receipt compliance and rising reimbursement claims from cardholders is not working, however good the first number looks.

For adjacent reading: spending controls covers turning policy into configuration, card limits covers sizing and declines, budgets covers ownership and accountability at the group level, and finance teams covers what all of this looks like from the controller’s side of the desk.