TL;DR
- The core decision: which system is authoritative for each field, which is a decision rather than a product.
- When doing nothing is right: when one system holds everything and nothing else keeps its own copy.
- What has to be true: somebody can point at a field and say where the correct version lives.
- How the options split: field by field, not system by system, which is the part everybody gets wrong.
- Decision rule: if two systems can both be edited for the same field, they will diverge.
- Outcome to expect: one place to correct things, and numbers that stop disagreeing.
Four Systems, Four Addresses
Somebody moves house. They tell HR, who update the record.
Two months later a document goes to the old address. Payroll had its own copy, and nothing passed the change across. Then benefits administration turns out to have a third version, entered when the person enrolled and never touched since. And the team's own contact list, maintained by whoever set it up, has a fourth.
Nobody did anything wrong here. Each system was added to solve a real problem, each brought its own record of a person because that's what systems do, and nobody ever decided which one was supposed to be right. The question was never asked, because it doesn't come up until something goes wrong.
Best tools for HRIS Software
This is the ordinary state of employee data in most organisations, and it produces a specific set of symptoms. Numbers disagree between reports. A leaver keeps appearing somewhere. Changing an address means telling several systems and discovering the ones you missed months later. And nobody can answer a simple question about what's held where.
The instinct is to solve it by consolidating: one system, everything in it. Sometimes that's right and it's frequently not available, because the systems exist for reasons and removing one means losing something. Consolidation is also a project, and the underlying problem can be addressed without one.
The reframe worth holding: a system of record is a decision, not a product. And the decision has to be made field by field rather than system by system, because almost no organisation has a single system that should be authoritative for everything.
When You Genuinely Do Not Need to Act Yet
Your current setup is genuinely fine. One system holds the employee record, nothing else keeps its own editable copy, and when something changes it changes in one place. This is more common in smaller organisations than people expect, and it's worth protecting rather than improving.
Friction is starting to show. A document went to an old address, or two reports disagreed once, or somebody had to update the same detail in two places. These are early and cheap to address, usually by deciding which copy wins and making the other read from it rather than hold its own.
It has become a real cost. Numbers disagree routinely, corrections have to be made in several places, or somebody spends time reconciling. At this point the ambiguity is producing measurable waste and the fix is a decision rather than a purchase.
The edge case that forces it. Somebody asks a formal question you can't answer: what data do you hold about this person, where is it, who has access, how long will you keep it. Obligations around employee personal data, access rights, retention and transfer between countries differ sharply by jurisdiction and by sector, and several have been changing. Establish what applies where you operate with local advice, because that defines the answer you need to be able to give rather than something you can design freely.
Five Questions This Reader Asks at 11pm
What is a system of record? The system holding the version of a fact that everybody agrees is correct. If the address in that system and the address elsewhere disagree, the record wins and the other is wrong. The important word is agreed: it's not a technical property of a product, it's a decision people make and then respect, and it's meaningless if nobody has made it.
Which system should hold employee data? Not one system, which is where the question usually goes wrong. Different fields have different natural owners: the employment relationship belongs with the core record, what was actually paid belongs with payroll, enrolment choices belong with whoever administers them. The work is deciding per field, and the mistake is trying to decide per system and then arguing about which product is more important.
Why do our headcount numbers disagree? Two reasons that look identical from outside. Either the definitions differ, meaning both systems are right about different questions, or the underlying data differs, meaning one of them is wrong. Finding out which is the first step and it's frequently skipped, because reconciling the number feels more urgent than diagnosing why it needed reconciling.
How do we clean this up without a big project? Take the fields that cause actual problems, which is usually a short list, and decide each one. Address, position, reporting line, employment status and contact details cover most of the pain. You don't need to resolve every field in every system to stop the symptoms, and treating it as a complete data governance exercise is how it never starts.
Who should be able to see employee data? A question with a local answer rather than a general one. What you may hold, who may access it, and what you must be able to demonstrate differ by jurisdiction and by the kind of data involved. Establish that specifically with proper advice, then design access against it. Access models that grew by accident are the norm and they are not a defence.
Deciding the Authoritative Source, Field by Field
This is the exercise that fixes most of the symptoms. It takes an afternoon for the fields that matter, and the test in the last column settles most arguments.
| Field | Plausible owners | The test that settles it |
|---|---|---|
| Home address and contact details | Core record, payroll, benefits | Where does the individual update it themselves |
| Position and job title | Core record, or a planning tool | Where does a change get approved |
| Reporting line | Core record, or a directory | Which one do approvals route from |
| Employment status and dates | Core record | Which one determines whether somebody is paid |
| Pay rate as agreed | Core record | Where is the change authorised |
| What was actually paid | Payroll | Which system produced the payment |
| Enrolment choices | The administering system | Where did the person make the election |
| Skills, certifications, training | Wherever they are captured | Which system is the reason it was recorded |
The distinction in rows five and six is the one that causes the most confusion and it's worth being precise about. The record holds what was agreed and from when. Payroll holds what was actually paid in a given run. Those can legitimately differ, because a change agreed late might not reach a run, and an organisation that treats them as the same field loses the ability to notice when they shouldn't differ.
The first row is the one to fix first because it produces the most visible failures. The answer is almost always that the individual should update it in one place and everything else should read from there, since the person who moved is the only reliable source. What breaks it is several systems each offering an editable field, so the person updates whichever they happen to be in.
The last row is worth flagging as genuinely harder. Skills and training data tends to accumulate in whichever system was used for a particular purpose, and there's often no single natural owner. It's acceptable to leave that scattered as long as you know it is, rather than believing you have a consolidated view that doesn't exist.
Five Diagnostic Questions You Can Self-Assess Against
Pick a field. Where does the correct version live? Try it with home address and with reporting line. If the answer requires thought, or differs depending on who you ask, that field has no owner and will diverge.
How many places does somebody's address exist? Count them, including spreadsheets and the team contact list. Most organisations find more than they expected, and the count itself usually settles whether this needs attention.
When somebody changes, how many actions are needed? Trace a real promotion. If it requires updating several systems separately, each is an opportunity to be missed, and one will be. The systems that get missed are the ones nobody uses daily.
What happens on the last day? Leavers are where data problems become visible and occasionally consequential. Access that outlives employment is the failure with the most exposure attached, and it happens because closing accounts in several systems depends on somebody remembering each one.
Could you answer a formal question about one person? What you hold, where, who can see it, how long you'll keep it. If not, that's worth addressing on its own terms, and what you're actually required to be able to answer differs by jurisdiction, so establish it with local advice rather than assuming.
Six Ways Employee Data Ends Up Scattered, Reviewed
Systems arriving one at a time, each with its own record
The main cause, and it happens through entirely reasonable decisions. Each system is added to solve a real problem and brings its own concept of a person, because a product that manages something about employees needs to know who they are.
Where the trouble starts is that nobody decides, at the point of adding the third system, which one is authoritative for the fields they share. The default is that each holds its own editable copy, and the divergence begins immediately and invisibly.
The fix is not to remove systems. It's to decide, per shared field, which one is authoritative and make the others read rather than hold. That's a smaller intervention than consolidation and it addresses most of the symptom.
The moment to do this is when a system is being added, not afterwards. A new product arrives with fields that overlap what you already hold, and the question of which one wins is easy to answer while somebody is configuring it and awkward to answer a year later once both contain data people rely on. Adding one line to whatever process approves new software, asking which fields it will hold and which of those it should own, prevents most of this permanently.
A department keeping its own list for a real reason
Somebody maintains a separate list because the central record doesn't hold something they need, or doesn't produce a view they can work from. It earns its place more often than central teams like to admit, because it exists in response to a genuine gap.
Where it falls short is that it becomes a competing source. The list gets used in a meeting, its numbers differ from the official ones, and nobody can reconcile them because its definitions live in one person's head. It also contains personal data in a place nobody has assessed, which matters for access and retention in ways that differ by jurisdiction.
Find these rather than banning them. Ask what the list holds that the record doesn't, and either add that or accept the list and document what's in it and who can see it.
Expect the conversation to be slightly defensive, because the person maintaining it generally assumes they are about to be told to stop. They have usually solved a real problem at their own expense and without being asked. Treating the list as evidence of a gap rather than a breach gets a far more complete account of what it holds and why, which is the information you actually need.
Data entered at hire and never revisited
Fields captured during onboarding that nobody updates afterwards: emergency contacts, qualifications, preferences recorded once. It earns its place as a category because the data was worth collecting at the time.
Where it falls short is that stale data is worse than absent data, specifically because it looks current. An emergency contact from years ago is the clearest example: it gets used at exactly the moment being wrong matters most. Nothing prompts a review, because nothing in the ordinary course of work touches the field.
Decide which of these fields genuinely need to stay current, prompt for those on a rhythm, and consider whether the rest should be held at all. Holding personal data you never use is a question with a local answer, so take advice.
Emergency contacts deserve a specific mention because they are the clearest case of stale data being actively dangerous rather than merely untidy. The field looks populated, so nobody questions it, and it gets used at the one moment when being wrong matters most. Prompting people to confirm it on some regular occasion, attached to something they already do, costs very little and is worth more than most of what sits alongside it.
Integrations that copy rather than reference
A connection between systems that duplicates a value rather than pointing at it. It earns its place because copying is simpler to build, works offline, and doesn't create a dependency between systems.
Where it falls short is that a copy is a fact that was true at a moment. If the connection stops working, and connections do, the systems drift silently and nobody notices until two records disagree. Two-way synchronisation is worse, because both sides believe they can be edited and something eventually has to resolve a conflict that nobody designed for.
Prefer one-directional flow from the authoritative source, and build a periodic comparison that reports differences rather than assuming the connection is working.
Decide in advance what happens when the comparison finds something, because the moment of discovery is a poor time to work it out. Overwriting the non-authoritative copy automatically sounds obvious and destroys the evidence of what diverged, which is the information needed to fix the cause rather than the instance. Flagging it for somebody to look at is slower and keeps the diagnosis available.
Spreadsheets built to answer one question and kept
Somebody extracts data to answer a specific question, the sheet is useful, and it persists. It earns its place because it answered something the official reporting couldn't, which is real information about a gap.
Where it falls short is that the extract is a snapshot presented as current. It gets forwarded, reused and quoted long after the data behind it moved, and because it looks like a report, nobody treats it as stale. It also puts personal data somewhere nobody has assessed for access or retention.
The question the sheet answers is worth more than the sheet. Bring the question into the official reporting and the sheet stops being recreated.
There is a second reason to care about these beyond the reconciliation problem. An extract taken once and kept sits outside whatever access arrangements you designed, in a location nobody assessed, frequently in somebody's personal storage. It will also outlive its author's involvement, and quite often their employment, which is the version of this that causes genuine difficulty when somebody eventually asks what is held and where.
Records held for compliance reasons nobody has reviewed
Data retained because somebody once said it had to be, in a location nobody revisits. It earns its place when the requirement is real, and frequently the requirement is genuine.
Where it falls short is that the reasoning is rarely recorded, so nobody knows which requirement drove it, whether it still applies, or when the retention period ends. Over years this accumulates into archives of personal data held on the basis of a rule nobody can cite, which is a poor position if somebody asks. Requirements differ by jurisdiction and by record type and several have changed, so what was correct when the decision was made may not be now.
Establish what you're actually required to retain, with local advice, and record the reason and the period alongside the data rather than in somebody's memory.
The reason matters as much as the period, and it is the part that never gets written down. Without it, the next person to review an archive faces material somebody kept deliberately, no explanation, and no safe way to decide, so the rational choice is to keep it and defer again. That is how retention decisions compound: each reviewer inherits the caution of the last one and nobody is ever in a position to act.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One system, no competing copies | Under fifty | Single system | None | Change nothing |
| Documents going to an old address | Any | Several systems | No authoritative source for one field | Decide that field, make others read |
| Reports disagreeing | Any | Several systems | Definitions or data, unclear which | Diagnose which, before reconciling |
| A change needs several updates | Any | Several systems | No propagation | One-directional flow from the source |
| A department keeps its own list | Any | Any | A real gap in the central record | Ask what it holds that yours does not |
| Leaver still active somewhere | Any | Several systems | Closure depends on remembering | One event, propagating outward |
| Cannot say what is held about a person | Any | Any | No inventory | List the systems first |
| Archives nobody can justify | Any | Long-established | Retention reasoning never recorded | Establish requirements, take advice |
| Considering consolidation | Over two hundred | Many systems | Ambiguity, not system count | Decide fields first, then reconsider |
The last row is worth pausing on, because consolidation is the response most organisations reach for and it's frequently a larger answer than the question needs. Deciding which system is authoritative per field removes most of the symptoms without a migration, and doing that exercise first tells you whether consolidation is actually necessary or whether the problem was ambiguity rather than architecture.
The third row matters because the two causes need opposite responses. If the definitions differ, both systems are correct and you need an agreement about which definition applies where. If the data differs, one is wrong and you need to find out why the change didn't reach it. Reconciling the number without diagnosing which case you have means doing it again next month.
Data That Should Not Be Where It Is
Some categories accumulate in the wrong place reliably, and they're worth looking for specifically rather than waiting for them to cause a problem.
Personal data in shared drives and message history. Documents attached to conversations, spreadsheets in a folder somebody set up, scans sent for a purpose and never deleted. This is the largest and least visible category in most organisations, and it's outside whatever access model you designed.
Sensitive material in the core record. Notes about performance or personal circumstances stored against the employee record because it was the obvious place. It then inherits the access model built for basic lookups, which is either too open for the note or gets tightened and makes ordinary lookups awkward.
Data about people who never joined. Applicant information kept indefinitely, particularly where recruitment and employee records share a system. These are people you have no ongoing relationship with, and what you may retain about them and for how long differs by jurisdiction, so it needs establishing rather than assuming.
Records of former employees held indefinitely. Often retained on the general principle that it might be needed. That principle isn't a basis, and retaining beyond what's permitted is itself a problem in many places rather than a cautious default.
Copies in the hands of people who moved on. Extracts taken for a project, sitting in personal drives long after the project ended and sometimes after the person changed roles. Nobody remembers these exist, which is what makes them hard to address.
The common thread is that all five are invisible to whoever designed the access model, because they exist outside it. That's why an inventory of systems is not sufficient on its own: the systems are the part you know about.
What to do about any of it is genuinely a local question. What you may hold, on what basis, for how long, who may access it and what happens when somebody asks all differ by jurisdiction, by sector and by data type, and several of these rules have been tightening. Establish your actual position with proper advice, then work outward from it. Designing a data policy from general principles and hoping it matches your obligations is the approach that produces unpleasant surprises.
Where HR Data Goes Wrong
| The failure | How it shows up | What would have to change |
|---|---|---|
| No authoritative source per field | Four addresses, all defensible | Decide field by field, write it down |
| Several systems editable for one field | Divergence nobody notices | One editable, the rest read |
| Copying integrations that silently stop | Records drift apart over months | One-directional flow, plus a comparison |
| Definitions differing between systems | Reports disagree, both correct | Agree which definition applies where |
| Leaver closure depends on memory | Access outliving employment | One event, propagating outward |
| Retention reasoning never recorded | Archives nobody can justify | Record the reason and the period |
The fifth row is the one with genuine exposure attached and it recurs because departure requires several systems to act while only some of them are visible. The account somebody uses daily gets closed promptly. The system they logged into twice a year does not, and nobody notices because nobody is looking.
The third row is the quiet one. A connection that stops working produces no error anybody sees, the two systems simply stop agreeing, and the divergence is discovered when somebody spots two records that differ. A periodic comparison that reports differences rather than correcting them silently is the cheapest available detection, and it also preserves the evidence of what went wrong.
What to Put in Writing
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| Which system is authoritative, per field | Whoever owns the systems | Before adding another system | Several defensible answers |
| Which fields are editable where | The same person | At the same time | Divergence with no detection |
| What each definition means, per system | HR with finance | Before reconciling anything | Reconciling the same gap repeatedly |
| The list of systems holding personal data | HR | Now, and at each addition | Being unable to answer a question |
| What happens on the last day, in order | HR with IT | Before the next leaver | Access outliving employment |
| What you must retain, and why, and how long | HR, with local advice | Before archiving anything | Archives nobody can justify |
The fourth row is the one worth doing regardless of anything else on this list. A list of every system holding employee personal data, including spreadsheets and shared locations, is the prerequisite for answering almost any question anybody will ask you about data. Most organisations cannot produce it, and producing it usually takes less time than expected and surfaces at least one thing nobody remembered.
Questions to Ask Before You Commit
On authority. Which system wins for this field? A bad answer is that it depends.
On editing. How many places can this be changed? A bad answer is more than one.
On flow. Does this integration copy or reference? A bad answer is that it syncs.
On definitions. Do both systems mean the same thing? A bad answer assumes so.
On leavers. What closes, and who triggers it? A bad answer names one person.
On retention. Why are we keeping this, and until when? A bad answer is just in case.
What Getting This Wrong Costs
The first cost is the correction that has to happen several times. Somebody moves, and the change reaches some systems and not others, and the gap surfaces weeks later when a document arrives at the wrong place. Each instance is small, faintly embarrassing, and lands on an individual who now has less confidence that the organisation has their details right. Repeated across a workforce, that's a steady low-level erosion nobody measures.
The second cost is the disagreement that consumes senior time. Numbers from different systems don't match, and because nobody has agreed which is authoritative or which definition applies where, the conversation becomes a reconciliation rather than a decision. That repeats at whatever interval the numbers are reviewed, and it never resolves, because the reconciliation addresses the instance rather than the cause.
The third cost is the one with real exposure and it's why this topic deserves more attention than its symptoms suggest. Being unable to say what you hold about somebody, where it is, who can see it and how long you'll keep it is a poor position when somebody asks formally, and access that outlived employment is worse. What's required of you differs by jurisdiction and by sector, and several requirements have been tightening, so this is a question with a specific local answer that you need to have established rather than assumed.
So start with the two cheapest things. Produce the list of systems holding employee personal data, including the spreadsheets. And take the handful of fields that cause visible problems, decide which system is authoritative for each, and write it down. Those two remove most of the symptoms and put you in a position to answer the question that matters.
When You Are Ready to Go Further
None of this needs consolidation, which is the response most organisations reach for and the largest available. It needs a list of where employee data lives, a decision per field about which copy is authoritative, and everything else reading rather than holding its own version.
Do the leaver sequence next, because it's the one with consequences. Write down every system that has to act when somebody departs, in order, and make it one event rather than several things somebody remembers. The systems that get missed are always the ones nobody opens daily, which is exactly where lingering access is least likely to be noticed.
Then establish your actual obligations, with proper local advice, about what you may hold, who may see it and how long it's kept. That's the piece that can't be worked out from first principles, it differs by where you operate, and it defines the answers everything else has to support. Once you have it, record the reason and the period alongside the data rather than in somebody's memory, because the memory leaves.
HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.
Frequently Asked Questions
What is a system of record in HR?
It's the system holding the version of a fact that everybody has agreed is correct, so that when two systems disagree, one of them is simply wrong rather than differently right. The important word is agreed, because this isn't a technical property that a product possesses. It's a decision people make and then respect, and it means nothing if nobody has made it. Most organisations have never made it explicitly, which is why several systems each hold an editable copy of the same detail and drift apart without anybody noticing.
Which system should hold employee data?
Not one system, which is where the question usually goes wrong. Different fields have different natural owners: the employment relationship belongs with the core record, what was actually paid belongs with payroll, enrolment choices belong with whoever administers them. The productive exercise is to decide field by field rather than system by system, using a simple test for each one, such as where the individual updates it themselves or where a change gets authorised. Trying to crown one system as authoritative for everything produces an argument about which product matters most.
Why do HR and finance headcount numbers disagree?
For one of two reasons that look identical from outside, and diagnosing which comes first. Either the definitions differ, in which case both systems are correct about different questions and you need an agreement about which definition applies to which purpose. Or the underlying data differs, in which case one of them is wrong and something failed to propagate. Reconciling the figure without establishing which case you have means the same reconciliation happens next month, because you addressed the instance rather than the cause.
How do you clean up scattered employee data?
Take the fields that cause visible problems, which is usually a short list covering address and contact details, position, reporting line and employment status, and decide the authoritative source for each. Then make every other system read from it rather than hold its own editable copy. You don't need to resolve every field in every system to stop the symptoms, and treating this as a complete data governance programme is the reason it usually never starts. Separately, produce a list of every place holding employee personal data, including spreadsheets.
Should you consolidate onto one HR system?
Not as the first response, because it's a larger answer than the question usually needs. Deciding which system is authoritative per field removes most of the symptoms without a migration, and doing that exercise first tells you whether consolidation is genuinely necessary or whether the problem was ambiguity rather than architecture. Consolidation is also expensive, disruptive, and frequently unavailable, since the other systems exist for reasons and removing one means losing something somebody depends on.
How long should employee records be kept?
Retention periods differ by jurisdiction, by record type and sometimes by sector, and several have changed in recent years, so there's no general answer that's safe to act on. Keeping everything indefinitely is not the cautious option it appears to be, since holding personal data longer than you're permitted to is itself a problem in many places. Establish what applies where you operate with proper local advice, then record the reason and the period alongside the data rather than in somebody's memory, because the memory leaves with the person.
Who should be able to see employee data?
A question with a local answer rather than a general one, and one worth establishing properly rather than inheriting from whatever defaults your systems shipped with. What you may hold, who may access it, on what basis, and what you must be able to demonstrate all differ by jurisdiction and by the kind of data involved. Most access models grew by accident, as people requested something once and kept the permission, and an accidental model is not a defence. Establish the requirement first, then design access to satisfy it.
What should you do about departmental spreadsheets?
Find them rather than banning them, because banning drives them out of sight while they continue to exist. Each one was built because the central record didn't hold something or couldn't produce a usable view, which is genuine information about a gap. Ask what the sheet contains that your record doesn't, and either add that or accept the sheet and document what's in it and who can see it. The risk isn't that they exist, it's that they hold personal data in a place nobody has assessed and quote numbers nobody can reconcile.
The system of record is a decision. Most organisations have several systems and no decision.
