How corporate credit card management is set up in finance and ERP systems

Corporate cards usually sit between the bank's card platform and the ERP expense module. The bank issues cards and enforces limits. The ERP keeps cardholder records and approval rules. Transactions arrive as a feed to be coded, approved and posted against the statement.

Where the policy lives

Card policy is written as a document, but it only works once it becomes configuration. Spending limits, blocked merchant categories and cash withdrawal rules are set on the bank side, often by card profile. Approval routing, receipt requirements and default coding are set in the ERP or the expense tool attached to it.

The two halves drift apart easily. A limit agreed by the finance committee may be loaded at the bank and never reflected in the ERP's delegation table, or the reverse. Whoever owns the policy should also own the mapping between the written rule and each system setting.

Requests and issuing

A new card normally starts as a request in the expense tool, the HR system or a service desk form. The request captures the employee, their cost centre, a proposed limit and a business reason. It routes to a line manager, and above a set threshold to a finance approver.

Once approved, someone in the card administration team places the order through the bank's online portal. Few organisations have a live integration for this step. The card arrives, the employee activates it, and an administrator links the new card number to the employee record in the ERP so that future transactions find their owner.

That link is the step most often missed. When it fails, charges land in an unassigned queue and sit there.

Running the accounts day to day

The bank sends a transaction file, typically daily, through a secure transfer or a direct feed into the expense tool. Each line matches to a cardholder. The employee adds a receipt, a purpose and coding, then submits. Their manager approves.

On the accounting side, approved card charges post as debits to expense and credits to a card clearing or liability account. The bank statement, settled either by direct debit or by a payment run through accounts payable, clears that account. Reconciliation means proving that the clearing balance equals what the bank says is still outstanding.

Corporate liability cards are billed to the organisation. Individual liability cards are billed to the employee, who is then reimbursed through the normal expense process. The configuration differs significantly between the two, so it matters which model is in place.

Personal or disallowed charges need their own path. They are usually recorded as an amount owed by the employee, recovered through payroll deduction or a direct repayment. Merchant refunds and disputed charges come back as credits on the feed and must be matched to the original transaction. Unresolved disputes and unrecovered personal spend should be tracked with someone named to chase them.

Changing limits

Limit increases follow a lighter version of the request flow. Temporary uplifts for travel or a project are common, and the bank portal often supports an expiry date. Permanent changes should update both the bank profile and any matching record in the ERP. Reductions get less attention but matter after role changes.

Cancelling cards

Cancellation is triggered by a leaver, a role change, a lost card or suspected fraud. The safest designs feed HR termination events straight to the card administrator. Where that link does not exist, cards stay active after people leave.

Cancelling at the bank is only part of the job. Outstanding transactions still need approval, often by the manager in place of the departed employee. Any personal balance owed must be settled before final pay. The cardholder record in the ERP is then closed so no new charges can attach to it.

Questions to ask the people who run the process

The documented process and the lived one rarely match here. These questions tend to surface the difference.

• When a card request is approved, who actually places the order, and how do they know it was approved?
• How is a new card number connected to the employee in the system, and what happens to charges that arrive before that is done?
• Where are limits really controlled, and when did someone last compare the bank's settings with the policy?
• Who approves transactions for a cardholder who has left or moved teams?
• What is sitting in the unassigned or unsubmitted queue today, and how old is the oldest item?
• How are personal charges recovered in practice, and what happens when recovery fails?
• How do refunds and disputed charges get matched back, and who follows up with the bank?
• Does HR tell anyone when a cardholder leaves, or does the card team find out from the statement?
• Is the clearing account reconciled to the bank each period, and who signs off on unexplained differences?
• Are there cards held centrally or shared by a team, and how are those approved and reviewed?

Answers that rely on one person's memory or a private spreadsheet point to where the setup needs work before anything else changes.

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.