Structure and master data in SAP S/4HANA

Everything after this station — a purchase cycle, a sales cycle, a close, a report — stands on what you decide in it. And this is the only station on the path where correcting it after go-live costs more than doing the whole thing again from scratch.

The reason is structural: the organisational levels are decided once, and stamped on every document issued afterwards. So an error here does not surface as an error message; it surfaces as a report that fails to answer a question two years later.

The levels, and what each one settles

This is the vocabulary that precedes every screen, and most people starting this system skim it and pay for that later:

Level	What it represents	The decision it settles
Company code	The legal entity the financial statements are issued under	Who files the tax return, and in which currency
Controlling area	The container for management accounting	Whether two entities’ costs can be compared together
Purchasing organisation	The body that contracts with suppliers	Who negotiates, and who owns the framework agreement
Plant	An operating location — factory, warehouse or branch	Where requirements are planned and where goods are valued
Storage location	A subdivision inside the plant	Counting precision and where the balance sits
Sales organisation	The body that sells in its own name	Terms of sale, and sales reporting
Distribution channel and division	How and to whom you sell	Different pricing for the same item

Read the last column on its own first. These levels are not formal bureaucracy; each one is a real management question asked once and answered for ever.

The rule that settles most of the argument

The same debate runs on every project: do we open a second company or a branch? Do we make this a plant or a storage location? One sentence settles it:

Open a new legal entity only if it issues independent financial statements and files a tax return in its own name. Everything below that — a branch, a store, a line of business — is represented at a lower level.

Break that rule and you get two results at once: a doubled monthly close, and consolidated reports that can only be built by hand. Both are a permanent monthly cost against a decision taken in a week.

The unified business partner — the difference that explains the generation

Here is one of the two changes this generation was built for.

In earlier generations a customer was one record and a vendor another. A company that buys from its own customer and sells to it — commoner in distribution and contracting than people assume — carried that party twice, under two different numbers. To find the net position between you, you added the two numbers by hand outside the system.

Now a single record carries the roles. One partner, with a customer role and a vendor role, and its identity data — name, address, tax registration number — written once.

Three practical consequences are worth writing down.

One: no two tax numbers for one party. That reads as a detail today and becomes decisive at station eight, when e-invoicing asks about the identity of the other party.

Two: data cleansing became measurable. When identity lives in one place, “how many partners do we have with no tax number?” becomes a question with one answer rather than two.

Three: roles are added, not cloned. A vendor who becomes a customer acquires a role rather than being created afresh.

The material master — why it is the longest record you will see

The material master in this system is divided into views by who uses it: a purchasing view, a sales view, an inventory view, an accounting view, and views for planning and quality.

That division is the key, not the complexity. One material carries information a buyer does not care about at all and an accountant cares about exclusively: the purchase unit differs from the sales unit, the valuation class belongs to accounting alone, and the planning data belongs to production.

The practical rule: do not populate a view nobody uses. A field filled because the screen displays it is a field maintained for ever at no return — and most master data projects bloat from here rather than from the number of items.

Three master-data rules that hold in any system

One: master data is a project in itself, not a step inside a project. Schedule it as one week and you discover it is three, having already promised a go-live date that now falls.

Two: clean before you migrate, never after. Migrating dirty data makes the cleansing a task performed on a live system, which costs twice as much.

Three: every field has an owner. A field where nobody knows who fills it and who reviews it stays empty for a year, is then demanded in a report, and gets filled at random.

What you actually do at this station

If you have an environment, build the structure. If you do not — the usual case at this stage, as the previous station explained — the following work is done on paper and appears in your portfolio:

• Take a real company you know — your current employer, or a family business — and draw its seven levels by name.
• Justify every decision in one line. Why two plants rather than one? Why a single controlling area?
• Write out five materials with only the views they need, giving your reason for each view you excluded.
• Take one partner who both buys and sells and write out how it is represented by one record with two roles.

That sheet specifically is the closest thing you produce at this stage to a real deliverable — because the first thing an implementation partner asks a client for is exactly that drawing.

Two recurring mistakes

Copying another company’s structure. The structure reflects how the company works and who decides in it, and copying it imports decisions that were never taken.

Deferring the controlling-area decision. It looks like an internal accounting detail, and then turns out to be the decision that determines whether two entities’ costs can be compared in one report. When that is asked for two years later, the change is a project rather than a setting.

How all of this translates into a real project cost structure is set out in the SAP S/4HANA guide.

The acceptance test for this station

1. Draw the seven levels for a company you know, with a written reason for every decision.
2. Write the legal-entity test in your own words, and apply it to two real branches.
3. Explain in five lines what a company did before the unified partner when a party was both customer and vendor.
4. Design five materials with only the views they require, and state why you left the others out.
5. Count, in your current company’s data, how many partners have no tax number and how many addresses are written in a single field. That figure gets used at station eight.

What comes next

The structure is ready. The next station moves the first real document: three-way matching in the purchase cycle — the requisition, the receipt and the vendor invoice — and why three-way matching is the one idea that, once understood, gives you half of materials management.