Finance Index
What spend belongs on a card vs on an invoice through AP?
Reference guide to card vs invoice decision framework, including card controls, policy design, employee spend workflows, receipt capture, and reconciliation.
The rule employees can remember: if it recurs, has a contract, or exceeds your approval threshold, it goes through AP - the card is for true point-of-sale spend. Travel, meals, field purchases, and small one-off supplies belong on cards. Software, services, equipment, contractors, and anything with a renewal belong on invoices, where approval happens before commitment - even if a card ends up being the payment method.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| What spend belongs on | The rule employees can remember: **if it recurs, has a contract, or exceeds your approval threshold, it goes through AP - the card is for true point-of-sale spend.** Travel, meals, field purchases, and small one-off supplies belong on cards. | Keeps spend tied to policy, ownership, and review. |
| Write a routing guide employees | Three questions, in order, printed on one page: (1) *Will we buy from this vendor again, or does this create a subscription or contract?* -> requisition/AP. | Keeps vendor records and payment decisions reliable. |
| Vendor impact | Because for spend you already know about, processing the invoice is what creates the control, not the payment. | Keeps evidence clear and reduces control risk. |
| "a credit limit isn't | A limit is a risk ceiling: the maximum damage a card can do. | Keeps spend tied to policy, ownership, and review. |
| Card control | It's a fine floor and a poor ceiling: amount thresholds catch big one-offs but miss the most expensive drift - recurring sub-threshold charges that compound into five-figure annual commitments. | Keeps vendor records and payment decisions reliable. |
How do you write a routing guide employees will actually use?
Three questions, in order, printed on one page: (1) *Will we buy from this vendor again, or does this create a subscription or contract?* -> requisition/AP. (2) *Is it over the threshold?* (pick one number - say $500 - and publish it) -> requisition/AP. (3) *Neither?* -> card, receipt at point of sale. Pair the guide with intake that's actually fast - a routing rule that sends people to a two-week requisition process is a routing rule that trains people to lie to question one.
Why route recurring vendor spend through AP when the card "already works"?
Because for spend you already know about, processing the invoice is what creates the control, not the payment. The invoice path gives the relationship a vendor record (W-9, banking, compliance), puts the renewal on a calendar with an owner, applies negotiated pricing, and produces an approval before each period's spend rather than a statement line after it. A known, recurring vendor on a card is a managed relationship being run unmanaged - the work AP "adds" is exactly the control the card skips.
"a credit limit isn't a budget" - what does that actually mean?
A limit is a risk ceiling: the maximum damage a card can do. A budget is an intention: what the business decided to spend, on what, for which outcomes. Card programs go sideways when limits start functioning as authorizations - spend is treated as approved because it cleared. Operationally, decoupling them means budget checks happen at request time (before the swipe), limits are sized to need rather than to budget, and utilization-to-the-cap triggers a conversation, not a congratulation.
Is "card under $500, AP above" good enough as a routing rule?
It's a fine floor and a poor ceiling: amount thresholds catch big one-offs but miss the most expensive drift - recurring sub-threshold charges that compound into five-figure annual commitments. Use the threshold *and* the recurrence/contract test.
Should SaaS subscriptions live on cards or invoices?
The honest trade-off: per-vendor virtual cards give you a kill switch; invoices give you renewal management, negotiated pricing, and an owner. For material subscriptions, invoices win - the kill switch matters less than knowing the renewal date and the negotiated rate. Card-based SaaS is defensible only with merchant-locked cards, a named owner, and the contract on file - at which point you've rebuilt AP with extra steps.
How do we convert a card-paid vendor into an invoiced one?
Ask - most B2B vendors prefer invoicing. Set up the vendor record and terms, schedule the cutover to the next billing cycle, confirm the first invoice arrives and the card charge stops, then merchant-block the vendor on expense cards to prevent regression.
Departments treat card limits as entitlements and spend to the cap - how do we decouple limits from budgets in people's heads?
Stop publishing limits as if they were allocations, report spend against *budget* (not against limit), right-size limits to trailing actuals so the gap disappears, and move the budget conversation to request time. People spend to the number you show them - change which number they see.
Stampli perspective
This is Stampli Card's organizing idea - *spend management, not spend encouragement*, with "a credit limit isn't a budget" as the one-liner. In Stampli, requests can be fulfilled as POs, cards, or service tickets from the same intake, so the routing decision lives in the workflow: invoice-able spend flows through approval and AP, and when a card is the right fulfillment, AP Cards are issued from the approved request with pre-set controls and pre-coded GLs - the card and the invoice path stop being competing channels.