Manage corporate credit cards: what to automate and what stays human

Software can already take card requests, place orders with the issuer, apply routine limit changes and shut cards when someone leaves. People still need to write the policy, judge exceptions and decide what to do about misuse. None of this holds up unless employee, cost centre and card records agree.

Where software can take the work today

Requests are the easiest place to start. A form tied to the HR system can pull the employee's role, manager and cost centre without anyone retyping them. Routing then follows the reporting line. For most requests the only human touch is the manager's approval.

Ordering follows on naturally. Most issuers accept new card instructions through a portal or a file feed. Once a request is approved, the order can be raised automatically with the default limit and merchant category blocks the policy assigns to that grade. The issuer's confirmation should write back to the card record, so nobody chases it by email.

Account maintenance is mostly event driven. A transfer to another team, a name change or a new delivery address all start as HR updates and can be pushed to the issuer the same way. AI earns its place here by reading the transaction feed and spotting spend that looks odd for a particular cardholder. A sudden run of cash withdrawals is one example. A merchant far outside that person's usual pattern is another. The model flags. It does not decide.

Limit changes split cleanly. A temporary increase for travel can be granted without review when it sits inside a band the policy already allows, with an end date that reverts it. Anything above that band goes to a person.

Cancellation is the clearest win of all. A leaver record should deactivate the card on the final working day without a ticket. Where the policy suspends cards during extended leave, that can run off the HR absence record too.

Where a person has to stay involved

Setting the policy is a judgment about risk appetite and culture. Someone has to decide who qualifies for a card at all and how high limits go by role. That person also has to settle which spend belongs on a card and which belongs in the reimbursement or purchase order route. No model should be choosing that.

Exceptions need an owner. A director asking for a permanent rise, or a team that buys software subscriptions on cards, raises questions that a rule cannot answer well.

Misuse is the hardest part. Once a transaction is flagged, a person has to look at it and speak to the cardholder. That person also decides whether to suspend the card and whether HR gets involved. Disputes with the issuer over fraud or chargebacks also need someone who can argue a case.

What the data has to look like first

Every card must link to a live employee record through one shared identifier. A name typed into the card platform is not enough. When HR, the card system and the ledger each hold their own version of a person, automated cancellation fails silently and cards outlive their holders.

Cost centres and approvers on each card need to be valid today, not as they were when the card was issued. Reorganisations quietly break this.

The policy itself has to be written so a system can read it. That means limits by grade, blocked merchant categories and the approval band for temporary increases, all held as data. A policy that lives only in a PDF cannot drive anything.

Leaver dates must reach HR before the person goes. In many organisations they arrive after, which defeats the whole point.

Shared departmental cards and cards held by contractors need separate handling. They have no single owner in HR, so rules built around employee events will miss them. Find them and give each one a named custodian before switching anything on.

The issuer feed must arrive reliably and match card numbers to the internal record. Gaps here make anomaly detection noisy enough that people stop reading the alerts.

Questions to ask the people who run it

• When someone leaves, who actually tells the card administrator, and how late does that usually happen?
• Are there cards nobody can match to a current employee?
• Which limit increases get approved informally, by a message to someone who knows the issuer contact?
• How many shared or team cards exist, and who holds the physical card?
• When a cardholder moves department, does anyone update the card's cost centre?
• What happens today when a suspicious transaction appears? Who sees it first?
• Are there teams that use cards for spend the written policy says should go through purchasing, and has anyone allowed it?
• Which parts of the issuer portal are still worked by hand because the file feed failed once and nobody trusted it again?

The answers to these usually show where the documented process and the real one have drifted apart. Automating the documented version alone tends to fail on exactly those gaps.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.