T549Q table — Generated Payroll Periods Table
T549Q stores the generated payroll periods for a period modifier: for a given period parameter, payroll year and period number it holds the actual start and end date of that period. Payroll areas do not own their own rows here; several payroll areas sharing the same period modifier read the same generated calendar from this table.
T549Q holds the calendar of generated payroll periods, keyed by period modifier, payroll year and period number, with the start and end date of each period. It is the table payroll and time evaluation actually read to know where one period ends and the next begins, and it must be pre-generated for future years before payroll or time evaluation can run against them.
Published 15 Sept 2026· 1,072 words
What it stores
One row represents a single generated payroll period belonging to a specific period modifier and payroll year: its sequential period number and its exact start and end date. Period modifiers group payroll areas that share the same period rhythm (monthly, weekly, four-weekly, and so on), so this table is not maintained per payroll area but per modifier. Rows are created in bulk by a periodic generation step, usually run years ahead so that payroll, time evaluation and any process depending on period boundaries can resolve dates without a config gap. Because the rows are generated rather than entered one at a time, the table is effectively a materialized calendar: correct only as far ahead as someone has run the generation, and silent (missing rows, not an error message) if nobody has extended it into the next year.
Key fields
- MANDT - client
- PERMO - period modifier, the grouping key shared by all payroll areas that follow the same period calendar
- PABRJ - payroll year the period belongs to
- PABRP - payroll period number within that year, meaning depends on the modifier's rhythm (monthly, weekly, etc.)
- BEGDA - start date of the generated period
- ENDDA - end date of the generated period
How it joins the data model
- PA0001-ABKRS resolves to a payroll area, whose period modifier is looked up in the payroll area customizing (period modifier assignment), and that PERMO is then used to select T549Q-PERMO
- T549Q-PERMO / PABRJ / PABRP together give BEGDA and ENDDA, the period boundaries time evaluation uses when reading TEVEN entries for accumulation and clock-time evaluation within a period
- Wage type valuation logic in T512W uses the period boundaries from T549Q to decide which validity slice of a valuation rule applies for a given payroll period
- PA0007-derived planned working time is evaluated inside the BEGDA/ENDDA window taken from T549Q for whichever period is currently being processed
How to read it safely
Always restrict by client and by PERMO first. The table holds decades of periods across every period modifier in the system, and browsing without a modifier mixes monthly, weekly and other rhythms in one result set with no obvious way to tell them apart except by row count per year. After PERMO, narrow by PABRJ, then PABRP if a specific period is being checked. Do not select on BEGDA or ENDDA alone to find a period: date ranges from different modifiers overlap freely, and a date-range scan across the whole table returns candidates from unrelated payroll areas that happen to share a calendar date.
How to prove it in the data
Symptom: payroll or time evaluation for period 09/2024 fails with a period-not-found style error, or the run picks up dates that look wrong for that period. First find the payroll area's period modifier in the payroll area customizing. Then select T549Q with that PERMO, PABRJ = 2024, PABRP = 09. If the row is missing, periods have not been generated far enough forward. If the row exists, compare its BEGDA/ENDDA against the adjacent periods (08/2024 and 10/2024) for a gap or overlap.
ECC vs S/4HANA
T549Q is a customizing/generation table, not a transactional master data table, and it carries over into S/4HANA unchanged in shape and purpose. It is not typically exposed through a CDS compatibility view because period generation is an internal payroll engine mechanism rather than a reporting object. In an Employee Central Payroll setup alongside SuccessFactors, period generation still happens in the payroll back end on this same table; SuccessFactors Employee Central itself does not generate or store payroll periods.
Common pitfalls
- Assuming PABRP is always a calendar month number: a period modifier configured for weekly or four-weekly periods runs PABRP up to 52, 53 or another count unrelated to months, so 'period 9' does not mean September for that modifier.
- Treating a missing row as an impossible state rather than a generation gap: rows for future years must be generated in advance by a periodic run, and payroll for a future period will error out with a period-determination failure until that run has been executed, not because of a master data problem.
- Editing BEGDA or ENDDA directly in this table to correct a perceived wrong date: the same boundaries are referenced by cumulation logic, adjacent periods, and any payroll results already posted for that period, so a manual change can create an overlap or gap with the neighbouring period and corrupt retroactive accounting silently.
- Assuming a payroll area's period rhythm is defined inside T549Q itself: it is not. T549Q only stores the generated dates for a period modifier; the assignment of a payroll area to a modifier lives in separate payroll area customizing, and several payroll areas can point at the same PERMO and therefore the same rows here.
- Assuming PABRJ always matches the calendar year printed in BEGDA/ENDDA: near a year boundary, a period can straddle two calendar years while still being filed under one PABRJ, so filtering only by calendar year on the date fields can miss the row a consultant is actually looking for.
Whose problem this is
Payroll configuration or time management consultants own period modifier design and the generation runs that populate this table, and generation ahead of year-end is normally a scheduled configuration task, not an ad hoc fix. A functional payroll lead should sign off before periods are regenerated or extended, since payroll areas across the organisation may share a modifier. HR administrators should never edit rows here directly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t549qERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.