Employee Cards

The uncomfortable fact underneath every employee card program is that the person spending is not the person paying. Every mechanism described on this page exists to close that gap without making the job harder to do.

Two failure modes bracket the problem. Delegate too much and the company discovers its spending pattern retrospectively, at which point the only available remedy is an awkward conversation about money already gone. Delegate too little and people either stop buying things they legitimately need or pay for them personally — which reintroduces reimbursement, delays evidence and quietly disadvantages anyone without spare cash.

Between those extremes sits bounded authority: a specific ceiling, specific permitted categories, and a fast route for anything outside them. That combination is what an employee card actually is, and it is why the design work matters more than the choice of provider. The wider program context is on the cards hub and in Brex Corporate Card.

Spending authority

The bounded permission an individual holds to commit company funds without asking first.

Limit template

A reusable set of ceilings and category rules attached to a role rather than to a person.

Evidence threshold

The amount above which supporting documentation becomes mandatory rather than optional.

Escalation route

The defined path for a legitimate purchase that exceeds the holder’s standing authority.

Dormancy

A card that has not been used for a defined period, indicating either a role change or a purpose that no longer exists.

The most consequential decision in an employee card program is whether limits attach to roles or to individuals. Attaching them to individuals feels responsive and produces, within a year, a set of ceilings that nobody can explain and nobody dares change.

Templates fix this by making the ceiling a property of the job. When someone joins, their card inherits the template for their role. When they change role, the template changes with them. When the company decides field engineers need more headroom, that decision is made once and applies everywhere, rather than propagating through forty individual conversations.

Set initial ceilings deliberately generously and tighten with evidence rather than starting tight and loosening under pressure. Tight-then-loose produces a queue of exception requests, teaches people the system is an obstacle, and generates no useful data because the spending never happens on the card. Card limits covers the sizing question in depth.

Card issuance and card revocation should both be steps in checklists that already exist, rather than separate finance processes that run on their own schedule. This is the single cheapest improvement available to most programs and one of the least often made.

The reassignment point is the one most often missed. When a departing employee owned vendor-locked credentials for team subscriptions, closing their cards without transferring ownership converts an orderly handover into a set of failed payments and service interruptions. Virtual cards covers rotation and reassignment mechanics.

Documentation policy is where good intentions meet human behaviour, and where most programs quietly fail. The rule that works is simple, uniform and enforced by the system rather than by reminders.

1. Set one threshold

   A single amount above which a receipt is mandatory, applied to everyone regardless of role or seniority. Multiple thresholds create ambiguity and ambiguity creates non-compliance.

2. Require capture on the day

   Evidence is easiest to obtain in the minutes after a purchase and hardest three weeks later. Same-day capture is the whole game.

3. Ask for a memo only where it adds information

   A note explaining business purpose is valuable on ambiguous spend and pure friction on an obvious one. Requiring it universally trains people to type "business expense" into every field.

4. Automate matching where possible

   Forwarded email receipts and vendor integrations remove most manual attachment work for recurring charges.

5. Escalate systematically, not personally

   Missing documentation should generate a consistent reminder and a defined consequence, not an individual chase from whoever noticed.

The purpose of all this is not tidiness. Receipts are the evidence that a transaction was what it claimed to be, they underpin tax treatment in most jurisdictions, and they are the first thing requested in any review. A program with excellent controls and poor documentation produces an auditable-looking system that cannot actually be audited. See expense controls and business expenses.

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

Category rules permit or block whole classes of merchant based on the classification code returned at authorisation. They are genuinely preventive — a blocked category declines at the terminal — which makes them powerful and, misapplied, extremely annoying.

The important limitation is that classification is assigned by the merchant’s acquirer, not by you. Codes are broad, occasionally counter-intuitive, and a single business can present under a category you would not predict. A rule that blocks an entire class to prevent one specific behaviour will also block legitimate purchases that happen to sit in the same class, and the employee will experience that as a mysterious decline in front of a supplier.

• Block narrowly and for clear reasons, rather than allow-listing a short set of categories and blocking everything else
• Expect edge cases, and make the escalation route fast enough that a decline is a minor inconvenience
• Tell holders which categories are blocked, so a decline is comprehensible rather than alarming
• Use vendor-locked virtual credentials where the requirement is really about one specific merchant
• Review the rule set periodically against actual declines, which is the only honest measure of whether it fits

That last point is worth operationalising. A decline log is the most useful diagnostic a card program produces: a cluster of legitimate declines in one category is direct evidence that a rule is miscalibrated. Spending controls and the spending controls guide go further into rule design.

Approvals do something different from limits, and conflating the two produces programs that are simultaneously restrictive and slow. A limit prevents. An approval assigns a decision to a named person. Both are useful; only one of them stops a transaction.

The practical guidance is to route approvals to budget owners rather than up a management chain. The person accountable for a budget has both the context to judge the request and the incentive to answer quickly; a senior manager two levels removed has neither. Budgets covers how that ownership is established.

Response time is a control parameter, not an administrative detail. An escalation route that takes two days is functionally a block, and people route around blocks — usually onto a personal card, occasionally onto a colleague’s.

Dormant cards are the accumulated sediment of every card program. Each one was issued for a reason that has since ended, nobody has any incentive to close it, and collectively they represent live spending authority attached to purposes that no longer exist.

A scheduled review catches them cheaply. The trigger is simple — no activity for a defined period — and the action is a question to the owner: is this still needed? Cards with a recorded purpose answer themselves. Cards without one require an investigation, which is exactly why purpose should be captured at issuance.

• Run the review on a schedule rather than after an incident, since reactive review only ever happens too late
• Check dormancy, unused headroom and role changes in the same pass
• Treat any card whose owner has left as an immediate closure, not a review item
• Reduce ceilings that have gone consistently unused, rather than leaving standing authority nobody needs
• Record the outcome, so the next review starts from a known position instead of from scratch

Quarterly suits most organisations. The review is not primarily about fraud — it is about keeping the program’s picture of itself accurate, which is what makes every other control meaningful. Employee spending treats access drift as the central long-run risk in card administration.

It is worth stating plainly: employees do not resent spending controls. What they resent is being made to fund company purchases out of their own money and wait to be paid back.

Reimbursement-based models push a working capital problem onto individuals. Someone books a flight, waits three weeks, and absorbs the cost in the meantime. For senior staff this is an irritation. For junior staff, 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 ones least able to do parts of their job. A card with a sensible ceiling removes the problem entirely.

The right-hand column is not a list of hypotheticals; it is the most common pattern in programs that people complain about. Almost all of it is a communication failure rather than a policy failure, and almost all of it is fixable without changing a single limit.

A short catalogue of the patterns that recur, and the structural response to each. None of them are exotic — which is precisely why they are worth naming.

The common thread is that most employee card problems are design problems wearing the costume of behaviour problems. People route around friction; if the program generates friction in the wrong places, the routing around it is the predictable outcome rather than a discipline failure.

For the surrounding topics, see employee spending for policy, virtual cards for purpose-scoped issuance, and expense management for what happens after the transaction posts. This is an independent reference project — we describe how these programs work rather than operating one, and we hold no accounts and take no applications.