Corporate Card Reconciliation for Finance Teams
Corporate card reconciliation is the month-end check that proves every employee card purchase is a real business expense, coded to the right cost centre, and posted once. It is not the same job as matching a card network's settlement file. Settlement tells the programme what the issuer and the networks agreed. Statement reconciliation tells finance what the employee bought, why it was allowed, and which ledger account should carry it.
Finance teams lose days when those two jobs are mixed. A cleared transaction can still lack a receipt. A receipt can describe a purchase the statement never shows. A refund can land in a later period and leave the original cost sitting in travel. This guide is the operating close for employee card statements: what to match, which exceptions to name, and what data the programme must supply before the books can close.
What Corporate Card Reconciliation Covers
A corporate card is a company-issued card an employee uses for a defined business purpose. The employer owns the programme rules. The employee initiates the spend. Finance owns the record that turns that spend into an accounting entry. Reconciliation is the comparison of those records.
Three files usually have to agree before a line is done:
- The card statement or transaction feed.
Date, merchant, amount, currency, card, and employee.
- The business evidence.
A receipt, invoice, or trip record, plus the policy check that says the spend was allowed.
- The ledger entry.
Cost centre, expense account, tax code, and the funding or liability account the programme uses.
If any one of those is missing, the line is an exception, not a posted expense. Treating an unmatched line as "close enough" is how duplicate refunds, personal spend, and audit findings survive into the next period.
Bank reconciliation is a cousin, not a substitute. A bank reconciliation compares the company's cash accounts with a bank statement. Card reconciliation compares employee-initiated card spend with receipts and the expense ledger. A programme can have a clean cash position and still have a drawer of unexplained hotel and software charges. The corporate expenses use case is where that second gap usually shows up: travel, meals, equipment, and remote-work purchases made on cards rather than through a purchase order.
Statement Lines, Receipts, and the Ledger
Start with the statement, not the receipt pile. The statement is the population. Every line needs a home. Working from receipts first hides the purchases nobody documented.
For each line, the reviewer needs five facts before coding:
- Who spent it.
The card and the named employee or team the card was issued to.
- What it was.
Merchant name is not enough. A receipt or invoice should show the goods or service.
- Whether policy allowed it.
Amount, merchant type, and timing against the employee's limits.
- Where it belongs.
Cost centre, project, and expense account.
- How it will be funded.
Prepaid balance, programme float, or a liability the company still has to settle with the issuer.
Merchant descriptors are a weak source of truth. "AMZN Mktp" can be a laptop charger or a household item. "UBER" can be a client visit or a weekend trip. The receipt, or a written business purpose when a receipt is not available, is what makes the line codable. Teams that skip this step and code from the descriptor alone rebuild the same exceptions at audit.
Currency adds a second match. The statement may show a billing amount in the programme currency and a local amount at the merchant. Code the billing amount the programme will fund, and keep the local amount as evidence. Do not add them. Do not convert the local amount again in the ledger if the feed already did.
What an accountable record needs
Tax treatment is local, and this is not tax advice. US employers who want employee expense payments kept out of wages generally use an accountable plan. Under Treasury Regulation §1.62-2, that arrangement has to require the employee to substantiate the expenses and to return any amount that exceeds them, within a reasonable period. A card programme does not create that file by itself. The statement proves a charge happened. Substantiation still needs a business connection, an amount, a time, and a place or description the reviewer can test.
Other countries set their own evidence rules. The operating point is the same: decide, in writing, what "supported" means, how long the employee has to provide it, and what happens to the line if they do not. A line with no support should stay open. It should not be forced into a miscellaneous account so the close can finish.
Build the Match Before the Close Starts
Reconciliation fails in the last three days of the month when the data model was never agreed. The match is easier if each system owns one job and the feed arrives with the keys finance will join on.
Record. | System that should own it. | Fields the close needs. | Do not use it to prove. |
Card transaction. | Programme back office or transaction feed. | Card ID, employee, date, merchant, billing amount, currency, and status. | That the purchase met policy or was coded. |
Receipt or invoice. | Employee submission, kept outside the card data store. | Supplier, date, amount, business purpose, and file reference. | That the charge has settled with the network. |
Policy result. | Programme controls and the reviewer. | Limit, merchant category, allow or flag, and reviewer. | The ledger account. |
Ledger entry. | Accounting or ERP. | Account, cost centre, tax code, period, and source transaction ID. | The original merchant conversation. |
Join on a stable transaction ID, not on merchant name plus amount. Two employees can buy the same train fare on the same day. Amount matching will pair the wrong receipt and leave the other line looking complete. If the feed has no stable ID, ask for one before you automate anything. A spreadsheet key made of date and amount will break the first time a tip, a split tender, or a currency difference changes the figure.
Keep card data out of the receipt store. Full card numbers and card verification codes are sensitive authentication data. The PCI Security Standards Council states that those codes must not be stored after authorization, even if encrypted. Finance does not need the PAN or the CVV to reconcile. It needs a card reference, a transaction reference, and the commercial fields above. A programme that already runs under PCI DSS should not push raw card data into an expense mailbox. KYC, AML, and fraud monitoring belong in issuing, not in a copy of the card number.
Name the Exceptions Before You Post
A clean close is a list of named exceptions with an owner, not a pile of lines marked for later review. Use a short code set. Keep it stable from month to month so the same problem is countable.
- No support.
The statement line has no receipt or business purpose inside the agreed window.
- Policy break.
The purchase is documented but sits outside the employee's limit, merchant category, or purpose.
- Amount difference.
Receipt and statement disagree by more than a set tolerance, often a tip, a split, or a currency difference.
- Personal spend.
The employee has confirmed the line is not a business cost and must repay it or have it deducted.
- Timing.
The charge, the refund, or the receipt falls in a different period from the one being closed.
- Duplicate.
The same economic event appears twice, often as a purchase plus a later adjustment that was posted as a second purchase.
- Missing line.
A receipt exists and no statement line matches it. Do not invent a charge. Park the receipt until the feed catches up.
Each code needs one next action. No support goes back to the employee with a date. Policy breaks go to the budget owner. Personal spend becomes a receivable, not an expense. Timing differences stay on a clearing account until the other side arrives. Duplicates are reversed against the original source ID, not netted in a journal with no reference.
Refunds and chargebacks are where closes go quiet and wrong. A refund is not income and it is not a new expense. It reduces the original cost, in the period your policy chooses, with the original cost centre if you can still see it. Posting the refund to a generic "other income" account hides the true travel or software spend and makes the next budget look better than the programme was.
A close sequence that survives audit
Freeze the transaction population for the period. Note the feed timestamp so late presentments are visible.
Match on transaction ID. Mark unmatched statement lines and unmatched receipts separately.
Code matched, supported, in-policy lines to the cost centre and account. Post them once.
Assign every remaining line an exception code and an owner. Do not post them to a suspense account without that code.
Reconcile the posted expense total to the programme funding total for the same population. Explain the gap with the open exception list, not with a plug figure.
Lock the file: source ID, coder, reviewer, and the receipt reference. Later changes get a new entry.
That sequence is the employee-statement close. It assumes the programme already knows which transactions cleared and which are still pending. How authorization, clearing, and settlement files move between the issuer and the networks is a different procedure, covered in the payment card settlement process. Use that page when the question is whether the scheme file agreed. Use this one when the question is whether finance can explain the employee's spend to the ledger.
What the Programme Has to Provide
Reviewers cannot code what the feed does not carry. Before a business asks employees to stop using out-of-pocket claims, the card programme should already expose the fields in the table above, on a schedule finance can trust. Real-time spend visibility matters here only because it shortens the exception loop. A line flagged on day two is a conversation. The same line found on day twenty-eight is a close blocker.
Controls and reconciliation are neighbours, not the same control. Limits, merchant locks, and approval rules stop some bad spend before it happens. They do not prove the spend that did happen. A card locked to airlines can still pay for a personal ticket. A monthly limit can still hide the wrong cost centre. Spend-control design belongs in its own review. This close only consumes the policy result: allowed, flagged, or blocked.
For a company that wants its own brand on the cards, the infrastructure question is separate again. Choosing an issuing partner, a BIN sponsor, and a rollout plan is the work in how to launch a corporate card programme. Reconciliation starts after that programme can issue a card, identify the employee, and return a transaction with a stable ID. Buying an expense tool is separate too. The corporate expense management solutions guide is about comparing software. It will not tell a reviewer how to treat a refund that arrived after the receipt was coded.
Intercash is a white-label card-issuing partner, not a consumer card brand and not the employer's accountant. Businesses use it to issue plastic, virtual, and debit cards under their own brand, with programme management in PrepaidGate and cardholder access in CardPortal. For corporate expenses, the useful pieces are the ones that feed this close. That means cards issued to named employees, limits by team or person, and real-time transaction tracking. An API can pass that transaction data into the client's own accounting flow. Virtual cards help when a single online purchase should be isolated. They do not remove the need for a receipt or a cost centre. Pricing is agreed per programme. There is no public rate card to drop into a business case.
The handoff to the ledger should be boring. One source transaction ID. One amount in the billing currency. One cost centre. One status that says whether the line is posted, open, or reversed. Teams that export a fresh spreadsheet with renamed columns each month are reconciling the export format as well as the spend.
Frequently Asked Questions
What is corporate card reconciliation?
It is the check that every employee card purchase on the statement is supported, allowed by policy, coded to the right cost centre, and posted once to the ledger. It answers a finance question, not a card-network question.
How is corporate card reconciliation different from bank reconciliation?
Bank reconciliation matches the company's cash accounts to a bank statement. Card reconciliation matches employee card purchases to receipts, policy, and expense accounts. A balanced bank account does not mean every card line is explained.
How is this different from card settlement reconciliation?
Settlement reconciliation compares the programme's records with authorization, clearing, and settlement information from the issuing side. Statement reconciliation starts after you know which employee charges are real, and it ties those charges to receipts and the ledger. One can be finished while the other is still open.
What should employees submit before a line is coded?
A receipt or invoice, the business purpose, and enough detail to test the amount, date, and merchant. Where an employer uses an accountable plan, US rules require substantiation and the return of any excess within a reasonable period. Local rules differ, so the programme policy should say what "supported" means.
Should finance store full card numbers with receipts?
No. Reconciliation needs a card reference and a transaction reference, not the full card number and not the card verification code. Those codes are sensitive authentication data and must not be stored after authorization.
A card programme that can name the employee, the transaction, and the policy result gives finance a close it can defend. The ledger entry is then a consequence of that match, not a guess from a merchant descriptor. If the statement feed, the receipt rule, and the cost-centre map are still being designed, that is the right moment to align them with the issuing setup rather than after the first month-end.
