GL Coding in Accounts Payable: How It Works and How to Automate It

GL coding in accounts payable is the assignment of general ledger codes to each line of a supplier invoice, so the expense posts to the correct account, department and period. It happens between capture and posting, and it decides whether month-end close is a reconciliation or an investigation.

Key takeaways

• The AP subledger holds invoice-level detail; the general ledger holds the summarised total in a control account.
• Code at line level. One invoice often spans several accounts and more than one cost centre.
• PO-backed invoices inherit a code approved before the money was committed. Non-PO invoices have no anchor, which is why they cause most errors.
• Three-way matching enforces the code agreed at ordering rather than one inferred later.
• The subledger and the control account must agree before close.

What is GL coding in accounts payable?

GL coding in accounts payable is the step where each line of a supplier invoice is assigned a GL code, setting which account the expense hits, which department carries the cost, and which period it lands in.

For an AP team this is a throughput problem rather than an accounting one. Every invoice arriving without a clear code becomes a question, and every question becomes a delay. The invoices that flow through untouched are the ones coded before they arrived.

How the AP subledger connects to the general ledger

Most AP process problems trace back to this relationship.

What the AP ledger records

The accounts payable subledger holds one record per supplier invoice: who invoiced you, for what, when it is due, what has been paid, what remains outstanding. It carries the line items, PO references, approval history and the coding applied to each line. It answers supplier-level questions: what do we owe, what is overdue, what did we pay last quarter.

How AP posts to the GL control account

The general ledger holds no such detail. It holds a single control account for accounts payable, usually in the 2000 range, carrying the total owed to all suppliers — the same structure the federal chart of accounts uses for the same reason.

Posting an invoice does two things at once: the expense lines debit the accounts their codes point to, and the total credits the control account. Expense goes wherever the coding says; liability goes to one place. Written out as a debit and credit as T-accounts, it is one credit against many debits, which is exactly why the subledger has to carry the detail the control account cannot.

Reconciling the AP subledger to the general ledger

At period end, the sum of open invoices in the subledger must equal the balance on the control account. When they agree, the subledger is proven and close proceeds.

When they do not, something has broken the link: an invoice posted directly to the GL bypassing AP, a manual journal against the control account, a payment applied in one system only, or a timing difference across the cut-off. Reconciling monthly rather than quarterly means a smaller haystack.

The AP invoice GL coding process, step by step

Five steps between an invoice arriving and the books closing.

Step 1: Invoice capture and data extraction

The invoice arrives by email, portal or post, and header and line data are extracted: supplier, invoice number, date, PO reference, descriptions, amounts, tax. Capture quality decides everything downstream, because a line that extracts badly cannot be coded automatically and lands in someone’s queue. This is the step invoice automation is usually bought for, though as the automation section below argues, it is not the step where the time actually goes.

Step 2: PO matching and line-level allocation

If the invoice references a purchase order, the system matches invoice lines to PO lines. A major part of the coding process happens at this stage because the PO line already carries the code agreed when the order was approved, and the invoice line inherits it. Where quantities or amounts differ, the line flags as an exception rather than passing through. The strength of this step depends entirely on how much discipline sits in the purchase order process upstream of it.

Step 3: GL code assignment and cost allocation

Lines that did not inherit a code need one. Rules handle the predictable cases: this supplier and this category always post to this account. What remains is genuinely ambiguous and needs a person. This is also where a line gets split if the cost belongs to more than one department.

Step 4: Approval routing and exception handling

Coded invoices route to whoever owns the budget the coding points at, which is the reason for coding before routing. Exceptions — a price variance, a quantity mismatch, a missing PO, a low-confidence code — route separately, because they need a decision rather than an approval.

Step 5: Posting to the general ledger

The approved invoice posts: expenses debited to their coded accounts, total credited to the control account, tax to its own. The posting date sets the period, which matters most at cut-off. Once posted, changing the coding means a reclassification journal rather than an edit.

GL coding examples in accounts payable

A coded invoice, line by line

One invoice, four lines, four accounts.

Line 1 is the one that matters. Coded to 5610 with the accessories it would be expensed in full this month; coded to 1510 it capitalises and depreciates. Same invoice, materially different profit for the period.

Split coding across two cost centers

A security services contract of £12,000 covers a site shared by two teams, and neither owns it outright. Split by headcount, 55% engineering and 45% operations:

• 5540-300-01 — engineering — 6,600
• 5540-400-01 — operations — 5,400

The split needs a stated basis that survives being questioned six months later. Headcount, floor area and usage are all defensible. A 50/50 split chosen because it was quick is not, and that is what happens when nobody records why. Write the basis into the invoice record, not into somebody’s memory.

Where AP GL coding breaks down

Non-PO and maverick invoices

An invoice with no purchase order has no pre-agreed code, so someone in AP works out what it was for from the supplier’s description. Often they cannot, so they ask, and the invoice waits. Non-PO invoices are a small share of volume and a large share of AP’s time.

Split coding across departments and cost centers

Splits break for a different reason than they get created. The allocation is agreed once, then repeats monthly for two years while the basis changes: teams move floors, headcount shifts, the project ends. Nobody revisits it because the invoice keeps posting cleanly. The coding is wrong and nothing flags it.

Duplicate and miscoded invoices

Duplicates arrive when a supplier resends an unpaid invoice with a new number, or the same document reaches AP by two routes. Miscodes are quieter: a wrong code is usually a valid code, so the transaction posts without error to the wrong account. Both surface late, once the context needed to unpick them has gone.

Period-end cut-off errors

An invoice for work done in one month, posted in the next, lands the expense in the wrong period. The coding is right and the timing is wrong, which is harder to spot than a wrong account. It distorts both months, and it is why a departmental budget looks fine one period and overspent the next. Under an accrual method, which period an expense belongs to is set by when the liability was incurred rather than when the paperwork was processed — a distinction that only shows up at cut-off.

How three-way matching improves GL coding accuracy

Three-way matching compares the purchase order, the goods received note and the invoice before anything posts. It is usually justified on fraud and overbilling. Its underrated benefit is coding.

The reason is sequencing. In a matched process the code is set on the purchase order, when someone who knew what they were buying asked for approval, and the approver reviewed the code as part of approving the spend. By the time the invoice arrives, two people with context have agreed it. The invoice inherits it and nobody in AP decides anything.

Compare that with an unmatched invoice, where the code is inferred weeks later by someone who was not involved, reading a description the supplier wrote for their own purposes.

The match also catches errors coding alone cannot. A quantity mismatch means the receipt does not support the invoice, so an otherwise correctly coded line overstates the expense. A price variance does the same. Both flag before posting rather than after close, which makes matching a preventive control rather than a detective one — the distinction the GAO’s internal control standards build on, and the reason a matched process survives a procurement audit with a narrower sample.

One limitation worth stating: matching enforces consistency, not correctness. A PO coded to the wrong account at requisition will match cleanly and post confidently to the wrong place. The match proves the invoice agrees with the order. It does not check whether the order was right.

Automating AP GL coding

OCR capture and AI-suggested codes

Capture extracts the data; prediction proposes a code per line based on how similar lines were coded before. The useful part of AI-suggested codes is the confidence score. High-confidence lines post without review, low-confidence lines queue for a person. Without that split, automated coding moves the review work rather than reducing it.

Vendor and category coding rules

Rules cover the traffic you can specify in advance: this supplier always posts to this account, this category always carries this cost centre. They are transparent, easy to audit, and cover a large share of volume for little effort. They also only cover what someone thought to write down, which is why they work best alongside prediction rather than instead of it.

Touchless posting to your ERP

The end state is an invoice that arrives, matches, codes, approves within policy and posts without anyone opening it. What makes it possible is a live connection to your ERP and its chart of accounts, so the codes applied still exist. A stale copy produces confident postings to retired accounts, which is worse than no automation at all. For what to measure once the flow is running, see the guide to accounts payable automation.

Frequently asked questions about AP GL coding

What is the difference between the AP ledger and the general ledger?

The AP ledger is a subledger holding one detailed record per supplier invoice. The general ledger holds the summarised total in a single control account. One tells you what you owe each supplier; the other, what you owe in total.

Is accounts payable a GL account?

Yes. It is a liability account in the general ledger, and it functions as the control account for the AP subledger. The two must reconcile at period end.

What GL code is used for accounts payable?

It varies by chart, but AP typically sits in the 2000 range, which conventionally holds liabilities. There is no universal number. In the standard GL code list, trade accounts payable is 2000 and accrued accounts payable is 2010.

How do you reconcile accounts payable to the general ledger?

Compare open invoices in the subledger to the control account balance, then investigate any difference: postings that bypassed AP, manual journals, payments applied in one system only, or cut-off timing.

Can GL coding be automated for non-PO invoices?

Partly. Rules based on supplier and category handle recurring non-PO spend well. One-off invoices from unfamiliar suppliers have no history to predict from. The bigger win is reducing how many arrive without a PO at all.

Who assigns GL codes to invoices in accounts payable?

In a PO-driven process the code is set at requisition and inherited by the invoice. Without a PO, an AP clerk assigns it at entry, usually after asking the budget holder what the purchase was for.

Close the books faster with automated AP coding

Most AP coding problems are questions arriving too late — someone in finance asking a department what a purchase was for, weeks after both had moved on.

Zapro connects the requisition, the purchase order and the invoice, so the code an approver agreed at ordering is the one that posts. Book a demo and we will walk through it end to end.

Book a free demo →