What is GL coding?
GL coding is assigning the right general ledger account, VAT code and optionally cost centre or cost unit to a purchase invoice or to an individual invoice line, so the cost lands in the right place in the accounts.
Also known as: coding, GL account assignment, posting proposal
Recognition takes the data off the invoice. Coding decides what that data means for your administration. That is a different kind of work: the answer is not on the invoice, it is in your own chart of accounts and in the way your organization classifies costs. Two companies can post the same invoice completely differently and both be right.
That makes coding the place where automation wins the most time and can lose the most trust. A system that learns from what you posted before gets better every month. A system that always fills something in, even when unsure, means somebody checks every line anyway, and then you have gained nothing.
In Exact Online
Exact Online holds a separate chart of accounts, VAT codes, cost centres and cost units per administration, and they can be named differently per entity. Coding configured on one administration therefore does not automatically hold in another. Glimps pulls the scheme per administration from Exact Online and learns coding behaviour per supplier and per invoice line, so the proposals fit your accounts rather than a generic model.
Header coding and line coding
The simplest form puts the whole invoice on one account. That works for a phone bill and not for a wholesale invoice with forty lines across four cost types. Line coding takes more effort to get right, but it is the only way to get reliable figures per cost type and per cost centre.
Where the proposal should come from
There are three sources, and they should apply in this order. An explicit instruction from you always wins. Then what you posted before for this supplier and this line description. Only when both are missing is a language model up, interpreting the description. The other way round, with the model first, you get proposals that sound convincing and do not fit your scheme.
- A line you correct once should be right the next time.
- Below a confidence threshold the field should stay empty rather than filled with a guess.
- An instruction in plain language, the way you would explain it to a colleague, beats a rule list nobody maintains.
Where it usually goes wrong
- 1Hard-wiring coding per supplier. One supplier often delivers several kinds of cost.
- 2Always filling the proposal. A field that is always filled teaches your team to never trust it and check anyway.
- 3Not feeding corrections back. If a correction is not remembered, you do the same work again every month.
- 4Deriving the cost centre from history while it is on the document or in the instruction. That is guessing where reading would do.
Frequently asked questions
Common questions about GL coding.
Questions about your situation?
Open the demoRecognition reads what is on the invoice: amounts, dates, supplier, lines. Coding decides where that belongs in your administration: which GL account, which VAT code, which cost centre. Recognition is largely a solved problem, coding is not.
For a recurring supplier with a fixed cost type a handful of invoices is often enough. For a supplier delivering varied items it takes longer, because the system learns per line type rather than per supplier. History from your own postings in Exact Online speeds that up considerably.
Yes, and that is often faster than waiting for the system to learn it from history. The difference with classic rule engines is that you write it in plain language, the way you would explain it to a new colleague, instead of in a scheme of conditions.