The promotion was entered in the HCM on 4 March, effective 1 March. February payroll was calculated on 20 February and paid on the 25th.
None of that is unusual, and none of it is the connector’s fault. But an interface that sends the current state of the worker record and nothing else has told the payroll engine she earns 74,000, as if she always had. March pays the new number. The 380 euros owed for February exists in no system until she notices, in April.
I have sat through a lot of interface workshops. The agenda is field mappings, file layouts, SFTP keys. Almost never the thing that actually breaks: the HCM records when facts became true, payroll records when money moved, and nobody makes those clocks agree.
Every change carries two dates and most interfaces send one
An effective date says when a fact became true. An entry date says when a human typed it. Payroll needs both, because the gap between them is the entire retro problem.
Workday’s Payroll Effective Change Interface exists for that gap. As SOAIS’s technical primer describes it, the extract carries “the effective date and data entry date for each change,” and an incremental run picks up changes “effective within the current or prior pay periods entered after the last successful integration run datetime.” It is asking what became true in a period you may already have paid, according to something typed since you last spoke.
Older patterns do not ask that. DZone’s walkthrough describes PICOF as capturing data “in a top-of-stack manner for each worker,” missing changes inside a period. Oracle’s Global Payroll Interface extract keeps effective-dated history for salary, element entries and bank accounts, and for everything else reports “the top of the stack record” in the extraction window.
What is retroactive accounting?
The engine’s ability to recognise that an input for a closed period changed, recalculate the period as it should have been, and carry the difference into a live run. SAP formalises it in the payroll status infotype, which stores the earliest master data change date per employee. Change an August record in November and August becomes the retro start point. No connector supplies that; either your engine has the concept or it does not.
Then somebody decides per country, in writing, whether February gets reopened and refiled or March carries the adjustment line. Both are legitimate, and they produce different payslips and journals.
In a cumulative-tax country the choice reaches backwards regardless. UK PAYE assesses tax on year-to-date position, so a February gross correction moves the year-to-date figures already filed with HMRC under RTI. Send a current-state file with no effective date into that and you have not built an integration. You have built a well-formed source of unexplained variances.
Full-file extracts feel safer until one of them terminates 400 people
Delta extracts frighten people, rationally: if change detection misses something, nothing in the file says what is absent. So teams ask for a full file instead.
That trade has a worse failure mode. In a full-file model, absence is the only way to express deletion, so a record that stops appearing means the employment ended. Which makes a truncated extract, a job that died at row 12,400 of 12,800, indistinguishable from a mass termination. I have watched a provider process one of those obediently. Four hundred leavers, generated in an afternoon, from a file that transferred successfully.
The controls are unglamorous. Carry a status on every record so a termination is a positive assertion, never an inference. Put a trailer on the file with a record count and one numeric control total, and reject the file when either disagrees with the body. Compare the count against the prior period and refuse anything outside tolerance. And mind the order: as AssistNow’s PECI and PICOF guide notes, interfaces run out of sequence relative to payroll produce “stale or incomplete data” that still looks valid.
Batch is not laziness and an event stream is not a free upgrade
Files are supposedly legacy, APIs modern. In payroll that runs backwards.
Statutory reporting is periodic. Payroll is a batch process by nature, because gross-to-net depends on the totality of a period rather than the arrival order of its inputs. And a file is an immutable artefact. Ask an API what it sent in June and you get an answer only if you built the logging you probably did not build. PayrollOrg’s 2025 Global Payroll Week survey of over 500 practitioners found 44 percent using APIs, which tells you most of this still moves as files, and not because everyone is behind.
Events earn their place at the edges: a new hire who must exist before cutoff, a bank detail change that would bounce a payment, a termination in a state with a same-day final pay rule. Where they hurt is against a run that has locked its inputs. Once master data is cut off, an event that writes straight through means the calculated result no longer matches the approved inputs, and nobody knows. Queue it against a period instead, so the 16:40 arrival on cutoff day lands in the next run, deliberately.
The mapping table nobody owns
Ask who owns the mapping between HCM organisational units and payroll cost centres. You get a pause, a name, and a note that they left last year.
An HCM hierarchy is built for reporting lines and headcount. Payroll needs legal employer, tax jurisdiction and pay group. Different trees, same people. Add employment type, which drives statutory treatment rather than describing a contract, and work location, which is two fields pretending to be one: the one that determines withholding, and the one used for reporting.
The United States is where that pretence collapses first. Symmetry’s guidance on local tax lookup counts over 7,000 local tax jurisdictions and nearly 200 new local taxes a year, Pennsylvania alone holding 2,500 municipalities with their own PSD codes, plus Ohio school districts and JEDD boundaries. And ZIP codes, as they put it, “are postal delivery routes, not tax jurisdiction boundaries.” A work location arriving as free text cannot resolve withholding. It produces a default that is wrong for a predictable slice of your people. Cross-border repeats it at entity level: employed by the Dutch company, in a German cost centre, two days a week in Belgium is one HCM row and three payroll answers.
Time and attendance is the third system here, and it thinks it owns the premium. It should not. Under 29 CFR 778.109 the regular rate is total remuneration for the week divided by hours worked, and a nondiscretionary bonus has to be folded in and the overtime recomputed, apportioned back over the workweeks in which it was earned. T&A does not know about the bonus. Only payroll does. So T&A owns hours by category, payroll owns rate and premium, and that sentence belongs in the spec. Rounding is the same argument: the California Court of Appeal held in Camp v. Home Depot that an employer capturing exact minutes must pay for all captured time, which makes a rounding rule buried in a T&A config screen a liability nobody in payroll has read.
The journal is where finance finds out
Payroll’s output is not a payslip file, it is a journal. Finch’s write-up on ERP integration describes the two shapes: a summary rolling a run into a handful of debits and credits mapped to GL accounts, or line-item detail with earnings by type, employer contributions, taxes by jurisdiction and department tagging. You can build the first from the second, never the reverse. Choose the summary and you have given up answering why a cost centre moved.
Then timing. Month end lands mid-period, so part of the cost accrues and reverses. A worker employed by one entity and charged to another needs an intercompany payable and receivable pair, and that pair is a transfer pricing position, not a bookkeeping convenience.
Multi-currency forces the decision most teams never document. IAS 21.21 requires the spot rate at the transaction date, IAS 21.22 permits an average where rates do not fluctuate significantly, and IAS 21.23 retranslates monetary items at the closing rate, differences hitting profit and loss under IAS 21.28. Calculation date, payment date and month-end close are all defensible. What is not defensible is payroll picking one, treasury another, the ERP a third. Write the policy, source rates from one place, stamp the rate on the journal line.
“The job ran” is not “the job was correct”
Most integration incidents are found by an employee. PayrollOrg’s 2025 survey found 26 percent of respondents tracking payroll performance in spreadsheets, BI tools or manual reports, which is not monitoring an interface so much as noticing it afterwards.
The technical reason is specific. As WD Radar’s PECI monitoring guide puts it, an integration can report “Completed Successfully” because the job it was measuring, generating and delivering the file, succeeded. “The rejection happens downstream.” Green means transmitted. It does not mean accepted, and it does not mean correct.
Log at record level, not job level. Alert on the absence of an expected file at an expected time, because a job that never started raises no error. Alert on counts outside tolerance and control total mismatches. Alert on a record still rejected 24 hours later, and on the same employee failing across consecutive periods, which is a mapping gap rather than a keystroke. Confirm success positively rather than inferring it from silence.
HR Blizz was built around that failure rather than the happy path. Its interface status view puts every inbound file and integration on one screen, down to the individual failed record, so “did Poland’s T&A extract land, and did all 812 rows load” has an answer before anyone calculates. Its dynamic parser is built for inbound layouts that shift without notice, the ordinary cause of a file that transfers cleanly and loads nothing.
What to check on your interface this week
Pull last month’s inbound files and answer four questions about each. Does the record carry an effective date distinct from its entry date. Does a termination arrive as an explicit status or as an absence. Does the file have a trailer with a count and a control total, and does anything reject the file when they disagree. What time was it expected, and what time did it land.
Then find the mapping table for cost centre, legal entity, pay group and tax location, and find out who owns it today. If the answer is a spreadsheet on somebody’s drive, that is next quarter’s incident, already scheduled. And ask your ERP counterpart which rate the payroll journal uses. Two people, two answers, and you have a reconciliation difference as old as the interface.
To see that visibility inside the payroll run rather than beside it, ask for a look at the HR Blizz interface status view.
The wage and hour rules and accounting standards referred to here are described in general terms and are not legal, tax or accounting advice.
FAQ
Q: Why do HCM to payroll integrations fail even when the connector works?
Because most connectors send the current state of a worker record with no effective date and no change history. Payroll needs to know when a fact became true as well as when it was entered, since a change entered on 4 March effective 1 March requires recalculating a period that has already been paid.
Q: What is the difference between a delta extract and a full-file extract in payroll?
A delta extract sends only changes since the last successful run, which is efficient but depends entirely on reliable change detection. A full-file extract sends the whole population every period, which means absence is the only way to signal a termination, so a truncated file can be read downstream as a mass termination.
Q: Should HCM to payroll integration use files or APIs?
Both, for different jobs. Batch files suit periodic payroll and statutory reporting and give you an immutable artefact to reconcile against, while APIs and events genuinely help for new hires, bank detail changes and terminations. Events should be queued against a pay period rather than written straight through, or they will alter inputs after a run has been approved.
Q: Which exchange rate should a multi-currency payroll journal use?
IAS 21 requires the spot rate at the transaction date, permits an average rate where rates are stable, and retranslates monetary balances at the closing rate. The calculation date, payment date and month-end rate can each be defended, so the real requirement is a written policy, a single source of rates, and the rate stamped on every journal line.