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
A card program is not judged by finance on how well it pays merchants. It is judged on how much unplanned human work arrives in the last week of the period, and on whether the record can be reconstructed by someone who was not there.
Those two tests — predictable workload and reproducible evidence — explain almost every preference a controller has about card structure. They also explain why finance teams frequently want something different from what the rest of the company wants. A spender optimises for the absence of friction. Finance optimises for the absence of surprises. Both are legitimate, and the design job is to satisfy the second without destroying the first.
The structural material behind this page sits elsewhere on the site: Brex Card for the program and instrument model, spending controls for what is enforced when, and expense management for the path from posted transaction to reconciled entry. This page assumes that vocabulary.
- Close
- The period-end process of ensuring every transaction is recorded, documented, coded and reconciled so the reported figures can be relied on.
- Cut-off
- The boundary between periods. Getting cut-off wrong misstates two periods at once, which is why card timing details matter more than they appear to.
- Coding
- Assigning account, cost centre, project and tax treatment to a transaction. The most repetitive work in a card program and the most automatable.
- Exception
- Any item that cannot be processed by the standard rule — missing receipt, out-of-policy category, unusual amount. Exception volume, not transaction volume, determines finance workload.
- Audit evidence
- The record that allows an independent party to reconstruct what was bought, by whom, on whose authority and why.
What finance actually needs
Vendor material tends to describe finance requirements as "visibility" and "control", which are too vague to design against. The concrete requirements are narrower and easier to test.
Policy enforced, not published
A policy that exists only in a document is a policy finance has to enforce manually, one conversation at a time. What finance wants is the policy expressed as configuration — ceilings, category rules, documentation thresholds — so that compliance is the default path.
Complete evidence at source
Documentation captured at the moment of spend is cheap; documentation reconstructed at close is expensive and less reliable. The difference across a year is measured in weeks.
Coding that is right first time
Every item recoded by hand is a small tax on the close. Instruments tied to a single vendor or purpose let coding be a rule rather than a judgement.
A close with a predictable shape
Finance can absorb a heavy close. What it cannot absorb is a close whose length is unknown until it is over, because everything downstream is scheduled against it. A large item discovered during close is worse than the same item known in advance, even at an identical amount — timing of knowledge is itself a requirement.
Notice that none of these is about preventing spending. Prevention is a control objective; these are operational objectives, and they are what determines whether the finance function is calm or permanently behind. Expense controls covers the documentation side in more depth.
Relative spend by period — shape only, no real figures.
Month-end close mechanics
Card programs affect the close in one specific way: they determine how many items arrive in the queue needing human attention. Everything else about the close is unaffected by which card you use.
| Close activity | Helped when | Hurt when |
|---|---|---|
| Completeness of transactions | All company spending runs on program instruments | Personal cards and reimbursements carry a material share of spend |
| Coding | Instruments map to a single vendor or purpose so rules apply cleanly | A few shared, high-limit cards carry everything |
| Documentation | Receipts are captured at the point of spend by the spender | Receipts are chased centrally after the period has ended |
| Cut-off | Posting and statement timing are understood and consistent | Timing is assumed rather than checked, especially around period boundaries |
| Exception handling | Exceptions are rare, visible early and owned by a named person | Exceptions surface only in the final days of the close |
| Reconciliation | Program totals tie to the ledger without manual bridging | Multiple uncoordinated arrangements have to be consolidated by hand |
A structural framing of close activities. Actual accounting treatment and close procedures depend on your reporting framework and should be set with your accountants and auditors.
The lever with the largest effect is the second row. Coding effort scales with the ambiguity of the transaction, not with its size, so a program built on purpose-scoped instruments produces dramatically less close work than one built on a handful of general-purpose cards — even at identical spend. This is the finance-operations case for virtual cards, and it is stronger than the fraud-control case usually made for them.
Accruals and cut-off
Card transactions introduce three timestamps that do not coincide: when the purchase happened, when the transaction posted, and when the statement period ended. Treating them as one is the most common source of period error in card-heavy companies.
The gap matters because expense recognition generally follows the economic event rather than the settlement. A purchase made near period end may post in the next one, an authorisation may be held and never captured, an amount may be adjusted after posting. None of this is exotic, but each needs a written treatment rather than a case-by-case decision.
- A documented rule for items purchased before period end but posted after it
- A consistent treatment of pending authorisations that have not been captured
- A known handling for amount adjustments, refunds and reversals crossing a boundary
- Prepayments identified at source — annual renewals are the usual case and are easy to spot when each vendor has its own instrument
- Foreign-currency items with a stated conversion and timing convention
- A defined process for items still missing documentation when the period closes
The structural point is that per-vendor instruments make several of these easier rather than harder. Annual prepayments are identifiable without inspection, refunds land on the instrument that generated the charge, and a recurring commitment can be accrued from its own history rather than estimated from a blended statement. Business expenses covers the recording side; the specific treatment for your framework belongs with your accountants.
Segregation of duties and internal control
Card programs create a genuine internal control question that companies frequently overlook: the same person often initiates the spending, holds the credential, attaches the documentation and codes the result. That is four steps of a process under one pair of hands.
In a small company this is unavoidable and is handled by compensating review. As the company grows, the separations that matter most are between administering the program and spending on it, and between approving an item and benefiting from it.
| Activity | Should not be combined with | Why it matters |
|---|---|---|
| Issuing cards and setting ceilings | Spending on the cards being administered | Self-granted authority leaves no independent record of who approved what |
| Approving an expense | Being the beneficiary of it | Self-approval is the weakest possible control and the first thing an auditor tests |
| Coding a transaction | Sole responsibility for reviewing the coding | A single-person path means errors are systematic rather than random |
| Adding a vendor | Approving payments to that vendor | The classic fictitious-vendor exposure, and cheap to prevent |
| Administering the program | Owning the reconciliation without review | Removes the independent check that reconciliation is meant to provide |
General internal-control principles as commonly described in accounting practice. Your specific control framework and materiality thresholds should be set with your auditors.
Where separation is genuinely impossible because of headcount, the accepted answer is documented compensating review: someone independent looks at the whole population on a defined cadence and signs that they did. What is not acceptable is leaving the gap undescribed, because an undocumented control is indistinguishable from an absent one. Employee spending covers delegated authority policy.
Audit readiness and evidence
The practical test for audit readiness is simple to state: can an independent person, with no access to anyone’s memory, reconstruct what was purchased, by whom, on what authority, for what business purpose, and how it reached the ledger? If any link in that chain depends on someone remembering, it is not evidence.
-
Authority
A record of who was permitted to spend, within what ceilings and categories, and when those permissions changed. Permission history matters as much as current state.
-
Initiation
The transaction itself with its merchant, amount and timestamp, attached to a named cardholder rather than a shared credential.
-
Purpose
A business purpose that a stranger could not have inferred from the merchant name. This is the field most often left blank and most often asked about.
-
Documentation
The receipt or invoice, retained for the period your framework requires, and retrievable without depending on an individual’s inbox.
-
Approval
Where an approval was required, evidence of who gave it, when, and on what basis — including the exceptions that were declined.
-
Recording
The coding applied and any subsequent change to it, with the change itself visible rather than overwritten.
The last point is worth dwelling on. A system that silently overwrites a coding decision destroys the evidence that a decision was made; audit trails need to be additive. Retention periods and materiality vary by framework and belong with your auditor. What belongs here is the structural observation that evidence captured at source is cheaper and more reliable than evidence assembled afterwards.
Reporting and exception volume
Two things consume finance capacity in a card program, and neither is transaction volume. The first is exception volume. The second is answering questions from leadership that the reporting should have answered already.
Exception volume is a direct function of how well the control configuration matches how the company actually works. Controls tighter than the work requires generate exception requests; controls looser than the policy generate breaches. Both land in the same queue, and both are measurable.
Signs the controls are too tight
- A steady stream of limit-increase requests for routine purchases
- Approval routes that approve essentially everything they receive
- Employees paying personally and claiming it back to avoid a decline
- Ceilings that were set once at onboarding and never revisited
- Category rules blocking merchants that are legitimately used every month
Signs the controls are too loose
- Items reaching close with no business purpose recorded
- Charges that require investigation to attribute to a team
- Recurring commitments nobody has reviewed in a year
- Cards still active for people who have left
- Aggregate spend for a department that nobody owns or can explain
The trade-off between strictness and finance workload is real and does not have a universal answer, but it can be managed empirically: track exception volume by cause and adjust the configuration that produces the most. That is a considerably better use of time than rewriting the policy document. Card limits and budgets are the two configurations that most often need adjusting.
On reporting to leadership, the recurring request is almost always the same: what are we committed to next month, where is spending growing, and is anything unusual. All three are easy to answer when instruments map to purposes and budgets have owners, and all three become research projects when they do not.
Evaluating a card platform
Finance is usually asked to assess a card platform, and the assessment is easily distorted by demonstrations. The following criteria are structural, provider-neutral and can be asked of anyone. We deliberately name none, and we publish no rankings.
| Criterion | What to establish | Why finance cares |
|---|---|---|
| Instrument model | How easily instruments are issued per vendor, project or person | Determines how much coding can be rules rather than judgement |
| Control granularity | Which rules act at authorisation versus after the fact | Only authorisation-time rules genuinely prevent anything |
| Evidence model | How documentation is captured, retained and retrieved | Determines whether audit evidence exists at source or is assembled later |
| Change history | Whether coding, limits and permissions retain a visible history | An overwritten record is not an audit trail |
| Accounting integration | How coded transactions reach your ledger and in what shape | Determines the size of the manual bridge at close |
| Timing behaviour | Posting, statement and export timing relative to your period end | Cut-off errors misstate two periods at once |
| Administration model | Who may issue, re-limit, freeze and cancel, and how granularly | Enables segregation of duties and delegated administration |
| Exit path | How instruments and history are exported if you leave | Migration risk is a real cost and is rarely discussed upfront |
An evaluation framework only. This site publishes no product comparisons, ratings, pricing or eligibility information for any named provider — obtain those from the provider directly.
Commercial terms — fees, rates, rewards, credit limits, eligibility — sit outside this framework deliberately. They matter, they change, and they should be read from the provider and assessed against your own numbers rather than taken from a reference site. Brex vs other corporate card solutions develops the neutral evaluation approach further, and Brex Value covers how to think about a value proposition without relying on marketing claims.
Where to go next
Finance rarely gets to design a card program from scratch. More often the job is to improve one that already exists, in which case the highest-return changes are the ones that reduce exception volume rather than the ones that add rules.
- Expense Management The full path from a posted transaction to a reconciled ledger entry.
- Expense Controls Documentation thresholds, coding consistency and policy evidence.
- Expense Automation What genuinely automates in the close workload, and what does not.
- Spending Controls Which mechanisms act at authorisation and which only document.
- Brex Corporate Card Company liability, centralised issuance and the administration model.
- Corporate Finance Guide Where a card program sits within the wider finance operation.
If you are inheriting a program built for a smaller company, growing businesses describes the transition and the migration mechanics. If you support an early-stage company where the finance function is you and one afternoon a week, startups covers what to prioritise. The solutions hub sets all four contexts side by side, and the cards hub holds the underlying card taxonomy.
FAQ
Frequently asked questions
What single change most reduces month-end workload?
Reducing the ambiguity of transactions rather than the number of them. Coding effort scales with how much judgement each item requires, so mapping instruments to single vendors or purposes lets coding be applied as a rule.
A program with many purpose-scoped instruments generally produces less close work than one with a few shared cards, even at identical spend and transaction count.
How should segregation of duties work in a small finance team?
Where genuine separation is impossible, the accepted approach is documented compensating review: someone independent examines the population on a defined cadence and records that they did.
The critical failure is leaving the gap undescribed. An undocumented control cannot be distinguished from an absent one, and specific expectations should be agreed with your auditor.
What makes a card program audit-ready?
The ability for an independent person to reconstruct authority, initiation, business purpose, documentation, approval and recording for any transaction without relying on anyone’s memory.
The two links most often missing are business purpose — frequently left blank — and permission history, since many systems show only the current state of limits and roles rather than what they were at the time of the transaction.
Are stricter controls always better for finance?
No, and treating them as such increases finance workload. Controls tighter than the work requires generate exception requests, and exceptions consume the same queue as policy breaches.
The practical approach is to measure exception volume by cause and adjust the configuration producing the most, rather than rewriting policy text.
How do card programs affect cut-off?
They introduce three timestamps that do not coincide: purchase, posting and statement period end. Items bought before a period ends may post after it, authorisations may be held without capture, and amounts may be adjusted later.
Each case needs a written, consistently applied treatment. The specific accounting treatment depends on your reporting framework and belongs with your accountants.
What should finance ask a card provider that is not a feature question?
Ask how change history is retained — whether you can see what a coding, limit or permission used to be, who changed it and when. Ask how data and history leave the platform if you stop using it. Both are decisive for audit and migration, and neither usually appears in a demonstration.
Does this site evaluate or rate card providers?
No. This site is an independent, non-commercial reference project with no relationship to any issuer. We publish no ratings, rankings, fees, rates or eligibility criteria. The evaluation criteria on this page are structural questions you can ask of any provider and assess against your own requirements.
Sources and reference basis
- Reference Standard internal-control and accounting practice literature on segregation of duties, documentation, period-end cut-off and audit evidence.
- Practice Common finance-operations patterns in card program administration: exception tracking, coding rules, compensating review and periodic access review.
- Reference General payment-network reference material on authorisation, capture, posting timing and merchant category classification.
- Method Our methodology and fact-checking policy describe how these pages are researched, written and corrected.