JinJin48

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

July 8, 2026 · 9 min read

SAP Fieldglass Business Unit

The Business Unit is the cost and reporting-organization dimension in SAP Fieldglass Company Structure — a Tenant-level master, independent of Site, that groups requisitioning activity for financial reporting, GL posting, and downstream Cost Center allocation. Unlike Site, which anchors a physical work location, Business Unit answers a different question: which part of the organization is paying for and reporting on this work. It is also the only Company Structure object with a hierarchy of its own — a Business Unit can be nested under a parent Business Unit to build a roll-up reporting tree, independent of how Sites and Locations are organized. This article maps Business Unit’s core concepts across all Fieldglass capability areas (Part 1), then details every field an administrator configures when creating and maintaining Business Unit records (Part 2).

Part 1: Business Unit — Core Concepts (All Modules)#

1.1 What Is the Business Unit?#

The Business Unit represents the internal organizational or cost-reporting entity that owns a requisition — a department, division, or budget-holding group — independent of where the work physically happens. It is created after Site in the Phase 1 Company Structure setup sequence (Site must already exist because a new Business Unit’s Site ID field requires a resolvable Site to reference), but it does not sit organizationally underneath Site: Business Unit is its own Tenant-level branch, with Site attached only as a reference field, not a parent.

1.2 Business Unit Scope Dimensions#

Like Site, Business Unit does not carry a formal “Business Unit Type” field — its influence shows up as a set of downstream scope dimensions inherited by every requisition raised under it. Modeling the Business Unit hierarchy incorrectly at design time (e.g., flattening what should be a multi-level cost roll-up, or conflating it with Site’s location scope) is a common source of GL-posting and reporting rework after go-live.

Design principle: Model the Business Unit hierarchy around how the business wants to see consolidated spend reporting, not around physical location — that grouping belongs to Site, and conflating the two forces a redesign of one or the other once reporting requirements diverge.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Tenant "WorkingNet" (client-level scope)
│
├── Business Unit "BU-ENG" — Network Engineering  ◄── this article
│      └── Business Unit "BU-NETDESIGN" — Network Design (child of BU-ENG)
│
├── Cost Center "CC-1001" — flat financial-tracking master (not hierarchical)
│
└── Site "SITE-CHI" — Chicago, US
       └── Location "LOC-CHI-01" — Chicago HQ Floor 3

Business Unit sits directly under the Tenant, as a sibling of Site and Cost Center — not nested inside either of them, and neither of them nested inside it. Business Unit is the only hierarchical object in this zone: it can have child Business Units, as shown by BU-NETDESIGN under BU-ENG, letting spend roll up through an arbitrary number of levels for consolidated reporting. Cost Center, by contrast, is a flat, non-hierarchical financial-tracking master; and Site’s own hierarchy runs downward into Location, not into Business Unit.

Two objects reference Business Unit without being its organizational children. Business Unit itself carries a Site ID field to associate a requisitioning organization with a physical work location (an assignment, expressed as a reference field rather than nesting — see Section 1.2); and Cost Center (FG-A02-04) requires an existing, active Business Unit before it can be created, referencing it via its own Business Unit ID field for budget roll-up — again an assignment, not an organizational child. Neither Site nor Cost Center is drawn underneath Business Unit in this landscape, because neither is contained by it.

1.4 Integration with Other Master Data Objects#

The Business Unit record does not stand alone — it is the cost-reporting anchor that one downstream Phase 1 object, one self-reference, and one external system all point to.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

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

2.1 Basic Identification & Site Assignment#

These fields uniquely identify a Business Unit and establish which Site it is paired with before any child Cost Center or downstream reference can be configured against it.

2.2 Hierarchy Configuration#

This is the field that gives Business Unit its own multi-level structure, independent of Site and Location — the only Company Structure object modeled this way.

2.3 GL Account & Cost Allocation#

These fields determine how spend raised under this Business Unit posts financially and, where used, how it is split across multiple cost objects.

Prerequisite: Site must exist before a Business Unit’s Site ID assignment field can be populated; Business Unit must exist and be Active before Cost Center (FG-A02-04) can reference it.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction