Running a purchasing card program: limits, reconciliation, and the GL

Reference article · 6 min read

A purchasing card program moves small-dollar buying out of the requisition and purchase order process and into a controlled card transaction. Done well, it reduces the volume of low-value purchase orders staff have to create, approve, receive, and pay, it shortens the gap between a need and a delivery, and it concentrates spend with one issuer so the agency has a single clean dataset to analyze. Done poorly, it produces a stream of charges nobody codes correctly, statements that sit unreconciled past the close, and a recurring audit finding.

The difference is rarely the card itself. It is the structure around it: who holds cards, what those cards may buy, who reviews the charges, what documentation is required, and how transactions reach the general ledger with coding that survives review. The sections below take those decisions roughly in the order an agency has to make them.

Decide what the card is for before setting limits

Write down the purchase types the card is meant to cover and the types it is not. Common inclusions are consumables, small tools and parts, registrations and training, subscriptions, and travel. Common exclusions are anything under an existing term contract that already has ordering mechanics, capital assets that must be tagged and tracked, professional services that require a scope and insurance, and anything that would trigger formal solicitation thresholds.

That written scope becomes the basis for everything else. Limits, merchant category rules, and approval paths are simply the enforcement of a policy decision. If the scope is vague, the controls will be arbitrary, and cardholders will read them as obstacles rather than rules.

Structuring limits: categories, ceilings, and velocity

Most issuers let you control four dimensions independently. Use all four rather than relying on a single dollar cap.

Merchant category controls. Cards can be restricted to or blocked from merchant category codes. Remember that the code is assigned to the merchant by its acquirer, not by you, so a general retailer may present a code that does not match what the cardholder is actually buying. Treat category blocking as a coarse filter, not a guarantee.
Single transaction ceiling. Set this below the threshold at which your procurement rules require quotes or a formal process, so a card purchase cannot quietly bypass a solicitation requirement. Confirm the applicable thresholds in your own state statute, local code, and grant terms, since they differ by jurisdiction and change over time.
Cycle and daily limits. A monthly or cycle ceiling caps exposure per card. A daily or per-count velocity limit is what actually catches a compromised card before the cycle ends.
Card-level defaults. Assign a default fund, department, and object code to each card so an uncoded transaction still lands somewhere defensible.

Vary limits by role instead of issuing one profile to everyone. A facilities supervisor buying parts and a program assistant buying registrations do not need the same envelope.

Roles and separation of duties

Three roles should be distinct people wherever headcount allows. The cardholder makes the purchase, obtains documentation, and codes the transaction. The approver is the cardholder's supervisor or a designated reviewer who confirms the purchase was for agency business, was allowable under the funding source, and is coded correctly. The program administrator issues and closes cards, sets limits, runs exception reports, and manages the issuer relationship.

An approver should never approve their own transactions, and a cardholder should never be the person who releases the payment to the issuer. If a small department cannot separate these, document a compensating control such as finance review of that department's activity every cycle.

Receipts, coding, and the monthly close

Require an itemized receipt, not just a card slip or a card-issuer transaction line. The receipt is what shows what was bought, and it is what an auditor asks for. Require a short business purpose in plain language, the funding string, and, where applicable, the grant or project identifier.

Set the cardholder and approver deadlines relative to the cycle close, and set them early enough that accounting can still post before the accounting period closes. Publish what happens when the deadline passes: a documented escalation, then suspension of the card. Escalation that is never applied is the fastest way to lose the deadline entirely. Also confirm your sales tax exemption practice, because exempt agencies are still routinely charged tax at the register and the correction is far easier during the cycle than after it.

Posting card activity to the general ledger

The mechanics that keep a program clean are usually these. The issuer provides a transaction file or API feed on a defined schedule. Transactions load into a staging area where cardholders recode and split lines across accounts. Approved lines post to the general ledger. The single payment to the issuer posts to a clearing or liability account that the coded transactions relieve.

The control to watch is that clearing account. If it does not return to zero after each cycle, something posted that was never coded, or something was coded that never posted. Reconcile it every cycle rather than discovering a drift at year end. Ask the issuer whether enhanced merchant data, sometimes called Level II or Level III data, is available for your merchant mix, since line-level detail reduces manual coding for the merchants that supply it.

Monitoring, audit, and deciding whether to expand

Run standing exception reports rather than sampling only when an auditor asks. Useful ones include transactions just under the single transaction ceiling, repeated same-merchant same-day charges that suggest a split purchase, weekend and after-hours activity, blocked-category attempts, and cards with no activity for several cycles. Dormant cards are pure risk and should be closed.

Expansion is a reasonable goal once reconciliation is consistently on time. The case for it is administrative: fewer small purchase orders, faster delivery, and a rebate on volume that is typically tied to spend and payment speed. Expand by raising limits for proven cardholders and adding well-defined categories, not by issuing cards broadly and hoping policy catches up.

What to ask the issuer and your ERP team

Controls. Which limit types can be set per card, how quickly do changes take effect, and can approvers be assigned in the issuer system as well as in the ERP?
Data. What file formats or APIs are offered, on what schedule, and does the feed include merchant category, tax, and line-level detail?
Integration. Who owns the mapping from merchant data to your chart of accounts, and what happens to a transaction that fails to load?
Disputes and fraud. What is the dispute window, who may file, and how are credits reflected in the feed so reconciliation still balances?
Reporting. Can the program administrator build exception reports without a service request?
Tax reporting. Payments made by payment card are generally reported by the card networks and acquirers rather than by the paying organization, which affects your information return obligations. Confirm the current treatment with your finance leadership or tax advisor before changing practice.

HQT works with state and local agencies on financial system integrations and the data feeds that connect payment and procurement activity to the general ledger.

Frequently asked questions

How often should purchasing card transactions be reconciled?

Most agencies reconcile on the issuer's billing cycle, with cardholder coding and receipt attachment due first and approver sign-off due a few days later. Set both deadlines early enough that finance can post the activity before the accounting period closes. The practical test is whether the card clearing account returns to zero every cycle; if it does not, reconciliation is incomplete regardless of what the calendar says.

What controls stop cardholders from splitting a purchase to stay under the limit?

Set the single transaction ceiling below the point where your procurement rules require quotes or a formal solicitation, so splitting is the only way to evade the rule and is therefore detectable. Then run a standing exception report for repeated charges at the same merchant on the same day or across consecutive days. Pair the report with a written policy statement that splitting is a disciplinary matter, and apply it consistently the first time it happens.

How do purchasing card transactions get into our ERP general ledger?

The card issuer provides a transaction file or API feed on a set schedule. Transactions load into a staging area where cardholders assign or correct the funding string and split lines across accounts, approvers review, and approved lines post to the general ledger. The single payment to the issuer posts to a clearing or liability account that the coded transactions relieve, so that account should reconcile to zero each cycle.

Do we need to issue information returns for vendors paid by purchasing card?

Payments made by payment card are generally reported by the card networks and merchant acquirers rather than by the organization making the purchase, which is one reason agencies expand card use for small vendors. The rules and thresholds in this area do change, and the treatment depends on how a given payment is processed. Confirm current requirements with your finance leadership or tax advisor before changing your reporting practice.

Should a purchasing card program replace small purchase orders entirely?

Not entirely. Cards work well for consumables, small parts, registrations, and subscriptions, but purchase orders remain the better instrument for anything requiring a scope of work, insurance or bonding, asset tagging, or ordering against an existing term contract. A reasonable approach is to define the card's scope in writing and expand it gradually as reconciliation performance proves stable.