Virtual card risk and compliance, the checklist finance leaders need before rollout.

A virtual card risk and compliance program comes down to seven decisions made before the first card ships: who approves it, what limit and lock policy it carries, how offboarding cancels access, how often you reconcile, what audit trail proves who did what, and what access controls protect the platform itself. The card enforces the policy; you write it.

If you are a controller or finance lead rolling out virtual cards for business to a department or every manager at once, the technology is the easy part. Any card can be capped and canceled. The harder work is the policy behind it: who signs off on a new card, a limit that matches the actual budget, a lock policy that is honest about what it can and cannot guarantee, and an offboarding sequence that closes access the day someone leaves without pretending a pending charge disappears with it. This guide walks through that policy layer, then works one exit through it end to end. For the reader-facing version of "is this safe," see our separate piece on whether virtual cards are safe; this one is written for the person who signs off on the program.

The seven-item checklist to confirm before rollout

Before virtual cards go out to more than one or two people, confirm these seven items exist in writing, not just in someone's head. None of them is complicated on its own. The failures happen when a company skips straight to issuing cards and only writes the policy down after something goes wrong.

Who should approve a new card request

Put one named owner on the approval, typically the controller or the finance lead, and keep it separate from the person requesting the card. A department head asking for a card for a new hire should not be the same person clicking issue. That single separation is what makes the audit trail mean something later: an auditor can see that every card traces back to a documented approval, not to whoever happened to have access that day.

Keep the approval step lightweight so it does not become the thing people route around. A short form or ticket capturing who the card is for, the requested limit, and the business reason is enough. What matters is that the step exists every time, not that it is elaborate.

Setting a limit and lock policy you can defend

Start with the spend cap, because it is the control that actually holds. Set it to the role's real budget, monthly or per project, and any charge above that cap is declined at authorization. That is the rule you can point to in a review and say it worked exactly as designed. Part of why the cap holds so cleanly is the funding model: these cards are funded from a company wallet rather than an underwritten credit line, so the cap is a ceiling on what can move out of that wallet, not a credit limit a processor could extend or override.

Where the merchant's processor supports it, you can add a merchant, category, location, or time lock behind the cap. Be precise with your finance team and your auditors about what these do. The table below separates what is deterministic from what is a strong second layer.

Write the limit and lock policy down by role, not by individual, so a new department head inherits the same rule the last one had. That is what turns a one-off decision into a program.

Seeing transaction activity as it happens

Yes. Transaction activity shows in the dashboard as charges authorize, broken out by cardholder and by card, so you can review spend by department without waiting for a statement or a manual pull from anyone holding a card. That live view is what makes the approval workflow, the limit and lock policy, and the reconciliation cadence workable in practice: each one only holds up if someone can actually see whether it is being followed.

Use that visibility as a standing habit, not just an audit-time lookup. A short weekly glance at activity by department catches a limit that is quietly too loose long before month-end reconciliation would.

Building an offboarding process that actually closes the door

Canceling a card stops new charges immediately; it does not reverse a charge that already authorized before the cancellation. Offboarding is where most card programs get the timing wrong, and it matters most to a finance leader because it touches both control and reconciliation. The process itself is simple: the day HR confirms a departure, finance cancels that person's card.

A charge already authorized before you canceled the card, a subscription renewal that ran the day before, can still settle afterward and will still count against that card's activity for the period. That is not a control failure; it is how authorization and settlement work. A documented offboarding process should say so explicitly, so whoever reconciles the account is not surprised by a charge landing on a card that is already closed.

A real example: closing out a departed employee's card

Here is how that plays out on an actual rollout. Marlow Logistics has 40 employees and issued virtual cards to its eight department heads, each with a documented limit and lock policy that James Carter, the company's controller, approved before any card went live.

Setting a reconciliation cadence that holds

Pick a cadence and stick to it, monthly tied to your close, or per pay cycle. Reconcile against settled activity, never against the cap, since the cap only tells you the ceiling, not what actually cleared.

Add one specific step for any card canceled during the period: pull its settled activity separately and confirm nothing landed after the offboarding date except a transaction already pending at cancellation. That check keeps an offboarding event from turning into a reconciliation mystery weeks later.

What counts as an audit trail for a card program

An audit trail for a card program is a record of four things: who approved the card, who issued it and with what limit and lock, what settled against it over time, and what receipt backs each charge. Issuance, limit changes, and cancellations should all show against the account that made them, alongside the settled transaction history, so you can reconstruct the full life of any card without asking around.

That record is what an auditor or a new finance hire will actually use. If every card traces back to a named approver, a documented limit, and a receipt, the program holds up under review without anyone having to remember the reasoning months later.

Mistakes that undermine a card compliance program

People also ask