How to Automate GL Coding for Corporate Card Transactions
A practical approach to card coding: connect each charge to evidence, apply scoped accounting rules, and review exceptions before they become duplicate expenses.
To automate GL coding for corporate card transactions, connect each charge to its supporting evidence, choose an account from the company's chart, apply the relevant dimensions, and route uncertain cases for review. Keep the original card transaction linked to the resulting accounting entry so the same purchase is not recorded twice.
A merchant name is a useful clue. It rarely explains the whole purchase. A charge from a cloud provider could relate to customer delivery, internal development or an annual service paid in advance. The invoice, service period and business purpose determine which treatment is appropriate.
Start with a coding record the reviewer can explain
For each charge, retain the provider's transaction reference, amount and currency, purchase and settlement dates, cardholder where known, and supporting receipt or invoice. Preserve the original description even when a cleaner merchant name is available.
Then add the accounting proposal: account, entity, department or project, tax treatment where applicable, and the reason for those choices. The source record and the proposal serve different purposes. A reviewer should be able to change the proposal without losing what the provider originally reported.
| Field | What it helps establish |
|---|---|
| Provider reference and original description | Which movement is being processed |
| Receipt or invoice | What was purchased and from whom |
| Service period and business purpose | Which period and activity the purchase relates to |
| Entity and cardholder | Whose books and whose purchase are involved |
| Account and dimensions | How the cost is classified and reported |
| Existing bill or journal reference | Whether the purchase has already been recorded |
| Decision and supporting evidence | Why the coding was accepted or changed |
Missing evidence should remain visible. An empty project field is not a reason to invent a project, and a plausible merchant category is not proof of tax treatment.
Apply defaults within a defined scope
Recurring purchases are good candidates for defaults. A dedicated software card might carry a department default; a known subscription may have an established account mapping. Float's card automation documentation illustrates this approach with card-level GL, vendor and tax fields that can still be adjusted on individual transactions.
Write down where each default applies and when it should stop. A vendor-wide rule is too broad if different departments buy different services from that vendor. A cardholder's department can help with ownership while leaving the project unresolved.
Use AI to interpret descriptions and propose classifications within those boundaries. Give it the permitted accounts and the finance team's written policy. Ask it to identify missing evidence and explain uncertainty. A confidence score alone should not authorize a financial action.
A worked example: one purchase, two incoming records
Consider a synthetic EUR 120 software subscription for the current month. The company uses accrual accounting and a credit card liability account. Assume no tax or foreign exchange for this example, and that the finance team has confirmed immediate expense recognition.
The card feed arrives first. An accepted posting records:
| Entry | Debit | Credit |
|---|---|---|
| Software expense | EUR 120 | — |
| Credit card liability | — | EUR 120 |
A supplier invoice for the same purchase arrives later. Posting it as another expense without resolving the existing card entry would count EUR 240 of expense for a EUR 120 purchase.
Before processing the invoice, identify the original charge and its accounting result. Use the system's supported linking or settlement procedure. If the invoice has also been posted, an authorized correction must remove the duplicated expense effect while preserving both source documents and their history. The exact correction depends on what has already posted; a second payment or an unrelated balancing journal is not a substitute for that investigation.
When the company pays its card issuer, the simple example's liability is settled against cash. That payment does not create another software expense. Debit cards, refunds, fees, tax and foreign currency require their own treatment.
Give exceptions an owner and a reason
A useful review queue tells someone what decision is needed. It should distinguish an unknown account from a missing receipt, an ambiguous cardholder, and a purchase that appears already booked.
| Finding | Review action |
|---|---|
| Receipt covers several kinds of purchase | Review line-level coding and any required split |
| Annual subscription charged today | Review the service period and applicable prepaid-expense policy |
| Charge appears to settle an existing bill | Verify the link before creating another expense |
| Merchant or account is uncertain | Obtain evidence or select the account explicitly |
| Department is known, project is missing | Resolve the missing dimension without replacing supported values |
| Refund appears without a clear original purchase | Investigate the original transaction and its treatment |
These are review questions, not universal account assignments. Your accounting framework, company policy and evidence determine the answer.
How this applies in Arfiti
Arfiti keeps card sources and accounting results connected. Its built-in bank/card processor can classify transactions, and its current card path sends uncertain classifications for review rather than silently using a default expense account. It also distinguishes charges that appear already booked and cases requiring allocation outside an ordinary expense classification.
Receipt evidence, GL posting and settlement remain separate states. A receipt being accepted does not prove that the charge is posted or that an existing bill is settled. Supported operations remain subject to permissions, entity scope, integrity checks and applicable approvals.
The built-in processor is optional. A compatible external assistant can use supported tools under the same controls; the finance team's accounting policy must still be explicit. See corporate card management and reconciliation for the relevant workflows.
Measure the quality of the result
For an initial rollout, review a representative sample of recurring charges, mixed receipts, refunds and missing-document cases. Track how many proposed accounts were changed, which dimensions were incomplete, and whether duplicate purchases were caught before posting. Keep unresolved exceptions visible through close.
Expand automation where those results support it. A higher automatic-coding rate is useful only when the resulting books and evidence remain reliable.
Request access to discuss your card workflow and the evidence you need to review it. Access requests are enquiries; they do not create a workspace automatically.