SAP Mass HR Master Data Upload with PA30

What SAP mass HR master data upload means

SAP mass HR master data upload is the practice of creating or changing many infotype records in one controlled run from a structured file, instead of maintaining each employee through PA30. Infotypes hold everything SAP knows about a person: organisational assignment, personal details, addresses, basic pay, bank details and recurring payments, each stored as a record with a validity period.

Two things make this different from every other object in the master data cluster, and both need understanding before a file is built.

Every record is time dependent by design. Not optionally, like cost centres, but structurally. An infotype record is identified by employee, infotype, subtype and validity period together, so the dates are part of the key rather than attributes of it.

The data is personal. Which changes the access controls, the retention obligations, and how the file itself should be treated from the moment it is extracted.

Time constraints decide what may coexist

The time constraint class is the single most important thing to know about an infotype before building a file for it, and it is the thing most often skipped.

Time constraint 1: must always exist. Exactly one record valid at any moment, with no gaps ever. Organisational assignment and personal data work this way, because an employee cannot meaningfully exist without them. A gap is not permitted, so SAP will not let you create one.

Time constraint 2: at most one. One record at a time or none at all. Gaps are permitted, overlaps are not. Many optional infotypes work this way.

Time constraint 3: any number. Multiple records may be valid simultaneously. Family members, qualifications, and addresses of different types all need this, because an employee legitimately has several at once.

The constraint frequently applies within a subtype rather than across the infotype as a whole. An employee may have a permanent address and a temporary address simultaneously because they are different subtypes, while having two permanent addresses at once is not permitted.

Delimiting: the behaviour that catches everyone

On time constraints 1 and 2, writing a new record does not fail when one already exists. It delimits the previous record, setting its valid-to date to the day before the new one begins.

That is correct behaviour and it is exactly what you want when recording a genuine change: an employee moves cost centre on the first of July, so the old assignment ends on the thirtieth of June. It becomes a problem in a mass run because it happens silently. A file with a wrong valid-from date does not error; it ends a record that should have continued.

The fields you have to map

Four identifying columns before any actual data, because an infotype record is identified by the combination rather than by a single key.

One file per infotype

Different infotypes carry entirely different fields. Basic pay has wage types and amounts, addresses have street and postcode, bank details have account numbers and sort codes. A file attempting to serve several infotypes is mostly empty columns and impossible to review.

Split by infotype, always. Where several infotypes must be loaded for the same population, that is several runs in a defined order, not one file.

Operation is not implied

Insert, change and delimit are different operations with different effects, and the file should state which. An insert creates a new record. A change modifies an existing one in place. A delimit ends a record without creating anything.

Assuming insert for everything is how a correction becomes a new validity segment rather than a fix to the existing one, which leaves the wrong value visible for the earlier period.

Dates are the key, not attributes

Worth repeating because it drives file design. Valid-from and valid-to are not two more columns to populate. They determine which record you are creating and what happens to the records around it. A file where the dates were filled in last, after the values, has usually got them wrong.

Retroactivity and payroll

This is the consequence that makes HR loads different from everything else in this cluster.

Where payroll has already run for a period, changing an infotype record valid in that period triggers retroactive accounting. Payroll recalculates the affected periods and produces differences that flow into the next payroll run.

That is correct behaviour: a backdated pay change should produce back pay. It is also a consequence that a mass load can produce at scale without anybody intending it.

• A backdated file can trigger recalculation for hundreds of employees. Which payroll will process, and which will appear as differences in the next run.
• The earliest retroactive accounting date limits how far back changes reach. Records dated before it may be rejected or handled differently depending on configuration.
• Payroll and HR administration need to know before the run, not after. A large retroactive population landing unannounced in a payroll cycle is a genuine problem for the team running it.

The practical rule is that any file containing dates in closed payroll periods deserves a conversation with payroll before it runs, regardless of how routine the change looks.

Personal data changes the obligations

The technical mechanics of an HR load resemble any other master data load. The obligations around the file do not, and treating an HR extract like a material master extract is the mistake that matters most here.

Authorisation is structural. HR uses authorisation concepts that go beyond transaction and organisational unit, controlling access down to individual employees through personnel area, employee group and organisational structure. A load runs under the operator's authorisations, which means a file covering employees they cannot see will partially fail, and that is the control working correctly.

The file is a personal data extract. Whatever the project plan calls it. It contains names, addresses, pay and bank details, sitting on somebody's desktop or in a shared folder. Where it is stored, who can open it, and when it is deleted are all governed rather than matters of convenience.

Test data needs thought. Copying production HR data into a test system is a data transfer that most data protection frameworks have something to say about. Anonymised or synthetic data is the usual answer, and it needs preparing rather than assuming.

Retention applies to the file as well as the system. The completed load file is evidence and it is also personal data, which means it has a retention period rather than living indefinitely in a project folder.

The eight stages of a controlled PA30 run

Validation: six checks before a single record is written

Two deserve expanding.

Employee hired by that date. A record cannot be valid before the employee exists. On a file loading historical data for a population with varying hire dates, this fails for the subset hired later, which looks random and is entirely systematic.

Authorisation covers the population. HR authorisation is finer-grained than most, and a file spanning personnel areas the operator cannot maintain will partially succeed. Partial success on an HR load is worse than outright failure, because the result is an inconsistent population that looks complete.

Running the whole sequence inside Excel

Where HR load volume comes from

• Annual pay review. Basic pay records for a whole population, effective on one date, prepared in a spreadsheet by reward.
• Reorganisation. Organisational assignment changes when departments merge, split or move, affecting cost centre and position on every employee involved.
• Acquisition and TUPE transfers. An acquired population loaded across many infotypes, usually against a fixed transfer date.
• Benefits enrolment. Recurring payments and deductions from a benefits platform, refreshed periodically.
• Bank detail refreshes. Where a banking change affects a population rather than an individual.
• Data cleansing. The output of an audit, arriving as a list of corrections across mixed infotypes.
• System migration. Historical infotype records carried into SAP, which is the largest and most date-sensitive case of all.

What these share is that the data originates outside SAP, with reward, HR operations or a third-party provider, and arrives as a file because that is what those teams work in.

Personnel actions versus individual infotypes

There is a second way to change HR data, and choosing wrongly between them produces incomplete records that look fine.

A personnel action is a defined sequence of infotypes maintained together for a business event: hiring, leaving, promotion, transfer. The action guides the user through every infotype that event requires, in order, and records why the change happened.

Maintaining individual infotypes touches one at a time, which is right for a correction and wrong for an event.

The distinction matters for mass loading because business events rarely affect one infotype. A reorganisation changes organisational assignment, and depending on configuration it may also need position, cost centre and possibly pay. Loading only the organisational assignment leaves an employee whose record is internally inconsistent, and nothing errors because each individual record is valid.

• Ask which infotypes the event should touch. HR operations knows; the file usually only carries one.
• Load them as a sequence, in the order the action would. Some infotypes depend on others, so the order is not arbitrary.
• Carry the action reason where the infotype records it. It is what makes reporting on why people moved possible later.
• Consider whether a mass load is right at all. For a genuine hiring or leaving population, the action exists because it enforces completeness, and bypassing it to load faster removes that.

The honest position is that infotype-level loading suits corrections, refreshes and bulk parameter changes. Life-cycle events are better served by the action, and where volume makes that impractical the file has to reproduce what the action would have covered.

Organisational management sits underneath

Infotype 0001, organisational assignment, references objects that live in a different part of SAP, and those objects have to exist first.

Positions, jobs and organisational units are organisational management objects with their own maintenance, their own validity periods and their own relationships. An employee is assigned to a position, the position belongs to an organisational unit, and the unit sits in a hierarchy.

Three consequences for a mass load:

The prerequisite chain is real. A reorganisation file assigning employees to new positions fails if those positions do not exist yet, and creating them is a separate exercise in a different transaction. This is the same sequencing dependency the cost centre guide describes for hierarchy nodes.

Validity has to align. Positions are time dependent, so assigning an employee to a position from a date before that position exists fails in a way that reads as though the position is missing entirely.

Relationships carry defaults. Cost centre and organisational unit frequently derive from the position rather than being stated per employee. A file supplying them explicitly may conflict with what the position implies, and which wins depends on configuration.

Before any reorganisation load, the question worth asking is whether the target structure exists in organisational management. If it does not, the HR file is the second run rather than the first.

Governance

• Approve the file, and treat it as personal data. Reviewable in one artefact, and governed from the moment it exists.
• Run as a named user with their own HR authorisations. Never a service account, because structural authorisation is the control.
• Separate preparation from loading. Reward or HR operations supplies the file; somebody else runs it.
• Tell payroll about anything retroactive. Before the run, not when differences appear.
• Keep the before extract, with a retention date. It is the rollback and it is personal data, so it needs both.
• Delete the working files when the run is complete. A finished HR load file has no reason to persist in a project folder.

Common mistakes and how to avoid them

• Not knowing the time constraint before building the file. It determines whether records may overlap and what happens to the previous one.
• Unintended delimiting. A wrong valid-from date silently ends a record that should have continued.
• Combining infotypes in one file. Different infotypes share almost no columns, so the sheet is mostly empty and unreviewable.
• Treating dates as attributes. They are part of the key and should be mapped first.
• Assuming insert for every row. Insert, change and delimit are different operations with different effects.
• Loading records before the employee is hired. Fails for the subset hired later, which looks random.
• Triggering retroactive payroll without warning anyone. A backdated file can recalculate hundreds of employees.
• Treating the extract as an ordinary spreadsheet. It is a personal data extract from the moment it is created.

Historical data and migration loads

The largest and most date-sensitive HR load is a migration, and it has rules the routine cases do not.

How much history to carry is a decision, not a default. Loading every historical infotype record from a legacy system reproduces a complete timeline and multiplies the volume enormously. Loading only current records is far smaller and loses the history that reporting, seniority calculation and legal obligations may depend on. That choice belongs to HR and legal rather than to the project.

Time constraint 1 infotypes must be continuous from the hire date. Which means historical records have to join up exactly, with no gaps anywhere between hire and today. A partial history for these infotypes is not a smaller version of a full one; it is an invalid one.

Load chronologically per employee. Because each record delimits the one before it, loading out of order produces a timeline that is repeatedly rewritten and may not end where intended.

Suppress retroactivity deliberately. A migration loading years of history would otherwise trigger retroactive payroll for every period. The earliest retroactive accounting date is what controls this, and setting it correctly before the load is the difference between a clean migration and a payroll run nobody can reconcile.

Reconcile per employee, not in aggregate. A count of records loaded proves nothing about whether any individual timeline is continuous. Reading a sample of employees end to end is the only check that does.

After an HR load

Four checks, and the first two have no equivalent in other master data.

Read employees end to end, not records. Open a sample in PA20 and look across every infotype touched, checking the periods join up. A record-level check cannot see a gap; only a timeline view can.

Check for unintended delimiting. Compare against the extract taken before the run. Any record whose valid-to date moved and should not have is a period you have quietly ended.

Confirm with payroll before the next run. Particularly where anything was backdated. Payroll would rather know than discover.

Delete the working files. The completed load file is personal data with no further purpose once the run is evidenced. Retaining it in a project folder indefinitely is the most common data protection failure in these projects and the easiest to avoid.

The complete PA30 mass upload reference

The reference sheet below collects everything above into one image you can share before an HR load.

Go deeper

Frequently asked questions