Virtual cards for supplier payments, matched to every invoice.

Read summarized version with:

ChatGPT Claude Grok Perplexity Gemini

Paying suppliers with virtual cards means you issue a wallet-funded card set to the exact invoice amount and email it to the supplier, or keep it in your wallet to charge, instead of cutting a check or sending an ACH. You set a spend cap so the card cannot be charged for more than you owe, and where the supplier's processor supports it you can also restrict the card by merchant, category, location, or time. The spend cap is a hard limit; the other locks are checked at authorization and depend on data the network passes, so treat them as strong controls, not guarantees. Each card ties one payment to one invoice, which gives you a clean 1:1 match at reconciliation instead of hunting through a pooled bank feed. You issue cards one at a time or in bulk from a spreadsheet or API, attach receipts, and run the whole thing inside the Zil Money wallet that also pays your other vendors, payroll, and expenses. No credit check, no separate bank link per supplier.

If you own accounts payable, the question is rarely whether virtual cards are useful. You already know they are. The real question is how to run a supplier-payment program on cards day to day: which vendors will take one, how a card payment lands clean against the invoice, and where it beats the ACH or check you send today. This guide stays at the program level. For the broader workflow around approvals, coding, and posting, see our deeper write-up on accounts payable automation; here the focus is the supplier payment itself.

How virtual card supplier payments actually work

A virtual card supplier payment is one card issued for one invoice. You create the card, fund it from your wallet, set the cap to the amount you owe, and label it with the invoice number. Then you either email the card to the supplier's accounts receivable team with the remittance detail, or you keep the card in your wallet and charge it yourself against the invoice. When the supplier runs it, the charge clears against the cap, posts under the invoice label, and waits for you to match it.

That is the whole loop, and it is deliberately small. The control lives at the moment of payment, not after the money has already left in a wire or an ACH batch. Because the card holds only what you loaded and is capped to the invoice, the supplier cannot quietly bill more than you agreed, and you are not handing out your real account number to do it. If you want this at the per-transaction level, our guide on how to pay vendors with virtual cards walks the same steps for a single payment.

Will your suppliers accept a card?

Many will, and the reason is in it for them too: they get paid with remittance data attached and never see your bank details. The card is a Visa, so any supplier that accepts Visa can charge it. The friction is not the card being virtual. It is the supplier's own card policy and the cost of acceptance they carry on their side.

Some suppliers will not take a card at all, and some accept one but pass on an acceptance cost to cover their processing. Both are normal, and neither breaks the model. The move is to segment your vendor list: lead with the suppliers who already take cards or who value not having your account number on file, then have the conversation with the ones on the fence, and keep ACH for the rest. You do not have to push every supplier onto cards to get the win. You only have to put the right ones there.

When you do email a card, include the invoice or PO number and the remittance detail in the same message. That answers the supplier's first question, what is this payment for, before their AR team has to ask, and it is what makes the charge easy for them to apply on their side.

Card vs ACH vs check vs wire: when each wins

Every AP team is choosing among a few real rails, not reading a feature sheet. Here is how they compare on the things that actually bite at month-end.

The pattern is consistent: ACH and wire are cheap to send but give you zero control once the money leaves, and checks add a physical failure mode on top. A card keeps control at the moment of payment and reconciles itself, at the cost of acceptance you have to manage per vendor. For a closer read on the cheapest-to-send rail against the most controllable one, see virtual cards vs ACH.

How card payments reconcile 1:1 against the invoice

This is the part that gives controllers their month-end back. Because each card is issued for one invoice and labeled with the invoice number, reconciliation collapses to a one-to-one match: one card, one settled charge, one invoice, one receipt. You are no longer staring at a pooled bank feed trying to work out which deposit belongs to which invoice.

That 1:1 structure also closes two of the most common AP failures. You do not pay the same invoice twice, because the invoice is bound to a single card that gets marked paid against a single line. And you keep a paper trail an auditor will accept, because the card's label, the settled charge, and the attached invoice all point at the same document. The pooled-feed guessing game is what creates duplicate payments and missing-backup findings; isolating each payment on its own card removes the guessing.

Setting spend caps and locks per supplier

The cap is the control you rely on, so set it deliberately. Make the spend cap equal to the invoice amount. The agreed charge clears, and any attempt to bill more is declined at authorization. That single rule is what stops a vendor charging more than the PO, and it is the reason the cap, not the fancier locks, is your primary control.

Where the supplier's processor supports it, you can layer on merchant, category, location, or time restrictions so the card only works in a narrower lane. Be honest about what these do. The spend cap is deterministic: over the cap, declined, full stop. The merchant, category, location, and time locks are probabilistic. They are checked at authorization using the data the supplier's acquirer passes through the network, and that data is not always complete or correctly coded. So treat those locks as a strong second layer where supported, and let the cap carry the weight.

Issuing supplier cards one at a time or in bulk

For a single invoice, you create one card on screen. For a real AP run, that is not the workflow. You can create many cards at once from an Excel or CSV upload, one row per invoice with its own cap and label, or issue them programmatically through the API so a card is generated as each invoice is approved for payment. Each card still carries its own cap, its own invoice number, and its own receipt, so volume does not cost you the 1:1 cleanliness. See issue virtual cards in bulk for the spreadsheet and API workflow.

How you issue also depends on the vendor. For a one-off invoice, a single card is the cleanest fit. For a supplier you pay over and over, a reloadable card with a standing cap can beat spinning up a fresh card each time. The trade-off between the two is covered in single-use vs reloadable virtual cards.

Handling overcharges, partial captures, refunds, and credits

The cap handles overcharges for you: an attempt to bill above the invoice amount is declined at authorization, so there is nothing to claw back later. Partial captures are normal too. A supplier can capture less than the cap, and the difference simply stays unspent on the card. You reconcile against what actually settled, not against the cap.

Refunds and credits run as their own settled lines. A supplier refunds to the same card, and you treat that refund as a separate entry against that card's invoice record, then reconcile the net. Keep the card's label and receipt and the credit ties back cleanly to the original invoice instead of floating loose in a bank feed. The one thing to respect is timing, which is the subject of the next warning.

A real example: one supplier invoice, one capped card

Here is an invoice walked end to end. Your supplier, Northgate Supply, sends invoice INV-7781 for $4,250.00. You issue a card capped at $4,250.00, label it INV-7781, and email it to Northgate's AR team with the invoice attached.

Building a supplier-payment program on cards

A program is just these pieces applied with discipline. Decide which vendors go on cards by acceptance and by how much control each payment needs, then keep ACH for the rest rather than forcing everyone onto one rail. Standardize the remittance you send so every supplier's AR can apply the charge without emailing you back. And make the cap-to-invoice rule non-negotiable, since that single habit is what produces the clean 1:1 record across the whole run.

Run inside one wallet and the program compounds. The same Zil Money wallet that issues your supplier cards also handles the ACH you keep, plus payroll and expenses, so AP stops being scattered across rails and logins. You get spend control where you want it, a reconciliation that matches itself, and a paper trail that holds up, without a separate bank link for every supplier.

Mistakes to avoid

People also ask