How do you reconcile the corporate card statement to the GL each month?

Step by step: (1) transactions flow into your coding workflow daily as they clear, not in a statement-close dump; (2) cardholders code and attach receipts within days of the swipe, with automated reminders; (3) accounting reviews exceptions - uncoded items, missing receipts, policy flags - weekly; (4) at statement close, you're tying a liability account to a statement, not coding a month of history; (5) the payment to the issuer clears the liability account to zero (or to a known timing difference). The defining feature of a healthy process is that statement day is boring.

Move the work upstream. Set a coding-and-receipt SLA measured in days from transaction, not days from statement. Enforce it with escalating reminders and, ultimately, card pause - one paused card converts more procrastinators than a quarter of emails. Then accrue rather than chase: if a handful of transactions are uncoded at close, book them to an accrual with a default coding and true up next month. Close should never wait on a cardholder.

Daily (or continuous) posting keeps expenses in the right period, gives real-time budget visibility, and spreads the reconciliation workload. Batch posting at statement close is simpler to tie out but concentrates work, blurs accrual cutoffs, and means your GL is blind to card spend for weeks at a time. Modern practice is continuous posting to a card clearing/liability account, with the statement payment clearing the balance.

Book on cleared/posted date for the GL and treat the statement as a timing snapshot; a small, explainable list of in-transit transactions at cutoff is normal. Accrue anything material that's swiped but unposted at period end.

The usual suspects: refunds and merchant credits landing in a different period than the original charge, FX rate differences between authorization and settlement, issuer fees that never enter the expense tool, disputed amounts provisionally credited, and feed gaps or duplicates. Reconcile by transaction count first, then by amount - it isolates the category of break faster.

Post them as contra entries to the same GL account (and job/project, if applicable) as the original charge, not to miscellaneous income. Provisional dispute credits should sit in a suspense or clearing line until the dispute resolves.

Transactions credit the card liability account as they post; the statement payment debits it. A healthy clearing account returns to zero (or to a documented in-transit list) every cycle - a balance that grows month over month means uncoded or duplicate activity is accumulating.

Separate liability accounts per program, one shared coding workflow, one exception report. The mistake is separate processes per program; the account structure should differ, the workflow shouldn't.

With continuous coding, the statement tie-out is hours, not days - best-in-class teams treat it as a checklist item, not a project. If card reconciliation consumes multiple days every close, the problem is upstream coding discipline, not the reconciler.

Quantify by matching on card number + date + amount + merchant, reverse in the current period (with prior-period disclosure if material), and add a duplicate-detection control at the import step so a future feed change gets caught in days, not months.

Estimate from authorization data if available, or from the trailing average of late-posting transactions, and book a reversing accrual to the card liability account. Document the method once and reuse it - auditors care about consistency more than precision at this size.

Stampli Card posts transactions in real time, and transactions arrive pre-coded - they inherit GL and project codes from the approved request, with spending limits set by cardholder, merchant category, or vendor up front. AP Cards are treated like invoices in the approval workflow, so card spend moves through the same review and audit trail as the rest of payables instead of accumulating as a month-end pile.