FlyExpense

The Complete Guide to Virtual Corporate Cards

A practical playbook for issuing, managing, and optimizing virtual cards across vendors, ad spend, and AI agents.

Virtual cards are not just digital versions of physical cards. They are a different financial primitive, and treating them as the same thing is why most teams under-use them.

What a virtual card actually is

A virtual card is a card number that exists only as data: PAN, expiry, CVV, network. It is issued instantly, can be limited in dozens of dimensions, and can be revoked in one click. Crucially, a virtual card can be single-use, scope-limited, or vendor-locked in ways no physical card can.

The mental model: a physical card is a wallet. A virtual card is a contract. Each virtual card represents a specific spending agreement: this vendor, this amount, this purpose, this duration.

The four use cases that justify virtual cards

1. Per-vendor SaaS cards. Issue one card per SaaS vendor (one for AWS, one for Slack, one for GitHub, etc.). Each card has a hard monthly cap. Cancelling a vendor becomes revoking a card, no email chains to support, no surprise renewal charges.

2. Per-campaign ad-spend cards. Issue a card for each marketing campaign with the exact budget as the hard limit. The card declines when budget is exhausted. No more "we overran the campaign by 30%" surprises.

3. Per-employee project cards. A consultant working on a specific client engagement gets a virtual card tied to the engagement budget. Reimbursable expenses become trivially trackable. Project P&L is real-time.

4. Per-agent AI cards. Each AI agent (research bot, code assistant, procurement automation) gets its own virtual card with merchant allow-list and velocity limits. Audit attribution becomes automatic.

Controls that matter

The good virtual card platforms differentiate on the control surface. The controls we recommend turning on by default:

  • Amount cap. Per-transaction maximum and per-period total.
  • Merchant lock. First merchant who charges the card locks the card to that merchant. Any other merchant declines.
  • MCC allow/block list. Restrict to specific merchant categories.
  • Geography limit. Only allow transactions in specific countries.
  • Auto-expiry. Card expires at end of project, end of fiscal year, or 90 days of no activity.
  • Single-use. Card declines after the first successful charge.

You will not use all of these on every card. The point is to compose them per card so each card is the smallest possible attack surface for its purpose.

Cards vs reimbursements

Every dollar your team puts on a personal card and submits for reimbursement is a dollar of finance work. Receipt chase, expense report review, accounts payable processing, payroll deduction, reconciliation. A virtual card collapses all of that into a single matched transaction with a receipt attached at swipe time.

The rule we recommend: if a category of spend happens more than three times per quarter, it belongs on a virtual card, not in reimbursements. The setup cost is one card. The savings recur forever.

The reconciliation win

Traditional corporate card statements arrive monthly, get parsed manually, and categorize spend by best guess. Virtual cards categorize at issuance time. Each card has a designated category, vendor, owner, project, and GL code. The reconciliation work is done before the transaction happens, not after.

This is the single biggest reason virtual cards reduce finance team workload. Not because the cards themselves are special, but because the metadata is baked in at the right moment.

Anti-patterns to avoid

One giant virtual card for everything. Defeats the purpose. You now have a digital corporate card instead of a meaningful contract.

Issuing virtual cards without revocation discipline. If your team has 400 virtual cards and nobody knows which are still in use, you have created a control problem instead of solving one. Cards need owners. Owners need a quarterly review.

Skipping merchant lock. Merchant lock is the single highest-leverage control. Always turn it on unless the use case explicitly forbids it.

What "good" looks like

A 50-person company running virtual cards well typically has 80-150 active cards, 90% of them merchant-locked, with a clear owner on each. Card count grows linearly with team size. Reimbursement count drops by 60-80% within the first six months. Month-end close shrinks by 2-3 days because reconciliation is mostly automatic.

That is the production state. It is unglamorous, but it adds up to thousands of hours of finance team time freed per year, and a meaningfully lower fraud surface.