An invoice arrives from a supplier you have worked with for three years. The automation reads it, recognizes the supplier, and assigns the same expense account it assigned last month. The code is right. The invoice is a duplicate.
GL coding is the step that assigns each line of a financial document to a general ledger account, so the transaction can become a journal entry in your books. Automating it is now standard practice: most accounts payable tools predict the account from your own coding history.
What almost none of them do is check the line before coding it. This article covers how GL coding automation works today, where prediction from history breaks down, and what a finance team should control before an entry reaches the ledger.
Key takeaways
- GL coding assigns each invoice line to a general ledger account, and that assignment is what turns a supplier document into a journal entry.
- Most GL coding automation predicts the account from past coding on the same supplier, so it repeats previous decisions rather than testing current ones.
- A correctly coded invoice can still be a duplicate, a price above contract, or a delivery that never arrived, and the resulting entry will be clean and wrong.
- Controlled coding checks the line first (price, quantity, duplicate, tax treatment) and assigns the account second, which catches errors before payment rather than at month end.
- At Astotel, an 18-hotel group, line-level price control on a single supplier surfaced close to 5,000€ a year in billing errors that coding accuracy alone would never have flagged.
What GL coding is, and where it sits in the invoice chain
GL coding is the process of assigning a general ledger account, and usually several additional segments, to each line of a financial document so the transaction lands in the right place in the accounts. A GL code is the alphanumeric identifier that represents that account. Coding an invoice means deciding which accounts the transaction hits, and in what proportion.
Every general ledger organizes accounts into five families: assets, liabilities, equity, revenue, and expenses. A supplier invoice for cleaning products typically credits the supplier account (a liability) and debits a consumables expense account. The same purchase can land elsewhere: goods bought for resale hit inventory, an asset, until they are sold. The GL code is how the system knows which one.
Coding is one step in a chain, and it is easy to confuse it with the steps around it. The accounting inbox receives and sorts the document. Extraction reads the fields off the page. Validation checks that what was read matches what is on the document. Coding decides which accounts the transaction hits. Posting writes the entry to the ledger.
The anatomy of a coded invoice line
A GL code is rarely a single number. In most mid-sized organisations it is a string of segments, each answering a different question about the transaction. The natural account is the accounting question. The others are management questions.
| Segment | The question it answers | Who usually decides |
|---|---|---|
| Natural account | What is this in accounting terms: an expense, an asset, a liability? | Accounting |
| Entity | Which legal entity in the group carries the cost? | Accounting, from the document |
| Cost center or department | Which team or site consumed it? | The requester or approver |
| Project or analytical code | Which job, site, or contract does it belong to? | Operations |
| Tax code | How is the tax on this line treated and recovered? | Accounting, from the supplier status |
The distinction matters operationally: the segments are not decided by the same people and do not fail the same way. A wrong natural account distorts the financial statements. A wrong cost center distorts management reporting and the budget review but leaves the accounts correct.
GL coding is not cost center coding
These two decisions get bundled together under the word coding, and they should not be. Assigning the natural account is an accounting judgment: is this a repair or a capital improvement, an expense or a prepaid asset. Assigning the cost center is an allocation judgment: which site, which team, which project carries the cost.
The controls that catch a wrong natural account are not the controls that catch a wrong cost center. If your issue is analytical allocation rather than account selection, the specific checks for that dimension are covered in our guide to cost center invoice validation. This article stays on the natural account and the entry it produces.
Why manual GL coding breaks between 50 and 500 employees
Manual coding does not fail because accountants are careless. It fails because manual data entry scales with the business and the finance team does not. A company running 8 sites and 120 suppliers can process a few hundred invoice lines a month by hand. The same company at 20 sites and 300 suppliers is processing thousands, with the same one to three people in finance.
What breaks first is not speed, it is consistency. Two people code the same supplier differently. The same person codes it differently in March and in September. Neither error is visible on the invoice: it only surfaces when someone reviews a cost line that moved for no operational reason.
The three coding errors that survive to the trial balance
- Wrong account. The line goes to a plausible neighbouring account. Nothing fails, nothing balances incorrectly, and the expense category is quietly wrong for the year.
- Wrong period. The invoice is coded correctly but posted to the month it was received rather than the month the service was delivered, which distorts both months.
- Wrong entity. In a group structure, the cost lands on the entity that received the document rather than the entity that consumed the goods, which creates an intercompany correction later.
All three produce a balanced ledger. That is precisely why they survive: nothing in the posting mechanism objects, and the correction happens at month end, during reclassification or account reconciliation, and it lands on the person with the least time available.
How GL coding automation works today
Four approaches coexist on the market, and they differ less in accuracy than in what they do when something is wrong. The table below compares them on the criteria that actually separate them in production.
| Criterion | Manual coding | Rules and templates | Prediction from history | Controlled coding with AI agents |
|---|---|---|---|---|
| How the account is chosen | Human judgment, invoice by invoice | Fixed rule per supplier or category | Learned from previous coding on the same key fields | Learned from your rules and chart of accounts, after the line is checked |
| New supplier, no history | Coded manually | No rule exists, falls back to manual | Low confidence, falls back to manual | Proposed with a confidence score and routed for validation |
| Invoice is a duplicate or overbilled | Caught only if someone notices | Not detected, the rule still applies | Not detected, coded like every previous one | Flagged before coding, against contract, delivery, and prior invoices |
| Traceability of the decision | None beyond the ERP audit log | The rule, not the reasoning | Partial, the key values used | Every output linked to its source line, page of the PDF or ERP row |
| Who handles exceptions | Everything is an exception | Whoever spots the gap | Whoever the queue defaults to | Routed to a named person with the document and the matched data |
| What improves over time | Individual habits, not shared | Only what someone reconfigures | Prediction accuracy on repeat spend | Both the coding logic and the controls, from each correction |
What prediction from history actually does
The dominant approach in accounts payable software is prediction from coding history. The system identifies one or more key fields (most often the supplier, labeled the vendor in most US systems, sometimes supplier plus entity plus department) and proposes the account combination used the last time those key values appeared. Modern versions add a confidence score and handle split allocations and percentage distributions.
It works well on stable, repetitive spend. A supplier coded to the same account forty times will be coded correctly the forty-first. The limitation is structural, not technical: the model is trained on what you did, never on what you should have refused.
The flaw nobody names: a perfect code on an invoice you should not have received
Coding accuracy measures whether the account matches the invoice. It says nothing about whether the invoice is correct. Two different questions, and only one of them is being automated.
Four situations produce an impeccably coded entry on a document that should never have been posted:
- The duplicate. The same invoice arrives twice, through two channels, with a different reference. Prediction from history codes both identically, because both look exactly like every previous invoice from that supplier.
- The price above contract. The line is billed at a rate higher than the negotiated price. The account is right, the amount is not, and nothing in the coding step compares the line to the agreed rate.
- The undelivered quantity. The invoice bills 40 units, the delivery note shows 32. Coding never opens the delivery note.
- The wrong tax treatment. The tax code carried on the line does not match the nature of the purchase or the supplier status, which distorts the tax return rather than the profit and loss.
None of these is exotic. They are the ordinary failure modes of supplier billing, and they are the reason three-way matching exists. What is unusual is that the coding step and the control step are almost always separate, sequential, and owned by different tools, so a line can be coded long before anyone has checked it.
At Astotel, an 18-hotel group in Paris, supplier price checks used to be done on a sample. A Phacet agent comparing every invoice line against negotiated prices surfaced close to 5,000€ a year in billing errors on a single supplier. As Valérie, the group's purchasing director, puts it:
"I save up to two days a month, and I spot errors I would never have seen on my own."
Those errors were on invoices that had been coded without incident for years. That is the whole point: line-level billing control is not a refinement of coding accuracy, it is a different check entirely.
From a controlled line to a journal entry
Once the line has been checked, producing the entry is the easy part. A journal entry from a supplier invoice credits the supplier account, debits one or more expense or asset accounts, carries a tax line, balances, and belongs to a period. What separates a usable entry from a fragile one is not the arithmetic, it is whether every element can be traced back to the document it came from.
This is the layer where Phacet sits. The standardize and reclassify agent assigns categories and analytical codes based on your own rules and your own chart of accounts, not a generic taxonomy.
Every output traces back to the exact source line: the page of the PDF, the row in the ERP, the bank transaction. Confidence scores, decision logs and a native audit trail are built in rather than bolted on, which is what makes an entry defensible to an auditor months later.
Phacet sits above your existing systems rather than replacing them. It does not become your general ledger. The controlled, coded lines are prepared for your accounting system and returned to it, so the ledger stays where it is and the control layer runs in front of it.
The effect on a finance team is measured in reclaimed hours. At La Nouvelle Garde, a group of ten Paris brasseries, automating the document to entry chain eliminated 70% of the time previously spent moving between the mailbox and the accounting tool, and returned two days a week to the finance team. A part-time CFO working across a client portfolio describes the same shift on categorization:
"For every new client, we used to spend hours manually categorizing 200+ suppliers. With Phacet, it's now 10x faster and we've harmonized category logic across the board."
What a human still decides
Automating coding does not mean removing judgment, it means concentrating it. Ambiguous lines are routed to the right person with the full context attached: the original document, the matched data, the confidence score. The person validates, corrects, or rejects inside the approval workflow, every decision is logged, and each correction feeds back into how the agent handles the next similar case.
In practice the finance team stops touching the 80% of lines that are unambiguous and spends its attention on the exceptions, which is where the money and the risk actually sit.
What to check before you automate GL coding
Automation inherits the quality of what it is pointed at. Six things are worth auditing first:
- Chart of accounts hygiene. Duplicate accounts, accounts nobody uses, and accounts with overlapping definitions will produce inconsistent predictions no matter how good the model is.
- Supplier master data. The same supplier registered three times under three spellings breaks any logic based on supplier history. A clean supplier database is a prerequisite, not a nice to have.
- Line level or header level. Decide whether you code the invoice or each line of it. Header-level coding is faster and hides mixed-nature invoices, which are common in food service and construction.
- Multi-entity rules. If several entities share suppliers, define which entity a document belongs to before automating, not after.
- Mapping tables. Analytical mapping tables drift silently as sites and cost centers are added. A completeness check on the mapping table catches the gaps before they become coding errors.
- Exception ownership. Name the person who handles routed exceptions before go-live. An exception queue nobody owns is just a slower manual process.
Control first, code second
The market has worked hard to make GL coding faster and more accurate, and that work was worth doing. But accuracy answers the wrong question when the document itself is wrong. An entry is only as good as the invoice it came from, and no coding model can tell you the invoice should never have been paid.
The practical move is to reverse the order: check the line against the contract, the delivery, the tax rules and the duplicates, then assign the account. Your team keeps the judgment calls and stops doing the repetitive ones. Start with a single supplier category where you already suspect leakage, measure what surfaces, and expand from there. More on this layer in the general accounting agent library and the accounts payable library.
Frequently asked questions
What is GL coding in accounts payable and how is it used?
In accounts payable, GL coding assigns each supplier invoice line to a general ledger account so the cost lands in the right expense category. It is used to produce the journal entry, to route the invoice to the correct approver, and to make spend reportable by account, department, and entity.
Can you provide an example of a GL code?
A common convention numbers accounts by family: 1000 for assets, 2000 for liabilities, 3000 for equity, 4000 for revenue, 5000 for expenses. A cleaning supplies invoice might be coded 5210 for consumables, extended with segments such as 5210-300-12 where 300 is the site and 12 the department.
Are GL codes universal?
No. Chart of accounts structures are specific to each organisation, and numbering conventions vary by country, accounting framework, and ERP. Some jurisdictions impose a standardized chart, such as the French plan comptable général. Elsewhere, companies design their own, which is why coding logic rarely transfers between two businesses.
What are the 5 types of general ledger accounts?
The five families are assets, liabilities, equity, revenue, and expenses. Assets and expenses increase with a debit. Liabilities, equity, and revenue increase with a credit. Every journal entry touches at least two of these families and balances, which is the mechanism that makes double-entry bookkeeping self-checking.
Is AI replacing bookkeeping?
No. AI is absorbing the repetitive parts of bookkeeping, such as reading documents, proposing accounts, and flagging anomalies, while judgment calls stay with the accountant. In production, Phacet agents route ambiguous lines to a named person with the source document and a confidence score attached, and log every decision for audit.
