Corporate Cards for Growing Businesses

Growth does not break a card program by increasing the amount of money spent. It breaks it by increasing the number of independent spending decisions past the point where one person can hold them all in their head.

That threshold is a cognitive one, not a financial one, which is why it arrives without warning. A founder or office manager who once recognised every vendor on the statement begins encountering names they have never seen. Nothing has gone wrong; the company simply exceeded the capacity of the review method it was using. Every symptom described on this page follows from that single fact.

The failure mode to avoid is over-correcting. Companies that discover they have lost visibility frequently respond by installing an approval process modelled on a much larger organisation, and then spend a year discovering that people route around it. The correct response is narrower: restore attribution and visibility first, and add approval structure only where a real decision needs to be made by someone other than the spender.

Informal setup

A card arrangement that works because everyone knows everyone. Not a mistake — it is efficient right up to the point where it is not.

Attribution

Knowing which team or purpose a charge belongs to without asking. The first thing growth destroys.

Delegated administration

The ability for someone other than the original account owner to issue, freeze, cancel or re-limit cards.

Approval matrix

A rule set mapping request type and amount to a named approver, replacing a single universal approver.

Program migration

Moving a card program between providers or restructuring it in place, with recurring vendor charges attached to existing credentials.

These complaints are rarely phrased as card problems. They arrive as accounting complaints, manager complaints or an unexplained slowdown at month end, which is why the underlying cause often goes unaddressed for several quarters.

The diagnostic value of this table is in the middle column. Attribution problems and visibility problems look identical from the outside — both present as "we do not know what is happening" — but they are fixed by completely different mechanisms. Installing approvals when the real problem is attribution produces bureaucracy and no relief, which is the single most common mistake at this stage.

The governing principle is that a control should cost less than the mistake it prevents, and the cost includes the time of everyone who has to comply with it. A three-step approval on a routine software renewal fails that test comprehensively.

It helps to be precise about what each mechanism actually does. Only card limits and merchant category rules genuinely prevent spending, because only they are evaluated at authorisation. Budgets track and create accountability. Approval routes move a decision to a named person. Receipt requirements produce evidence. Confusing these leads to control frameworks that feel heavy and prevent nothing.

A useful test before adding any rule: name the specific incident it would have prevented. If nobody can, the rule is being added because it feels responsible rather than because it is needed. Spending controls and the spending controls guide work through the translation from written policy into enforceable configuration.

These three are usually introduced together and are frequently confused with one another. They operate at different moments and solve different problems, and a program that uses all three deliberately is far lighter than one that uses one of them for everything.

The sequencing that tends to work is limits first, budgets second, approvals last. Limits are invisible when correctly sized and instantly effective when not. Budgets give managers a number they own, which is usually what "visibility" actually means in practice. Approvals are the most expensive of the three in human time and should be reserved for decisions that genuinely require a second person. Card limits and budgets cover the first two in detail.

One of the clearest signals that a program has outgrown its setup is that a single person is still the only one who can issue a card, raise a ceiling or freeze a credential. That person becomes a bottleneck for routine work and a single point of failure for urgent work.

Delegation here is not the same as delegating spending authority. It is delegating the administration of the program: who may create instruments, change their rules and end their life. Those permissions should be explicit, assigned to named roles, and separated from the ability to spend on the cards being administered — the segregation principle described in solutions for finance teams.

Write these down. Administration rights that exist only as an informal understanding are the ones that get exercised inconsistently and are impossible to review later. Employee spending covers the policy side of delegated authority.

As a company grows it acquires internal boundaries — departments, cost centres, sometimes separate legal entities for a subsidiary or a different country. The card program has to mirror that structure or it will quietly undermine it.

Departmental structure in a card program is mostly about ownership rather than restriction. Each department having its own budget envelope, its own instruments and a named owner turns "who spent this" into a question with an answer, and it lets managers make trade-offs inside their own allocation without escalating. That is usually a net reduction in process, not an increase.

1. Map cost centres before configuring anything

   The card structure should follow the accounting structure. If the two disagree, every month end includes a reconciliation nobody planned for.

2. Give each department an owner, not just a name

   An envelope without a named owner is a report, not a budget. Ownership is the mechanism that produces attention.

3. Separate shared vendors explicitly

   Tools used by several teams need a deliberate allocation rule agreed in advance, or they will be re-argued every quarter.

4. Keep entities genuinely separate

   Where multiple legal entities exist, instruments, statements and coding should not cross the boundary. Intercompany cleanup is expensive and avoidable.

5. Review the structure when the org chart changes

   Reorganisations invalidate budget ownership silently. A short review after each one prevents orphaned envelopes.

The corporate finance guide covers how card structure interacts with the wider finance operation, and expense controls covers coding consistency across departments.

The single-approver model has a precise breaking point: the moment the approver stops recognising the vendors. After that, approval is no longer review — it is a delay with a signature at the end, which is worse than no approval at all because it creates the appearance of control.

An approval matrix replaces one universal approver with a rule that maps the type and size of a request to the person best placed to judge it. Designed well, it usually reduces total approval time, because most requests reach a decision-maker who already understands the context.

• Every route ends at a named role, never at a group inbox with no owner
• Routine, recurring and previously approved items skip the matrix entirely
• The number of steps reflects the cost of being wrong, not the seniority of the requester
• Every approver has a defined deputy, because absence is the main cause of queues
• Escalation thresholds are written down and reviewed, not inherited from a template
• The matrix is measured: if a route approves everything it receives, it is not a control

That last point deserves emphasis. An approval route with a hundred per cent approval rate is producing delay and no information. Either the threshold is set too low, or the decision does not need a second person, and both are fixable. Measuring approval outcomes is one of the cheapest improvements available to a growing finance function.

At some point a growing company changes providers, restructures its program, or consolidates several arrangements into one. The technical part is straightforward. The part that causes incidents is that recurring vendor charges are attached to specific credentials, and those credentials are about to change.

A failed renewal on a payroll system, an authentication provider or a cloud account is not a finance inconvenience — it is an outage. Treat migration as a change with a rollback plan rather than as an administrative task.

1. Inventory every recurring charge first

   Per-vendor instruments make this trivial. If everything shares a card, expect the inventory itself to take longer than the migration.

2. Rank by blast radius, not by amount

   A small monthly charge for a domain registrar or an SSO provider can take more down than a large one for office supplies.

3. Run both programs in parallel

   Keep the old instruments alive while credentials are updated vendor by vendor. Overlap is cheaper than an outage.

4. Update, verify, then retire

   Confirm a successful charge on the new instrument before cancelling the old one. A vendor accepting a card update is not the same as a vendor successfully billing it.

5. Close deliberately, with a list

   Cancel old credentials on a schedule against the inventory rather than all at once when someone remembers.

6. Re-establish coding rules

   Coding rules are attached to instruments. New instruments start with none, and the first month end after a migration is where this is discovered.

The migration is also the best opportunity you will get to fix the structure rather than reproducing it. Carrying an outgrown configuration across to a new provider is a common and entirely avoidable outcome. Brex vs other corporate card solutions sets out a neutral evaluation framework for that decision, and Brex Corporate Card covers the administration model you are moving toward.

If you are working through a transition, the order that tends to help is: diagnose the symptom precisely, fix attribution, restore manager visibility, and only then design approval structure.

• Spend management hub Controls, limits, budgets and employee spending in one place.
• Budgets Owned envelopes and the visibility managers actually ask for.
• Employee Cards Per-person issuance, role templates and offboarding at scale.
• Expense Automation Which parts of the month-end workload genuinely automate, and which do not.
• Corporate Card Guide Program design and governance in long form.
• Finance Teams The controller’s requirements, which your structure will eventually have to satisfy.

If your company is earlier than this page assumes, startups covers card setup before there is a finance function, and small business covers owner-operated contexts where light-touch remains the right answer. The solutions hub shows all four side by side.