Finance Index
What is GL coding on an invoice, and who should be responsible for it?
Reference guide to invoice GL coding fundamentals, including invoice workflow, coding, approvals, ERP impact, and AP controls.
GL coding is assigning each invoice (or each line) to the right general ledger account - and usually the right department, location, or project - so the expense lands correctly in the books. Responsibility should be split by knowledge: the person closest to the purchase supplies business context, while accounting owns the chart of accounts and validates that codes are correct and consistent.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| GL coding on an invoice | GL coding is assigning each invoice (or each line) to the right general ledger account - and usually the right department, location, or project - so the expense lands correctly in the books. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Approval path | Neither alone. | Keeps accounting records aligned with the ERP. |
| Control point | Move validation upstream. | Keeps evidence clear and reduces control risk. |
| Best practice | Maintain vendor-level defaults for predictable spend, validate against the live chart of accounts at entry, require the fields that matter, document the judgment calls (what's supplies vs equipment, when to capitalize), and review reclasses monthly as a feedback loop. | Keeps vendor records and payment decisions reliable. |
| Card control | Start from your actual data: pull six months of coded invoices by vendor and document the dominant account per vendor plus the exceptions. | Keeps vendor records and payment decisions reliable. |
Should AP code invoices, or should the requester/approver who bought the item assign the GL account?
Neither alone. AP coding without business context produces plausible-but-wrong codes; requester coding without accounting knowledge produces creative ones. The healthy pattern is suggestion-plus-confirmation: a default or AI-suggested code based on vendor and history, confirmed by the approver who knows what was bought, validated against accounting rules before posting. The worst pattern is coding at month-end by whoever is reclassing - that means the process failed weeks earlier.
Coding errors keep surfacing at month-end and the controller reclasses dozens of entries - how do I reduce miscoding?
Move validation upstream. Reclasses are the symptom of coding decisions made without guardrails: free-text codes, stale account lists, no required fields, and coders guessing. Fixes, in order of leverage: validate codes against the live ERP chart of accounts at entry (not at export), make critical fields required, set vendor-level defaults for predictable spend, and route ambiguous invoices to the business owner instead of letting AP guess. Track reclasses by root cause monthly - the top three causes are usually fixable with rules.
What are best practices for coding invoices to the right GL account consistently across a team?
Maintain vendor-level defaults for predictable spend, validate against the live chart of accounts at entry, require the fields that matter, document the judgment calls (what's supplies vs equipment, when to capitalize), and review reclasses monthly as a feedback loop. Consistency comes from system guardrails, not memos.
How do I build a cheat sheet or rules so AP coders pick the right expense accounts?
Start from your actual data: pull six months of coded invoices by vendor and document the dominant account per vendor plus the exceptions. Encode the stable patterns as vendor defaults in your system and reserve the written cheat sheet for genuine judgment calls - rules belong in software, guidance belongs on paper.
How do I enforce that certain vendors always hit certain GL accounts?
Vendor-level default coding, applied automatically at capture and overridable with a reason. Hard enforcement (blocking any other account) suits single-purpose vendors like utilities; soft defaults suit vendors with varied spend. Review overrides periodically - frequent overrides mean the default is wrong.
What is the difference between coding an expense invoice and an inventory/cogs invoice?
Expense invoices hit P&L accounts in the period incurred; inventory invoices hit a balance-sheet inventory asset and reach the P&L as COGS only when goods sell. Inventory coding usually requires item-level detail and PO context, which is why inventory-heavy AP needs line-level capture and matching.
How should invoices be coded when the expense spans future periods - prepaids, subscriptions, annual licenses?
Code to a prepaid asset account and amortize over the service period rather than expensing twelve months into one. Set a materiality threshold (small annual charges can just be expensed) and use amortization scheduling at coding time where your tools support it, so the schedule is created when context is fresh.
How should AP handle invoices that need to be capitalized vs expensed?
Apply your capitalization policy at coding time: above the threshold and providing future benefit, code to a fixed-asset account and flag for the asset register; below it, expense. The frequent failure is capital invoices coded as expense by default - give coders a clear threshold and route borderline cases to the controller.
How does invoice coding work with my ERP chart of accounts - does the AP tool pull GL accounts live?
It should. Mature AP platforms sync the chart of accounts, dimensions, and validation rules from the ERP continuously, so coders pick from current values and invalid combinations are caught at entry. If your tool requires manually re-uploading account lists, every ERP change is a future export failure.
Stampli perspective
Stampli mirrors the ERP's chart of accounts, dimensions, field dependencies, and validation logic inside the invoice workflow, so coding happens against live ERP structure and invoices are validated before posting - not cleaned up after export. Stampli AI suggests coding from vendor history and your organization's actual patterns, while templates, defaults, and split-coding support handle the repeatable cases; humans confirm and stay in control of judgment. The result is coding correct at the source, with clean exports and fewer month-end reclasses.