JinJin48

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

July 8, 2026 · 9 min read

SAP Fieldglass Rate Category

The Rate Category is the foundational master data object in SAP Fieldglass’s Rate Structure — the first configuration decision made in Phase 3, before a single Rate, Rate Grid, or Rate Card can be built. It classifies pay/bill rates by Rate Type (Hourly, Daily, or Monthly) and fixes the Unit of Measure and Currency that every child rate record inherits at creation and can never override. This article first covers the concepts that apply across every Fieldglass process area that touches rates — Contingent Labor, Services Procurement (SOW), and Job Posting — then moves into the field-level detail Fieldglass Administrators configure when setting up a Rate Category.

Part 1: Rate Category — Core Concepts (All Modules)#

1.1 What Is the Rate Category?#

The Rate Category is a classification master that groups pay/bill rates by a common Rate Type, Unit of Measure, and Currency. It does not itself hold a price — the price lives one level down, on the Rate or Rate Grid — but every downstream rate record depends on the Rate Category for its basic denomination. Getting the Rate Category design right up front (how many categories, split by what dimension) shapes how easy rate governance is for the life of the tenant.

1.2 Rate Type Variants#

The Rate Type is the single most consequential attribute on a Rate Category — it determines the cadence at which every downstream Rate value is expressed, and it cannot be changed once Rates exist beneath the category. Picking the wrong Rate Type for a worker population forces a full rebuild of the Rate, Rate Grid, and any Rate Cards or Worker Roles already pointing at it.

Design principle: A Rate Category bundles Rate Type + Unit of Measure + Currency as one indivisible unit. Since every child Rate, Rate Grid, and Rate Card inherits all three at creation and none can be overridden downstream, changing any one of them after Rates have been built requires creating a new Rate Category rather than editing the existing one.

1.3 Organizational Levels and Data Hierarchy#

Zone C — Rate Structure (this object’s own zone): Rate Category sits at the top of the Rate Structure zone, branching into a flat Rate on one side and a supplier/site-varying Rate Grid on the other.

Zone D — Job Posting · SOW · MSP: Worker Role carries an inbound ↗ RC-STD reference chip back to this Rate Category, since a Worker Role’s Rate Structure is inherited from the Rate Category at creation time and cannot be changed later.

Data hierarchy with a concrete example

Rate Category "RC-STD" — Standard Bill Rate
   │
   ├── Rate "R-STD-01" — $85/hr, uniform rate across all suppliers/sites
   │      │
   │      └── Rate Card "RCARD-2026" — active rate schedule
   │
   └── Rate Grid "RG-SUP-01" — varies by supplier/site
          │      ── assigned to ──> Site "SITE-CHI" (Chicago, US)
          │
          └── Rate Schedule "RS-SHIFT-01" — shift + applicable rate

Referenced by (Zone D — Job Posting / SOW):
   Worker Role "WR-DEV-01" ── inherits Rate Structure from ──> Rate Category "RC-STD"

Coexistence note: Rates 1.0 and Rates 2.0 (the Rate Category → Rate/Rate Grid → Rate Card/Rate Schedule structure shown above) can coexist at the tenant level, but each individual Job Posting Template or SOW Worker Role is built on only one of the two — never a mix.

1.4 Integration with Other Master Data Objects#

The Rate Category does not stand alone — it is the point every rate-carrying object in Fieldglass ultimately traces back to, whether directly or through one intermediate layer.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

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

2.1 Basic Identification#

Basic Identification carries the fields that give the Rate Category its name and lifecycle state — the attributes a Fieldglass Administrator sees first in every dropdown and list view.

2.2 Rate Type & Currency Configuration#

This is the operational core of the Rate Category — the three attributes every downstream Rate, Rate Grid, and Rate Card inherits and can never override, so they must be right before any child record is built.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction