General ledger structure: accounts and dimensions you will not regret

A good general ledger structure keeps the chart of accounts close to a standard such as SKR04 and puts the business view into dimensions: cost centre, project, product, customer and entity are attributes of each booking, not separate accounts. The accounts answer what kind of income or cost it is. The dimensions answer where, for whom and for which purpose. That split keeps the books readable for your tax advisor and the reports useful for management.

Many growing German companies do the opposite. Every new question from management becomes a new sub-account, and after a few years the ledger has hundreds of accounts that nobody fully understands. This guide explains how to design the structure once, so it still works at five times the size.

---

What does the general ledger have to do in a German company?

The general ledger (Hauptbuch) is the record of every booking, organised by account. Under § 238 of the German Commercial Code (HGB), every merchant must keep books that show the business transactions and the financial position according to proper bookkeeping principles. The ledger is where that happens.

In practice, your ledger serves three audiences at once:

• The tax advisor (Steuerberater) and the tax office, who need a clean, standard structure for the VAT return, the annual accounts and the E-Bilanz (the electronic submission of the balance sheet and income statement to the tax office under § 5b EStG).
• Management, who need margin, cost and budget figures by team, product or project.
• Auditors, banks and investors, who need consistency over time.

A structure that serves only one audience fails the others. A ledger built purely for tax is useless for steering. A ledger built purely for management questions becomes a problem every time it has to be mapped back for tax.

Which chart of accounts should you start from?

Most German companies start from one of the two DATEV standard charts. SKR03 is organised along business processes. SKR04 follows the structure of the financial statements, so the account order mirrors the balance sheet and income statement. That makes SKR04 a natural fit for companies that produce annual accounts under HGB, and it is the standard in Agent F.

Staying close to the standard has practical benefits. Your tax advisor knows it, the DATEV export needs no translation, and the mapping to the E-Bilanz taxonomy is largely prepared. For fiscal years beginning after 31 December 2025, taxonomy version 6.9 generally applies (version 6.10 follows for fiscal years beginning after 31 December 2026), and each account must map to a taxonomy position. Every custom account you add is one more mapping someone has to maintain and check.

Why do sub-accounts multiply, and what does it cost?

It usually starts with a reasonable request. Management wants to see marketing cost per country, so the marketing account is split into four. Then per channel, so each country account is split again. Then a new product line arrives, and travel, software and freelancer costs are duplicated per product. Nobody deletes anything, because historical comparisons depend on it.

The result has three costs. First, booking gets harder: the person entering an invoice has to choose between dozens of similar accounts, and the same cost ends up in different places. Second, reports become fragile: every new combination needs a new account, and every report has to be rebuilt to include it. Third, the handover to the tax advisor gets slower, because each custom account needs to be explained, mapped and checked.

The underlying mistake is using general ledger account codes to carry information that belongs elsewhere. An account can hold one piece of meaning. A booking often needs four or five.

What belongs in an account and what belongs in a dimension?

A simple rule: if the distinction matters for the annual accounts or for tax, it is an account. If it matters for management and steering, it is a dimension.

Five questions help in borderline cases.

1. Does it change the line in the balance sheet or income statement? Personnel costs, rent, software and travel are different lines, so they are different accounts.
2. Does it change the VAT or tax treatment? Different VAT rates, non-deductible expenses and reverse-charge items need their own accounts.
3. Does it describe who or where? Team, department, location and country are cost centres.
4. Does it describe what for? Project, product, customer or grant are dimensions.
5. Will it change in a year? Org charts, product lines and projects change often. Accounts should not.

In DATEV, cost centres travel with each booking in two fields, KOST1 and KOST2, so a two-dimensional view survives the export to your tax advisor. Additional dimensions such as product or customer typically stay in your own system and feed management reporting, including contribution margin by product, customer or project.

What rules keep dimensions from becoming the next mess?

Dimensions can sprawl just like accounts if nobody owns them. A few rules keep them useful.

• Make some dimensions mandatory. Every expense and revenue booking should carry a cost centre. A booking without one is incomplete, not optional.
• Use fixed lists, not free text. "Sales DACH", "Sales Dach" and "DACH sales" are three cost centres to a report. Values should be picked from a list that one person maintains.
• Close what has ended. Finished projects and discontinued products should be closed for new bookings but kept for history.
• Limit the number. Three to five dimensions cover most companies. If you need more, the question is usually better answered in a report than in the booking.
• Document the meaning. A short description per dimension and value helps new team members, the tax advisor and the auditor, and belongs in your procedure documentation.

How do dimensions work in reporting and across entities?

With dimensions, one booking to a single travel expense account can carry cost centre "Sales DACH", project "Customer rollout" and product "Platform". The same booking then appears in the income statement as travel, in the cost centre report under sales and in the project report under the rollout. Nobody books it three times.

This is what makes budget vs actual per cost centre work without spreadsheets. Budgets are set per account and dimension, and actuals arrive in the same structure.

For groups, the same principle applies one level up. If each entity uses the same chart of accounts and the same dimension definitions, consolidation becomes a matter of eliminations rather than translation. Agreeing on this before the second entity goes live is one of the main points in multi-entity accounting.

How does Agent F help you keep the ledger clean?

Agent F uses SKR04 as the standard and adapts the chart of accounts to your company during setup, rather than copying an industry template. Cost centres, projects, products and entities are dimensions on one data model, so finance, operations and people all post into the same structure.

When an invoice or bank transaction arrives, Agent F suggests the account and the dimensions from your own booking history, each with a confidence score. If a supplier's invoices have always gone to software with cost centre "Engineering", that is the suggestion; if something looks different, the confidence drops and a person decides. Every approval is recorded in the immutable audit trail. The bookings flow into the BWA (the monthly management report from your tax advisor), your management reports and the DATEV export from the same records.

Before your next fiscal year, list your accounts that exist only to answer a management question, and decide which dimension should carry that information instead. Agree the change with your tax advisor, ideally effective from the start of the year so comparisons stay clean, and check it against the E-Bilanz mapping. The year-end close is the natural point to make the switch.

Learn how Agent F works, or see it on your own chart of accounts at agent-f.ai/demo.