Brex Corporate Card

The defining feature of a corporate card is delegation. The company holds the account and hands out bounded spending authority, instrument by instrument, to people who are spending money that is not theirs.

That single fact explains the whole category. Consumer cards need no administrator because the holder and the payer are the same person. Corporate cards need an administrative layer precisely because they are not: someone has to decide who receives an instrument, how much authority it carries, what evidence is required afterwards, and when it is withdrawn. Everything described on this page is a consequence of that separation.

If your question is about settlement — whether a balance can be carried — that is a different axis, covered on Brex Credit Card. If you are trying to work out whether "corporate card" and "corporate credit card" name the same thing, Brex Corporate Credit Card is written for exactly that. And for the general vocabulary of company card programs, start at Brex Card or the cards hub.

Company liability

The obligation for the balance sits with the business entity rather than with an individual cardholder.

Program administrator

The role authorised to issue instruments, set limits, change rules and revoke access.

Instrument

One card credential, physical or virtual, with an owner and a rule set attached from the moment it is created.

Access review

A scheduled check of who holds instruments, at what limits, and whether each is still justified.

A corporate card program can be read as four layers stacked on top of a single account. Each layer answers a different question, and problems in a program almost always trace back to one specific layer rather than to "the card".

The reason this framing helps is that the layers are independently fixable. A company drowning in month-end work has a reconciliation problem, not a card problem, and issuing fewer cards will not help. A company suffering surprise spend has a policy or issuance problem, and a better accounting integration will not touch it.

The layer that most often goes undesigned is governance: who is allowed to change a limit, who approves an exception, and how often access is reviewed. Programs rarely fail because a rule was set wrongly on day one. They fail because rules drifted for eighteen months with nobody explicitly responsible for them. Employee spending treats that drift as the central operational risk.

Physical instruments remain necessary because a real share of company spending happens in the world: travel, transport, hospitality, client meetings, hardware, on-site purchasing. Anywhere a card has to be tapped, inserted or handed to someone, a digital credential is awkward at best.

The important distinction is that a physical card in a managed program is not the same object as a physical card in a personal wallet. It carries the program’s real-time policy wherever it goes. A decline at a merchant is not a malfunction; in a well-configured program it is the control layer behaving exactly as designed, and it is far cheaper than the conversation that would otherwise happen three weeks later.

• Assigned to a named individual, so every transaction has an owner the moment it posts
• Subject to the same limits and category rules as every virtual instrument in the program
• Freezable in seconds without disturbing any other card on the account
• Replaceable without rebuilding the surrounding policy configuration
• Covered by the same receipt and coding requirements as all other spend

Most physical card trouble is lifecycle trouble rather than policy trouble. Two patterns account for the majority of it: instruments that outlive the holder’s need for them, and limits set once during onboarding and never revisited as the role changed. Both are cheap to fix on a schedule and expensive to fix after an incident.

Virtual issuance is where corporate programs diverge most visibly from traditional business banking. Rather than one credential used everywhere, a credential is minted for a purpose and bounded before its first authorisation.

For a corporate program specifically, virtual cards solve an attribution problem that grows quadratically with size. In a company of two hundred people, a charge from an unfamiliar merchant descriptor can plausibly belong to any of a dozen teams, and resolving it costs someone an afternoon. A vendor-locked credential collapses that question to zero effort, because the instrument itself is the answer.

The virtual cards page covers scoping, rotation and closure in depth, and the virtual card guide follows a credential from request to retirement.

The behavioural core of a corporate program is that employees are spending company money in situations where nobody is watching in real time. The design goal is not surveillance; it is making the correct action the easy one and the incorrect action structurally difficult.

The commonest self-inflicted wound is over-tightening. Controls that are too restrictive push spending onto personal cards and into reimbursement claims, which is precisely the retrospective, evidence-poor process the card program was meant to replace. Worse, it quietly disadvantages employees who cannot float company costs. Employee cards and card limits cover how to calibrate.

Controls in a corporate program act at three distinct moments, and being precise about which does what prevents a great deal of wasted policy effort.

• Before the purchase — request and approval routes, budget allocation, instrument scoping at issuance
• At authorisation — per-transaction and per-period ceilings, merchant category rules, vendor locks; the only controls that can actually decline a payment
• After posting — receipt requirements, coding rules, exception flags, review queues and audit evidence

A frequent mistake is to invest heavily in the third group while leaving the second largely unconfigured. That produces a program with excellent records of spending it never had any ability to prevent. The inverse mistake — heavy authorisation controls with no documentation discipline — produces tight spending and an unauditable ledger. Both layers are needed, and spending controls, budgets and expense controls each cover one part of the combination.

Card management is the unglamorous administrative work that determines whether a program stays coherent past its first year. It is mostly lifecycle: creating instruments correctly, changing them deliberately, and retiring them promptly.

1. Request

   A named requester states purpose, expected amount and duration. Purpose is what later makes the instrument reviewable.

2. Issue from a template

   Role or purpose templates supply limits and category rules so no instrument is ever created unconfigured.

3. Operate

   The instrument runs under its rules, with exceptions escalating through a defined route rather than by direct limit edits.

4. Review

   On a schedule, check dormancy, unused headroom, role changes and whether the original purpose still exists.

5. Rotate or retire

   Close instruments whose purpose has ended, and rotate credentials where exposure warrants it, rather than leaving them dormant.

6. Offboard

   Cancellation runs in the same checklist as identity and system deprovisioning, on the employee’s last day and not later.

Two administrative habits do most of the work. The first is recording the purpose of every instrument at issuance, because a card with no stated purpose can never be confidently closed. The second is scheduling review rather than triggering it, since reactive review only ever happens after something has already gone wrong.

The reconciliation layer converts a stream of authorisations into accounting records. Corporate programs generate a lot of them, and the difference between a good program and a bad one is almost entirely about how much of that conversion happens without a human.

What arrives automatically is thin: amount, merchant descriptor, timestamp, merchant category code, instrument owner. What a controller needs is richer: business purpose, cost centre, project, tax treatment and supporting evidence. The gap between those two is either closed by rules or closed by people, and only one of those approaches survives headcount growth.

• Default coding derived from the instrument, the vendor or the merchant category rather than chosen manually
• Receipt capture at the point of purchase, since evidence gets harder to obtain every day it is delayed
• Exception-only review, so compliant items pass straight through instead of queuing behind them
• Ledger integration that carries the instrument owner through, keeping accountability intact after posting
• A defined close checklist so the month ends on a schedule rather than when someone finishes

The full workflow is set out in expense management and business expenses, with the automation boundaries in expense automation.

Seen from the finance function, a corporate card program is a data source and a control surface before it is a payment method. It produces near-real-time visibility of committed spend, which is materially more useful than a monthly statement arriving after the decisions have been made.

Card programs are one instrument in a wider finance operation, and they interact with procurement, budgeting and accounts payable rather than replacing any of them. Finance teams and the corporate finance guide cover the surrounding function. If you are still deciding between structures, corporate card vs credit card and corporate card vs business card frame the choice without reference to any particular provider.