JinJin48

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

July 6, 2026 · 12 min read

SAP Service Service Contract Template

The Service Contract Template is a reusable master record that pre-configures the item structure, billing plan defaults, and price agreement type a Service Contract needs — it is not itself a live contract with a customer, but the standardized pattern that a Service Manager builds once and re-uses every time a new, similar contract must be created. It is distinct from an individual Service Contract instance: the instance carries a specific customer, specific equipment, and a specific validity period, while the template carries only the defaults that make creating that instance fast and consistent. This is the first of two Phase 4 “Service Templates” objects in the Service master data setup (Service Contract Template and Service Order Template), and it sits directly downstream of the Service Product and Pricing Condition masters already defined in Phase 2. This article first covers the template concept in general terms (Part 1), then the Service-specific billing plan, price agreement, and renewal-rule field detail (Part 2).

Part 1: Service Contract Template — Core Concepts (All Modules)#

1.1 What Is the Service Contract Template?#

A template, in the general SAP sense, is a master record that captures a repeatable pattern of defaults so that a downstream transaction does not have to be configured line-by-line every time it is created. The Service Contract Template applies this idea to Service Contract Management: instead of a Service Manager re-entering the item category, billing frequency, and price agreement type on every new contract, the template stores these once and the contract-creation process copies them in as a starting point that can still be adjusted for the specific customer.

1.2 Item Category (Contract Billing Method) Variants#

The template’s most consequential default is its Item Category, because this single setting determines how the resulting contract bills the customer — as a fixed periodic charge, an escalating multi-year rate, usage-triggered billing, or a capped quantity/value ceiling. Picking the wrong default at template design time means every contract created from it inherits the wrong billing behavior until someone notices and corrects it manually.

Design principle: The template should pre-select exactly one Item Category as its default. Mixing billing methods within a single template defeats the purpose of standardization — create a separate template per Item Category instead of one template with manual overrides for every contract.

1.3 Organizational Levels and Data Hierarchy#

The diagram above crops Zone D — Service Product & Template (Client-Level) from the Service module’s Master Data Landscape. The Service Contract Template has no plant-level or organizational scoping of its own — it is a client-level pattern built directly from the Service Product and Pricing Condition masters that already exist in the same zone.

Data hierarchy with a concrete example

Client 100
   │
   Material Master "SRV-001" (Type DIEN · UoM H)
      │
      └── ── Service Product is based on ──> Service Product "SRV-PM-01"
                                             (Preventive Maintenance · UoM H)

   Service Product "SRV-PM-01"
      │
      └── ── Contract Template is derived from Service Product ──>
                                     Service Contract Template "SCT-001"   ← this article's object
                                     Item Cat. SCN · Billing Plan: Monthly

   Pricing Condition "PR00" (JPY 15,000 / H)
      │
      └── ── Contract Template inherits pricing from Pricing Condition ──>
                                     Service Contract Template "SCT-001"

   Service Product "SRV-PM-01"
      │
      └── ── Order Template is derived from Service Product ──>
                                     Service Order Template "SOT-001"
                                     Inspection · Planned Duration 4H (sibling Phase 4 template)

Design principle: A Service Contract Template gets its item defaults from a Service Product and its price defaults from a Pricing Condition — always confirm both upstream masters are finalized and released before the template is created, or the template will need rework the moment either upstream master changes.

1.4 Integration with Other Master Data Objects#

The Service Contract Template does not stand alone — it is the convergence point of the Service Product and Pricing Condition masters, and the starting point for every Service Contract instance created from it.

Part 2: Service-Specific Field Details#

2.0 Scope of Service Ownership#

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

2.1 Template Header & Item Category Defaults#

Template Header & Item Category Defaults identify the template itself and set the single default that governs how every contract created from it will bill.

2.2 Object List Defaults#

Object List Defaults determine which kind of technical object — Equipment or Functional Location — a contract created from this template is expected to cover, and how many.

2.3 Billing Plan Defaults#

Billing Plan Defaults are copied directly into a new contract’s own Billing Plan and are what FI ultimately reads to generate periodic billing documents — this is the section with the most direct downstream financial impact.

2.4 Price Agreement & Renewal Rules#

Price Agreement & Renewal Rules govern how the contract’s price behaves over a multi-year term and what happens automatically when the contract approaches its validity end date.

What to Read Next#

L1) Big Picture

L2-A) Master Data