Spend cluster hub
Spend Management for Business Cards
A card decides how money leaves the company. Spend management decides whether it should have left, who was allowed to authorise it, and what evidence exists afterwards. This hub sets out the control stack that connects the two, and routes you to the four topics underneath it — spending controls, budgets, card limits and employee spending.
Information only. This site is a reference project. We do not provide account access, financial services, card applications, payments, credit decisions or official support, and we never ask for account or financial credentials.
Definition
What spend management means
The phrase is used loosely, often as a synonym for expense software. It is more useful to treat it as a discipline with a specific job: converting written spending policy into rules that a payment network can evaluate, and into evidence an accountant can rely on.
Spend management is the set of decisions a company makes before money is committed. Who holds spending authority, how much of it, over what categories, for how long, and what has to be true for a purchase to be permitted at all. Expense management, by contrast, is what happens after a transaction posts: coding, documentation, review and reconciliation. The two are continuous — the same transaction passes through both — but they use different mechanisms and fail in different ways.
The distinction matters because most frustration with card programs comes from applying the wrong layer to the problem. A policy document does not decline a transaction. An approval workflow does not prevent a purchase already made. If the goal is prevention, the mechanism has to sit at authorisation; if the goal is accountability, it sits in budgets and review.
People who arrive here searching for a brex corporate card or a brex business credit card are frequently asking a spend management question wearing a product question’s clothes. "Which card should we get" usually resolves into "how do we let fifteen people buy things without losing control of what they buy" — and that is answered by structure, not by brand. The cards hub covers the instruments; this cluster covers the governance around them.
This site is an independent reference project. We are not Brex, not an issuer, not a broker and not affiliated with any provider. There is no application here, no account, no pricing and no eligibility guidance — those are commercial terms that vary by company and provider and should be read from the source. What we publish is the structural vocabulary, so provider documentation is readable when you reach it.
- Spending authority
- The bounded permission a person, team or card holds to commit company money without asking first.
- Control
- A rule that changes what happens to a transaction — either by blocking it at authorisation or by flagging it afterwards.
- Budget
- An owned ceiling applied to a group of spend rather than to a single card or transaction.
- Authorisation
- The real-time decision, made in a fraction of a second, about whether a specific transaction is permitted.
- Evidence
- The receipt, memo, coding and approval record that makes a posted transaction auditable.
Model
The control stack
Six layers sit between a written policy and a reconciled ledger entry. Each one does something the others cannot, and a weakness at any layer shows up as a symptom somewhere else.
The most common diagnostic error is treating the stack as a single thing called "controls". Policy is a human artefact; issuance is an operational act; limits and category rules are machine-evaluated; evidence is collected from people; reconciliation is an accounting process. Fixing a reconciliation problem by tightening limits, or a limits problem by writing more policy, is why programs get simultaneously stricter and less effective.
| Layer | What it decides | Where it lives | Typical failure |
|---|---|---|---|
| Policy | What the company considers acceptable spend | A written document people can read | Written in prose that cannot be expressed as a rule |
| Issuance | Who holds an instrument and for what purpose | Card creation and assignment | Cards issued without a recorded purpose or owner |
| Limits | The ceiling on each card, transaction and period | Card configuration | Set once at onboarding and never revisited |
| Authorisation | Whether this specific transaction is approved | The payment network, in real time | Rules so broad they permit everything, or so narrow they decline legitimate work |
| Evidence | Whether the purchase is documented and explained | Receipts, memos and approvals after posting | Collected weeks late, under pressure, at close |
| Reconciliation | Where the transaction lands in the ledger | The accounting system | Manual coding of every line because enrichment was skipped |
A model used throughout this site to organise the topic. Platform terminology varies; the sequence of decisions does not.
- 1RequestEmployee or system requests a card for a defined purpose.
- 2PolicyLimit, category and expiry rules are attached before issuance.
- 3IssueCard credentials are generated for the approved scope.
- 4AuthoriseEach transaction is checked against the rule set in real time.
- 5ReconcileTransaction data is matched to receipts and the general ledger.
Read downward and the stack answers a question that policy documents rarely answer explicitly: at which moment is this rule enforced? Only the limits and authorisation layers can stop a payment. Everything above them is preparation, and everything below them is documentation. Spending controls works through that boundary in detail, and the spending controls guide covers translating a written policy into configurable rules.
Cluster map
The four pages in this cluster
Each page takes one layer of the stack and treats it properly. Read them in this order if you are designing a program from scratch; read them individually if you already know which part is broken.
Spending Controls
What a control actually is, the difference between preventive and detective rules, merchant category codes and their imprecision, allow and block lists, approval routing and how to tune a rule set that has drifted.
Read more EnvelopesBudgets
Funded envelopes versus tracked targets, budget owners and accountability, department and project scopes, rollover and reset behaviour, and when a budget is the wrong instrument entirely.
Read more CeilingsCard Limits
Limit types and how each is evaluated at authorisation, the effect of pending holds, the difference between a spending limit and a credit line, sizing principles and handling declines gracefully.
Read more PeopleEmployee Spending
Delegated authority as a management problem: policy design and communication, the reimbursement model versus the company-card model, travel, meals, software purchases and out-of-policy spend.
Read moreThe four are deliberately separated because they are separate mechanisms. A budget and a card limit can both bind on the same purchase and neither substitutes for the other. A spending control can prevent a transaction that policy permits, and a policy can permit something no control enforces. Treating them as one undifferentiated setting is how companies end up with a program nobody can explain.
Mechanics
Preventive and detective control
Every control in a card program belongs to one of two classes. Knowing which class a given mechanism belongs to tells you exactly what it can and cannot promise.
A preventive control is evaluated before the money moves. It runs during authorisation, and its only outputs are approve or decline. A detective control is evaluated after posting. It cannot undo the transaction; it can flag it, route it, escalate it and demand documentation. Both are necessary. Confusing them produces control frameworks that read impressively and prevent nothing.
| Mechanism | Class | Moment of effect | What it can promise |
|---|---|---|---|
| Per-transaction limit | Preventive | At authorisation | A single purchase above the ceiling will not complete |
| Merchant category rule | Preventive | At authorisation | A merchant in a blocked classification will be declined |
| Per-period limit | Preventive | At authorisation, cumulatively | Total card spend in the window cannot exceed the ceiling |
| Budget | Mostly detective | Continuously, across a group | Visible consumption and a named owner; enforcement depends on configuration |
| Approval route | Either | Before request, or after posting | A decision assigned to a named person, not a guaranteed block |
| Receipt requirement | Detective | After posting | Documentation exists before the item is reconciled |
| Exception review | Detective | Periodically | Patterns are noticed; individual transactions are not stopped |
Classification of common mechanisms. Some platforms allow budgets to decline at authorisation; where that is available, the budget becomes a preventive control.
The practical consequence is that a program relying entirely on approvals and receipts is retrospective, however elaborate it looks on paper. Conversely, a program relying entirely on hard limits generates a stream of declines and no explanation of what was bought. A working design uses preventive controls to bound the blast radius and detective controls to create accountability inside those bounds. Card limits covers the preventive side; expense controls covers the detective side after the transaction posts.
Cards
Where the instrument meets the control layer
Controls are configured per instrument, so the shape of your card estate determines what is controllable at all. This is the point where card selection and spend design stop being separate conversations.
A single high-limit card shared by a team is not controllable in any meaningful sense: every rule applied to it applies to everyone, every transaction has ambiguous ownership, and revocation punishes the whole group. Split the same spending across purpose-scoped instruments and each one carries its own ceiling, its own category permissions and its own owner. That is why issuance design precedes control design rather than following it.
Brex Corporate Card
Company-liable programs with centralised issuance — the structure that makes per-card policy possible in the first place.
Read more InstrumentVirtual Cards
One credential per vendor, subscription or project, with the ceiling and expiry attached before the first transaction runs.
Read more InstrumentEmployee Cards
Role-based issuance and limit templates. The card-side counterpart to the policy questions covered in this cluster.
Read more UmbrellaBrex Card
The general explainer on company card programs, instrument types and how transactions reach the ledger.
Read more CreditBrex Business Credit Card
Credit and statement mechanics, and why a credit line is a different constraint from a spending limit.
Read more HubCards hub
The full card taxonomy: which search term means what, and which instrument answers which need.
Read moreOne useful heuristic: issue one instrument per distinct spending purpose rather than one per person. A person needs a card that works in many places; a subscription needs a card that works in exactly one. The second kind is self-describing at reconciliation, which removes a large share of the manual investigation work in software-heavy companies — a point the virtual card guide develops in full.
Reconciliation
Downstream: expense management
Spend management ends at the moment of authorisation. Everything after that is expense management, and the quality of the handover between the two determines how much manual work lands on a finance team at close.
A card authorisation carries very little information: an amount, a merchant descriptor, a timestamp and a merchant category code. Everything a controller actually needs — business purpose, project, cost centre, tax treatment, receipt — has to be attached afterwards. Well-designed spend controls make that attachment cheap, because the instrument already encodes the answer. A vendor-locked virtual card does not need to be coded by hand; the card is the coding.
- Expense management The cluster hub: how posted transactions become categorised, documented, reconciled records.
- Business expenses Categories, business purpose, documentation standards and what makes an expense defensible.
- Expense controls The detective layer: review queues, policy flags, thresholds and audit evidence.
- Expense automation Where automated matching and coding reliably remove manual work — and where they do not.
The reverse is also true: expense data is the only honest feedback loop for spend design. Recurring exceptions in one category mean a rule is miscalibrated. A persistent receipt backlog in one team means the evidence threshold is unrealistic or the capture route is broken. Reading business expenses as a diagnostic on your controls is more productive than reading it as a filing problem.
Practice
Sequencing a spend program
If you are building this from nothing, order matters. Most programs that feel chaotic were assembled in the wrong sequence — controls before policy, or approvals before limits.
-
Write the policy in rule-shaped language
Not "spend responsibly" but "purchases above a defined threshold require a receipt" and "these categories are not permitted on employee cards". If a sentence cannot be turned into a setting, it is guidance, not policy. See spending controls.
-
Decide the issuance model
Who gets an instrument, of what type, for what recorded purpose. Role templates beat individual decisions. The employee cards page covers template design.
-
Size the limits
Set the smallest ceiling that does not generate weekly exception requests, then adjust with evidence. Card limits explains why starting generous and tightening beats the reverse.
-
Group spend into owned budgets
Assign each meaningful pool of spend to a named owner with visibility into consumption. Budgets covers scopes, rollover and over-budget handling.
-
Set one evidence threshold
A single amount above which documentation is mandatory, applied uniformly. Multiple thresholds create ambiguity, and ambiguity creates non-compliance.
-
Review on a schedule, not after an incident
Dormant cards, unused headroom, declined-transaction patterns and role changes in one quarterly pass. Reactive review always happens too late — see employee spending.
- Can you name the owner of every card in the estate, without looking it up twice?
- Does every card have a recorded purpose that still exists?
- Is there a written escalation route, and does it resolve in hours rather than days?
- Do you review declines as a diagnostic, or only as complaints?
- Could someone leaving the company tomorrow leave orphaned recurring charges behind?
- Is any material spend still happening on personal cards because the program made it easier?
Context
Company size changes the answer
The same six layers exist at every scale, but the amount of structure worth building differs enormously between a ten-person company and a three-hundred-person one.
Early-stage companies
Spend is concentrated in software and cloud infrastructure, there is no finance headcount, and card structure has to substitute for process. Virtual cards per vendor do most of the work. See startups and the startup card guide.
Growing companies
Somewhere between twenty and two hundred people, informal spending stops working. This is where limits, budgets and approval routes stop being optional and start being the thing that keeps close manageable. See growing businesses.
Established finance functions
Controllers need policy enforcement, audit evidence and a clean month-end rather than a payment method. The emphasis shifts from prevention to reconciliation quality. See finance teams.
Small businesses
Fewer cardholders, but the same subscription sprawl and the same reconciliation burden on someone who has another job as well. Simplicity beats completeness. See small business.
If you are still deciding between card structures rather than designing controls, the comparison pages are the better starting point: corporate card vs credit card resolves the most common confusion, and brex vs other corporate card solutions sets out a neutral evaluation framework you can apply to any provider without relying on marketing claims.
FAQ
Frequently asked questions
What is the difference between spend management and expense management?
Spend management is everything that happens before money is committed: policy, issuance, limits and the authorisation decision. Expense management is everything after a transaction posts: coding, documentation, review and reconciliation.
The same transaction passes through both, but only the spend side can prevent anything. If a mechanism runs after posting, it produces evidence and accountability rather than prevention. Expense management covers the second half.
Do I need budgets if every card already has a limit?
They constrain different things. A card limit binds one instrument; a budget binds a group of spend that may run across several cards and several people. A department can be well inside every individual limit and far over its budget, or the reverse.
Most programs use both, with limits sized to the role and budgets owned by whoever is accountable for the outcome. See budgets and card limits.
Can spending controls block a specific merchant?
Category-level control is standard, because a merchant category code is returned at authorisation. Control over one named merchant is narrower and is usually achieved by issuing a virtual card locked to that vendor rather than by writing a rule. Virtual cards explains how that scoping works.
How tight should spending controls be?
Tight enough that a mistake is bounded, loose enough that ordinary work never requires an exception. The failure mode people underestimate is over-tightening: when the card becomes unreliable, spending migrates to personal cards and reimbursement, which destroys exactly the visibility the controls were meant to create.
There is no universal setting. The right ceiling depends on the role, the company and the spending pattern, and it should be revisited rather than fixed once.
Does this site provide spend management software or accounts?
No. This site is an independent, non-commercial reference project. There is no login, no account area, no application form, no pricing and no request for card, banking or identity information anywhere on the site. We describe how these programs work; we do not operate one.
Where do I find actual limits, fees or eligibility rules?
From the provider directly. Those are commercial terms that vary by company, change over time and often depend on an underwriting assessment. We deliberately publish none of them, because a number reproduced here would be wrong for most readers and stale for the rest.
How are these pages researched?
From publicly available documentation, payment-industry reference material and standard corporate card administration practice. Our methodology describes how pages are built and our fact-checking policy describes how claims are verified and corrected.
Sources and reference basis
- Reference General payment-network reference material describing how authorisation decisions are made and how merchant classification codes are assigned and returned.
- Practice Common corporate card program administration patterns: role-based issuance templates, budget ownership, evidence thresholds and periodic access review.
- Reference Established internal-control literature on the distinction between preventive and detective controls, delegation of authority and segregation of duties.
- Method Our methodology and fact-checking policy describe how these pages are researched, written and corrected.