The Bonus Approved on the 28th, the Double-Paid Leaver, and the Overtime That Sums to Zero
A 2,200-employee group runs Employee Central to Employee Central Payroll, monthly, with nightly replication. Recurring salary comes from Job Information pay components. Spot bonuses are captured on a custom MDF object, approved by workflow, and expected to be paid in the month of approval. Last month: a 1,500 bonus approved on the 28th was not paid; a leaver terminated effective the 15th was paid a full month and then paid again in the following period; and a report of overtime hours reconciles to exactly zero for one legal entity while the other three look correct. Payroll ran on the 29th. The integration logs show successful completions for every night of the month.
1. Trace the missing bonus end to end. Where are the plausible break points, and how do you distinguish between them?
Read the worked answer
A successful integration log only proves the run completed; it says nothing about whether the record was in scope. Break points to test, in order:
- Approval timing versus the payroll cut-off. Approved on the 28th, payroll on the 29th - the question is whether the record's effective date falls in the period being paid or the next one. A record approved on the 28th but effective the 1st of the following month is correctly unpaid this period. Check the effective date first; it resolves most of these.
- Was the record in the replication scope at all? Custom MDF objects are not replicated unless they are included in the integration's object selection/extension scenario. A record can be perfectly approved and still invisible to payroll.
- Mapping to a payroll pay component. The object must resolve to a pay component that exists in payroll with a valid mapping; an unmapped or inactive pay component silently drops the line.
- Was the record replicated before or after the payroll extraction? Nightly replication on the 28th does not help if the approval completed at 23:50 after that night's run.
Distinguishing them is mechanical: pull the object record's approval timestamp, effective date and replication status; compare with the payroll input file for that employee. Presence in payroll input with no payment = mapping or pay component issue. Absence from payroll input = scope, timing, or replication issue.
2. The leaver was paid a full month and then paid again. Reconstruct the most likely mechanism and specify the checks that would confirm it.
Read the worked answer
Double payment of a leaver is almost always a master-data end-dating problem, not an integration failure. The integration faithfully replicated what it was told.
Most likely mechanism: the termination was recorded on the employment or Job Information record, but one of the paying records was left open. The usual suspects:
- The recurring pay component on the Job Information record has no end date matching the termination, so it continues to generate in payroll.
- The termination was entered with an effective date that landed in the next payroll period, either by mistake or because the workflow completed after the current period's cut-off, so the current period paid in full and the next period processed the final pay plus the proration.
Checks to confirm:
- Compare the termination effective date on the employment record against the date on the Job Information record and on the pay component - all three should be consistent.
- Confirm the replication status of the termination to payroll, and whether payroll received it before the period it was paid.
- Inspect the payroll input for both periods to see whether the second payment is a genuine second recurring payment or a final settlement.
Recovery is a payroll-side correction (off-cycle or adjustment) coordinated with the replication fix; do not simply end-date the record now and assume the overpayment resolves itself.
3. Overtime hours total zero for one legal entity. What class of cause fits that signature, and how do you verify it?
Read the worked answer
Exactly zero - not low, not slightly off - is the signature of an absence of data rather than a calculation error. A calculation error produces a number that is wrong; a filter or scope error produces nothing.
Candidate causes for one entity only:
- Overtime is captured via time recording or time valuation rather than Time Off, and that entity's employees or work schedules are not configured for the recording mechanism - so no hours exist to report.
- The overtime pay component or time type exists in three entities but was never enabled or mapped for the fourth - new entities frequently inherit employee data but not the time configuration.
- The report's filter (legal entity, pay group, or employee status) excludes that population, for example because the entity was added to the filter as a new value that does not match the stored value.
Verification: run the same report with all filters removed and check whether any row appears for that entity at all. If no rows, go upstream to the raw time records for a sample of 10 employees and confirm whether overtime exists at source. That single test separates 'not captured' from 'not reported' and tells you whether the fix is time configuration or report configuration.