How to Build a Per-Client Policy for business virtual cards

The safest way to manage client spending is to give each client, campaign, or approved supplier a separate business virtual card with a written policy attached to it. The policy should define who may use the card, what it can pay for, its spending limit, when it expires, how receipts are submitted, and what happens when the engagement changes.

Do not treat the card itself as the policy. A card limit can reduce exposure, but it cannot explain whether a team member may add a new software subscription, pay an overage, or use the card for a different client. Use the template below as an operating document, then configure card controls to match it. For teams comparing providers, a practical starting point is to review how business virtual cards handle limits, merchant controls, reloads, transaction visibility, and recurring charges.

Start with a card assigned to one client and one purpose

A per-client policy works best when the card has a narrow job. A card labelled Client A Ads is easier to monitor than a general card called Marketing. The first card might be limited to approved advertising platforms, while a second card covers the client’s analytics software. Separating these purposes makes unusual activity visible without waiting for a monthly statement.

For most agencies and freelancers, use this hierarchy:

Client: the customer or internal cost centre responsible for the spend.
Purpose: advertising, SaaS, contractors, inventory, travel, or another defined category.
Merchant scope: named vendors or an approved merchant category where the provider supports that control.
Budget period: daily, weekly, monthly, campaign-based, or project-based.
Owner: the person accountable for approvals, receipts, and exceptions.
End condition: a date, budget exhaustion, campaign completion, or manual closure.

This structure avoids a common failure mode: one shared card being used by several clients and then reconstructed through memory, chat messages, and incomplete invoices. If one card must serve several purposes, document the reason and add a stronger reconciliation process.

Choose the right card model before writing the rules

The funding model affects how strict your policy needs to be. A single-use card can be appropriate for a one-off supplier invoice, but it is inconvenient for a subscription that renews every month. A reusable card is better for ongoing services, provided the owner reviews the merchant, amount, and renewal date.

Use this decision framework:

Choose a single-use or short-lived card when the payment is a one-time purchase, the vendor is unfamiliar, or the exact amount is known in advance. This reduces the period during which the credentials remain usable.
Choose a reusable card with a fixed limit when the same client repeatedly pays one approved vendor, such as a design platform or ad account. Set a cap that reflects the approved budget rather than the highest possible account balance.
Choose a reloadable card when the client budget is released in stages, such as weekly advertising funding or milestone-based supplier payments. A reloadable vcc can fit this workflow, but the policy should state who can add funds and what evidence is required before each reload.
Choose a physical payment method instead when a vendor requires a physical card, in-person verification, or a cardholder name that a virtual product cannot reliably support. Do not force a virtual-card workflow onto a payment channel it was not designed to handle.

For recurring services, check the provider’s rules before switching card details. Some merchants use authorization checks, delayed captures, or account-level verification. A guide to virtual card recurring payments can help your team identify renewal risks before a critical tool stops working.

Use this per-client card policy template

Copy the following structure into your client operations handbook, approval system, or finance workspace. Replace the bracketed fields and keep the completed version alongside the client contract or statement of work.

Per-Client Card Policy

Client and account: [Client name, account ID, and billing contact]

Card name: [Client] – [Purpose] – [Owner]

Business purpose: This card may be used only for [approved purpose] on behalf of [client].

Approved merchants: [List named merchants, platforms, domains, or merchant categories]

Prohibited uses: No personal purchases, cash withdrawals, unrelated client expenses, gift cards, unapproved subscriptions, or payments to vendors not listed above.

Budget and limits: The approved budget is [amount or formula] for [period]. The transaction limit is [amount], the period limit is [amount], and the card may not be reloaded above [amount] without written approval.

Authorized users: [Names or roles]. Credentials may not be shared, stored in an unapproved password manager, or sent through ordinary email or chat.

Approval rule: New merchants, budget increases, recurring charges, and purchases outside the approved category require approval from [role] before payment.

Receipt rule: The cardholder must upload the invoice, receipt, client reference, and business purpose within [time period] of the transaction.

Monitoring: [Owner] reviews transactions [daily, weekly, or monthly] and resolves unmatched transactions within [time period].

Exceptions: Emergency spend up to [amount] may be approved by [role] and documented within [time period].

End date and closure: The card expires, is frozen, or is closed on [date or condition]. Any remaining balance is handled by [role] under [procedure].

Policy acknowledgement: The assigned user confirms that use of this card is limited to the rules above and that violations may result in suspension of access, repayment review, or other internal action.

The strongest policies are specific without pretending that every transaction can be predicted. If a client’s advertising spend changes frequently, use a formula such as approved media budget plus a documented buffer rather than an arbitrary permanent limit. If a vendor has several legitimate domains or billing entities, list them clearly so normal payments are not blocked unnecessarily.

Set limits that control risk without breaking operations

A limit should reflect the maximum exposure you are willing to tolerate between reviews. It does not need to equal the client’s entire monthly budget. For example, a campaign may have a large approved budget but receive funding in smaller tranches. That arrangement gives the owner a chance to pause spend if performance, client approval, or account access changes.

Set four limits where your provider supports them:

Per-transaction limit: prevents an unusually large charge or accidental bulk purchase.
Daily or weekly limit: controls rapid spending and is useful for advertising accounts.
Total card balance: limits the amount exposed if credentials are compromised.
Merchant or category restriction: keeps a card tied to its documented purpose.

Leave room for legitimate authorization behavior. A hotel, advertising platform, or software vendor may place a temporary hold or charge a small verification amount. If the cap is too close to the expected invoice, the payment may fail even when the budget is correct. Your policy should explain who can increase the limit, for how long, and what evidence is required.

When a card needs regular funding, compare a reloadable virtual credit card with a standard virtual card based on the actual workflow. Reloadability can simplify staged budgets, but it also creates an additional control point: every reload should have a client, campaign, amount, approver, and date attached to it.

Build a repeatable approval and reconciliation workflow

A policy becomes useful when it is connected to a short operating routine. Before a card is issued, the account owner should confirm the client agreement, intended merchant, budget, and end date. After issuance, the cardholder should know exactly where to submit receipts and how to request an exception.

A practical workflow is:

Create the card with a descriptive name that includes the client and purpose.
Record the card owner, approved merchants, limits, funding source, and closure date.
Require approval for any new vendor, recurring charge, or budget increase.
Attach receipts and client references as transactions appear, rather than waiting for month-end.
Review declined, reversed, duplicated, and unfamiliar transactions separately from ordinary spend.
Match each transaction to the client ledger, project, invoice, or campaign report.
Freeze or close the card when the project ends, the client pauses work, or the owner leaves the team.

For suppliers and subscriptions, a reloadable virtual card may be useful when the same payment credential needs controlled funding over time. It is not a substitute for vendor review. If a subscription renews at a higher price, the transaction should be treated as a policy exception unless the agreement explicitly permits price changes.

Apply this seven-point implementation checklist

Use this checklist whenever you create or revise a client card. It is short enough for a ticket template and detailed enough to expose the most common gaps.

Confirm the commercial basis: link the card to a signed proposal, statement of work, purchase order, or written client approval.
Name the owner: assign one person who is responsible for limits, receipts, and closure.
Define the purpose: write the exact category of spend and list what is excluded.
Configure controls: set transaction, periodic, balance, merchant, and geographic controls where available.
Document funding: record the source, approved amount, reload authority, and approval evidence.
Test the workflow: complete a small authorized payment, upload its receipt, and confirm the transaction appears in the correct ledger.
Schedule review and closure: set a recurring review date and an automatic reminder for the card’s end condition.

Keep the checklist evidence in one place. Scattered approvals in direct messages are difficult to audit and easy to lose when a contractor or account manager changes. A shared finance workspace with restricted access is usually more reliable than a collection of personal spreadsheets.

Know the common mistakes before they become charge disputes

Most card-policy problems are process failures rather than sophisticated fraud. Watch for these patterns:

One card for every client: this makes attribution difficult and increases the impact of compromised credentials.
Limits with no owner: a cap does not explain who may approve an increase or investigate a declined payment.
Permanent cards for temporary work: a finished campaign can keep charging if no closure date exists.
Confusing a card balance with a client budget: available funds do not prove that a purchase is commercially approved.
Ignoring delayed or recurring charges: the original approval may not cover a later renewal, tax, overage, or exchange-rate difference.
Allowing informal credential sharing: shared details make attribution and access removal harder.
Over-restricting merchant controls: a narrow rule can block legitimate billing entities, verification charges, or approved platform features.
Keeping exceptions undocumented: a verbal approval may be forgotten when the invoice is reviewed weeks later.

If a card is used for international suppliers, check currency conversion, local acquiring entities, and tax documentation before setting hard merchant rules. Some declines are caused by payment routing rather than unauthorized activity. The right response is to investigate the transaction and update the documented workflow—not to weaken every control.

Handle reloads, recurring payments, and card type decisions carefully

Reloadable products can work well for agencies that release client funds in stages. Before selecting a virtual visa reloadable option, decide whether reload authority belongs to finance, the account manager, or the campaign operator. The person who spends the funds should not automatically be the person who can increase the total budget.

For a recurring SaaS charge, use a reusable card with a documented renewal owner. Record the renewal date, expected amount, cancellation terms, and the business consequence of a failed payment. If the card is used for advertising, consider shorter funding periods and more frequent review because spend can accelerate quickly after a campaign setting changes.

There are also situations where a reloadable virtual visa card is the wrong tool. Avoid it when the vendor requires a direct debit, a physical card, a legally named account holder, or a verification process that does not accept the product. Avoid it when the team cannot reliably record reload approvals. More flexibility without adequate records can create more reconciliation work, not less.

FAQ: Per-client card policy questions

Should every client receive a separate virtual card?

Usually, yes when the client has a distinct budget, billing responsibility, or risk profile. A separate card makes attribution and suspension easier. It may be unnecessary for a low-volume shared tool used across many clients, provided your accounting system can allocate the cost accurately and the vendor permits shared billing. In that case, use a documented cost-allocation rule and review access more frequently.

How much should the spending limit be?

Set the limit to the maximum exposure you can tolerate before the next review, not automatically to the full monthly budget. Consider expected transaction size, billing delays, temporary authorizations, campaign volatility, and the time required to freeze the card. For staged advertising, a smaller weekly limit may be safer than loading a full month of funds. Document the reasoning so the limit can be adjusted consistently.

Can a client or contractor use the card directly?

They can if the arrangement is approved, the user is identifiable, and the provider’s terms permit it. Give the user only the access needed for the task, prohibit credential sharing, and require receipts with a client reference. For contractors, define whether they may request reloads or only spend the existing balance. Remove access immediately when the contract ends or the assignment changes.

What should happen when a recurring payment is declined?

First check whether the decline is caused by an exhausted limit, an expired card, a merchant mismatch, a verification hold, or a genuine control rule. Do not immediately raise the limit without recording the reason. Notify the service owner, confirm that the subscription is still approved, and use an exception approval if the amount or merchant has changed. Update the policy if the recurring arrangement is meant to continue.

Is a reloadable card safer than a standard virtual card?

Neither is automatically safer. A reloadable card can reduce exposure when funding is released in controlled stages, while a standard card may be simpler for a fixed, one-time payment. Safety depends on limits, merchant controls, user access, monitoring, and closure procedures. Choose reloadability when staged funding solves a real operating problem, not merely because the feature is available.

Take these actions in the next seven days

On day one, list every client-funded card and identify cards shared across clients. On day two, assign each card a client, purpose, owner, limit, and end condition. On day three, move those details into the policy template above and obtain written approval for exceptions.

On days four and five, configure transaction and merchant controls, then test receipt capture and ledger matching with a small authorized transaction. On day six, review recurring charges and cancel or reassign anything without a current business owner. On day seven, freeze unused cards, schedule monthly policy reviews, and decide whether staged funding requires a reloadable virtual visa card or a simpler one-time card.

The goal is not to create paperwork for its own sake. It is to make every client charge answerable: who approved it, what it was for, how much exposure was allowed, and when the payment authority ends.