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

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

How to Build a Per Client Policy for business virtual cards A per client card policy gives agencies, freelancers, and small teams a repeatable way to...

VBy VCC Business20 min read

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

A per-client card policy gives agencies, freelancers, and small teams a repeatable way to control spending without mixing client budgets, personal funds, and business subscriptions. The practical recommendation is to issue one card or card group per client, define exactly what it may pay for, set a funding and approval process, and review transactions on a fixed schedule.

Use business virtual cards when you need clear separation, controlled access, and easier reconciliation. Do not treat a virtual card as a substitute for bookkeeping, client consent, or platform compliance. The policy should explain who can use each card, which merchants are allowed, what happens when a payment fails, and how the card is closed when the engagement ends.

Start with a card structure that matches your client work

The best setup depends on how your team buys services. A single card for every client is simple but creates problems when multiple people need access or when one client has several campaigns. A card for every individual transaction provides control but can create unnecessary administration and recurring-billing failures.

For most agencies, a three-level structure works well:

  • Client-level card: Used for approved tools, suppliers, or general operating costs attributable to one client.
  • Campaign-level card: Used when advertising spend, budgets, or reporting must be separated by campaign or channel.
  • Vendor-level card: Used for a recurring SaaS subscription or supplier that serves several client accounts but needs its own payment control.

Choose the lowest level that gives you reliable attribution without creating needless card maintenance. If one client has five small tools and one media budget, a client-level card plus a separate advertising card may be more practical than six cards.

Define what each client card is allowed to pay for

A card policy should describe permitted spending in operational terms. “Business expenses only” is too vague for a team member who is deciding whether a design marketplace, stock image library, contractor invoice, or software upgrade qualifies.

Write a short permitted-use statement for every card. For example: “This card may pay for approved advertising on the client’s named platform, campaign-related software, and pre-authorized production costs. It may not pay for personal purchases, unapproved subscriptions, cash-equivalent products, or expenses belonging to another client.”

Separate recurring payments from one-time purchases. Recurring charges need an owner, renewal date, expected amount, cancellation rule, and backup payment plan. The virtual card recurring payments guidance is useful when deciding whether a card is suitable for subscriptions that may retry, renew, or change amount.

Also define prohibited categories. Depending on your business and provider terms, these may include cash withdrawals, gambling-related merchants, cryptocurrency purchases, gift cards, personal travel, political advertising, or any transaction that the client has not approved. The policy should say that provider rules and applicable platform rules take priority over internal preferences.

Use a client approval and funding workflow

The card should not become the approval system. Before funding or authorizing a card, record the client’s approval in the contract, statement of work, purchase order, email, or project management system. Include the budget, merchant or platform, billing frequency, expected start date, and who may approve changes.

A simple workflow looks like this:

  • The account owner records the business purpose and client budget.
  • The client or authorized contact approves the purpose and spending limit.
  • The finance or operations owner creates the card and assigns an internal cardholder.
  • The cardholder confirms the merchant, currency, billing cycle, and receipt requirements.
  • The card is funded only for the approved amount or operating window.
  • Transactions are matched to receipts, invoices, campaigns, or client work.
  • Any unusual charge is paused, investigated, and escalated before the card is replenished.

For prepaid or balance-controlled products, document whether unused funds remain available for the next billing cycle or are returned to the client ledger. A reloadable vcc can be useful when a known card needs additional funding over time, but reloadability should not remove the need for approval before each material increase.

Choose limits that control risk without breaking operations

Set at least three limits: a maximum balance or funding amount, a transaction ceiling, and a time or review window. A media buyer may need a higher daily limit than a contractor purchasing a software seat, while a subscription card may need a low transaction ceiling but enough balance for the monthly renewal.

Use a limit formula based on expected activity rather than an arbitrary amount. Start with the approved forecast, add a clearly documented buffer for timing or tax differences, and review the result against the provider’s controls. Do not load the full value of a long campaign if the client has only approved the first phase.

When deciding between a fixed-limit card and a reloadable card, use this comparison:

Choose a fixed or disposable card when the purchase is one-time, the merchant is unfamiliar, the amount is precisely known, or the card may be exposed to a higher-risk checkout. This reduces the balance left behind after the transaction.

Choose a reloadable card when the same approved merchant needs repeated funding, the cardholder needs a controlled operating balance, and your team can review reloads. A reloadable virtual credit card may fit recurring operational workflows, but check its merchant acceptance, reload rules, expiration terms, and fees before assigning it to a client.

Do not choose based only on the word “reloadable.” A product may have restrictions on reload frequency, supported funding sources, currencies, verification, or merchant categories. Confirm the current provider terms and test the payment flow with a small approved transaction.

Separate card ownership, permissions, and accountability

Every card should have one accountable internal owner, even if several people can view transactions. The owner is responsible for knowing the purpose, checking activity, requesting limit changes, and closing the card when it is no longer needed. A client may approve the budget without being responsible for internal access management.

Keep a card register with the following fields:

  • Client name and internal client ID.
  • Card identifier, without storing sensitive card details in an unapproved document.
  • Assigned owner and backup owner.
  • Approved merchants, platforms, and expense categories.
  • Funding source and current control method.
  • Opening date, review date, renewal date, and planned closure date.
  • Approved limit, current balance, and escalation contact.
  • Links to the relevant approval, contract, budget, and reconciliation record.

Use the principle of least privilege. A person who only needs to check a subscription should not automatically receive authority to reload a card. The person who can approve a budget increase should not be the only person reviewing the resulting transactions.

If your workflow requires a card that can be topped up for repeated use, compare the operational details of a reloadable virtual card with your team’s approval process. The right choice is the one your staff can monitor consistently, not the one with the most features on paper.

Make reconciliation part of the client promise

Client-level cards only improve reporting if transactions are reconciled promptly. Set a cadence based on risk and volume: daily for active advertising accounts, weekly for normal SaaS and supplier spend, and immediately for any disputed or unfamiliar transaction.

Require a receipt or invoice for every transaction unless an exception is documented. The record should connect the charge to a client, project, campaign, vendor, date, amount, currency, tax treatment, and approver. If the merchant descriptor is unclear, add a plain-language note before month-end billing.

For advertising, retain the platform receipt and the campaign reference. For SaaS, record the seats or workspace covered. For supplier payments, record the purchase order, delivery status, or contractor approval. This evidence helps explain variances without forcing the client to inspect raw card statements.

Set an exception threshold that triggers review. Examples include a duplicate charge, a charge outside the billing window, a failed reversal, a sudden amount increase, a merchant change, or a transaction made after the project was paused. Your policy should state whether the card is frozen immediately or whether the owner first contacts the merchant.

Build closure and dispute rules before you need them

Cards often remain active because teams focus on launching work and forget to close payment instruments when a project ends. Add closure to the offboarding checklist. Confirm that subscriptions are canceled or transferred, pending refunds are tracked, the final invoice is received, and no scheduled campaign will continue charging.

For client disputes, preserve the transaction details and communicate quickly. Do not promise that a charge can be reversed until the provider or merchant confirms the outcome. If the client’s funds are involved, follow the contractual treatment for refunds, disputed expenses, and timing differences.

A virtual card is not automatically anonymous, risk-free, or immune to merchant review. Providers and platforms may require identity verification, transaction monitoring, or additional documentation. Never use a card policy to conceal the beneficial owner, evade account limits, bypass advertising rules, or misrepresent the payer.

Use this per-client card policy checklist

Before issuing or reloading a card, confirm each item below:

  • The client and project are identified in the card register.
  • The permitted merchants, categories, and business purpose are written down.
  • The budget, transaction ceiling, and review date are approved.
  • One owner and one backup owner are assigned.
  • The receipt, invoice, and campaign-reference process is clear.
  • Recurring payments have an owner, renewal date, and cancellation plan.
  • The escalation procedure for unusual, declined, or duplicated charges is documented.
  • The closure trigger and final reconciliation steps are recorded.

Avoid the mistakes that undermine card controls

Most card-policy failures are process failures rather than technology failures. Watch for these common mistakes:

  • Mixing clients on one card: This makes attribution difficult and increases the chance of charging the wrong budget.
  • Giving everyone reload access: A card should not be topped up simply because the balance is low; each reload needs a purpose and approval trail.
  • Using a low-limit card for a volatile subscription: Variable renewals can fail, trigger retries, or interrupt service.
  • Ignoring merchant descriptors: A legitimate charge can still appear suspicious if nobody records what it relates to.
  • Leaving cards open after offboarding: Canceling a client contract does not always cancel subscriptions or scheduled payments.
  • Treating a card as bookkeeping: Card separation improves evidence, but it does not replace ledger entries, tax records, or client invoices.
  • Choosing a product without testing acceptance: Some merchants reject particular card types, currencies, regions, or prepaid funding methods.

FAQ about per-client card policies

Should each client have a separate virtual card?

Usually, yes, when the client has meaningful recurring spend, advertising activity, or multiple team members. Separate cards make reconciliation and limit management easier. For very small engagements, a shared vendor card may be acceptable if every transaction is tagged and approved. Do not share a card merely to reduce administration if it causes client funds or permissions to become ambiguous.

Are reloadable cards suitable for advertising spend?

They can be suitable when the advertising platform accepts the card type and the agency can monitor funding, daily limits, and billing behavior. Test acceptance before committing a campaign budget. Advertising platforms may preauthorize, retry, or charge after a campaign changes, so leave an approved operational buffer and define who handles a declined or unexpected charge.

What should happen when a client wants a higher limit?

Require a written request that states the new amount, purpose, start date, end date, and approving contact. Check current spend and unresolved exceptions before increasing the limit. Record the approval in the card register, apply the change, and schedule a follow-up review. Never raise a limit permanently when the need is a temporary campaign or purchase.

Can one card pay for tools used by several clients?

It can, but the arrangement requires stronger allocation controls. Record the client share, billing basis, and approval for each expense, then reconcile before invoicing. A separate vendor-level card is often cleaner for a shared SaaS tool, while client-specific advertising should generally remain separate. Avoid shared cards when the vendor cannot provide useful invoices or usage records.

What kind of card works best for recurring subscriptions?

Use a card with reliable merchant acceptance, sufficient balance, clear renewal visibility, and controls that do not unexpectedly interrupt service. A virtual visa reloadable option may be worth evaluating where Visa acceptance and ongoing funding fit the workflow. Confirm provider terms, billing limits, verification requirements, and cancellation handling before relying on it for a critical tool.

Take these actions in the next seven days

On day one, list every active card, client, merchant, owner, balance, and recurring charge. On day two, identify mixed-client cards and assign each transaction to a client or shared-cost category. On day three, create the card register and write the permitted-use statement.

On days four and five, obtain approval for limits, test the highest-risk merchants with small authorized transactions, and document the reload process. On day six, review subscriptions and set closure dates for inactive projects. On day seven, run a sample reconciliation from card transaction to client invoice and fix any missing evidence.

If your team needs ongoing funding for approved expenses, compare a reloadable virtual visa card against the control requirements in this policy. The objective is not to create the maximum number of cards. It is to create a payment workflow where every client charge has a clear purpose, owner, approval, limit, and audit trail.