SAP HCM and SuccessFactors explained

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 9 October 2026 · facts checked against the SAP Help Portal and SAP's maintenance pages, October 2026

SAP HCM is SAP's on-premise HR component — employee master data, organisational structure, time and payroll — continued today as SAP HCM for SAP S/4HANA. SAP SuccessFactors is the cloud suite SAP sells for the same processes plus talent management (what SAP SuccessFactors is). Most large employers run a mix, and the two name the same things differently.

What is SAP HCM?

SAP HCM is the on-premise HR engine inside SAP ERP and S/4HANA, and SuccessFactors is not its next release but a separate cloud product with its own data model and tools. That is why an HR roadmap is a deployment decision rather than an upgrade: moving from HCM to Employee Central means re-implementing core HR on a different platform, while the on-premise path stays on the classic engine.

It is also why "we use SuccessFactors" says little on its own. Most often it means recruiting and learning in the cloud while core HR and payroll are still on premise, so the first question on any HR project is which modules are live where, and which system is the record for an employee's data.

Which HR processes sit in HCM, and which in SuccessFactors?

Core records, organisation, time and payroll exist on both sides; the talent processes are developed only in the cloud. On-premise pieces go by classic code, cloud pieces by product name.

• PA — Personnel Administration — employee master data held in infotypes: hires, contract changes, basic pay, bank details. Maintained in PA30, with hires and leavers run as personnel actions in PA40.
• OM — Organizational Management — units, jobs and positions; the structure reporting lines, workflow and access hang from, usually maintained in PPOME.
• PT — Time Management — work schedules, absence quotas, positive and negative time recording, time evaluation (PT60).
• PY — Payroll — gross-to-net per country version: wage types, schemas and rules (edited in PE01 and PE02), retroactive accounting, the posting to accounting. Each country has its own payroll driver — PC00_M01_CALC for Germany, for instance.
• SuccessFactors — Employee Central as the cloud system of record, Employee Central Payroll behind it, and the talent modules around it; the full list is in the SuccessFactors module guide.
• The hybrid seam — employee data replicated both ways across the two systems: a specialism in itself.

Which Employee Central objects does a classic HCM consultant relearn?

The infotype gives way to foundation objects, generic objects and business rules, and someone arriving from the classic side has to unlearn it first. In Employee Central the structure is built from foundation objects — legal entity, business unit, division, department, location, job classification, pay grade — and anything the standard does not cover is modelled as a generic object in the metadata framework, which is both the suite's greatest flexibility and the easiest thing to over-use.

Four mechanisms carry most of the configuration effort. Records are effective-dated, so a change is entered with the date it takes effect and the history stays readable, and an event with its reason classifies why the change happened — the basis of nearly every report and interface downstream. Business rules replace ABAP for defaults, validations and derivations, and a badly ordered set of them produces behaviour nobody can trace. Workflows are derived by rule rather than assigned, which is why a request routes to the wrong approver long before anyone changes an approver. And role-based permissions combine a permission role with a group of holders and a target population, so who may see which fields of which employees is the single most intricate design object in the system, and the one most often rebuilt after go-live.

Position management deserves its own decision. Running with positions gives clean vacancy handling, a real link to recruiting and structured reporting lines; running without them is simpler and pushes the burden into every downstream process. Changing your mind afterwards is expensive.

What are the deployment options, and which dates drive them?

There are three models — talent hybrid, core hybrid and full cloud — and almost every HR roadmap conversation is about which one a company is in and where it intends to move next.

Talent hybrid

Core HR stays on premise; SuccessFactors supplies recruiting, learning, performance or compensation. The cheapest step and the most common starting point, at the cost of an employee record that has to be pushed into the cloud continuously.

Core hybrid

Employee Central becomes the system of record and payroll stays where it is, fed by replication. Popular in countries with complex payroll and strong employee representation, because it moves HR without touching pay.

Full cloud

Employee Central with Employee Central Payroll behind it — technically the same payroll engine as the classic product, operated as a service — or a third-party payroll provider per country, which is the real alternative and the one most often underestimated in a business case.

The clock is what made this urgent, and part of it has already run out. Classic SAP ERP HCM could run inside an on-premise S/4HANA system only under compatibility-pack usage rights; those were due to end on 31 December 2025, and SAP then added a final transition period to the end of May 2026 (SAP News Center). The on-premise successor is SAP HCM for SAP S/4HANA — known as H4S4 — shipped with the S/4HANA 2022 release, with maintenance committed to the end of 2040 (SAP's product note). So a company with on-premise payroll now chooses between the cloud, another payroll vendor, and H4S4; consultants who can lay out those options credibly are doing the most valuable work in the area (the wider S/4HANA effect).

The table is the whole roadmap conversation in four rows: every classic HR landscape sits in the last two and is choosing between the first two or a third-party payroll provider.

Why is payroll treated as its own discipline?

Because the pay date is fixed outside the project and the output is money leaving a bank account. The period is opened, simulated, corrected and locked on dates no plan can move, and a backdated change forces retroactive accounting through closed periods. Country versions and statutory reporting are shared with finance localisation; what is not shared is the pay date, the bank transfer, and — where works councils hold co-determination rights — their agreement on the time and performance configuration before go-live.

Technically the discipline rests on a small number of ideas that take a long time to master: the wage type as the unit of everything calculated, the schema and its rules as the calculation itself, the control record that says which period is open and locks master data while it runs, and retroactive accounting, which recalculates a closed period and carries the difference forward rather than reopening it. The tooling has improved — modern payroll operation runs as a monitored process with validation rules that catch a wrong result before anyone is paid — but none of it removes the need to read a payroll result and explain a number.

The career consequence is locality: the gross-to-net core travels, the country layer is relearned on arrival — a cost that shows up when you move markets.

How does an HR project run with live payroll underneath?

Through the usual phases, each bent around pay dates that cannot move. Each project phase has its own shape, with a live payroll period running underneath.

• Design — workshops with HR operations and payroll: org model, absence and time rules, the wage-type catalogue.
• Build — configuration in the IMG, or business rules, picklists and permissions in Employee Central; interface specs for banks and insurers.
• Test — parallel payroll runs: the same period calculated old and new, reconciled until every difference is explainable.
• Cutover — loading balances and year-to-date results, opening the control record, standing behind the first live run.
• Run — the AMS rhythm: legal change packages applied as SAP ships them, heaviest at year-end, and support shaped by pay day, not month-end.

A cloud release adds a rhythm no other SAP area has. The tenant is upgraded on SAP's date whether the project is ready or not, some features arrive switched off and some switched on, and a small regression test against the preview tenant becomes a standing item in the calendar rather than a project activity.

What makes HR data different to work with?

Three constraints shape HCM projects and almost no others. Employee representation comes first: in several European countries a works council has a formal say over systems that can monitor performance, which puts time recording, performance management and some analytics on a separate approval track with its own timeline — and a go-live date that ignores it is fiction. Second, the data is among the most restricted in the company, so permission design is a design task rather than a hand-off, and a demonstration to the wrong audience with real data is a genuine incident. Third, retention is regulated in both directions: some records must be kept for a statutory period, others must be deleted when their purpose ends, and neither happens unless someone configures it.

Integration inherits all of that. Replication between the cloud and a payroll system fails, in practice, on records that were valid where they were entered and rejected by a validation on the other side, and somebody has to own that error queue every day (the integration specialism).

Where do payroll results post, and who owns the mapping?

Payroll results post to the general ledger and settle onto cost centres and orders, so FI and CO are the closest neighbours; the wage-type-to-account mapping is usually owned by an HCM consultant, and it is the artefact both sides discover they need during the first parallel run rather than during design.

Security and authorizations pairs tightly too, on the classic side through structural authorizations that follow the org structure you configure, and in the cloud through the permission model above (which combinations work).

Who moves into HCM work, and what must a payroll CV prove?

People arrive from four directions: from HR itself — payroll administrators and time officers who know the process (the key-user route); from classic PA, OM and PT into Employee Central, where the process knowledge transfers and the configuration does not; from cloud into payroll, the harder direction; and from the technical side, through the replication interfaces. A payroll CV has to name the country payrolls run live, the go-lives and what you owned, because interviews probe exactly that — how a retroactive change reaches the current period, or how a permission was scoped to one country's employees.