How should corporate card transactions be coded to the GL?

Employees know *what* they bought; accounting knows *where it belongs* in the GL. Pure self-coding produces creative account selection; pure central coding produces accountants googling merchant names. The working model is layered: the system suggests codes (from card configuration, merchant history, and rules), the employee confirms the business context and attaches the receipt, and accounting reviews exceptions only. Anything that lets the card carry pre-assigned codes from an approved request removes the question entirely for that spend.

As a starting suggestion, useful; as a coding system, weak. MCCs are assigned by the merchant's acquirer at the merchant level - one code per merchant, regardless of what was bought - so a big-box retailer's MCC tells you nothing about whether the purchase was office supplies, equipment, or a gift card. MCC mapping handles the easy recurring tail; the meaningful dollars need merchant-level rules, transaction context, or pre-coding at request time.

Descriptor decoding only goes so far - aggregator prefixes hide the real merchant. The durable fix is receipt capture at the point of sale and a stated purpose on the request, so you never depend on the descriptor.

Dimensions have to come from somewhere other than the feed: the card's configuration (department cards, project cards), the request that authorized the spend, or the cardholder at submission. Decide the dimension source at program design time, per dimension.

The platform should support line-level splits on the transaction record, just like invoice line coding; if yours doesn't, splits end up as journal entries that detach from the source transaction and break the audit trail.

The dump account is a symptom of coding-after-the-fact. Fix the source: pre-code cards where possible, build merchant rules for the recurring tail, and make "miscellaneous" a reviewed exception queue with an owner, not a destination.

Card feeds rarely separate tax. For use-tax accrual you need receipt-level data - capture receipts, have the coding workflow record taxable status, and accrue use tax on out-of-state purchases where the merchant didn't collect. This is a place where receipt compliance has direct tax consequences.

Memorize merchant-to-GL mappings from confirmed codings, scope rules by amount range and cardholder where one merchant serves multiple purposes, and review the library quarterly - stale rules miscoding confidently are worse than no rules.

AI coding learns from history - merchant, amount, cardholder, past corrections. Card transactions carry less native signal than invoices (no line items, no document), so accuracy depends on enrichment: receipts, requests, and configuration. The structural answer is to attach the context upstream so the AI has an invoice-grade record to work with.

Job and cost code must attach at or before the swipe - field purchases coded weeks later by office staff produce committed-cost blind spots. Issue job-scoped cards or require job selection at receipt capture, and sync to the job-cost module with the same dimensions as AP spend.

Stampli Card transactions are pre-coded - they inherit GL and project codes from the approved request and card configuration, so coding is decided before the spend exists. Transactions post in real time and flow through the same workflows as invoices, where Stampli AI supports coding and routing with ERP-aligned suggestions that humans review before posting.