JinJin48

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

July 19, 2026 · 14 min read

SAP SF Time Type

Time Type is the master data object that defines a category of leave or absence — annual leave, sick leave, unpaid leave, and similar — as a reusable label with no accrual logic of its own; Time Account Type is the child object that attaches to a Time Type and carries the actual grant, consumption, and carryover rules that make the category operational. Together they form the third of three parallel, independent chains in the Time Configuration group of Phase 2 (Permission & System Configuration): where Holiday Calendar → Work Schedule (SF-A03-03/04) defines when employees are expected to work, Time Type → Time Account Type defines what kinds of time away from work exist and how much of each an employee accrues. This article covers what a Time Type and Time Account Type are, their leave-category behaviors (accruing vs. non-accruing, paid vs. unpaid, carryover-eligible vs. not), how they sit alongside the parallel Permission Management and Holiday Calendar/Work Schedule chains in the same landscape zone, and every field an Admin Center consultant configures for both objects.

Part 1: Time Type — Core Concepts (All Modules)#

1.1 What Is the Time Type?#

Time Type is a client-level configuration object that carries no accrual or consumption logic of its own — it simply establishes a named category of absence (e.g. “Annual Leave,” “Sick Leave”) and a small set of category-defining flags (paid vs. unpaid, whether the category counts against attendance). Its value comes from being the parent that one or more Time Account Type records attach to: each Time Account Type inherits its category identity from a Time Type and then adds the concrete accrual amount, frequency, and carryover ceiling that a Time Profile ultimately bundles for employee assignment.

1.2 Time Type / Time Account Type Category Behaviors#

Not every absence category behaves the same way once accrual rules are attached, and modeling a non-accruing category as if it accrues — or vice versa — is a routine cause of Time Off balance discrepancies that surface as employee escalations rather than build-time errors.

Design principle: define the category behavior (paid/unpaid, accruing/non-accruing, carryover-eligible or not) once at the Time Type level so every Time Account Type built under it inherits a consistent policy intent — mixing conflicting accrual logic under a single Time Type produces confusing category semantics for anyone auditing the leave taxonomy later.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Time Type sits in the same tenant-level “Permission & Time” zone of the SuccessFactors Master Data Landscape as Permission Group / Permission Role (SF-A03-01/02) and Holiday Calendar / Work Schedule (SF-A03-03/04) — one of three parallel, independent client-level configuration chains bundled into that zone (Permission Management; Holiday Calendar → Work Schedule; Time Type → Time Account Type, tied together by Time Profile). This article’s own objects are the third chain; the other two chains exist in the same landscape zone but belong to sibling articles:

Client (SuccessFactors Instance)
   │
   ├── Permission Group "PG_Manager" — Managers, Direct Reports  (see SF-A03-01)
   │      │
   │      └── Permission Role "PR_ESS" — Employee Self-Service, of PG_Manager  (see SF-A03-02)
   │
   ├── Holiday Calendar "HC_JP2024" — Japan 2024, 16 holidays  (see SF-A03-03)
   │      │
   │      └── Work Schedule "WS_JP_Std" — JP Standard, 40H/week, of HC_JP2024  (see SF-A03-04)
   │
   └── Time Type "TT_Annual" — Annual Leave, category
          │
          └── Time Account Type "TAT_Annual" — 20 days, 5-day carryover, of TT_Annual

Time Profile "TP_JP_Std" — JP Standard, Work Schedule + Time Account Type bundle  (see SF-A03-06)
   ├── assigned to ──> Work Schedule "WS_JP_Std"
   └── assigned to ──> Time Account Type "TAT_Annual"

MANDATORY landscape verification note: the module Master.md’s Hierarchy Structure lists Time Type as the direct parent of Time Account Type (“Level 7: Time Type └── Time Account Type”), and the ER Diagram draws it as a 1:N relationship — a single Time Type (e.g. “Annual Leave” as a category) can have multiple Time Account Type records attached where accrual rules differ by population (e.g. a different annual grant amount for a specific country or employee tier under the same leave category), never the reverse. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html, Zone C) draws this as a single solid parent-child connector — TT_Annual → TAT_Annual — representing one instance of that 1:N relationship. On the downstream side, the ER Diagram shows Time Profile ←── Time Account Type, and the landscape renders this as the purple dashed “assigned to” arrow running from TP_JP_Std into TAT_Annual (verb “uses”) — Time Profile references a Time Account Type directly, never Time Type itself. See Section 1.4 and 2.4 for how this two-level structure plays out in practice.

Design principle: Time Type itself carries no organizational sub-levels — it is a flat category label. All of the structural depth in this data picture lives one level down, in the Time Type → Time Account Type parent-child relationship, and one level further down still in each Time Account Type’s own accrual field configuration (Part 2).

1.4 Integration with Other Master Data Objects#

Time Type’s category label only becomes operational once a Time Account Type attaches accrual rules to it, and that Time Account Type in turn only reaches an employee once bundled into a Time Profile.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

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

2.1 Time Type Definition (Core Identification)#

Time Type Definition is the minimum record a Time Type needs to exist — it is what every Time Account Type’s parent-category reference, and every reference to the category elsewhere in the system, resolves back to.

2.2 Category Behavior Flags#

Category Behavior Flags determine how a leave category is treated by payroll and attendance calculations, and are the field group that drives the accruing/non-accruing and paid/unpaid distinctions introduced in Section 1.2.

2.3 Time Account Type Definition#

Time Account Type Definition is the child object that turns a Time Type category into something a Time Profile can actually bundle — every Time Profile’s account-type picker (SF-A03-06) resolves to a Time Account Type, never to a Time Type directly.

2.4 Accrual and Carryover Rules#

Accrual and Carryover Rules are the actual payload of a Time Account Type — the concrete numbers that Time Off reads to calculate an employee’s real balance. Everything in Sections 2.1–2.3 exists to organize and identify these rules; this is the data that determines what happens in an employee’s leave request.

Prerequisite: because Grant Amount and Carryover Ceiling directly drive payroll and Time Off balance calculations, changes to an existing Time Account Type already referenced by active Time Profiles and employee assignments should be treated as effective-dated, payroll-impacting configuration changes — review and communicate before applying, not after.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction