JinJin48

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

July 19, 2026 · 11 min read

SAP SF Pay Grade

Pay Grade is the master data object that defines a compensation band — a salary range with a minimum, midpoint, and maximum — such as “Manager L1” or “Professional P2,” in the Job Structure Management area of SuccessFactors Employee Central. Unlike Job Family and Job Code, which classify what the work is, Pay Grade classifies what it pays, and the two dimensions are maintained as separate, independently configured objects rather than one feeding the other automatically. This article covers what Pay Grade is, how it actually connects (and does not connect) to the surrounding master data, and every field an Employee Central consultant configures for it.

Part 1: Pay Grade — Core Concepts (All Modules)#

1.1 What Is the Pay Grade?#

Pay Grade is a compensation-classification object — it does not describe job content the way Job Code does, and it does not represent an org placement the way Department does. It groups employees into a defined salary band so that base-pay decisions, market pricing, and pay-equity analysis can be evaluated against a consistent range rather than against each employee’s individual number in isolation.

1.2 Pay Grade Examples by Level#

Pay Grade is not selected from a fixed SAP-delivered list — like Job Family and Job Code, it is entirely client-defined. What does vary structurally is how many tiers a client builds and whether the same Pay Grade set applies uniformly, or whether each Pay Grade carries a different Pay Range per country (a global “Manager L1” Pay Grade with a JPY range for Japan and a separate USD range for the US, for example).

Design principle: Pay Grade names, codes, and range widths are entirely client-defined — decide the number of tiers and the country/currency scoping strategy once at blueprint. Adding or splitting tiers after go-live requires re-evaluating every Compensation Information record currently pointing at the affected grade, since Compa-Ratio calculations shift the moment a range boundary moves.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Client (SuccessFactors Instance)
   │
   └── Job Family "JF_Sales" — Sales family, Job group
          │
          └── Job Code "JC_SalesRep" — Sales Representative, of JF_Sales
                 │
                 └── Position "POS_SalesMgr01" — Sales Manager, seat
                        (Job & Pay Structure branch — no configured link to Pay Grade)

Pay Grade "PG_M1" — Manager L1, 6M-9M JPY
   (standalone Foundation Object in the Job & Pay Structure branch, positioned
    alongside Job Family/Job Code/Position — not a parent or child of any of them)

Employment "EMP_000001" (Employee Data branch, Zone E)
   │
   └── Compensation Information "CI_001" — Base Salary 7.5M JPY ── references ──> Pay Grade "PG_M1"

MANDATORY landscape verification note: the module Master.md’s ER Diagram describes a “Job Code — N:M — Pay Grade” relationship in prose. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html) draws Pay Grade as a standalone node in Zone B with no SVG connector to Job Family, Job Code, or Position — the same finding already confirmed from Job Code’s side in SF-A02-08. The only connector that actually touches the Pay Grade node in the landscape is the Zone E → Zone B reference chip on Compensation Information (↗ PG_M1). This article follows the landscape’s drawn topology rather than the source prose: Pay Grade is referenced directly only by Compensation Information at the employee-record level, not by Job Code.

Design principle: Pay Grade sits in the Job Structure Management branch as an independent node with no configured Foundation Object parent or child — separate from the Legal Entity → Business Unit → Division → Department → Cost Center organizational chain, from the Job Family → Job Code → Position chain in the same branch, and from the standalone Location master. The only system-drawn link touching Pay Grade runs from Compensation Information, a child record of Employment in the Employee Data branch — not from Job Code, Job Family, or Position.

1.4 Integration with Other Master Data Objects#

Pay Grade has the narrowest configured footprint of any object in the Job Structure Management branch — a single direct, system-drawn reference, with every other relationship a reader might expect (to Job Code, to Position) turning out to be a reporting-layer combination rather than a configured link.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

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

2.1 Core Identification#

Core Identification is the minimum record a Pay Grade needs to exist — it is what every Compensation Information record referencing it, and every Pay-Grade-filtered compensation report, resolves back to.

2.2 Pay Range Definition#

This is the section that gives Pay Grade its actual purpose — the salary band values that Compensation Information, Compa-Ratio calculations, and Compensation Template guideline logic all read from.

Prerequisite: Confirm with the client’s Compensation team whether Pay Range values are maintained per-country under a single Pay Grade or as fully separate Pay Grades per country before blueprint — this decision changes both the Pay Grade picklist size and how market-pricing reports segment results.

2.3 Status & Lifecycle#

Status and revision history govern whether a Pay Grade remains selectable and how past range values are preserved when a market adjustment updates the band.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction