A GL coding error occurs when a transaction is posted to the wrong general ledger account, cost centre, department, or project code. The money moved correctly — it just landed in the wrong bucket. GL coding errors don't cause cash discrepancies, but they corrupt financial reporting, misstate departmental P&Ls, and create reconciliation breaks between subledgers and the GL.
Why GL coding errors matter
A single miscoded invoice doesn't move the needle. But at scale — hundreds of invoices per day across dozens of GL accounts — coding errors compound into material misstatements. Marketing's budget looks overspent because IT invoices were coded to their cost centre. COGS is understated because a freight invoice was coded to SG&A. The CFO's dashboard shows numbers that don't match reality.
Common causes
| Cause | How it happens | Detection method |
|---|---|---|
| Manual entry error | AP clerk selects wrong account from dropdown (adjacent account numbers) | Pattern analysis — transaction doesn't match historical coding for this vendor |
| Default account fallback | System uses a default GL code when the correct one isn't mapped | Concentration analysis — too many transactions hitting a catch-all account |
| Vendor master misconfiguration | Vendor's default GL account is wrong in the master data | All invoices from this vendor are miscoded consistently |
| Multi-entity confusion | Invoice coded to wrong subsidiary or cost centre | Intercompany reconciliation flags the imbalance |
| Chart of accounts change | GL restructure created new accounts but old mappings weren't updated | Spike in transactions hitting deprecated accounts |
| Split coding omission | Invoice should be split across departments but coded entirely to one | Amount exceeds typical single-department threshold for this vendor |
Impact on reconciliation
GL coding errors create reconciliation breaks in two ways:
- Subledger-to-GL mismatch — The AP subledger shows the invoice under the correct vendor, but the GL shows it in the wrong expense account. The control account reconciliation fails.
- Intercompany imbalance — An invoice coded to the wrong entity creates an imbalance that blocks elimination entries during consolidation.
Detection approaches
- Historical pattern matching — Compare each transaction's GL coding against the vendor's historical coding pattern. Flag deviations.
- Concentration analysis — Identify GL accounts receiving abnormally high transaction volumes (catch-all accounts).
- Cross-reference validation — Validate GL coding against PO coding, contract terms, or budget allocations.
- Peer comparison — Compare coding patterns across similar vendors or similar transaction types.
- Threshold alerts — Flag when a single transaction exceeds the typical amount for its coded GL account.
How AI agents detect and correct GL coding errors
The agent builds a coding model per vendor, per transaction type, and per amount range. When a new transaction arrives:
- Compare the assigned GL code against the expected code based on vendor history, PO coding, and transaction description
- If the code deviates: check whether the deviation is explained (new vendor category, new cost centre, restructure)
- If unexplained: flag as potential coding error with the suggested correct code and reasoning
- For confirmed errors: propose a reclassification journal entry with the correct coding
- Track error patterns to identify systemic issues (vendor master problems, training gaps)
Related
- Ledger reconciliation — where GL coding errors surface as subledger-to-GL breaks
- Timing differences — often confused with coding errors but have different root causes
- Invoice reconciliation — where coding errors are caught at the point of invoice processing