SAP Concepts: Org Structures in SAP: Client, Company Code, Plant, Sales Org (S/4HANA Hierarchy)

If you've spent time using SAP, you'll have noticed that every transaction asks you to specify a bewildering set of contextual identifiers. Which client? Which company code? Which plant? Which storage location? Which sales organisation? It feels like bureaucracy. It isn't. It's the organisational hierarchy that makes SAP capable of modelling a global corporation with subsidiaries in forty countries.

This is episode seven of our SAP Concepts series, and we're going to walk the five levels of SAP's organisational structure, explain why each one exists, and show how they assemble into the skeleton that every transaction hangs off.

By the end, when someone says "this posting is to company code 1710, plant 1720", you'll know exactly what they mean and why those two pieces of information are both necessary and sufficient to place the posting on the map.

Why the hierarchy exists at all

Before we get into the levels, the why. A global business — even a simple multi-national — has a few hard realities that the software has to model.

Each country subsidiary is a separate legal entity. The German GmbH, the US Inc., the UK Ltd — each has its own books, its own tax registration, its own statutory accounts. SAP has to keep those books separate, because the tax authorities expect each entity's filings to be legally distinct.

Each entity has its own functional currency. The German subsidiary reports in euros. The US subsidiary in US dollars. Transactions happen in the local currency first; consolidation into a group currency happens separately.

Consolidation across the group has to roll up cleanly. The parent company needs a group P&L and balance sheet. That means all the subsidiaries' books have to be translatable to a common structure — usually a shared chart of accounts.

Auditors, tax authorities, and regulators want the numbers sliced many ways. By legal entity, by product line, by region, by plant. The software has to support all of those slices from the same transactional base.

The organisational hierarchy is SAP's answer to all of that. It's not bureaucracy for its own sake — it's the minimum set of structural levels needed to represent a real business.

Level one: the client

At the very top sits the client. This is the highest level in SAP, and it's often the one newcomers find most confusing because the English word "client" is overloaded.

In SAP terms, a client is a tenant — a completely isolated logical installation of SAP that shares the physical server but has its own database, master data, configuration, and transactional data. A company might run three clients on the same SAP installation:

• 100 for development
• 200 for quality assurance
• 800 for production

These are isolated from each other. Data in client 100 is invisible in client 800. The numbers 100, 200, 800 aren't magic — they're convention, and the actual numbers used can vary by company — but the three-digit pattern and the dev/QA/prod split is extremely common.

For a user, which client you log into is the very first thing you specify. Everything else — every piece of master data, every transaction — is scoped to that client. You can't accidentally create a sales order in dev that shows up in production; they're different worlds.

Level two: the company code

Inside a client sits the company code. This is where FI lives.

A company code is one legal entity — one company that files its own statutory accounts. It has:

• A local currency (EUR, USD, GBP, etc.), fixed at creation
• A chart of accounts — the set of GL accounts in use
• A tax registration number and trade register entry
• A leading ledger (and possibly parallel ledgers for different accounting standards — IFRS, local GAAP)
• A parent for consolidation, if it's part of a group

Company code 1710 might be "DE01 Finance GmbH" — the German subsidiary, in EUR, with the group's shared chart of accounts YCOA. Company code 2100 might be "US02 Finance Inc" — the US subsidiary, in USD, with the same chart of accounts for consolidation.

Every FI posting happens inside exactly one company code. When someone says "post this to company code 1710", they mean "book this transaction against the German entity's ledger."

The company code is the level at which the books balance. It's where the statutory P&L, balance sheet, and cash flow roll up.

Level three: the plant

Below the company code sits the plant. If the company code is the legal and financial unit, the plant is the physical unit.

A plant is a physical site: a factory, a distribution centre, a warehouse. It has a location (address, country, region). It's where MM and PP live. Plants are where:

• Materials have a value — the same material can have different values at different plants
• MRP runs — each plant plans its own production and procurement
• Inventory is managed — stock is tracked at plant level

Every plant is assigned to exactly one company code. That one-to-one assignment is how physical goods movement turns into accounting entries: when stock leaves plant 1720, the system knows it belongs to company code 1710, so FI postings go to that entity's ledger.

A company might have multiple plants. Company code 1710 might have plant 1710 (Walldorf DC) and plant 1720 (Stuttgart Works). Both are German entities, but they're physically separate sites with their own inventory and their own production.

Level four: the storage location

One level deeper: the storage location. Inside a plant, storage locations are zones — warehouse bays, shelves, quarantine areas, specific warehouse buildings.

A storage location is a sub-plant addressable location. Plant 1720 might have storage locations:

• RAW1 — raw materials bay 1
• RAW2 — raw materials bay 2
• FG01 — finished goods main
• REJ1 — reject / quarantine
• TRAN — in-transit

Critically, the storage location tracks quantity, not value. Valuation lives at the plant level; storage location is about where the stock physically sits. Moving stock from RAW1 to RAW2 inside the same plant doesn't change anything financially — you still own the same stock at the same value.

Every goods movement in MM cites both a plant and a storage location. That combination is the physical address of the stock.

Level five: the sales organisation

The SD side has its own hierarchy, structured as a three-axis cube.

Sales organisation — the top of the SD side. A sales organisation is a legal-selling unit, always assigned to one company code. "Germany Sales" (sales org 1710) sells on behalf of company code 1710.

Distribution channel — how you sell. Direct sales, retail, wholesale, online. Different channels can have different pricing strategies and different customer masters.

Division — what you sell. Product lines like "pumps" or "valves" or "chemicals".

Together, sales organisation + distribution channel + division = a sales area. Every sales order, every customer master record, every pricing condition attaches to a specific sales area. Sales area 1710-10-00 might mean "Germany Sales / Direct / Pumps and Valves (combined)."

The sales org also assigns to a company code (one-to-one), so every sales transaction ultimately lands in the right entity's books.

How the assignments wire together

The five levels don't float independently. They assemble through explicit assignments:

• Each plant assigns to exactly one company code (one-to-one)
• Each storage location assigns to exactly one plant (one-to-one)
• Each sales organisation assigns to exactly one company code (one-to-one)
• Sales organisations can sell from multiple plants (many-to-many)

These assignments are configuration, set up at the beginning of an SAP implementation, and generally not changed afterward. They form the skeleton — the immutable structural framework — that every transaction hangs off.

When a user creates a sales order, the system needs to know: which sales area? (That tells it which pricing conditions to apply.) Which plant will fulfil? (That tells it where the stock lives and what currency the cost is in.) Which customer? (That has its own master record with credit terms, tax details, etc.) The answer to all of those is determined by the org structure.

Why it matters

Two takeaways.

Every SAP transaction has an organisational fingerprint. You can't post a sales order without knowing the sales org, the plant, and the company code. The four pieces of information are what determine which currency, which chart of accounts, which tax jurisdiction, and which statutory books the transaction rolls up into.

The org structure is the skeleton for multi-entity reporting. When the CFO asks "what was our revenue by country last quarter?", the company-code dimension answers it. When she asks "by product line?", the division dimension answers. When she asks "by distribution channel?", that dimension is right there in every sales order. The hierarchy makes cross-cutting analysis possible because every transaction is tagged with every level.

For anyone new to SAP, understanding the org structure is the most important orientation you can get. Transactions are confusing in isolation; they make sense when you see them as events within a structural hierarchy.

What's next

That's the five-level skeleton. Client at the top (tenant), company code (legal entity), plant (physical site), storage location (zone inside the plant), and sales organisation with its distribution channel and division (the SD cube).

Episode eight is the Season 1 finale. We'll cover S/4HANA vs ECC — what actually changed in SAP's biggest rewrite, why the Universal Journal matters, why Business Partner replaced the old customer and vendor masters, and why everyone's talking about RISE. It's the episode that ties the whole season together.

See you there.