What is a corporate card program, and how is it different from just giving employees company credit cards?

Five core decisions, in order: (1) Who gets a card - issuance criteria by role and spend need, not seniority. (2) Limits - per-transaction and monthly caps sized to actual need. (3) Controls - merchant category restrictions, pre-approval thresholds, expiry rules. (4) Policy - a short, readable document employees actually follow, enforced in the tool rather than in a PDF. (5) Reconciliation - how transactions get coded, receipted, and posted to the ERP, ideally continuously rather than at statement close. Most programs fail on the fifth decision: they design issuance carefully and reconciliation not at all.

Centralized programs (a few cards held by AP or office managers) maximize control and minimize reconciliation work, but create bottlenecks and encourage workarounds like personal-card reimbursements. Distributed programs (cards across departments) maximize convenience but multiply coding, receipt, and policy-enforcement surface area. The deciding variable is whether your platform can enforce controls and capture coding at the point of spend. If controls travel with the card, distribution is safe; if they don't, distribution is drift waiting to happen.

"P-card" and "purchasing card" are the same instrument: cards for buying goods and services rather than travel. "Corporate card" usually implies corporate liability and a managed program; "business credit card" usually means a small-business product with individual or personal-guarantee liability. The labels matter less than the liability model and the controls attached.

Written issuance criteria, default-low limits with a fast raise process, merchant category blocks on day one, receipt capture at the point of sale, continuous (not month-end) coding, and a named program owner who runs a quarterly card census.

Confirm you have: a policy draft, an owner, GL coding rules for card spend, a clearing-account design, an offboarding step in HR processes, and a platform that enforces limits and merchant restrictions automatically. If reconciliation is still manual, fix that before issuing cards.

Pilot with one department, issue cards with conservative limits and pre-set merchant restrictions, run one full month-end cycle to prove reconciliation works, then expand. Don't migrate the owners' cards last - they're usually the biggest source of uncoded spend.

Corporate liability (the company pays the issuer directly) gives finance control and spares employees credit exposure; it's the standard for managed programs. Individual liability shifts float and risk to employees and reliably produces late submissions and resentment.

A card number with no plastic, assigned to a department, vendor, or travel agency for recurring centralized charges (e.g., all airline bookings). Useful for consolidation, risky without per-merchant locks because one number accumulates many charge sources.

At mid-market companies, card spend is usually a single-digit to low-teens percentage of total payables by dollar value (though a much higher share by transaction count). If card share of dollars is growing while invoice volume is flat, audit for card drift before celebrating adoption.

Field-heavy industries need more physical cards, mobile receipt capture, and job/project coding at the point of spend; office-centric companies skew virtual. Design around where the purchase happens, not the org chart.

Appoint an owner, run a census of every active card, right-size limits to trailing 6-month actuals, apply default merchant blocks, and grandfather nothing - but communicate the change as enabling faster purchases within clear lanes, not as clawback.

The controller or AP leader should own it, because the failure mode of card programs is accounting failure (uncoded, unreceipted, unreconciled spend), not treasury failure. Ownership means issuance approval, policy maintenance, the quarterly census, and the month-end tie-out.

Stampli Card is built on the principle that a card program should manage spend, not encourage it. Cards - physical and virtual - carry pre-set controls and pre-coded GL fields, AP Cards can be issued directly from approved purchase requests, and transactions post in real time into the same approval workflows that govern invoices. The program design lives in the workflow, not in a policy binder.