On this page
- Part 1: Business Unit — Core Concepts (All Modules)
- 1.1 What Is the Business Unit?
- 1.2 Business Unit Configuration Patterns
- 1.3 Organizational Levels and Data Hierarchy
- 1.4 Integration with Other Master Data Objects
- Part 2: SF-Specific Field Details
- 2.0 Scope of SF Ownership
- 2.1 Core Identification
- 2.2 Legal Entity Assignment
- 2.3 Status & Lifecycle
- 2.4 S/4HANA Integration
- What to Read Next
SAP SF Business Unit
SAP SF Business Unit
Business Unit is the second-level organizational master data object in SuccessFactors Employee Central, sitting directly below Legal Entity and directly above Division in the standard organizational chain. It groups the Divisions, Departments, and Cost Centers of a Legal Entity into a major business line or region — for example, a Sales headquarters, a Manufacturing arm, or a regional operating unit. Every Division that a consultant configures (when the Business Unit level is enabled) is ultimately assigned to exactly one Business Unit. This article covers what Business Unit is, how it sits in the broader hierarchy, and every field an Employee Central consultant configures.
Part 1: Business Unit — Core Concepts (All Modules)
1.1 What Is the Business Unit?

Business Unit is a foundation object one level below Legal Entity — it does not represent the legal/statutory employer boundary itself, but the first major internal grouping underneath it. Where Legal Entity answers “who is the legal employer,” Business Unit answers “which major line of business, or region, does this part of the organization belong to.” Division, Department, and Cost Center are then nested beneath it to further subdivide that grouping.
| Aspect | Details |
|---|---|
| Role | Second level of the organizational hierarchy — groups one or more Divisions under a single Legal Entity, typically representing a major business line or region |
| Modules using it | Employee Central (owner — foundation object framework), Recruiting (job requisitions are frequently scoped or routed by Business Unit), Compensation (budget pools and eligibility rules are frequently segmented by Business Unit) |
| Transactions | Admin Center → “Manage Organization, Pay and Job Structures” (create/edit foundation object records); “Import and Export Data” (mass load via CSV); Business Rules can auto-derive Business Unit from other Employment fields |
| Key Tables | OData API entity FOBusinessUnit (Foundation Object) — SuccessFactors has no classic ABAP table; each record is effective-dated rather than table-row based |
| S/4HANA note | Business Unit commonly syncs inbound from S/4HANA Organizational Management, but unlike Legal Entity’s clean 1:1 mapping to Company Code, there is no single universal S/4HANA counterpart — clients variously map it to an upper-level Organizational Unit (PPOME), a Business Area, or keep it SuccessFactors-native when no equivalent grouping exists in S/4HANA |
1.2 Business Unit Configuration Patterns

Business Unit 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.
| Pattern | Marker | Use Case | Key Behavior |
|---|---|---|---|
| Functional Business Unit | Functional | Client organizes primarily by product/service line (e.g. Sales, Manufacturing, R&D) | Business Unit name reflects a business function; Divisions beneath it typically represent regional breakdowns of that function |
| Regional Business Unit | Regional | Client organizes primarily by geography under a single Legal Entity | Business Unit name reflects a region or market (e.g. “APAC Business Unit”); Divisions beneath it typically represent product lines or functions within that region |
| Enabled Business Unit Level | Enabled | Legal Entity has enough organizational complexity to warrant an intermediate grouping above Division | Every Division must be assigned to a Business Unit; Business Unit becomes a mandatory link in the chain |
| Bypassed Business Unit Level | Bypassed | Simpler organizations where Division (or Department) attaches directly to Legal Entity | The Business Unit foundation object type remains configured in the system but has zero active records referencing it; the org chart and reporting skip straight from Legal Entity to Division |
Design principle: Decide the design axis (functional vs. regional) and whether the level is enabled once, at blueprint. Every Division created afterward inherits that axis — retrofitting either decision later means re-parenting every Division under new Business Unit 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 Organizational Management (Org Unit / Business Area)Design principle: Business Unit → Division → Department → Cost Center is a strict single-parent chain below Legal Entity. When the Business Unit level is bypassed (see 1.2), Division attaches directly to Legal Entity instead — but the chain below whichever level is used remains single-parent throughout.
1.4 Integration with Other Master Data Objects

Business Unit does not stand alone — it is the mandatory upward link to Legal Entity and the mandatory downward grouping for everything organized beneath it.
| Object | Relationship | Practical Notes |
|---|---|---|
| Legal Entity | Direct parent (N:1) — every Business Unit must be assigned to exactly one Legal Entity | Changing a Business Unit’s Legal Entity assignment after go-live re-parents every Division, Department, and Cost Center beneath it, and should be treated as a formal reorganization rather than a routine edit |
| Division | Direct child (1:N) — every Division must belong to exactly one Business Unit, when the Business Unit level is enabled | The first mandatory step below Business Unit; if Division is not used either, Department attaches directly one level higher |
| Position | Indirect, via the Department → Division → Business Unit chain — Position itself references Department, not Business Unit directly | Relevant when building headcount or requisition reports segmented by Business Unit; the rollup path runs through Department and Division, not a direct field on Position |
| Compensation Budget | Frequently allocated and reported at Business Unit level, though the Budget object itself references Department | Compensation teams commonly roll Department-level budgets up to Business Unit for annual planning-cycle reporting, even though the system field points to Department, not Business Unit |
| S/4HANA Organizational Management | External sync source/target for clients running S/4HANA HR/OM | Confirm during blueprint which S/4HANA object (Organizational Unit, Business Area) is the mapping target, since Business Unit lacks Legal Entity’s clean 1:1 Company Code equivalent |
Part 2: SF-Specific Field Details
2.0 Scope of SF Ownership

| Data Section | SF Involvement | Notes |
|---|---|---|
| Core Identification | ◎ Owner | External Code, Name, Effective Start Date |
| Legal Entity Assignment | ◎ Owner | Parent Legal Entity, Business Unit head, sort order |
| Status & Lifecycle | ◎ Owner | Active/Inactive status, effective-dated change history |
| S/4HANA Integration | ○ Shared with FI/Basis/HR-OM | External Code mapping, sync direction, sync frequency |
Legend: ◎ = Owner / Critical, ○ = Direct involvement
2.1 Core Identification

Core Identification is the minimum record a Business Unit needs to exist — it is what every Division that belongs to it references when it points “up” to a Business Unit.
| Field | Description | Practical Usage |
|---|---|---|
| External Code | Unique identifier for the Business Unit | The key value every downstream reference (Division, integration payloads) points to. Decide the coding convention once with the integration team — changing it after go-live breaks any middleware mapping keyed on the old value. |
| Name | Display name of the Business Unit | Localizable per language pack in a global instance. If a synced S/4HANA Organizational Unit or Business Area exists, keep the naming convention aligned so HR and other teams recognize the same grouping across systems. |
| Effective Start Date | Date this version of the record becomes active | Every field change is captured as a new effective-dated row, not an overwrite. This is what allows an org-chart-as-of-date query to reconstruct historical structure — critical for audit and reorganization history. |
| Effective-Dated History | Chain of prior versions of this Business Unit record | Used to answer “what was this Business Unit’s name/status/Legal Entity on date X.” Consultants should avoid deleting history rows; correct forward with a new effective-dated entry instead. |
2.2 Legal Entity Assignment

This section ties the Business Unit record to its parent Legal Entity and to the display/ownership attributes consultants set for org chart purposes.
| Field | Description | Practical Usage |
|---|---|---|
| Legal Entity | The parent Legal Entity this Business Unit belongs to | Mandatory single-value assignment; every Division created under this Business Unit inherits the same Legal Entity context indirectly. Re-assigning a Business Unit to a different Legal Entity should be modeled as a formal reorganization, since it retroactively changes the legal-employer context implied for every downstream Division/Department. |
| Business Unit Head | Employee designated as the head/owner of the Business Unit (if configured) | Commonly used to drive Position-based org chart displays and to designate an escalation approver in workflow foundation rules; leave blank if the client does not model a formal Business Unit-level owner role. |
| Sort Order | Display sequence used when rendering the Business Unit alongside its siblings | Purely cosmetic — controls ordering in org chart and picklist displays, not the data hierarchy itself. Useful to keep consistent when a client wants Sales-related Business Units listed before support functions, for example. |
2.3 Status & Lifecycle

Status governs whether a Business Unit is available for new assignments — this section is where consultants handle reorganizations, mergers, and business-line closures.
| Field | Description | Practical Usage |
|---|---|---|
| Status | Active / Inactive flag | Setting a Business Unit Inactive does not remove existing Division assignments — it only blocks the Business Unit from being selected on new records going forward. Deactivation should always be effective-dated to match the actual reorganization date, not the date the admin makes the change in the system. |
| Deactivation Impact | Downstream effect of an Inactive Business Unit | Before deactivating, check for any Division still pointing to the Business Unit — those need to be re-pointed to the surviving Business Unit first in a restructuring or business-line consolidation scenario. |
2.4 S/4HANA Integration

For clients running S/4HANA HR/OM alongside SuccessFactors Employee Central, Business Unit reconciliation is less standardized than Legal Entity’s, since S/4HANA has no single dedicated “Business Unit” object.
| Field | Description | Practical Usage |
|---|---|---|
| External Code Mapping | Cross-reference between SuccessFactors External Code and the S/4HANA source object value | Confirm during blueprint which S/4HANA object the client’s Business Unit maps to (an upper-level Organizational Unit via PPOME, a Business Area, or none at all) — this decision drives whether the mapping table is even needed. |
| Sync Direction | Whether S/4HANA is the system of record (inbound to SF) or the Business Unit is SuccessFactors-native | Many clients treat Business Unit as SF-native even when Legal Entity and Cost Center are synced, since S/4HANA org structures don’t always carry a clean equivalent grouping. Confirm ownership explicitly to avoid ambiguity during maintenance. |
| Sync Frequency | Batch (scheduled) vs. near-real-time replication, when sync is used | Typically delivered via the same integration content or middleware used for Legal Entity/Cost Center sync. Batch-only sync means a newly created S/4HANA source object is not immediately usable in Employee Central — plan reorganization go-lives around the sync schedule. |
What to Read Next
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| sf-001 | Overview | What is SAP SuccessFactors? |
L2-A) Master Data
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| sf-b01 | Overview | SAP SuccessFactors Transactions: Process Flow, Hierarchy & Relationships |