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

A general ledger (GL) code is the identifier assigned to each account in your chart of accounts. It controls where every transaction lands in your GL, which means a well structured coding system helps your team code accurately and report consistently.

A good GL code process helps your team code transactions consistently, supports accurate category totals for tax and reporting, and makes your chart of accounts easier to manage as the business grows.

Overall, your GL code structure and the governance around it determine whether your chart of accounts stays accurate as your business grows.

To help you keep that structure accurate over time, this article covers what GL codes are, how to structure them, common coding mistakes to avoid, and how governance and automation help keep coding accurate. It also covers example UK code ranges, the reporting categories your codes need to support, and the controls that keep your chart usable over time.

What is a GL code? And what is it for?

The GL code (also called nominal code or account code) is the numerical or alphanumeric identifier for each account in your GL. The GL itself is the system that records all transactions posted to these coded accounts.

Every transaction your business records needs a destination, and the GL code provides it. When you post an entry, the code tells your accounting system which ledger account to file it under. For example, a code like 6200 might represent software expenses, while 2100 represents trade debtors. Every time your team records a software purchase or a customer payment, the GL code routes it to the right account. The Companies Act 2006 requires you to keep accounting records "sufficient to show and explain the company's transactions." Your GL codes are how you meet that obligation in practice.

Several related terms overlap in UK accounting. Your chart of accounts (COA) is the complete, organised list of every account your entity uses. A GL account is one specific account within that list, for example "Trade Debtors" or "Software Licences."

Neither Financial Reporting Standard (FRS) 102 nor International Financial Reporting Standards (IFRS) prescribe a numbering system. They tell you what your financial statements must show but leave the internal coding structure to you. Can your GL structure produce the financial statements FRS 102 requires? Can it generate management accounts broken out by department or submit accurate quarterly returns under Making Tax Digital (MTD)? Both depend on how you set up your codes.

How should you structure GL codes for your business?

The right format depends on how many entities you operate, how granularly you need to report, and whether your statutory and management reporting requirements diverge. According to the Financial Reporting Council, the broader FRS 102 amendments affect an estimated 3.4 million businesses in the UK and Republic of Ireland. Among those changes, the revised Section 20 requires new codes for right-of-use assets and lease liabilities from 1 January 2026.

Standard UK four-digit GL code framework

UK accounting software typically supports four- or five-digit formats. Most mid-market businesses use a sequential four-digit structure, with each range covering a major account category:

This framework gives you a logical skeleton. The sections below cover how to extend it for multi-entity, multi-department reporting without losing control of the code list.

Multi-segment GL structures for large organisations

A single four-digit code stops being enough once you operate across multiple departments, projects, or legal entities. A segmented structure solves this by combining dimensions into one string.

Take 01-100-2025-6050: Company 01, Marketing Department, 2025 Campaign, Advertising expense. This lets you track budgets at cost centre level without the code list spiralling out of control. But even thirty account codes across four cost centres already produce 120 nominal codes, so consistent segment rules matter from the start.

Two-tier mapping for operational and statutory GL codes

Modern UK accounting software often uses a two-tier approach. You keep an operational chart with detailed GL codes for internal reporting (often 200 or more accounts) and map those automatically to a statutory chart aligned to FRS 102 disclosure requirements (typically around 50 summary accounts). Your operational chart might have five separate marketing expense codes that all roll up into a single "Administrative expenses" line for statutory filing.

Examples of GL codes in practice

The codes below show how mid-market UK businesses typically number their expense accounts and map them to FRS 102 disclosure requirements.

Common UK expense code examples

Common UK accounting software uses codes in the 6000 to 9000 range for expenses. A typical mid-market chart might include:

• 6150: Travel and subsistence expenses

• 6170: Consultancy fees

• 6200: Computer software

• 6250: Advertising and marketing

• 6260: Printing, postage, and stationery

• 6270: Subscriptions and memberships

Exact numbering varies by software package. Some UK platforms use the 7000s and 8000s for payroll, depreciation, and corporation tax rather than grouping all expenses in the 6000 range.

FRS 102 disclosure categories your codes must support

Your general ledger needs enough account detail to populate the line items FRS 102 requires, including proper classification of tangible fixed assets, receivables, and payables by maturity.

Creditors need splitting between those due within one year and those due after more than one year, with trade creditors separate from other payables. Your profit and loss (P&L) structure will typically run turnover, cost of sales, administrative expenses, and distribution costs. Equity needs distinct components: share capital, share premium, revaluation reserve, and retained earnings. If your GL structure can't produce these divisions, your statutory accounts won't come together cleanly.

Common GL coding mistakes and their causes

GL coding problems are almost always process gaps, and they compound quietly until month-end or an audit forces them into the open.

Inconsistent coding across teams

Without a documented GL dictionary, your team will make different judgement calls about where to post the same type of cost. One person codes a SaaS subscription to Software Licences; someone else puts it under Office Expenses. After a quarter, that category is meaningless in your reports.

You’ll be able to see the impact at reporting time, but fixing the issues is a manual task no accountant looks forward to. Every line on your balance sheet and P&L statement aggregates GL-coded transactions, so posting the same expense type to different accounts means your P&L no longer shows where money actually goes. At month-end, that forces you to investigate discrepancies line by line rather than reconciling at the account level.

Over-granular code structures

Creating a separate GL code for every conceivable sub-category feels thorough at the time. But in practice, it makes the chart unwieldy and the coding inconsistent. A flat chart of 200 near-duplicates is harder to use correctly than 50 well-defined accounts.

Lack of governance for new GL codes

Without a formal approval process, codes proliferate. Within a year, you can accumulate dozens of overlapping codes that nobody fully understands, and nobody wants to clean up. Far from an ideal situation, especially if you’re looking to standardise processes and become more efficient.

Duplicate entries and misclassification

When two people process the same invoice, or when a transaction is entered and then forgotten, you get duplicates that inflate your expense totals and distort your reconciliation. Misclassification is equally common: coding an accounts payable entry as receivable, or posting a capital expense as operating, creates errors that compound across reporting periods.

Manual data entry and transposition errors

A four-digit GL code is easy to mistype, especially during rapid month-end processing. Manual keying also means hours spent cleaning and reshaping exported general ledger data in Excel before it's usable for expense reconciliation.

How to implement consistent GL coding governance

Most coding drift happens often because no single person owns the chart of accounts, and no documented standard tells the team how to use it. The fixes below cover how to design, document, train on, and maintain your coding standard.

Start with your reporting questions, then build your structure

Work backwards from the reports and decisions you actually need. What is your travel spend by department? Which projects are running over budget? Build your GL structure to answer those questions directly.

Use cost centres instead of multiplying accounts

If you need to track the same expense type across departments, use a cost centre dimension rather than separate GL codes for each one.

Let's say a sales team member books a £320 train fare to a client site. And a marketing colleague spends £185 on travel to a conference. Rather than creating 6100-Sales-Travel and 6100-Marketing-Travel, use a single 6100 Travel and Subsistence code with a cost centre that distinguishes the department. Both transactions land in the same GL account, but you can still report spend by team.

Structure and document your codes with clear naming conventions

Your chart of accounts needs both a logical numbering scheme and a written reference that explains it. Leave gaps in your numbering (6100, 6200, 6300 rather than 6001, 6002, 6003) so you can insert new accounts logically without restructuring the whole chart.

Your finance controller or head of finance should own the chart of accounts and approve every new code with written justification. Maintain a GL code dictionary as a living document recording every active code, its name, purpose, what it includes and excludes, and its FRS 102 mapping. Consistent naming conventions matter: if your team can't look up the right code in under a minute, the dictionary isn't doing its job.

The consequences of getting this wrong go beyond bad reports. Auditors now analyse full populations of general ledger data, which means coding errors are easier for them to spot. Under FRS 102 Section 10, material GL coding errors require restatement of prior period comparatives and mandatory disclosure.

Train your team on GL coding standards

A GL dictionary is only useful if your team knows it exists and uses it. When new finance staff join, walk them through the chart of accounts, the naming conventions, and the most common coding judgement calls (where does a SaaS subscription go? how do you distinguish capital from operating spend?). Periodic refresher sessions reduce drift, especially after structural changes to the chart.

Retire and review codes regularly

When a code becomes obsolete, mark it as inactive rather than deleting it to preserve historical reporting continuity. Review your chart regularly for duplicates, underused codes, and unnecessary expansion.

Align your GL codes with HMRC categories

Map your GL codes to HMRC categories so that digital submissions generate automatically from your accounting software. Making Tax Digital for VAT creates a direct link between your coding and your VAT returns. Since April 2022, all VAT-registered businesses must keep digital records and submit VAT returns through MTD-compatible software. If your GL codes map cleanly to HMRC's VAT categories, quarterly submissions take care of themselves. If they don't, a single miscoded invoice can distort your return.

How to reduce GL coding errors at scale

Governance sets the rules; automation enforces them at scale. The volume of transactions flowing through a mid-market accounts payable function makes purely manual coding unsustainable, and rule-based logic, machine learning, and optical character recognition (OCR) each address a different type of error.

Rule-based automation and machine learning

Rule-based automation helps: define a rule (vendor X plus amount range Y equals GL code Z) and the system applies it consistently every time. Machine learning adds a second layer by predicting codes based on historical patterns. OCR pulls invoice data at the point of entry, which eliminates the manual keying that causes transposition errors in the first place.

Handling invoices without a purchase order

Non-PO-backed invoices are a good example of where automation helps. These are ad hoc costs, such as consultancy fees, one-off services, or emergency purchases, that arrive without a purchase order to match against. Without that PO reference, there is no structured matching point to support coding, so the invoice is more likely to default to manual review and inconsistent judgement. In practice, that is where automation proves its value: OCR captures the invoice data at entry, rules apply coding logic consistently, and historical patterns provide a starting point for the first coding decision before human review.

Where human review still matters

Automation doesn't remove the need for human review entirely. First-time vendors, multi-line invoices spanning different expense categories, and capital-versus-operating-expense judgements still require someone who knows the business. The practical approach is to auto-apply high-confidence matches and route everything else to manual review.

Miscategorised subscriptions, duplicate invoices, and ad hoc codes are the errors that can compound quietly. They're also the ones that surface under pressure at month-end or in an audit letter, creating more work and stress for your team. Structure, governance, and automation - all finance team favourites - stop that compounding before it starts.

This isn't a one-time setup, however. It is important to review your chart quarterly, enforce the dictionary, and automate what you can to remove as many opportunities for manual error as possible. The teams that treat GL coding as ongoing discipline close on time and file accurately without the stress.

For more details, our guide to accounting automation software covers how finance teams are putting these controls into practice.

Frequently asked questions about GL codes

What is a GL code?

A GL code is a numerical or alphanumeric identifier assigned to an account in your chart of accounts. You use it to route transactions to the right ledger account for reporting and compliance.

Are there standard GL codes every business must use?

FRS 102 doesn't mandate specific GL code numbers, and neither does IFRS. You still need enough account detail to support statutory line items, tax reporting, and the management information your business relies on.

What is the difference between a GL code and a cost centre?

A GL code tells you what type of transaction you're recording, such as travel or software. A cost centre tells you who spent the money, or which department it belongs to. Using both together lets you analyse spend without creating duplicate accounts.

How do GL codes connect to MTD reporting?

Your GL codes should map to HMRC categories so your accounting software generates quarterly submissions automatically. Incorrectly coded transactions feed directly into your MTD return, so consistency matters for tax compliance.

What is a GL code dictionary?

A GL code dictionary is a reference document that your finance team consults when deciding where to post a transaction. It lists every active code alongside its name, purpose, inclusion and exclusion criteria, and statutory mapping. Without one, coding judgement calls default to individual discretion, and consistency erodes.