Corporate Card Issuance
Card issued next business day
Corporate cards are the answer to most "can I expense this?" friction — but issuing them is a slow, over-cautious workflow. Someone requests a card, finance debates the spend limit, the card takes days to issue, the employee expenses out-of-pocket in the meantime. Every card that could have been issued in a week but took three erodes trust in the finance function.
An hour-by-hour walkthrough.
Step by step.
- 01
Collect purpose + spend limit + cost centre
Manager or requester fills a form / DMs Fin. Fin parses: cardholder, purpose (travel / general / vendor payments), requested limit, cost centre, physical + virtual or virtual-only.
Slack · Teams · Portal - 02
Verify against approval matrix
Check requester is authorised at the requested limit (per your DoA policy). Amount above manager threshold escalates to finance manager or CFO per policy.
Approval Policies · Context Graph - 03
Route for approval
One-tap approval card in Slack. Deadline set (default 24h); escalation to delegate if untouched.
Slack · Approval Policies - 04
Issue card via API
On approval, call Ramp / Brex / Bill.com card issuance API with limit + category rules + cost centre. Virtual card active immediately; physical ships per courier SLA.
Ramp · Brex · Bill · Airbase - 05
Set spend rules
Category allowlist / blocklist per policy (travel + meals for expense cards; software + SaaS for vendor cards; no gambling / cash advances). Monthly limit enforced at swipe time.
Ramp · Brex · Card provider - 06
Notify user
Cardholder gets a Slack DM with virtual card details, limit, category rules, and how to expense. Physical card status link included.
Slack · Email
What you connect to make this run.
Ramp · Brex · Bill · Airbase
writeOAuth credential with card-issuance + limit-set + category-rule scopes. Virtual card immediate; physical shipping tracked via provider webhook.
NetSuite · QuickBooks · Xero · SAP
readCost-centre validation. Card usage flows back into GL per cost centre on transaction settlement.
Okta · HRIS
readCardholder verification. Cardholder must be an active employee; termination automatically cancels active cards via the offboarding playbook.
Before and after, honestly.
Playbooks that pair with this one.
Card Lock & Lost Replacement
The lifecycle counterpart — locking a lost/stolen card.
Card Spend Limit Adjustment
Adjusting limits after issuance (temporary raises for a specific project).
Spend Monitoring Detection
The watchdog that catches anomalous spend on issued cards.
Expense Submission & Approval
Downstream — card spend flows into expense reconciliation.
Answers about this playbook.
What if the requester needs a higher limit than the manager can approve?
Escalation chain — request goes to finance manager, then CFO per your DoA policy. Full context bundled at each level. Nobody has to re-explain the request.
Can we set category rules per card?
Yes — Fin passes category allowlist / blocklist to the card provider. Travel-card allows airlines + hotels + rideshare, blocks personal + gambling. Vendor-card allows software SKUs, blocks anything else.
What happens to cards when an employee leaves?
Offboarding playbook cancels all active cards on termination. Any pending transactions settle to the cardholder's cost centre; the card itself deactivates within seconds of the termination event.
Can Fin issue cards for vendors (not employees)?
Yes — vendor cards for AP flows. Same approval chain, different cardholder type. Vendor cards typically have lower limits and vendor-specific merchant rules.
How does this integrate with our expense tool?
Card transactions flow directly into your expense tool (Expensify / Ramp / Brex is often both card + expense; Bill + Concur are separate). Reconciliation is automatic.
See it run on your data.
Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.