How do I set up a corporate card program and reconcile card spend to the GL?

Connect the card program's bank/card accounts through a read-only transaction feed, filter to credit-type accounts specifically, and pull transactions on a sync cadence rather than a one-time pull. Code each transaction to a GL account via category or merchant-based default mapping, routing anything with low coding confidence to manual review rather than guessing.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 16, 2026Last reviewed September 16, 2026Editorial policy

Part of the spend and expense management guide.

How card transaction data actually arrives	Via a read-only bank/card data feed, filterable to credit-type accounts specifically
Why sync, not one-time pull	A transaction sync captures changes (new, modified, removed) as they settle, not just a snapshot at connection time
Coding mechanism	Category or merchant-based default mapping, same principle as invoice GL coding
What still needs review	A transaction with no confident category match — new merchant, ambiguous description
Reconciliation check	Sum of coded card transactions for the period should tie to the card statement/account balance for that period

How card accounts show up in a transaction feed

A read-only bank data feed doesn't only see checking and savings accounts — credit card accounts connect the same way, distinguished by account type and subtype (Plaid, for example, classifies a connected card account with type "credit" and subtype "credit card," alongside the operating bank accounts on the same connection). Setting up a corporate card program's data feed means connecting the actual card account through this same mechanism, then filtering specifically to credit-type accounts when the goal is card spend rather than bank activity.

Why a one-time pull isn't enough

Card transactions change state after they first appear — a charge that shows as pending can settle days later, sometimes for a slightly different amount (a restaurant tip added after the initial swipe, for instance). A sync-based approach that captures added, modified, and removed transactions over time reflects that reality; a one-time snapshot pull only captures whatever state transactions happened to be in at that single moment, which for card spend specifically is often still pending and not yet final.

Coding card transactions the same way as AP invoice lines

Once card transactions are flowing in, GL coding follows the same principle as automating invoice line coding: derive the account from a category or merchant-based default mapping rather than requiring a human to code every transaction individually. A recurring SaaS charge from the same merchant every month, or a transaction matching a known merchant-category code, can code confidently. A one-off charge from an unfamiliar merchant with an ambiguous description is exactly the case that should route to manual review, for the same reason a low-confidence AP invoice line should — auto-coding a guess creates a silent miscoding, not a saved step.

What reconciling card spend to the GL actually confirms

The reconciliation check itself is straightforward once coding is in place: the sum of all coded card transactions for a given period should tie to the card account's own statement balance or period activity for that same window. A gap points to one of two things — a transaction that arrived in the feed but wasn't yet coded (still pending review), or a transaction that settled with a different final amount than what was originally pulled and coded, which needs the coded entry updated to match the settled amount rather than left at its original pending-state figure.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A card account's pending-to-settled transaction, coded and reconciled

A corporate card transaction at a recurring SaaS vendor first appears in the transaction feed as pending, $89.00, categorized confidently as "Software Subscriptions" based on the merchant's known category — auto-coded to account 6410 without review. Three days later, the transaction settles at $91.24 (the vendor's actual charge included a small currency-conversion adjustment not visible in the initial pending amount), and the sync reflects this as a modified transaction with a new final amount.

The coded GL entry updates from $89.00 to $91.24 to reflect the settled amount — not left at the original pending figure. At period-end, this transaction contributes $91.24 to account 6410's total from card spend, and that $91.24 (not $89.00) is what needs to tie to the card statement for reconciliation to actually pass. Treating the pending amount as final would leave a permanent $2.24 gap between the coded GL total and the real card statement, for every transaction that settled differently from its pending state.

Frequently Asked Questions

The mechanics of connecting and syncing transactions work the same regardless of whose name is on the card, but mixing personal and business cards raises separate policy and expense-substantiation questions (see the IRS documentation requirements covered on the spend-management hub) that a dedicated corporate card program is specifically designed to avoid.

An expense report is typically employee-submitted after the fact, often for out-of-pocket spend later reimbursed. A corporate card program's transaction feed captures spend directly from the card account itself, without requiring an employee to manually submit each transaction — though the two can coexist for different spend categories.

A pending transaction that's removed without a corresponding settled transaction (a declined or reversed charge) should have its coded GL entry reversed too — leaving it coded would overstate spend for a transaction that never actually completed.

Sources

Diagnostic

What breaks when pending Plaid transactions post after month-end lock?

A transaction Plaid shows as pending on the last day of the month can settle days later with a posted date that still falls before close. If a snapshot is taken while it's pending and never revisited, that transaction can be missing from the close entirely, or double-counted if it's picked up again next period without checking whether it was already included.

How-to

How do I maintain segregation of duties in an automated AP approval workflow?

Keep three roles distinct in the workflow itself: who can create or edit a vendor record, who can enter or submit a bill, and who can approve it for payment. Institutional guidance is explicit that authorizing a payment and the person who executes it shouldn't be the same individual — automation makes it easy to collapse these into one click, which is exactly the risk to design against.

Topic

Spend & Expense Management

This cluster covers spend that shows up on a corporate card or an employee expense report rather than a vendor invoice: card transactions, reimbursements, and the controls that keep that spend from be…