JinJin48

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

July 6, 2026 · 15 min read

SAP Service Warranty Master

The Warranty Master is a reusable master record that defines a warranty’s determination rule (date-based, counter-based, or combined), its covered scope of Service Products and parts, and — since S/4HANA 2023 FPS3 — the accounting indicator that governs how covered repair costs are absorbed. It is not itself a claim or a transaction: it is the standing definition that the system reads automatically the moment a Service Notification or Service Order is created against a covered Equipment, to determine whether the work is billable to the customer or falls under warranty coverage. This is the fifth and final Phase of the Service master data setup, sitting directly downstream of two prerequisites established earlier — the Service Product master (Phase 2) that defines what is covered, and the Equipment master (Phase 3) that the warranty ultimately protects — and it is the only object in Phase 5. This article first covers the warranty concept in general terms (Part 1), then the Service-specific coverage, counter, and claim-entitlement field detail (Part 2).

Part 1: Warranty Master — Core Concepts (All Modules)#

1.1 What Is the Warranty Master?#

A warranty, in the general sense, is a standing promise that certain repair or replacement work will not be billed to the customer within a defined validity window and scope. SAP models this as a master record rather than a one-off note on a sales document, precisely because the same warranty terms typically apply across many pieces of equipment or many units of the same product, and because the check against that promise has to happen automatically and consistently every time a claim is raised — not be re-decided by a service agent case by case.

1.2 Warranty Determination Rule Types#

The most consequential design decision on a Warranty Master is which determination rule governs when it expires, because this decides both what data the warranty depends on to be checked correctly and what happens the day that data stops being reliable. Choosing a counter-based rule for equipment whose usage is never actually measured produces a warranty that can never be evaluated with confidence at claim time.

Design principle: Match the rule type to how the covered product is actually measured in the field, not to how the commercial team would prefer to word the promise — a Combined rule maintained against an Equipment whose counter is never updated silently degrades to a date-only check, and nobody will notice until a claim is wrongly approved or wrongly rejected.

1.3 Organizational Levels and Data Hierarchy#

Zone C — Technical Object Reference (Plant-Level). The Equipment that this Warranty Master ultimately protects lives at the plant level; its warranty assignment is drawn as the cross-zone reference chip on the Equipment card, pointing to the Warranty Master’s own node in Zone D below.

Zone D — Service Product & Template (Client-Level). The Warranty Master itself is a client-level record, defined independently of any specific plant, and its own “covers” relationship points to the Service Product whose service scope it applies to.

Data hierarchy with a concrete example

Client 100
   │
   ├── Material Master "SRV-001" (Type DIEN · UoM H)
   │      └── ── based on ──> Service Product "SRV-PM-01" (Preventive · UoM H)
   │
   ├── Warranty Master "WTY-001" (BGM1 · Combined Rule: 1yr / 8,000H)   ← this article's object
   │      └── ── covers ──> Service Product "SRV-PM-01"
   │
   └── Company Code 1000
          └── Plant 1000
                 └── Functional Location "FL-BLDG-01" — HQ Bldg. 1F, Cat. M
                        └── Equipment "EQ-10001" — Air Conditioner A
                               ├── ── assigned to ──> Warranty Master "WTY-001"
                               ├── Sub-Equipment "EQ-10001-A" — Compressor Unit
                               └── Sub-Equipment "EQ-10001-B" — Fan Unit

Design principle: A Warranty Master’s own record never sits under Plant or Equipment — it is always a client-level definition; only the assignment of that warranty to a specific Equipment (or, since 2023 FPS3, to a Material/equipment-category) is what varies by organizational scope, and that assignment is always modeled as a reference, never as containment.

1.4 Integration with Other Master Data Objects#

The Warranty Master does not stand alone — it is the convergence point that Equipment references for coverage and that Service Notification/Order processing reads automatically at claim time.

Part 2: Service-Specific Field Details#

2.0 Scope of Service Ownership#

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

2.1 Warranty Header & Validity Rule#

Warranty Header & Validity Rule fields identify the warranty itself and set the single default that governs how — and against what — its expiration is evaluated.

2.2 Warranty Counter Definition#

Warranty Counter Definition fields apply whenever the Rule Type from 2.1 is Counter-based or Combined, and determine what usage measurement the claim-entitlement check actually reads.

2.3 Service Coverage & Object List#

Service Coverage & Object List fields define exactly what falls inside the warranty’s promise, which is what a service agent or the automated entitlement check reads to decide whether a specific claimed item is covered.

2.4 Warranty Check Rule & Claim Entitlement#

Warranty Check Rule & Claim Entitlement fields govern how the automated coverage decision is actually made and applied the moment a claim is raised (see SRV-B06 Warranty Claim Process).

2.5 Accounting Indicator & Cost Assignment#

Accounting Indicator & Cost Assignment fields determine what happens financially once a claim has been determined to be covered — this is the section with the most direct downstream FI/CO impact.

What to Read Next#

L1) Big Picture

L2-A) Master Data