SAP tableObjectT512WModuleHCM_SUCCESSFACTORS

T512W table — Wage Type Characteristics Table T512W

T512W stores the technical characteristics of a wage type for a given payroll country grouping and validity period: whether an amount, number, or rate can be entered, and which processing classes and evaluation classes are attached to it. It is the table payroll and time evaluation consult to decide how a wage type behaves, not what it is called or how much it pays.

T512W is the wage type characteristics table that drives how a wage type is processed technically rather than how it is named or valuated. This page covers its key fields, how it joins to infotypes and time evaluation output, and the diagnostic traps consultants fall into when a wage type behaves unexpectedly in payroll or in Employee Central Payroll replication.

Published 15 Sept 2026· 1,136 words

What it stores

One row in T512W represents the full set of technical characteristics assigned to a single wage type, for a single country grouping, valid for a specific date range. This includes the permissibility indicators that control whether the wage type can carry an amount, a number, or a percentage rate, the unit in which a number is expressed, and the processing class and evaluation class values that downstream payroll schemas and evaluation reports use to decide how to treat the wage type during gross-to-net processing, cumulation, and reporting. The table does not store amounts paid to employees and does not store the wage type description. It answers a purely technical question: given this wage type in this country, what is it allowed to do and how is it classified for schema logic. Changes here affect every employee for whom the wage type is used, not just one record.

Key fields

  • MOLGA - country grouping (payroll country indicator), part of the key because characteristics differ by country
  • LGART - the wage type code being described
  • BEGDA - start date from which this set of characteristics is valid
  • ENDDA - end date of validity, delimited when characteristics are changed rather than overwritten
  • Indicator fields controlling whether amount, number, or percentage entry is permitted for the wage type
  • Processing class value fields, one slot per processing class number, each holding the class value assigned to the wage type
  • Evaluation class value fields, one slot per evaluation class number, each holding the class value assigned to the wage type

How it joins the data model

  • T512W-LGART = PA0008-LGA01 (and the other wage type fields in basic pay) - basic pay entries are validated against the characteristics defined here
  • T512W-MOLGA derived indirectly from the employee's payroll area and country assignment on PA0001, since characteristics are country-grouping specific
  • T512W-LGART = TEVEN-LGART - wage types generated by time evaluation carry the same technical behaviour defined here when they enter payroll
  • T512W-LGART = PA2001-LGART - absence valuation rules that generate wage types rely on the entry permissibility flags stored here
  • T512W-LGART = T512T-LGART (plus MOLGA) for the wage type's descriptive text, joined separately since T512W has no text field

How to read it safely

T512W is client-independent in the sense that country grouping, not client, is the real segmentation to filter on first; always restrict by MOLGA before LGART, since the same wage type code can carry entirely different characteristics in different countries. Always check BEGDA/ENDDA against the pay period or event date in question, because characteristics are time-delimited and an old row can still be sitting in the table with an end date in the past. The table is not large in absolute terms compared to master data tables, so full scans by MOLGA are cheap, but selecting by processing class value requires scanning the specific slot field, which is not indexed, so restrict by LGART or MOLGA first and inspect the result set rather than searching by class value directly.

How to prove it in the data

Symptom: a wage type entered on basic pay is rejected with an entry not permitted style error, or a payroll result shows the wage type being cumulated into the wrong total. Selection: read T512W for the employee's MOLGA and the wage type in question, restricted to the date range covering the pay period, and check the amount/number/rate permissibility indicators and the relevant processing class slot value. If the indicator does not allow amount entry, or the processing class value does not match what the schema expects, the characteristics table, not the schema or the infotype, is the root cause.

ECC vs S/4HANA

T512W is unchanged in shape and continues to be maintained and read the same way on S/4HANA on-premise and in Employee Central Payroll, since core payroll schema logic still depends on processing class and evaluation class values stored per country grouping. There is no compatibility view replacing it because it remains an active configuration table rather than a transactional one. Consultants working across an SAP HCM to SuccessFactors Employee Central migration should expect this table to exist identically on both the legacy on-premise system and any Employee Central Payroll instance running the classic payroll engine.

Common pitfalls

  • Assuming a wage type behaves identically across countries because the code and description look the same; MOLGA-specific rows can carry completely different processing class values
  • Changing a processing class or evaluation class value directly in this table without checking who else reads that class number in custom schema logic; a class reused for a different purpose elsewhere breaks silently in unrelated payroll functions
  • Forgetting that a characteristics change only applies from the BEGDA forward; retroactive payroll periods before that date still use the old row, so a fix here does not retroactively repair already-run periods
  • Reading the table without restricting by date and picking up a delimited historical row, concluding the wage type has a characteristic it no longer has
  • Treating an entry-permissibility rejection on an infotype as a configuration bug in the infotype screen when the actual restriction is defined in T512W and inherited by the screen logic
  • In SuccessFactors Employee Central Payroll landscapes, assuming wage type characteristics are automatically consistent between the source HCM system and EC Payroll; replication does not always carry configuration changes made directly in this table, so mismatches surface as valuation or cumulation differences after go-live

Whose problem this is

This is payroll configuration territory, owned by the payroll or time management functional consultant, not basic data or integration teams. Any change request touching processing classes or evaluation classes should go through the person who owns the payroll schema, since a class value change here has direct downstream effect on schema logic that only that person can trace.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tables/t512wERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.