SAP Organizational structure

Before you can post an invoice or raise an order, SAP needs to know the legal, logistical and reporting entities involved. The organizational structure defines these units and their relationships, and it is one of the earliest and most consequential configuration decisions in any implementation.

• Company code: the legal entity for financial reporting (FI).
• Plant: a location where goods are produced or stored (logistics).
• Storage location: a stock area within a plant.
• Sales organization / distribution channel: for selling (SD).
• Purchasing organization: for buying (MM).
• Controlling area: for cost accounting (CO).

All of it lives in the IMG under Enterprise Structure, reached with SPRO, and the tree there is split into two halves that must be done in order. Definition creates each unit. Assignment connects them to each other, and nothing works until the assignments exist.

The client sits above everything, and it is not really an organisational unit so much as the system boundary: separate data, separate configuration, separate users. Below it, the company code is the legal entity that produces a balance sheet, the plant is where goods are made or stored, the purchasing organisation negotiates, and the sales area is the combination of sales organisation, distribution channel and division.

The assignments are what carry meaning. A plant is assigned to a company code, which is how a goods movement knows whose books it posts to. A sales organisation is assigned to a company code for the same reason. A plant is assigned to a purchasing organisation, which decides who may buy for it.

The tables are readable if you want to see the result directly: T001 for company codes, T001W for plants, TVKO for sales organisations and T024E for purchasing organisations.

Twenty minutes, and it turns an abstract diagram into something you can see.

1. Open any purchase order with ME23N. On the header, find the purchasing organisation and purchasing group. On the item, find the plant.
2. Look up which company code that plant is assigned to. That is the entity whose accounts the goods receipt will post to, and you did not enter it anywhere on the order.
3. Open a sales order with VA03 and find its sales area on the header. Every pricing, partner and output determination on that document was resolved for that sales area.
4. Now try creating an order for a sales area that does not exist, or for a customer not extended to it. The refusal names the sales area, which is the system telling you the assignment is the problem.

Step two is the one worth internalising. Most postings derive their company code from the organisational unit on the document rather than from anything the user typed, which is why a wrong assignment produces correct-looking documents posting to the wrong books. See SAP company code for the unit finance cares about most.

These units are assigned to each other, plants to company codes, sales organizations to company codes, so that logistics events flow to the correct legal entity for accounting. Designing this structure correctly is essential; changing it later is painful.

The interlocking is why organisational design is done once, jointly, by every module team. A decision to run one plant or three changes procurement, production, warehousing and reporting at the same time, and none of those teams can make it alone. See cost centres for the controlling structure that sits alongside this.

• How many company codes. One per legal entity is the rule, and the temptation is to add more for reporting convenience. Resist it: a company code carries a full set of books and a close.
• How many plants. A plant is a place goods exist and are valued. Splitting one site into several plants gives finer valuation and multiplies master data maintenance.
• Centralised or local purchasing. One purchasing organisation gives negotiating leverage. Several give autonomy and fragmented spend.
• How complex the sales area. Every distribution channel and division multiplies the combinations that master data and pricing must cover.

These are close to irreversible. Changing a company code assignment after go-live is a data migration, not a configuration change, which is why this is the first design workshop on any project.

Enterprise structure covers the legal and physical world. Controlling has its own set of units for the management view, and they interlock with the first set without being part of it.

The controlling area is the boundary for cost accounting. It can span several company codes, which is what allows a group to allocate costs and report profitability across legal entities. Where it does, all of them must share a chart of accounts and a fiscal year variant, which is a real constraint decided early.

Cost centres are where costs are collected, usually mirroring departments or functions. Profit centres are for internal responsibility reporting, which may cut across the legal structure entirely: a product line spanning three company codes can be one profit centre.

The operating concern is the boundary for profitability analysis, defining the dimensions you can report margin by, such as product, customer group and region.

The relationship worth holding: a company code produces the statutory accounts and a profit centre produces the management view, and the same posting appears in both. When the finance director asks why the divisional numbers do not add up to the legal ones, the answer is usually a posting that reached a company code and not a profit centre.

Designing both structures together is the right approach, because a decision on one constrains the other. Choosing many small company codes, for instance, makes cross-entity cost allocation a monthly task rather than a configuration.

Most people meet an organisational structure already built, and there is a quick way to understand one.

Start with how many company codes and why. One per country usually means legal requirement. Several in one country usually means an acquisition, and that history explains a lot of what looks inconsistent.

Then plants per company code. One plant per site is normal. Several plants at one site means somebody wanted separate valuation, and it is worth asking why before assuming it was a mistake.

Then the sales areas. Many distribution channels usually means genuinely different routes to market. Many divisions usually means product-based reporting that could have lived in profit centres instead.

Then the purchasing organisations, which tell you whether buying is central or local, and therefore who negotiates.

Half an hour spent this way tells you more about how the business is organised than any presentation, because the structure records decisions that were expensive to make and cannot easily be undone.

• Designing the structure carelessly, it is very hard to change later.
• Confusing legal (company code) and logistical (plant) units.
• Missing the cross-module assignments that make integration work.

• Modelling the org chart instead of the legal and physical reality. Departments reorganise every year; legal entities and sites do not.
• Creating units "for reporting". Reporting dimensions belong in profit centres, cost centres and segments, not in the enterprise structure.
• Skipping the assignment step. Units that exist and are not assigned produce errors that name the document rather than the missing link. See document types for the next layer of configuration up.

Reading a structure is straightforward, and designing one for a real business so it survives ten years of change is the part you do in the course.