Virtual Corporate Cards & Spend Controls Playbook

Virtual Corporate Cards & Spend Controls Playbook

A marketing manager books a $49-a-month design tool on the shared company card, and the renewal quietly becomes $490 a month. Finance finds out at month-end, from the statement. A virtual corporate card would have stopped it at authorization: a number issued for one vendor, capped at $49, that declines the $490 charge before it posts. The control sits on the card itself, before money moves — not in a policy document read after the fact. Ramp's published figures put numbers on the mechanism: 3.5% of transactions are blocked at swipe for policy violations, and 90% are auto-coded on receipt. This playbook runs the operation end to end: card types, the five control layers, exposure and reconciliation arithmetic, tokenization, fraud containment, and the IRS accountable-plan rules. Pricing lives in the ramp-vs-brex-vs-mercury-spend-management-pricing comparison; rewards live in the amex-vs-chase-vs-capital-one-business-credit-card-rewards-playbook.

Step 1: What a virtual corporate card actually is

A virtual corporate card is a randomly generated 16-digit card number linked to your existing business credit account, issued without a plastic card. It travels the same payment rails as a physical card — same authorization, clearing, and settlement — and the difference is entirely in how the number is created and constrained. The cardholder enters it at online checkout or saves it with one vendor; it can also sit in a digital wallet. It cannot be swiped at a terminal that does not accept mobile wallets.

Under the number sits tokenization. Visa's Token Service replaces the 16-digit Primary Account Number (PAN) with a unique digital identifier — a token — of the same length and format as the original PAN, so back-end systems process it like an ordinary card number. The token is mapped to the real PAN inside Visa's vault; the merchant never holds the real number. A payment token can be limited to a specific device, merchant, or number of transactions. The consequence: the number a vendor stores is not the number that reaches your bank account.

Step 2: Single-use, multi-use, and vendor-locked — pick by the job

Three card shapes cover nearly every corporate use, and the wrong shape is the most common failure in the operation. A single-use card expires after one transaction; once it completes, the number cannot be reused even if it is compromised. A multi-use card stays active until you deactivate it, for trusted vendors and ongoing projects. A vendor-locked card is restricted to a specific merchant: if the number is stolen, it cannot be used anywhere else.

The rule is mechanical: if the spend has an end date, use a card with an end date. A trial is a single-use job; a monthly subscription is a vendor-locked multi-use job; an employee travel budget is an allocation with a reset. The trial math is blunt: a $1 trial card declines a $49 renewal, and twelve unnoticed months cost $588 a year. The business-line-of-credit-vs-term-loan-vs-invoice-factoring-playbook covers borrowing when the spend itself needs financing; cards control spend that is already funded.

Step 3: The five control layers — and what each one cannot do

A virtual card carries five independent controls, and each one fails in a different way. Set them deliberately, because the gap between two controls is where the loss sits.

Brex's Empower controls work the same way: spend limits carry a policy and a maximum amount, with an option to allow virtual-card spending only — blocking physical cards and reimbursements for that limit — plus auto-creation of a virtual card for every user on the limit, merchant and category restrictions that decline automatically, and a maximum amount per transaction. The two controls operators skip most are the per-transaction cap and the auto-lock date.

Step 4: Worked example — the blast radius of one leaked number

Exposure is the limit on the compromised card, not the limit on the account. Take a stated company with a shared corporate card carrying a $25,000 monthly limit, used across forty vendors. One vendor's database leaks, and the shared number is in it. The exposed headroom is the full $25,000, because the number works at any merchant until someone cancels the account's card.

Now split the same spend into per-vendor cards, each capped at that vendor's actual bill. The compromised card is the Figma card, capped at $150 a month. The exposed headroom is $150.

The ratio is the point: per-vendor cards do not reduce the probability of a leak, they divide the consequence by the number of cards. A $500-a-month SaaS card is useless to anyone if the number leaks, because it declines at any other merchant. The cost is administrative — forty cards instead of one — which is why the model only works when cards are auto-created on approval and auto-coded on receipt.

Step 5: Reconciliation — where the hours actually go

A virtual card earns its keep at month-end, not at checkout. Assign a general ledger code, cost center, and department when the card is issued, and every charge arrives already coded. Ramp reports 90% of card transactions auto-coded on receipt and synced to the ERP in real time. Stated assumptions below — 240 transactions a month, four minutes of manual coding each, $45 an hour fully loaded — and any finance team can re-run the arithmetic with its own numbers.

The 10% that still needs a human is the interesting part: miscoded merchants, split charges, and the first transaction from a new vendor. Review those the week they post, while the receipt and the cardholder's memory are fresh. Export the feed as CSV through the platform API; a transaction with no receipt after seven days is a follow-up, not a write-off.

The plumbing underneath is ordinary business payments infrastructure, and the acronyms stack up fast: a B2B SaaS vendor bills the card while the same company pays rent by ACH and a supplier by Wire, the operating account sits at an FDIC-insured bank, a European vendor invoices with an IBAN and settles over SWIFT with an FX conversion, the idle balance earns APY, a POS terminal takes the physical card, 3DS challenges the online checkout, KYC and AML checks run at onboarding, the platform API exports a CSV, the entity files under its EIN as an LLC, a C-Corp, or an S-Corp, and the CPA closes under GAAP.

Step 6: Fraud containment — lock one card, keep the rest alive

When a virtual number is compromised, the response is a single click: lock that card. Every other card keeps working, because no other vendor holds the exposed number. Compare that with a shared physical card, where the response is cancelling the account's card, reissuing, and updating every vendor that stored it. Ramp states a compromised virtual card can be locked without cancelling the main account.

The second containment number is the block rate. Ramp blocks 3.5% of transactions at swipe for policy violations, before they create reconciliation work. On a stated 1,000 transactions a month:

The $180 is a stated average violating charge for this illustration, not a vendor figure. A decline at authorization costs a conversation with the cardholder; a charge that posts costs a dispute, a credit, and a rebooked entry. Velocity limits add a third layer — a cap on transactions in a window.

Step 7: The IRS side — accountable plans, or the spend becomes wages

Cards control the spend; the accountable-plan rules decide how it is taxed. Under section 162, ordinary and necessary business expenses are deductible. Amounts paid under an accountable plan are excluded from the employee's wages; amounts under a nonaccountable plan are wages. Publication 463 states the three rules an accountable plan must include: a business connection — deductible expenses paid or incurred while performing services as an employee; adequate accounting within a reasonable period of time; and return of any excess reimbursement or allowance within a reasonable period of time.

Section 62(c) draws the hard line: an arrangement shall in no event be treated as a reimbursement arrangement if it does not require the employee to substantiate the expenses, or if it lets the employee retain any amount in excess of them. A card program that lets employees keep unspent balances with no accounting fails the second prong by design, whatever the policy document says.

The regulation makes "reasonable period" operational. Treasury Regulation §1.62-2(g)(2)(i) — the fixed-date method — treats an advance made within 30 days of when an expense is paid or incurred, an expense substantiated within 60 days after it is paid or incurred, or an amount returned within 120 days after an expense is paid or incurred as within a reasonable period of time. Worked on a stated expense paid 1 March 2026:

Map the card controls onto those dates: the receipt upload is the substantiation, due within 60 days; the unspent balance on a closed allocation is the excess, due back within 120 days. A program that auto-collects receipts at swipe and sweeps unspent allocations on close is, in substance, an accountable-plan machine — but only if the policy requires the accounting and the return. Publication 463 also notes the 50% limit on meals.

The decision

The build operation, start to finish

1. List every vendor paid by card, with the monthly amount and renewal date.
2. Issue one vendor-locked virtual card per vendor, capped at its bill, auto-locked at contract end.
3. Issue single-use cards for all trials and one-off invoices, limited to the agreed amount.
4. Set the per-transaction cap and MCC restriction on every card; leave no card open.
5. Assign the GL code, cost center, and department at issuance; turn on receipt capture.
6. Write the 30/60/120-day deadlines into the policy: receipts in 60 days, excess back in 120.
7. Run the month's blocked and declined transactions through the roi-calculator at the Step 6 figures before renewing any vendor.
8. Lock, never delete, a compromised card — its history is the audit trail.

• [x] Issue one vendor-locked card per vendor, capped at its bill.
• [x] Use single-use cards for every trial and one-off invoice.
• [x] Set a per-transaction cap and MCC restriction on every card.
• [x] Assign GL code, cost center, and department at issuance.
• [x] Collect receipts at swipe; chase any receipt missing at 60 days.
• [x] Sweep unspent allocations back within 120 days of the expense.
• [x] Lock a compromised card immediately; keep the rest alive.