Time Evaluation Not Generating Expected Quota

An employee reports their leave balance is zero, lower than colleagues in the same role, or simply not there when they open the time off request screen. Time administration hears the same thing phrased as 'the quota did not generate this month' or 'last year it generated ten days, this year nothing came through after the transfer'. Payroll or time admin re-runs the evaluation and gets the same result, so it gets escalated as 'time evaluation is not creating the quota'. Sometimes the complaint is the opposite: a quota record exists but the number is wrong, usually too high or too low compared to what HR believes the policy entitles the employee to. The pattern that should raise suspicion immediately is a recent transfer, a leave return, a new hire whose probation just ended, or a mid-year change to a time type or accrual rule.

Run PT60 for the affected employee with the exact period in question and pull the quota generation section of the log, which states the rule group and rule used. Cross-check that rule group against the generation table entry for the employee's current subarea and subgroup combination. Pull the absence quota infotype history for the employee and compare validity periods against the payroll status earliest recalculation date to see whether a gap or an unprocessed retro period explains the missing entitlement.

If the grouping feature returns the wrong rule because the employee's org data changed correctly and the rule genuinely does not exist for the new grouping, that is a configuration gap and needs a new or extended entitlement rule moved through transport, not a one-off data fix. If the grouping is correct but the org data itself was updated late or wrong, correct the infotype and force a retroactive recalculation from before the change, which is a data fix. If the rule exists but its validity period has a gap, extend the rule validity in customizing and transport it, then rerun time evaluation for the affected employees for the missing periods. If the employee was excluded from time evaluation by their time management status, correct that infotype record and rerun; this is master data. If Employee Central shows the accrual but the on-premise or ECP side never received it, fix the replication and re-trigger the transfer rather than manually creating the quota record. Always rerun the generation report or PT60 after any fix rather than trusting a single manual quota entry to stay consistent with the next scheduled run.

The common reflex is to open the absence quota infotype and manually type in the entitlement number the employee is supposed to have, or to re-run the quota generation report repeatedly hoping a different result appears. Manually entering the value hides the underlying grouping or rule gap, and the next scheduled generation run either duplicates the entry, overwrites it silently, or throws a delimitation conflict because the system now sees two competing records for the same period. It also removes the audit trail that shows the entitlement was policy-driven rather than typed in by a support analyst.

Time Management configuration owns the generation rule and grouping feature; time administration or HR operations owns the underlying master data (time management status, org assignment, accrual rule assignment in Employee Central). The handover note should state the employee ID, the period affected, the rule or accrual rule name involved, whether the fix was a rerun of generation, a retro trigger, or a configuration change, and confirmation that the fix was verified by a follow-up evaluation run rather than a manual quota entry.