JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 18, 2026 · 10 min read

SAP SF Division

Division is the third-level organizational master data object in SuccessFactors Employee Central, sitting directly below Business Unit and directly above Department in the standard organizational chain. It groups the Departments and Cost Centers of a Business Unit into a product line, functional area, or geographic sub-region — for example, an East Japan sales division, a Consumer Products division, or a Manufacturing division. Every Department that a consultant configures (when the Division level is enabled) is ultimately assigned to exactly one Division. This article covers what Division is, how it sits in the broader hierarchy, and every field an Employee Central consultant configures.

Part 1: Division — Core Concepts (All Modules)#

1.1 What Is the Division?#

Division is a foundation object two levels below Business Unit — it does not represent the major business-line boundary itself, but a further subdivision of that boundary into a product line, functional area, or sub-region. Where Business Unit answers “which major line of business, or region, does this part of the organization belong to,” Division answers “which product line, function, or local sub-region within that business, does this part of the organization belong to.” Department and Cost Center are then nested beneath it to further subdivide that grouping.

1.2 Division Configuration Patterns#

Division is not selected from a fixed SAP type code — but every implementation still has to decide two independent dimensions before go-live: the design axis the level is organized around, and whether the level is used at all.

Design principle: Decide the design axis (product-line vs. regional) and whether the level is enabled once, at blueprint. Every Department created afterward inherits that axis — retrofitting either decision later means re-parenting every Department under new Division codes.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Client (SuccessFactors Instance)
   │
   └── Legal Entity "LE_JP01" — Japan Legal Entity, Company Code JP01
          │
          └── Business Unit "BU_Sales" — Sales HQ, of LE_JP01
                 │
                 └── Division "DIV_East" — East Japan, of BU_Sales
                        │
                        ├── Department "DEPT_S01" — Sales Team 1, of DIV_East
                        │      │
                        │      └── Cost Center "CC_1000" — Sales cost center, of DEPT_S01
                        │
                        └── (external sync) ──> S/4HANA Profit Center / Functional Area

Location "LOC_TKY01" — Tokyo HQ, Asia/Tokyo TZ
   (independent tenant-level master — not nested under Division)

Design principle: Business Unit → Division → Department → Cost Center is a strict single-parent chain below Business Unit. When the Division level is bypassed (see 1.2), Department attaches directly to Business Unit instead — but the chain below whichever level is used remains single-parent throughout.

1.4 Integration with Other Master Data Objects#

Division does not stand alone — it is the mandatory upward link to Business Unit and the mandatory downward grouping for everything organized beneath it.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Core Identification#

Core Identification is the minimum record a Division needs to exist — it is what every Department that belongs to it references when it points “up” to a Division.

2.2 Business Unit Assignment#

This section ties the Division record to its parent Business Unit and to the display/ownership attributes consultants set for org chart purposes.

2.3 Status & Lifecycle#

Status governs whether a Division is available for new assignments — this section is where consultants handle reorganizations, mergers, and product-line consolidations.

2.4 S/4HANA Integration#

For clients running S/4HANA CO alongside SuccessFactors Employee Central, Division reconciliation is less standardized than Legal Entity’s, since S/4HANA has no single dedicated “Division” object.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction