JinJin48

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

July 6, 2026 · 11 min read

SAP Service Bill of Material

The Bill of Material (BOM) is the structured, itemized list of spare-part components attached directly to a specific Equipment record — or, less commonly, to a Functional Location — that Service Order and Maintenance Order planning explodes to reserve, procure, and consume parts during a repair. It is distinct from the classic Material BOM used in Production Planning and Engineering: this Equipment BOM is anchored to one physical asset rather than shared across manufactured products, and it never exists as an independent master — a BOM is meaningless without the specific Equipment (or Functional Location) it belongs to. It is the third and final of three Technical Object masters in Phase 3 of the Service master data setup (Functional Location → Equipment → Bill of Material), and it is the object that determines exactly which spare parts a Service Order proposes when a technician is dispatched to repair a given asset. This article maps its position among SAP’s BOM category types, its organizational hierarchy, its integration with the surrounding masters, and the Service-specific field-level detail consultants must configure.

Part 1: Bill of Material — Core Concepts (All Modules)#

1.1 What Is the Bill of Material?#

A Bill of Material is a structured, itemized list defining what components make up a higher-level object. In general SAP terms this higher-level object can be a manufactured product (Material BOM), a piece of technical equipment (Equipment BOM), or a fixed technical position (Functional Location BOM) — but the underlying structure is always the same shape: one header record identifying the object the structure belongs to, and one or more item records naming each component, its quantity, and how it is procured or consumed.

1.2 BOM Categories#

SAP’s BOM categories share the same underlying header/item structure (STKO/STPO) but differ in which object they attach to and how that assignment is stored. Getting this distinction right at blueprint matters because Equipment BOM and Material BOM are maintained by different teams, through different transactions, and serve entirely different planning processes — confusing the two leads to spare-part structure being built against the wrong object.

Design principle: Model spare-part structure at the Equipment level whenever the physical asset itself is individually tracked — reserve Functional Location BOM only for genuinely asset-agnostic, location-fixed components, since attaching structure to the wrong object level makes it invisible to the planning process that actually needs it.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Client 100
   │
   FUNCTIONAL LOCATION "FL-BLDG-01" — HQ Bldg. 1F, Category M
   │
   ↓  (Equipment installed at this Functional Location)
   EQUIPMENT (parent) "EQ-10001" — Air Conditioner A, Plant 1000
   │      Warranty ── assigned to ──> Warranty Master "WTY-001" (Zone D — reference, via Equipment, not owned by BOM)
   │
   ├── EQUIPMENT (sub) "EQ-10001-A" — Compressor Unit
   │      └── BOM ITEM "10 · Filter x2" — on EQ-10001-A                    ← this article's object
   │             └── references ──> Material "SP-FILTER-01" (Zone D — Spare Part Material Master)
   │
   └── EQUIPMENT (sub) "EQ-10001-B" — Fan Unit
          └── BOM ITEM "10 · Fan Blade" — on EQ-10001-B                    ← this article's object
                 (no spare-part reference)

Design principle: A BOM Item belongs to exactly one Equipment record — it is never a shared, floating structure the way a Material BOM can be. Track and version BOM changes against the specific Equipment (or sub-equipment) they apply to, not against whichever Functional Location that Equipment happens to be installed at.

1.4 Integration with Other Master Data Objects#

The Bill of Material does not stand alone — it is the structure that ties a physical asset to the procurable/stocked parts a technician needs, and the object that a Service Order reads at the moment components must be planned.

Part 2: Service-Specific Field Details#

2.0 Scope of Service Ownership#

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

2.1 BOM Header & Assignment#

BOM Header & Assignment data identifies which object the BOM belongs to and the organizational scope its item-level spare parts are read against.

2.2 BOM Item / Component Data#

BOM Item / Component Data is the actual parts list — each row names one component, how much of it is needed, and how it is procured or consumed.

2.3 Service Order Component Assignment#

Service Order Component Assignment is where the BOM stops being a static list and becomes the actual parts plan for one dispatched job — this is the data Service consultants configure and validate first.

What to Read Next#

L1) Big Picture

L2-A) Master Data