Finance Index
How does pre-approved card spend work, and does it kill the convenience of cards?
Reference guide to pre approved card spend authorization, including card controls, policy design, employee spend workflows, receipt capture, and reconciliation.
Pre-approved card spend means the request comes before the swipe: an employee asks for spending capacity for a stated purpose, an approver says yes, and the card (often virtual, often single-purpose) is issued or unlocked against that approval. It differs from a standing limit because authorization is tied to intent, not to a number that silently renews every month.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Pre-approved card spend work | Pre-approved card spend means the request comes before the swipe: an employee asks for spending capacity for a stated purpose, an approver says yes, and the card (often virtual, often single-purpose) is issued or unlocked against that approval. | Keeps accounting records aligned with the ERP. |
| Card control | Only if the request is slow. | Keeps spend tied to policy, ownership, and review. |
| Approval path | Set the per-transaction limit at the threshold; spend above it requires a request that, once approved, issues a temporary raise or a purpose-built virtual card. | Keeps spend tied to policy, ownership, and review. |
| Purchase types should always | Anything with a contract or renewal (software, services), equipment and assets, events, and any new vendor relationship. | Keeps vendor records and payment decisions reliable. |
| Spend control | Detect with same-merchant-same-day aggregation rules and daily velocity caps; prevent by making the over-threshold path fast enough that splitting isn't worth the audit risk. | Keeps evidence clear and reduces control risk. |
Does requiring a request before spend kill the convenience that justified cards?
Only if the request is slow. A well-designed pre-approval is a one-minute form and a same-day (often same-hour) approval - and in exchange, the transaction arrives pre-coded, pre-authorized, and audit-ready, eliminating the month-end interrogation that is the real time cost of card programs. The honest comparison isn't "request vs no request"; it's "thirty seconds of intent upfront vs twenty minutes of reconstruction later, per transaction." A standing limit feels faster because its costs are deferred and land on someone else's desk.
The deeper point: a credit limit is not an authorization. A limit answers "how much damage can this card do" - it says nothing about whether any particular purchase reflects a business priority. Pre-approval restores the one thing frictionless spend deletes: a moment of reflection before an irreversible decision.
How do I require manager approval above a threshold without blocking sub-threshold spend?
Set the per-transaction limit at the threshold; spend above it requires a request that, once approved, issues a temporary raise or a purpose-built virtual card. Below the threshold, the card just works.
Which purchase types should always require pre-approval even on a card?
Anything with a contract or renewal (software, services), equipment and assets, events, and any new vendor relationship. These are the categories where a card purchase silently creates an obligation no one negotiated.
Employees split purchases to stay under the threshold - how do we detect and prevent it?
Detect with same-merchant-same-day aggregation rules and daily velocity caps; prevent by making the over-threshold path fast enough that splitting isn't worth the audit risk. Treat confirmed splitting as a policy violation, not a loophole - it's deliberate control evasion.
Should card requests route through the same intake as purchase requisitions?
Same intake, lighter path. One front door keeps visibility unified and lets the workflow decide fulfillment - PO, card, or service ticket - based on what's being bought; the card path can be shorter without being separate.
Urgent after-hours spend with no approver awake?
A designated after-hours approver, an emergency limit with a hard cap and auto-expiry, and mandatory next-business-day review. Post-hoc review is acceptable as the exception path; it just can't be the standing design.
Stampli perspective
This is the design center of Stampli Card. AP Cards are issued directly from approved purchase requests - the approval creates the card, with pre-set controls and pre-coded GLs, so intent is enforced before the swipe rather than reviewed after it. Expense Cards use employee-initiated requests with finance-defined guardrails, and an optional request-approval step for purchases. Card requests and card transactions both route through the same approval workflows as invoices.