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.
Overview
Every company has a working definition of a business expense, and most of them are unwritten. That shows up at review, when two reasonable people disagree about the same transaction and neither can point at a rule.
A cost becomes a business expense when three conditions hold: it was incurred for the business rather than private benefit, somebody with authority permitted it, and there is enough evidence to show a reviewer what happened and why. Miss one and you have something else — a personal cost, an unauthorised purchase, or an item nobody can sign off.
This page is written from the operational side: how companies organise, categorise and evidence expenses so that a card program produces usable accounting data. It is deliberately not written from the tax side, because deductibility and apportionment are jurisdiction-specific and fact-specific. This site is an independent reference project, not an adviser, an issuer or a software vendor, and nothing here is tax, legal or accounting advice.
- Business purpose
- The written explanation of why the company incurred the cost. The most valuable field on an expense record, and the one no document supplies.
- Category
- The operational grouping used to think about spend — software, travel, marketing — which then maps onto an accounting code.
- Chart of accounts
- The structured list of ledger accounts a company posts to. Categories exist to be translated into this.
- Cost centre
- The team or function that bears the cost, used for internal accountability rather than statutory reporting.
- Capitalisation
- Treating an outlay as an asset on the balance sheet rather than a cost taken in the current period.
What makes an expense a business expense
Those three conditions are worth taking one at a time, because companies fail at different ones and the remedies differ.
Purpose
The cost has to serve the business. This is where mixed-use items get difficult: a laptop used partly at home, a phone bill, a dinner that is half client meeting and half friendship. The honest test is whether the company would still have paid if the personal element were removed.
Authority
Someone had to be allowed to commit the money. In a card program this is usually implicit — the card exists, the limit permitted it, so authority was delegated in advance. That is exactly why card limits and issuance policy are an expense question, not only a controls question.
Evidence
A reviewer, an auditor or a successor should be able to reconstruct what happened without asking anyone. Evidence is a receipt, an invoice, a contract, an order confirmation — plus the written purpose that explains why the document exists.
Attribution
Not a condition of being an expense, but of being a useful one. An expense with no owner, team or project is a number in the accounts that nobody can manage or question.
A card program changes the shape of these conditions rather than removing them. Authority moves forward in time, embedded in the card at issuance rather than granted per purchase. Evidence moves backwards, because the transaction posts first and the document catches up. Purpose does not move at all: it still has to come from a human who knows why the money was spent, which is the structural reason expense workflows always keep a manual element. Expense automation examines that limit.
The categories companies actually track
Category lists proliferate. A useful one is short, unambiguous at the point of coding, and built around questions someone actually asks. Most card-heavy companies converge on something close to the set below.
| Category | What it typically holds | Characteristic difficulty |
|---|---|---|
| Software and SaaS | Per-seat tools, developer services, design and productivity subscriptions | Shadow purchases by individual teams; renewals nobody notices until they post |
| Cloud infrastructure | Compute, storage, bandwidth, managed data services | Usage-based amounts that vary every month and resist any fixed ceiling |
| Travel | Flights, rail, accommodation, ground transport, visas | Multi-leg trips split across bookings, cardholders and periods |
| Meals and entertainment | Team meals, client hospitality, events | Attendee lists, mixed personal benefit, and treatment that varies by jurisdiction |
| Marketing and advertising | Ad platforms, sponsorships, content production, events | Large recurring platform charges that need campaign-level attribution |
| Professional services | Legal, accounting, recruitment, consulting | Invoices that arrive on their own schedule and rarely match the card cycle |
| Equipment and hardware | Laptops, monitors, phones, lab and production equipment | The expense-versus-capital-item question, decided by policy rather than by the receipt |
| Office and facilities | Rent-adjacent costs, utilities, supplies, cleaning, furniture | Shared costs that need allocating across teams rather than assigning to one |
| Subscriptions and memberships | Publications, professional bodies, community and support plans | Small recurring amounts that individually look trivial and collectively are not |
| Contractors and freelancers | Individuals and agencies paid outside payroll | Classification, project attribution and evidence of what was delivered |
A general operational taxonomy used on this site. Account names, groupings and treatment differ by company, framework and jurisdiction.
Two of those categories cause a disproportionate share of the pain: software and cloud. Both recur, both are bought by people outside finance, and both produce merchant descriptors that mean nothing to a reviewer. They are also where a vendor-locked virtual card most obviously pays for itself, because the instrument identifies the spend before anyone has to interpret a descriptor string.
Expense, purchase order and capital item
These three words describe different things and are routinely used as if they were interchangeable. Conceptually they differ on two axes: when the commitment is recorded and how long the benefit lasts.
| Concept | When it is recorded | What it represents | Where it usually appears |
|---|---|---|---|
| Expense | When incurred or paid | A cost consumed in the current period | The income statement for the period |
| Purchase order | Before the cost is incurred | A commitment to buy, made in advance of the invoice | A commitment ledger, then matched to an invoice |
| Capital item | When acquired, then spread over time | An asset expected to deliver benefit across multiple periods | The balance sheet, with a charge taken each period |
A conceptual distinction only. Recognition rules, capitalisation thresholds and useful-life assumptions are set by the applicable framework and company policy.
The purchase order model matters because it front-loads the control: a PO records what the company committed to before the invoice appears, so budget consumption is visible while it is still possible to change your mind. Card programs do something similar by different means, since a card issued for a defined purpose with a defined ceiling is a pre-authorised commitment — which is why budgets and PO systems solve overlapping problems.
The capital question is where card spend most often gets mis-coded. A hardware purchase on an employee card looks like any other line in the feed, but the treatment may differ entirely. Companies handle this with a written policy — a threshold and a definition — which has to be known by whoever codes the item, not only by the accountant reviewing it later. Where the underlying question is really about settlement rather than treatment, business credit card vs charge card is the relevant comparison.
Documentation and why business purpose matters more
Companies obsess over receipts and under-invest in purpose, which is the wrong way round. A receipt records a transaction: merchant, items, amount, date. It answers what. It does not say why the company needed it, who benefited, which project it served, or whether it was reasonable to buy. Those are the questions reviewers actually ask, and the only source is a person writing a sentence.
What a receipt proves
- That a transaction occurred, with a specific merchant, on a specific date
- The amount, and often its composition
- Any tax shown separately, where the format includes it
- That the charge in the feed is a real purchase
What only a business purpose can supply
- Why the company needed this at all
- Which project, client, campaign or team the cost serves
- Who was present or who benefited, where that is relevant
- Whether an apparent anomaly has an ordinary explanation
A good business purpose is short, specific and written by someone who was there. "Client dinner" is not a purpose; "dinner with the account team at a named client during the contract renewal" is. The difference costs the cardholder seconds and saves a reviewer an investigation three weeks later, when nobody remembers.
Documentation expectations belong in written policy rather than being improvised per transaction: what evidence is required, above what value, how quickly, and what happens when it is missing. This site publishes no thresholds or retention periods, because they depend on jurisdiction, sector and accounting framework. Enforcing whatever you choose is the subject of expense controls; collecting evidence with minimum friction is the subject of expense automation.
Recurring and one-off spend
These two behave differently enough that running one process over both wastes effort. A recurring charge is predictable in merchant, approximate in amount and repeated indefinitely. A one-off is unpredictable and will never be seen again.
| Aspect | Recurring spend | One-off spend |
|---|---|---|
| Coding | Set once as a rule against the vendor or card, then left alone | Decided per transaction, with the purpose supplied at the time |
| Review focus | Whether it should still exist and whether the amount changed | Whether it was appropriate, authorised and properly evidenced |
| Control mechanism | A vendor-locked card with a ceiling and an owner | A per-transaction limit and a documentation requirement |
| Characteristic failure | A subscription nobody owns renewing for years | An unusual purchase with no explanation attached |
| Right cadence | A periodic review of the whole population | Handled once, at review, and then closed |
Recurring spend is where card design does the most work. If every subscription sits on its own virtual card with a named owner, the periodic review is a list you can read: vendor, owner, amount, still needed or not. If they share one card, the same review is archaeology. Virtual cards and the virtual card guide cover the issuance patterns.
Categorisation as an accounting mapping problem
The most useful reframing on this page: a category is not a label, it is a mapping. Each expense is assigned along several independent dimensions at once, and collapsing them into one field is why category lists become bloated and inconsistent.
- Account — the general ledger line the amount posts to. Determined by the accounting framework and the chart of accounts, and the least negotiable dimension.
- Cost centre — the team, department or function that bears the cost. Internal, used for accountability and management reporting.
- Project or campaign — an optional dimension for companies that need cost visibility below team level, such as client work or product initiatives.
- Entity and location — relevant as soon as a company operates more than one legal entity or country, and frequently forgotten until it is urgent.
- Tax fields — whatever the local regime requires the record to carry. Jurisdiction-specific, and the dimension most often filled in wrongly by non-specialists.
Two things follow. A single "category" field forced to carry all five dimensions inevitably produces categories like Marketing software for the German entity, which is a symptom rather than a taxonomy. And most dimensions can be inherited from the card rather than chosen at coding time — cost centre from the card owner, project from the card’s stated purpose. That inheritance is how good card structure reduces expense work, as the expense management hub sets out.
Who owns categorisation
Ownership is usually left implicit, and that ambiguity is why coding queues stall. There are three plausible owners, each with a real claim.
-
The cardholder
Knows the purpose and can supply it immediately. Does not know the chart of accounts and should not be asked to learn it. Best asked for purpose and project, not for an account code.
-
The budget or cost-centre owner
Knows whether the spend was appropriate and which team it belongs to. The right approver for exceptions and unusual items, and the right person to run a periodic review of recurring spend.
-
Finance
Owns the account mapping, the consistency of treatment over time and the correctness of the close. Should design the rules and adjudicate disputes rather than type in codes.
The workable division: the cardholder supplies facts, the budget owner supplies judgement, finance supplies the mapping. Asking cardholders to select ledger accounts produces poor data because the question is outside their competence; asking finance for business purpose produces delay, because finance was not there. Each dimension should be filled in by whoever knows it. Employee spending covers the policy side, and the corporate finance guide how the split shifts as a finance function grows.
Common categorisation disputes
The same arguments recur everywhere. None has a universally correct answer; all have a correct process — decide once, write it down, apply it consistently.
- Is a developer tool bought by one engineer software spend, or infrastructure, or a team cost?
- Does a conference ticket belong to travel, marketing or professional development?
- Is a team meal a staff cost, an entertainment cost, or something with different treatment again?
- Does a contractor building one feature sit in professional services or in the product cost centre?
- Should a shared office cost be allocated across teams or held centrally?
- Is a laptop an expense or a capital item, and does the answer change with the amount?
- Which entity bears a cost incurred by a person employed by one and working for another?
The damage is rarely the individual decision — it is inconsistency over time, which makes period-on-period comparison meaningless and forces the same argument every quarter. A one-page written convention, owned by finance and visible to everyone who codes, resolves more of this than any software. Where a dispute has tax or statutory consequences, it belongs with a qualified adviser instead.
This site is an independent reference project, not affiliated with or operated by Brex or any issuer. Nothing on this page is a rule that applies to your company.
FAQ
Frequently asked questions
What actually makes a cost a business expense?
Operationally, three things together: it was incurred for the business rather than for private benefit, somebody with authority permitted it, and there is enough evidence for a reviewer to reconstruct what happened.
Whether it is also deductible is a separate, jurisdiction-specific question for a qualified tax adviser rather than a reference site.
Is a receipt enough on its own?
Rarely. A receipt establishes what was bought, from whom, for how much and when. It says nothing about why the company needed it, which project it served or who benefited — and those are the questions reviewers ask.
That is why the business purpose field carries more weight than the document. It is also the field that cannot be automated, because only the person who spent the money knows the answer.
How is an expense different from a purchase order?
A purchase order records a commitment before the cost is incurred, so budget consumption is visible while the decision is still reversible. An expense records a cost that has already been incurred.
Card programs achieve something structurally similar by issuing a card with a defined purpose and ceiling, which is a pre-authorised commitment. Budgets covers how that envelope model works.
When should a purchase be treated as a capital item rather than an expense?
That is determined by the applicable accounting framework and by a written company policy setting a threshold and a definition — not by anything you can read off a receipt.
The operational point is that the policy must be known by whoever codes the transaction, and that items likely to be capital should be routed to a named reviewer automatically rather than left to the cardholder to judge.
How many expense categories should a company maintain?
As few as answer the questions management actually asks. Each extra category adds a decision to every relevant transaction and another way for coding to become inconsistent.
Most of the apparent need for more categories is really a need for more dimensions — cost centre, project, entity — which should be separate fields rather than variations of the category name.
Who should assign the category: the employee or finance?
Split it by who knows the answer. The cardholder supplies the business purpose and, where relevant, the project. The budget owner judges whether the spend was appropriate. Finance owns the mapping to the chart of accounts and its consistency over time.
Asking cardholders to pick ledger accounts produces poor data because the question is outside their competence, not because they are careless.
Sources and reference basis
- Reference General accounting reference material on the chart of accounts, cost centre allocation, commitment accounting and the distinction between expensed and capitalised outlays.
- Practice Common finance-operations conventions for expense categorisation, documentation policy and periodic review of recurring vendor spend.
- Reference Payment-industry documentation describing merchant descriptors and merchant category codes, and their limits as a basis for accounting classification.
- Method Our methodology and fact-checking policy describe how these pages are researched, written and corrected.