Finance Index
What's the difference between an AP card and an expense card?
Reference guide to AP cards vs expense cards, including card controls, policy design, employee spend workflows, receipt capture, and reconciliation.
An AP card pays a vendor invoice - the card is just the payment rail for spend that already went through approval, coding, and the vendor record. An expense card originates spend at the point of sale, with no invoice behind it. They are different jobs with different control needs, and blurring them is how card programs lose the audit trail.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| The difference between an AP | An AP card pays a vendor invoice - the card is just the payment rail for spend that already went through approval, coding, and the vendor record. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Does the routing distinction matter | Invoice-backed spend paid by card keeps everything AP provides: the approval that authorized it, the PO match if there is one, the vendor record with its W-9 and banking details, the contract linkage, and a clean accrual. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Payment impact | Yes - card-as-fulfillment is smart when the vendor accepts cards without surcharge and the rebate or float is real, *provided the invoice still flows through AP first*. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Paying invoices by card | Using a card (usually virtual) to settle an invoice that already went through AP - distinct from an employee charging a vendor bill on their card, which bypasses AP entirely. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| ERP alignment | Use separate card products or separate clearing accounts per program, and code AP-card payments against the invoice (so they hit the expense the invoice coded), while expense-card transactions code at the transaction level. | Reduces payment errors, timing issues, and reconciliation cleanup. |
Why does the routing distinction matter?
Invoice-backed spend paid by card keeps everything AP provides: the approval that authorized it, the PO match if there is one, the vendor record with its W-9 and banking details, the contract linkage, and a clean accrual. Card-originated spend has none of that by default - it must be reconstructed after the fact from a merchant descriptor and a receipt photo. Best practice is to route by spend type: anything a vendor can invoice goes through AP (card as payment method if the economics favor it); true point-of-sale employee spend goes on expense cards with controls attached.
Should vendor invoices ever be paid on a card?
Yes - card-as-fulfillment is smart when the vendor accepts cards without surcharge and the rebate or float is real, *provided the invoice still flows through AP first*. It's a control failure when employees put vendor bills on expense cards "to save time": the invoice never enters the workflow, approvals are skipped, and you risk paying twice when the vendor also mails the invoice to AP.
What is paying invoices by card / card-as-payment-method?
Using a card (usually virtual) to settle an invoice that already went through AP - distinct from an employee charging a vendor bill on their card, which bypasses AP entirely. Same plastic, opposite control posture.
How do we separate AP card spend from employee expense spend in the GL?
Use separate card products or separate clearing accounts per program, and code AP-card payments against the invoice (so they hit the expense the invoice coded), while expense-card transactions code at the transaction level. Never let both flow into one undifferentiated card-clearing dump.
Employees pay vendor invoices on expense cards and we get duplicate payments - how do we stop it?
Detect by matching card merchants against your AP vendor master; prevent by making the AP path fast enough that the card shortcut loses its appeal, and by merchant-blocking known invoice vendors on expense cards. Duplicate-detection on invoice intake catches the second copy.
What is a one-card program?
A single card product covering both T&E and procurement spend. Pro: one feed, one program to administer. Con: one set of controls stretched across two very different jobs - the procurement side needs pre-approval and coding depth the T&E side resists.
AP automation with virtual card payments vs a standalone card program - do we need both?
They solve different problems: AP automation governs invoice-backed spend (card optionally as the payment rail); a card program governs point-of-sale spend. Most mid-market companies need both jobs done - the question is whether one platform does both inside one workflow or you reconcile two systems.
How do I decide which vendors get paid by card vs ACH vs check?
Weigh rebate value against vendor acceptance (and surcharges), early-pay discounts available on other rails, and audit-trail needs. Card where the vendor accepts it without pricing it back to you and no discount beats the rebate; ACH as the default; check only where nothing else works.
A recurring SaaS vendor auto-charges our card - AP spend or expense spend?
It's AP spend wearing an expense disguise: recurring, contracted, vendor-relationship spend. It should have a vendor record and an owner in finance, and ideally migrate to invoicing; if it stays on card, code it centrally against the contract, not by whoever's card it landed on.
Stampli perspective
Stampli Card makes the distinction structural. AP Cards are treated like invoices in the approval workflow - issued from approved requests with pre-set controls and pre-coded GLs - so card-paid vendor spend keeps the same audit trail as any invoice. Expense Cards handle employee-initiated spend with upfront guardrails, real-time transaction posting, and mobile receipt prompts. Both live inside one P2P workflow, so nothing requires a parallel system to reconcile.