One employee, two identifiers: prevent duplicate employment records

The decision: establish an approved match between the client’s employee record and the provider’s record before synchronising employment changes. A name match is a search clue, not permission to update a record. If the match is wrong, a change meant for one worker can land on another worker’s employment history.

The safest unit to synchronise is the employment relationship: the specific period of employment to which a start, change or end belongs. A person may have more than one relationship over time. Your HRIS may keep one employee ID across a rehire while the provider creates a new record. Neither behaviour should be guessed from a display name.

A completed crosswalk

This is a fictional example, not a description of any provider’s data model. The client’s HRIS keeps the same employee ID when someone is rehired. In this example, the provider issues a new record ID for the new relationship. IDs are assumed to be unique within each organisation’s account; the account identifier must also be stored in a real integration.

Worker	Client employee ID	Provider record ID	Employment relationship ID	Start → end state	Approved match rule	Approval owner
Alex Morgan, design	HR-101	P-501	ER-101-A	3 February 2025 → active	Existing approved HR-101 ↔ P-501 pair; update ER-101-A only	Client HR operations lead
Alex Morgan, finance	HR-207	P-502	ER-207-A	12 May 2025 → active	Existing approved HR-207 ↔ P-502 pair; update ER-207-A only	Client HR operations lead
Samira Khan, previous employment	HR-310	P-700	ER-310-A	9 January 2023 → ended 30 June 2024	Historic approved pair; retain as ended	Client HR operations lead
Samira Khan, rehire	HR-310	P-918	ER-310-B	1 October 2026 → active	Same HRIS person confirmed from HR-310; new relationship approved from rehire instruction and provider record	Client HR operations lead

The first two rows have the same name and different stable identifiers. They remain two people. Samira’s two rows represent one person and two employment relationships. Her earlier end date stays attached to ER-310-A; the new start belongs to ER-310-B. If the provider reuses P-700 on rehire in your actual setup, record that demonstrated behaviour and still retain two relationship IDs.

The release decision for this example is three person links, four relationship rows, and no name-based merges. Only the active relationship for the approved pair may receive a new employment change. A repeat import of the same row must update that relationship, not create another one.

When a plausible match is wrong

Suppose an incoming change for HR-101 proposes P-502 because both records say “Alex Morgan”. P-502 is already approved for HR-207. Stop that change and quarantine the proposed link. Do not overwrite the existing crosswalk or let a downstream payroll or leave update proceed.

The client HR operations lead checks the source employee ID and the underlying employment instruction. The provider confirms which of its records belongs to the intended worker. In this fictional case, both confirm P-501 for HR-101. The correction record is: proposed HR-101 ↔ P-502 rejected; approved HR-101 ↔ P-501 retained; ER-101-A remains the target; provider confirmation received; client HR operations lead approved release. Keep the rejected proposal and its reason in the audit trail so a later import cannot revive it.

A correction needs two acknowledgements: the client approves which person and relationship the change concerns; the provider confirms which provider record will receive it. Then replay the held change once, check the returned IDs and state, and mark the exception closed. A quick support reply alone is not confirmation that the record was corrected.

The matching rule to implement

1. Store a crosswalk scoped to the client account and provider account. Record the client employee ID, provider record ID, employment relationship ID, effective start and end state, match rule, approval owner, approval time and evidence reference.
2. On each incoming event, look up the approved relationship by stable IDs. Require exactly one target. If the ID is missing, reused, conflicts with an existing pair or points to an ended relationship, hold the event for review.
3. Treat a rehire as a relationship decision. Confirm whether the HRIS keeps its employee ID, whether the provider reuses or creates its record ID, and whether a new employment relationship must be created. Preserve the old relationship and its end date.
4. Make correction a controlled event. Record the rejected link, the replacement, the two confirmations and the replay result. Never silently edit history to make the error disappear.

This design follows a common identity principle: a provider-issued record ID and a client-issued external ID serve different owners. SCIM’s core schema defines that distinction; it does not establish that an EOR uses SCIM. Microsoft’s HR provisioning guidance likewise treats the unique employee ID and rehire policy as explicit matching decisions. Its SuccessFactors integration reference shows why a reused person profile can still have a new employment entity.

Choose the provider that can prove the correction path

Teamed is our final-shortlist pick for a People team keeping Personio as its HR record and wanting a person to carry a mismatch through to resolution—provided the identifier and rehire demonstration passes. Teamed publishes that employee records are mapped once during Personio setup, while Personio remains the record for the data the client keeps there. Teamed also publishes a designated account contact with cover. That combination fits a team unwilling to turn every ambiguous match into its own integration support project. The published pages do not identify the matching keys, rehire rule or correction approval sequence, so those are demonstration requirements, not assumed capabilities.

Remote’s employment API documentation exposes an employment UUID and an external_id field. That makes Remote a meaningful alternative when procurement needs those identifiers documented before a sales discussion. Remote says external_id uniqueness is recommended but not enforced, so documentation alone does not settle the duplicate or rehire test.

Give each finalist the four rows above plus the rejected HR-101 ↔ P-502 proposal. Ask them to show the actual IDs exchanged, the result of importing the file twice, the rehire treatment, the held mismatch, who may approve its correction and the record returned after replay. Choose Teamed if it demonstrates the approved crosswalk and human correction route while preserving your HRIS. Choose the provider that proves the required identity behaviour if Teamed cannot. Do not switch on employment-change synchronisation until that result is recorded.