SKR03 vs SKR04: German Chart of Accounts Explained

SKR03 and SKR04 are Germany's two standard DATEV charts of accounts, the main Kontenrahmen many businesses use for German bookkeeping. In plain terms, SKR03 is process-oriented, so it groups accounts around day-to-day business workflows, while SKR04 is financial-statement-oriented, so it mirrors balance sheet and profit-and-loss structure more closely. In a typical SKR03 vs SKR04 decision, teams often choose SKR03 for operational bookkeeping flow and SKR04 when financial statement alignment matters more. Haufe's overview of SKR03 and SKR04 explains that this is the core difference, and that both German standard charts of accounts are organized into account classes 0 through 9.

At a glance	SKR03	SKR04
Organizing logic	Business processes and workflow sequences	Financial statement structure
Best fit	Day-to-day bookkeeping and operational posting routines	Reporting frameworks tied closely to balance sheet and P&L presentation
What changes in practice	Account numbering, posting references, coding habits, software templates	Account numbering, reporting mapping, adviser handoff, statement-oriented structures

What matters is not that one chart is more complete than the other. Both cover the same bookkeeping universe. The difference is how that universe is organized, which is why any German chart of accounts explained in English has to go beyond definitions. Your chart choice affects numbering, coding references, adviser handoff, and software templates long before the first year-end report is produced. This guide breaks the topic into structure, invoice mapping, workflow impact, and selection guidance so you can evaluate an existing setup or choose the right Kontenrahmen Germany model for your team.

---

How Each Chart Organizes the Ledger

The starting point is this: SKR03 and SKR04 are not two different accounting worlds. They are two ways of arranging the same German standard chart of accounts so a business can record transactions under German bookkeeping rules. In both cases, the chart is designed to support HGB-based bookkeeping, year-end accounts, tax work, and day-to-day posting. What changes is the organizing logic behind the numbering.

SKR03 follows a process principle. That means the chart is arranged around how transactions arise in the business. As you move through the account classes, the structure tends to feel operational: capital and finance, then accruals and inventory-related areas, then operating expenses, then revenue, then year-end and statistical accounts. If you think in terms of workflows, purchasing, paying, selling, collecting, and closing, SKR03 often feels intuitive because related posting activity sits near the same part of the chart.

SKR04 follows a financial-statement principle. Its numbering is closer to the structure of the annual accounts, so it lines up more directly with balance sheet and profit-and-loss presentation. In practice, that means the lower account classes are easier to read as balance sheet territory first, then income statement territory afterward. If you think from the perspective of reporting, financial statement preparation, or how accounts roll into HGB presentation, SKR04 usually feels more natural.

At a usable level, the ten account classes from 0 to 9 work like the top shelves of the ledger. The first digit tells you the broad category, and the later digits narrow that category into groups and individual accounts. The exact labels differ between SKR03 and SKR04, but the overall bookkeeping universe is the same:

• 0 to 3 cover the core balance-sheet foundation, such as fixed assets, current assets, capital, liabilities, finance, inventory, or accrual-related areas, depending on the chart.
• 4 to 8 cover profit-and-loss territory, but in a different order. In SKR03, operating expenses appear earlier and revenues later. In SKR04, revenues appear earlier and expenses are grouped afterward in a way that mirrors statement logic more closely.
• 9 is typically where you find carryforward, opening, statistical, and technical accounts in both charts.

That is the practical reason the number families feel different. One chart asks, "Where in the business process does this happen?" while the other asks, "Where does this land in the financial statements?" When you read a chart template, a tax adviser's posting note, or a German software localization setting, that is the distinction you are seeing. Supporting SKR03 or SKR04 does not change the business event. It changes the numbering architecture that organizes ledgers, reports, import mappings, and account references.

How the Same Invoice Can Map Differently

In practice, the difference shows up at Kontierung: the step where you assign invoice details to the right accounts before the posting reaches the general ledger. A German supplier invoice usually needs at least three decisions: which expense or asset account to debit, which VAT account to use, and which Kreditoren account carries the payable. A customer invoice usually needs the mirror image: Debitoren, revenue, and output VAT. That is why invoice coding Germany workflows cannot safely copy mappings from another legal entity, adviser template, or ERP tenant without checking whether the company runs on SKR03 or SKR04.

The examples below show representative patterns, not a full account catalog. Exact account numbers, tax keys, and subaccounts differ by entity, chart variant, industry setup, and adviser policy. The point is to show why comparing SKR04 account codes to SKR03 examples only makes sense after you know which chart the company actually uses.

Transaction	Typical SKR03 pattern	Typical SKR04 pattern	What changed operationally
Supplier invoice for office rent	Rent expense sits in an operational expense family, input VAT is booked separately, and the payable remains on the vendor subledger	Rent expense sits in a reporting-aligned expense family, input VAT is still booked separately, and the payable remains on the vendor subledger	The invoice content is identical, but the approved expense family and review logic shift with the chart structure.
Customer invoice	Debitoren plus revenue, often in an 8xxx family, plus output VAT	Debitoren plus revenue, often in a 4xxx family, plus output VAT	The commercial event is the same, but revenue families move because the chart organizes the ledger differently.
VAT-bearing operating expense	Expense, Vorsteuer, and either Kreditoren or bank/cash follow the company's SKR03 mapping rules	Expense, Vorsteuer, and either Kreditoren or bank/cash follow the company's SKR04 mapping rules	The source document stays the same, but posting defaults, account references, and control checks can change.

A few workflow points matter more than the individual numbers:

• Debitoren and Kreditoren are usually entity-specific person accounts. In many DATEV-style environments, the vendor or customer account can stay stable while the revenue, expense, VAT, bank, and clearing accounts shift around it.
• Kontierung Germany is not just category tagging. It determines VAT treatment, reporting lines, and whether a posting lands cleanly in the target general ledger. If extracted invoice data feeds an ERP import, the mapping has to match the chart logic already configured for that company.
• Do not transplant mappings blindly. A template built for one SKR03 entity may be wrong for an SKR04 entity even if the invoices look nearly identical.

A compact end-to-end example makes the point clearer. Suppose extracted invoice data gives you these fields: vendor name, invoice date, net amount, 19% VAT, gross total, cost center "Office", and a description that clearly points to rent. Under SKR03, the mapping rule may route that package into an operational rent-expense family plus input VAT and a vendor payable. Under SKR04, the same extracted fields may route into a different rent-expense family plus the corresponding input VAT account. The extracted data did not change. The chart-specific Kontierung logic did.

If you want a broader view of what invoice GL coding looks like in practice, the same principle applies outside Germany too. For German bookkeeping, the source document also matters: German invoice fields that affect VAT and account treatment often determine whether the posting can use normal input VAT, needs correction, or has to be routed to a different account logic altogether.

---

When SKR03 Fits Better and When SKR04 Makes More Sense

If you are deciding between SKR03 and SKR04, the best choice usually comes down to how the business is run, how reports are consumed, and what your Steuerberater expects to work with every month. Neither chart is inherently better. The better fit is the one that matches your bookkeeping workflow, reporting structure, existing DATEV or ERP templates, and the way the entity will be managed over time.

SKR03 usually fits better when the finance team thinks in terms of daily bookkeeping flow: posting supplier invoices, classifying expenses, checking open items, and keeping routine accounting work consistent. It is often the more familiar operational setup in smaller and mid-sized German businesses, especially where the external adviser or accounting team already has established posting habits, account ranges, and import templates built around it. If your priority is smooth day-to-day posting and a setup your Steuerberater already uses comfortably, SKR03 is often the more practical choice.

SKR04 usually makes more sense when the organization wants the ledger to line up more directly with financial statement presentation. That matters more in groups with formal reporting packs, international stakeholders, management teams that review accounts in statement order, or ERP environments where reporting design drives the chart structure. If your main priority is clearer alignment between bookkeeping accounts and balance sheet or P&L reporting, SKR04 is often the stronger option.

Your priority	Likely fit	Why
Familiar operational bookkeeping structure	SKR03	Often better suited to day-to-day posting logic and common adviser workflows
Existing Steuerberater templates already use one chart	Usually follow that chart	Reusing established account mappings, DATEV exports, and review routines reduces friction
Management reporting should mirror financial statement structure	SKR04	The chart is typically easier to read in reporting terms
Group reporting or multinational finance oversight	SKR04	Helps when local ledgers must feed into more formal reporting frameworks
Smaller entity focused on practical bookkeeping efficiency	SKR03	Often easier to maintain if the team works transaction-first rather than report-first
New ERP design built around reporting models and account hierarchies	SKR04	Better fit when reporting presentation drives the system setup
Legacy bookkeeping, adviser handoff, and existing coding habits matter most	SKR03	Lower change burden for people already posting in that structure

A useful rule for SKR03 versus SKR04 selection is this: choose SKR03 if the accounting process is being designed around bookkeeping operations, and choose SKR04 if it is being designed around reporting presentation. If you are inheriting an existing setup rather than choosing from scratch, check the current account number families, DATEV export or localization settings, adviser onboarding documents, and any booking rules already baked into the ERP. Those clues usually tell you which chart the entity is already using before you remap anything.

Settle the choice before large-scale account coding, migration, or automation work starts. Once invoices are being posted at volume, changing charts means remapping accounts, retesting VAT logic, updating export structures, and checking controls across DATEV and ERP integrations. That is why deciding which chart fits best is not just an accounting theory question. It is a setup decision with real downstream control risk.

What the Choice Changes in DATEV Handoffs and ERP Mapping

Once invoice data has been extracted, the chart choice changes five downstream things immediately: mapping tables, DATEV exports, ERP import templates, approval rules, and reconciliation checks. SKR03 and SKR04 do not change what was on the invoice. They change where that information lands in the ledger, how your coding rules are written, and what your downstream systems expect.

For teams building an invoice data extraction workflow, that means the chart decision has to be reflected in more than the accountant's posting habits. It affects CSV import layouts, account lookup tables, approval coding rules, exception handling, and the notes sent with files that move into bookkeeping or tax review. If your adviser expects DATEV SKR03 accounts and your ERP staging table is built around SKR04 logic, even clean invoice data can be posted incorrectly.

Workflow area	What changes when the chart changes
Account mapping table	The extracted fields stay the same, but the expense, revenue, VAT, clearing, and fixed-asset accounts linked to those fields can differ.
DATEV export or handoff	Account numbers, booking templates, and adviser expectations must match the selected chart, not a generic German template.
ERP import template	Your ERP may need a specific crosswalk from internal dimensions or global account codes into SKR03 or SKR04 target accounts.
Approval rules	Rules such as "marketing invoices route to this expense account unless capex criteria apply" depend on the chart structure behind them.
Reconciliation	AP aging, VAT checks, and month-end reviews become harder if invoices were coded with the wrong chart logic at import stage.

The risk is highest in non-German ERP environments. NetSuite, SAP, Oracle, Microsoft Dynamics, and other platforms often support local charts, but German account assignment is not a plug-and-play default. For a workable setup, document four things clearly:

• which extracted invoice fields drive account selection
• which VAT codes and exceptions apply
• when cost centers or other dimensions are mandatory
• which SKR accounts your German adviser has approved for recurring scenarios

That is the real meaning of a German chart of accounts for ERP setup: not just loading a list of accounts, but agreeing how operational invoice data becomes a compliant German posting.

DATEV handoff is where this becomes visible fastest. If invoices are reviewed in one system and posted or finalized in DATEV, the handoff file has to carry enough structure for the receiving team to understand the intended Kontierung. That usually means consistent supplier naming, standardized dates, separate net and VAT values, clear tax treatment, and notes for exceptions such as reverse charge, intra-EU purchases, credit notes, or partially deductible VAT. If you want a more detailed process view, see how invoice data is handed off into DATEV.

Consistency matters even more when several people or systems touch the same invoice before posting. A shared-service analyst may capture the document, a local finance manager may approve cost allocation, and an external tax adviser may review the final booking. Mapping mistakes usually come from gaps between those steps, not from the raw invoice image itself. You reduce that risk when you standardize:

• which fields must always be captured before coding starts
• how VAT scenarios are labeled and escalated
• which account mapping table is the current approved version
• what handoff notes are required for unusual transactions
• who can override a default account and when that override must be documented

Even when invoice data is extracted into spreadsheets, CSV, or JSON first, the accounting logic still has to be applied deliberately. The safest setup is simple: capture the same core fields every time, maintain one approved SKR mapping table, align it with your German adviser, and make sure every ERP import or DATEV handoff uses that same rule set.

---

Switching Later, Industry Variants, and a Safe Rollout Checklist

Switching between SKR03 and SKR04 is possible, but it is rarely a light administrative change. You are not just renumbering accounts. You are reworking posting logic, account crosswalks, recurring booking templates, ERP defaults, report layouts, and the habits your finance team or tax adviser already uses. Historical comparability also becomes harder because trend reports, management packs, and exported bookkeeping data may no longer line up cleanly period to period unless you define a clear mapping strategy in advance.

That is why a chart decision should be documented, not treated as a hidden system setting. If someone later asks why a cost category, VAT account, or posting rule was configured a certain way, you need traceable bookkeeping logic that can be explained and defended. This matters for internal controls, adviser reviews, and GoBD rules for traceable digital bookkeeping.

Specialized variants such as SKR45 and SKR49 usually matter only in narrower cases where a particular industry convention, adviser workflow, or software environment already expects them. For most English-speaking readers setting up German bookkeeping, the trigger is simple: ignore variants unless your tax adviser, sector-specific software, or implementation template explicitly requires one. If nobody in your process has named a specialized chart as a requirement, the real decision is usually still SKR03 or SKR04.

Use this German chart setup checklist before go-live, or before any migration project already under discussion:

• Confirm whether the business should stay on its current chart or adopt a new one, and record the reason for that choice.
• Assign clear ownership for account mappings so one person or team is responsible for the SKR logic across extraction, posting rules, and reporting outputs.
• Review VAT account treatment carefully, especially for domestic VAT, intra-EU scenarios, reverse charge cases, and input versus output tax postings.
• Align the setup with your tax adviser or external accountant before rollout so DATEV expectations and filing workflows match the chart you configure.
• Review ERP templates, default accounts, booking rules, import layouts, and approval workflows to make sure they point to the correct chart structure.
• If a switch is being considered, plan the migration explicitly: build a crosswalk, decide how historical periods will be compared, test sample transactions, and set a controlled cutover date.