One human, two identities, and neither is a spare

Employee Central holds the person and the employment relationship. S/4HANA holds an identity it can post financial documents against. The same human therefore arrives in the second system twice, once as a business partner carrying an employee role and once as a user with a login, and those two records are not interchangeable. Most of the expensive incidents I have been asked to clean up started with someone assuming they were.

The business partner is what finance depends on. It is the requisitioner on a purchase requisition, the claimant on a travel expense, the agent a workflow resolves to. The user is the login and the authorisations behind it. A leaver who loses the user but keeps a live employee role still appears in approval routing. A new starter whose business partner never got created signs in perfectly well and fails at the first posting with an error that names nothing useful.

So the replication between SuccessFactors and the ERP is the real design object, not a plumbing detail to hand to whoever is free. The mapping decides which Employee Central fields become business partner attributes, which land in the organisational assignment that workflow reads, and which never travel at all. Every one of those choices shows up later in somebody's month end.

Employee Central owns the person and finance owns the cost object

Ask which system is the record of truth for organisational assignment and you will get two confident answers in the same meeting. The honest answer is split. Employee Central is authoritative for the person, the position and which cost centre that person is assigned to. S/4HANA is authoritative for the cost centre itself, because the controlling object lives there, gets opened and blocked there, and carries the reporting hierarchy finance actually uses.

That split means the mapping has an owner whether or not anyone has been named. Someone decides what happens when a cost centre is blocked in finance while forty people in Employee Central still point at it. Usually that someone turns out to be an integration consultant who rolled off eighteen months ago, and the rule survives in a mapping table nobody has opened since. Give the link a durable key on both sides, and read a field guide to durable business keys before the first load.

One of these calls is reversible and one is not. Flipping the direction of cost centre replication, or changing which attributes travel, costs a few weeks of work and a regression test. Moving the record of truth for the person is a different matter. Once payroll, time and benefits all hang off Employee Central, that decision is load bearing, and undoing it becomes a new programme with a new budget.

Effective dating meets a period that is already closed

Effective dating causes more production incidents between these two systems than anything else, and the cause is structural rather than accidental. Employee Central is built around effective dated records. Every job information row has a start date, and the system will happily accept a change keyed today with an effective date three months back. Finance does not work that way. A posting happens on a document date and lands in a period that eventually closes.

So a cost centre change entered on 12 May with an effective date of 1 March replicates a completely correct HR record into a system where March is shut. The employee assignment updates from the replication date forward. The March and April postings stay exactly where they landed. No system is wrong, no interface errored, and the two sets of numbers still do not agree.

Decide the retroactive rule before go live rather than during the first close that fails. The options are a hard cutoff on the replication with everything earlier handled by manual journal, full reposting through a correction run, or accepting the difference and documenting it for audit. Most organisations should take the cutoff and pair it with an exception report naming the person, the old cost centre, the new one and the affected periods. Then name who reads that report every month, because payroll cutover reconciliation teaches the same lesson the expensive way.

Quiet replication failures cost more than an outage

A batch that fails loudly is a good day. Someone gets paged, the queue backs up, the fix goes in. What actually hurts is the record that replicates with no error and the wrong content, or the record filtered out by a selection rule somebody wrote for a different purpose two years earlier.

The classic version is a posting against a stale cost centre. A transfer never arrived, so expenses and time confirmations keep hitting the old assignment, and the receiving manager sees a budget that looks healthy because the charge is landing somewhere else. Nobody queries it until a variance review in month four, and by then the correction spans several people and several closed periods.

The second version is approval routing to someone who left. The manager relationship in the organisational assignment never updated, so requisitions queue in a dormant inbox and ordinary business quietly stops. The workaround is always the same and always worse than the problem, which is an emergency authorisation that lets someone approve their own spend. If your interfaces cannot tell you which records did not arrive, read integration error handling that pages someone and fix the monitoring before you tune the mapping.

The hierarchy you should not copy twice

Duplicating an organisational hierarchy in two systems guarantees drift. The position and organisational unit structure in Employee Central exists to answer who reports to whom, who may approve what, and which roles are vacant. The standard hierarchy in controlling exists to roll up cost. Different people maintain them on different calendars, and they diverge inside two quarters.

The workable answer is deciding which parts must match exactly and which may legitimately differ. Cost centre codes and the assignment of a person to a cost centre must match exactly, because postings and reporting both depend on them. The shape above that does not have to. Finance groups by legal entity and profit responsibility. HR groups by reporting line and geography. Forcing those into one tree makes both worse and satisfies neither team.

Write the rule down as a short list of authoritative attributes and convenience copies, then build a reconciliation that compares only the authoritative set. Comparing everything produces a difference report so noisy nobody triages it, which leaves you no better off than no report. Reorgs are the stress test, and an integration that survives one is built on exactly this distinction.

A leaver exposes every weakness at once

One termination has to reach finance, access and approvals, and each of the three runs on a different clock. Access revocation is measured in hours and cares almost nothing about dates. Finance cares enormously about the date, because accruals, final pay and cost allocation all hinge on it while speed barely matters. Approval rerouting is measured in whatever time passes before the next requisition arrives.

Standard replication handles one of the three well. The employee role on the business partner gets delimited and the person stops being a valid requisitioner. The user lock usually travels a separate path through identity provisioning on its own schedule. Open workflow items belong to nobody in particular and tend to sit there until a frustrated requester escalates. A backdated termination makes all of it worse, because for some window the person held a valid posting identity after they had already gone.

Reconcile something specific this week. Pull the last ninety days of leavers and, for each one, line up four dates side by side. The termination date in Employee Central, the delimit date on the business partner employee role, the date the user was locked, and the date any workflow item assigned to them was reassigned. If those four do not agree for even one person, you have found the first defect and there will be others behind it. That exercise costs an afternoon, and it surfaces the same gaps described in the quiet failure in employee lifecycle handoffs before an auditor finds them for you.