GL codes: Definition, structure, and best practices for UK accounting

A card payment coded to the wrong account usually survives until month-end, when it costs a reclassification journal rather than a keystroke. Finance teams file each transaction under a general ledger, or GL, code. This process is known as general ledger coding. In the UK, GL codes are often called nominal codes, particularly in accounting software. HM Revenue & Customs and company law dictate the outputs that your accounting records must support, but they do not prescribe a specific numbering system. This article provides general guidance for UK finance teams, not tax advice. VAT treatment depends on your specific circumstances, so consult a qualified tax adviser before making decisions based on the rules covered here.

Key takeaways

• GL codes are internal; no UK statute prescribes the numbers.

• Your expense codes must aggregate into the statutory profit and loss headings used in your accounts.

• Upcoming lease and revenue changes may require accounts that your chart of accounts does not currently include.

• Your codes must support VAT outputs and either Self Assessment or corporation tax outputs, depending on your entity.

• Keep the chart of accounts short. Put departments, projects, and entities in cost centres or other dimensions.

• Many coding errors originate at the point of capture, so fix data entry before rebuilding the chart of accounts.

What is a GL code, and what is it for?

Sage and Xero classify transactions through a chart of accounts, but their numbering conventions differ. QuickBooks does the same while leaving account numbers off by default. Sage commonly uses four-digit nominal codes, while Xero defaults to three-digit codes. Accounting software uses account classifications to build trial balances and management accounts, while transaction-level VAT treatments feed into VAT returns. The Companies Act 2006 requires companies to keep records that are adequate to construct a trial balance. ICAEW's TECH 01/11 guidance describes those records as being kept “orderly and classified”, but does not attach any specific numbering scheme to them.

How should you structure GL codes for your business?

The most effective structure is the smallest one that can populate your required reports accurately.

Standard UK four-digit GL code framework

Sage 50 Accounts ships with a four-digit layout that is commonly used in the UK. Sage's report-range documentation groups codes so that the range determines where a balance appears in the financial statements.

A new code must sit inside its category’s range. Otherwise, it may not appear in the intended report section.

Other UK accounting packages use different conventions. Xero’s UK default chart of accounts uses three-digit codes, while QuickBooks Online leaves account numbers off by default. The format is therefore a convention, not a legal requirement.

Multi-segment GL structures for large organisations

Once you report by entity and department, one account number may no longer be enough. Projects can sit in a separate dimension. Dynamics 365 Finance concatenates segments into a single key consisting of a main account and up to ten dimensions. Business Central keeps the account short and attaches global dimensions to journal lines. Your implementation team must decide how much reporting information to embed in the account number itself. This decision can be difficult to reverse once transactions have been posted.

Two-tier mapping for operational and statutory GL codes

A bookkeeping code such as “Software subscriptions” is not a Companies Act line item, so a second layer is needed to translate operational codes into statutory reporting categories. Sage Final Accounts asks users to review nominal-to-statutory mappings before producing accounts. Keeping the statutory translation in a separate layer means that renaming a bookkeeping category does not automatically require a change to the accounts you file.

Examples of GL codes in practice

Most UK charts of accounts inherit their control accounts from the accounting software rather than being designed from scratch.

Common UK expense code examples

Sage 50 ships with default control accounts, and many UK charts begin with those codes unchanged. These include several of the accounts a finance team touches most frequently, including the suspense account.

Each posting also carries a VAT treatment. Sage users set this using T-codes.

Zero-rated and exempt supplies need separate treatment because input tax recovery differs.

Client and staff entertaining should also be separated. HMRC generally disallows the client side, and whoever prepares the corporation tax computation may otherwise need to unpick a blended account manually.

FRS 102 disclosure categories your codes must support

Your profit and loss codes must aggregate into the headings of the statutory format you use. Format 1, based on function, and Format 2, based on nature, are set out in Schedule 1 of SI 2008/410.

The main Format 1 headings your codes need to support include:

• Turnover

• Cost of sales

• Gross profit or loss

• Distribution costs

• Administrative expenses

• Other operating income

• Interest payable

• Profit or loss before taxation

• Tax on profit

• Profit or loss for the financial year

A function-based profit and loss statement still needs staff costs, depreciation, and raw materials analysed by nature. Those totals must therefore come from sub-codes or dimensions rather than being rebuilt manually at year-end. The Periodic Review 2024 amendments, effective for periods beginning on or after 1 January 2026, may require new accounts for:

• Right-of-use assets

• Lease liabilities, split between current and non-current

• Lease interest

• Contract assets

• Contract liabilities

Common GL coding mistakes and their causes

Most coding errors repeat every month until someone changes either the chart of accounts or the point at which data is captured.

Inconsistent coding across teams

Three teams may assign the same supplier to three different codes when they code card spend from memory. Budget-versus-actual reporting then shifts for a team whose spending has not changed. Supplier defaults and a shared code dictionary reduce this judgement and improve consistency.

Over-granular code structures

A chart of accounts that grows by one account for every new request eventually carries duplicate master data instead of supporting meaningful reporting.

Every unnecessary account creates:

• Another balance to reconcile

• Another line to map at close

• Another place where a coder can make the wrong selection

Lack of governance for new GL codes

If any user can create a nominal code, accounts labelled “Software” may appear alongside overlapping accounts such as “SaaS” and “Subscriptions”. Sage 200 does not allow users to change a code after it has been saved. Correcting a code created in haste may therefore require a replacement code and the deliberate retirement of the original.

Duplicate entries and misclassification

Exact-match checks based on supplier, invoice number, amount, and date can miss a duplicate invoice when a supplier resends it with a reformatted reference. For VAT, ICAEW's list of common mistakes includes recovering VAT on business entertainment and on-street parking. Both issues can result from selecting the wrong T-code.

Manual data entry and transposition errors

Every time someone re-keys information from a card statement or spreadsheet into the ledger, there is a chance of swapping digits or selecting a neighbouring code. Capturing the code against the transaction removes one re-keying point and reduces the opportunity for transposition errors. This is therefore a tooling problem as much as a training problem.

Spendesk is an all-in-one spend management platform that consolidates company cards, expense management, accounts payable, procurement, and budgeting. Finance teams using Spendesk can prepare coding fields against the transaction itself, helping to shorten expense reconciliation.

How to implement consistent general ledger coding governance

Finance leaders need to control:

• Code creation

• Naming conventions

• Mapping to statutory and tax outputs

• Code retirement

• Ownership of changes

UK standards do not prescribe how these choices should be made.

Start with your reporting questions, then build your structure

The questions that the board and budget owners will ask, together with the outputs required by HMRC, should form the design brief. If another field already supplies a segment’s value, that segment does not need to exist in the GL code. For example, department may already be supplied by the cardholder or a department field.

Use cost centres instead of multiplying accounts

Keep one “Travel” account and use cost centres to distinguish between sales and engineering. This is what the cost centre field is designed to do. Creating separate accounts such as “Travel - Sales” and “Travel - Engineering” makes the chart longer without necessarily improving the underlying reporting.

Structure and document your codes with clear naming conventions

A code name should allow a non-finance manager to make the right selection without asking finance for help.

For example:

Software subscriptions, including SaaS and per-seat licences, excluding implementation fees

A precise description helps prevent overlapping accounts such as “Software” and “Subscriptions” from being created.

Train your team on GL coding standards

Cardholders and approvers who apply codes rarely have formal accounting training. Training therefore works best when it is example-led and focused on the ten codes the team uses most frequently.

Retire and review codes regularly

Deactivating a code is safer than deleting it. An auditor tracing a retired code may still need access to its transaction history.

NetSuite and Sage 200 block deletion where transactions exist. Administrators can also configure Business Central to prevent deletion in similar circumstances.

VAT-registered businesses generally need to retain VAT records for at least six years. Companies generally need to retain corporation tax records until the sixth anniversary of the end of the relevant accounting period.

Confirm the period that applies to your entity against current HM Revenue & Customs guidance.

Align your GL codes with HMRC categories

Depending on your entity and obligations, your codes, or a mapping layer above them, must roll up into the appropriate reporting categories, including:

• The nine VAT return boxes for VAT-registered businesses

• The Self Assessment expense categories on form SA103F, boxes 17 to 30

• The applicable Making Tax Digital for Income Tax categories for qualifying sole traders and landlords

• Corporation tax adjustments for depreciation, capital expenditure, and entertaining for companies

Check the current form and categories for your entity before building the mapping.

Coding capital expenditure to repairs, or mixing client and staff entertaining, creates a tax adjustment that may surface only during the computation.

How to reduce GL coding errors at scale

As transaction volumes rise and more people outside finance apply codes, coding needs to move closer to the point of spend.

Rules should handle predictable transactions, while people review suggestions and exceptions. The key question for accounting automation software is whether it captures the code when the money moves.

Rule-based automation and machine learning

Deterministic rules can handle predictable activity. For example, a particular supplier may always post to the same overhead code.

A 2026 arXiv study found that a sentence-transformer model needed around 100 client-specific data points to reach an F1 score of 0.9. The authors also noted that performance on unseen clients “depends entirely on the overlap” with the training data.

Finance teams using Spendesk can set single- or multi-condition bookkeeping rules for predictable suppliers and review machine-learning GL code suggestions for other transactions.

According to Spendesk, heavy users may receive more than 1,000 correctly pre-filled accounting fields per month, with a reported 90% suggestion-acceptance rate.

Handling invoices without a purchase order

When the accounts payable team receives an invoice without a purchase order, it still needs to determine the correct account and budget before routing the invoice for approval.

Useful controls include:

• Supplier-level defaults for GL and VAT codes

• Approval routing by department or amount

• Review of any new supplier before its first invoice is posted

Where human review still matters

Confirming a suggested code only helps if the reviewer can realistically change it.

Human attention is most valuable when dealing with:

• New suppliers

• Low-confidence suggestions

• Non-standard VAT treatments

• Unusual or high-value transactions

• Transactions that fall outside established rules

Make correct coding the month-end norm

A short, governed chart of accounts will not prevent every miscoding. It does, however, make the right choice easier.

Capturing coding information at source also stops many errors from waiting until month-end, when they would otherwise require a reclassification journal.

The result is a close process built around reviewing exceptions rather than repairing routine transactions.

If manual coding is slowing the close, see how Spendesk combines bookkeeping rules with smart suggestions, allowing finance teams to review prepared fields instead of entering every code from scratch.

Frequently asked questions

These answers cover coding and reporting questions that complement the structures discussed above.

What is the difference between a GL code and a VAT code?

A GL code classifies what the transaction represents in the nominal ledger. A VAT code records the transaction’s VAT treatment. A single expense account can therefore contain transactions with different VAT treatments when the underlying supplies and circumstances differ.

Do small companies need the same coding detail as larger FRS 102 reporters?

Not necessarily. Small entities applying FRS 102 Section 1A use the same recognition and measurement principles but have reduced presentation and disclosure requirements. Their chart of accounts still needs enough detail to prepare the applicable accounts and disclosures. The appropriate level of detail depends on the entity’s transactions and reporting obligations.

Do you need a separate GL code for every supplier?

Usually not. The supplier record identifies who was paid, while the GL code records what was purchased. A separate nominal account is useful only when the supplier’s activity needs distinct management, statutory, or tax reporting.

How do GL codes connect to Making Tax Digital reporting?

Under Making Tax Digital for VAT, VAT-registered businesses must keep digital records for each supply made, including the rate of VAT charged, and for each supply received, including the input tax claimed. These requirements are set out in VAT Notice 700/22.

Manual re-entry or copy-and-paste may not qualify as a digital link when the relevant Making Tax Digital rules apply. Confirm the requirement against current HM Revenue & Customs guidance for your accounting setup.

For sole traders and landlords within scope, Making Tax Digital for Income Tax uses the same Self Assessment categories in quarterly updates. Whether and when it applies depends on qualifying income and the relevant mandation timetable, so confirm your position against current HM Revenue & Customs guidance.

What is a GL code dictionary?

A GL code dictionary is a document that lists every active code, including:

• What belongs in the code

• What does not belong in the code

• The default VAT treatment

• The code owner

• The approval process for changes

• The date and reason a code was added, changed, or retired

No standard defines the contents of a GL code dictionary. Teams that version the document can maintain a clear record of why a code was introduced or retired.