TL;DR
- The real question: how many places the same employee fact is written down, and whether your team can keep them in sync without a system of record that everyone trusts.
- When doing nothing is right: when a small group runs the same payroll on one system, one team owns the source of truth, and no board member is asking why two numbers disagree.
- What has to be true: there's a named owner for each employee fact, and that owner is enforced by a system rather than by memory.
- How the options split: by where the record of truth lives, not by which logo is on the contract. The split is payroll-anchored, suite-anchored, integrator-anchored, or spreadsheet-anchored.
- Decision rule: match the architecture to the smallest unit of disagreement you've actually had, not the largest one you fear.
- Outcome to expect: a stack that survives two reorganisations and one finance audit without anyone rebuilding the headcount model from scratch.
The First Morning of the New Role
A CHRO walks into the office on day one and is shown the systems map. Three colours. Eleven rectangles. Dotted lines between them that someone has drawn in PowerPoint. The recruiter who drew it left nine months ago. The new CHRO asks where the headcount number lives and gets three answers in the same meeting.
The first answer is payroll, because payroll sends the money and the money is real. The second is the HRIS, because the HRIS holds the org chart and the org chart is what the board sees. The third is the spreadsheet the FP&A team keeps, because the FP&A spreadsheet is what the bank saw during the last refinancing. All three are right. None of them agree. The board is going to ask which is correct at the next meeting, and the CHRO has eight days to find out.
But the disagreement about headcount isn't the problem. It's a symptom. The real problem is that the organisation has built a stack by procurement, where each tool was the right call at the time and was bought by the person whose problem it solved. The board is now asking for a number that three systems should produce identically, and the absence of a single owner for that number is what the new CHRO has inherited.
Best tools for HR Strategy
When You Do Not Need to Act Yet
The suite versus best-of-breed debate is held as a philosophical one, and that's the first tell that the room has the wrong brief. Most organisations that think they have an architecture problem actually have a workload problem. They have too few employees to justify the project, too few seams to worry about, or too little disagreement between their systems for anyone outside payroll to notice. Acting when the picture is fine is worse than waiting, because every architecture change pulls the attention of the HR team away from whatever they're currently doing. Here are the four stages at which the decision changes shape.
Stage one: the current setup is genuinely fine. A team of forty that runs payroll and HR on a single cloud product, has never had a headcount disagreement, has one person who can answer any employee record question in under five minutes, and has not been approached by talent, learning or workforce planning teams who want a separate tool. The board has not asked for a number that the payroll system can't produce. The risk in acting here's that the HR leader reads four articles like this one, panics, and signs a five-year platform deal that adds work without removing any. If nothing is hurting, leave it alone for another budget cycle and revisit when the first sign of friction appears.
Stage two: friction, not risk. A group of two hundred with one core HR and payroll system, two point solutions bolted on for things the core doesn't do well, and one spreadsheet that the finance team maintains on the side. The friction is visible: someone has to copy data between systems, a field is updated in one place and forgotten in another, and the recruiter has learned not to trust the time-to-hire number. Risk is low because the payroll system still holds the legal record and nothing the board has asked for is in dispute. The right move is to name the owner of each fact and tighten the discipline around the seam, not to rip anything out.
Stage three: real risk. A company of one to three thousand with three or more systems in the talent stack, a finance team that keeps a parallel headcount model, and at least one board paper where the headcount in the appendix is different from the headcount in the slide. The payroll system holds the legal record. The HRIS holds the org chart. Neither is wrong. Neither is complete. The risk is that a finance decision gets made on the wrong number and someone notices afterwards. This is where the project becomes necessary, and where the choice between architectures starts to matter.
Stage four: the edge case that changes the answer. A regulated entity, or a group that has just been told by an external party that its data has to be defensible in a particular shape. The architecture question is no longer a productivity question. It's a record question. The systems now have to be auditable as a set, not just as individual products. This is the only stage at which the answer is forced: there has to be one system that owns the record, and the others have to be subordinate to it.
The Five Questions on the List at 11pm
What does the payroll system own, and can it keep owning it? Yes, in most cases, because payroll is the only system whose output is checked by a counterparty every single month. The reasoning is that the record of truth tends to gravitate toward the system whose mistakes are punished fastest. If you try to move the record of truth to a system that doesn't produce a payment, the move won't stick and you'll be back here in eighteen months. If you get this wrong, you build a second source of truth on top of the first, and the disagreement becomes permanent.
How many places is each employee fact written today? Count it. The HRIS, the payroll, the ATS, the learning platform, the access system, the finance model, and at least one spreadsheet someone has forgotten to tell you about. The reasoning is that the stack isn't a set of tools. It's the set of places the same fact appears, and the question is how many of those places you can keep synchronised without a person doing the work. If you get this wrong, you keep adding systems and the gap between them widens, because each new tool assumes one of the existing ones is right and it usually isn't.
Who is on the hook when two systems disagree? If the answer is no one, the stack is fragile. The reasoning is that an architecture without an owner of disagreements is a stack that quietly chooses the wrong number every time, because the loudest voice wins. If you get this wrong, every finance and people decision carries a small chance of being made on the wrong base, and no one will catch it until after the fact.
What is the smallest unit of disagreement we've actually had? The new CHRO in the opening has just inherited one. The reasoning is that the smallest disagreement tells you what the system can't resolve today, and the largest one tells you what you fear. You solve for the smallest first. If you solve for the largest, you'll oversize the project and the team will resist it. If you get this wrong, you either buy a platform too large for the problem or you patch around the smallest disagreement and watch it grow.
What does the board actually ask for? If the answer is "the headcount, by entity, as of the last working day of the month", the problem isn't architecture. The problem is whether the headcount can be produced on time and without manual work. The reasoning is that a board number that has to be hand-built is a process problem wearing an architecture costume. If you get this wrong, you'll spend two years replacing systems and still build the board pack by hand.
Three Honest Categories the Approaches Split Into
The procurement framing of this decision treats it as a binary: buy one suite, or buy many point solutions. The framing is wrong, and a lot of the cost of getting this decision wrong comes from accepting it. The reality is that there are three honest architectures and the choice between them is driven by where the record of truth already lives, not by which logo you want on the contract.
The single suite, with everything inside one product. What it is: one vendor, one database, one contract, one login, one support queue. When it's right: when the company is below a few hundred people, when the HR team is small enough that one person can know every corner of the system, and when no function has needs that the suite can't meet within a reasonable configuration. When it fails: the day the company acquires a business unit that runs a different suite, the day a function demands a capability the suite is two product cycles away from delivering, or the day the suite vendor's roadmap takes a turn the company can't follow. The failure mode is that escape gets expensive. Switching out of a single suite means switching out of everything, and the migration cost is the thing the original purchase avoided.
The best-of-breed stack, with an integration layer doing the joining. What it is: the best tool in each category, wired together by an integration platform or by a small data team that runs the joins. When it's right: when the company has at least one function whose needs are genuinely different from the rest, when the company has the technical depth to operate an integration layer, and when the seams between systems are owned by named people with time in their week to keep them tight. When it fails: the day a system changes its data model without telling anyone, the day the integration layer falls behind the systems it joins, or the day the company runs out of the people who understood how the joins work. The failure mode is silent decay. The systems keep working, but the joins rot, and no one notices until a number is challenged.
The payroll-anchored stack, with payroll as the record of truth. What it is: the payroll system holds the legal employee record, the HRIS and other tools are downstream of it, and changes flow in one direction only. When it's right: when the company has employees in more than one country, when the audit posture matters, or when the finance team already trusts payroll's number because it has to. When it fails: the day the HRIS has to do something payroll can't, the day a downstream system becomes the de facto source for a fact that payroll has not been asked to hold, or the day the two-way sync between payroll and HRIS gets built by accident. The failure mode is dual authority. The two systems both think they own a fact and the team has to choose which one is right, by hand, every time.
Five Diagnostic Questions You Can Self-Assess Against
Open the payroll system, the HRIS, and the finance headcount model. How many employees appear in all three with the same record? Count them. If the answer is exact, the systems are aligned and the problem is somewhere else. If the answer is close, the systems are aligned by effort and someone is doing the work. If the answer is a number with a delta you can't explain, the architecture is the problem.
Ask the recruiter, the payroll lead, and the finance business partner what the headcount is, right now, without looking anything up. If the three answers agree within the same minute, the record of truth is working. If they disagree, write down the three numbers and ask each person where theirs came from. The disagreement is the architecture problem rendered as a number.
Ask who would fix the data if a regulator asked for a particular record tomorrow. If the answer names a person and a system, the architecture is sound. If the answer is "we would have to pull it together", the architecture is missing a record of truth. If the answer is silence, the architecture is missing an owner.
Find the last time a field was changed in one system and not in another. How did anyone notice? If the notice was a complaint from a downstream user, the seam is leaking and the owner is missing. If the notice was a reconciliation report someone runs, the seam is held together by effort and the effort is the price of the current architecture. If the notice was a system alert, the seam is governed and the architecture is sound.
Ask the team how much of their week goes to copying data between systems, reconciling differences, or explaining why a number is what it's. If the answer is small, the architecture is fine for now. If the answer is more than a day a week for one person, the architecture is consuming capacity the team can't afford, and the question is no longer whether to change but what to change to.
Five Stack Architectures, Reviewed
A Single Suite Covering Core HR, Payroll and Talent
One product holds the employee record, runs payroll, and carries the talent suite. One contract. One login. One support queue. One team that knows the system end to end. This is the architecture that most companies below a few hundred people should be on, and most companies above that head off it by accident when one function demands a capability the suite can't deliver at the speed the function needs. It earns its place because it removes the question of who owns a fact: the system owns it, and the configuration decides who can edit it. The weakness is real and specific. The day the suite stops being the best tool for one function, the company faces a choice between accepting a worse outcome in that function or replacing the entire stack. The escape cost is the price of the original simplicity, and the larger the company grows, the more that price is collected.
A Suite for the Core With Point Solutions Bolted On for One or Two Functions
The suite holds core HR and payroll. One or two point solutions sit alongside for functions the suite can't meet, such as a learning platform with deeper content libraries, or a workforce planning tool with modelling the suite doesn't offer. This is the architecture most mid-sized companies end up in, and it earns its place because it lets each function pick the tool that does its job best while keeping the legal record in one place. The weakness is the seam. Every point solution that touches employee data has to agree with the suite on a set of fields, and the agreement has to be maintained by a named owner with time in their week. When the owner changes or the time disappears, the seam rots in silence, and the rot is only visible when a number is challenged.
Best of Breed Throughout, Joined by an Integration Layer
The best tool in each category, wired together by an integration platform or a small data team that runs the joins. This architecture earns its place when at least one function has needs that are genuinely different from the rest, when the company has the technical depth to operate an integration layer, and when the seams are owned by named people with time in their week. It's the most flexible architecture and the one that most resembles how mature tech organisations run other parts of their business. The weakness is silent decay. The systems keep working, but the joins rot when an integration platform falls behind the systems it joins, when a vendor changes a data model without notice, or when the people who understood the joins leave. By the time the decay is visible, the recovery is a project.
A Payroll-Anchored Stack Where Payroll Holds the Record of Truth
The payroll system owns the legal employee record. The HRIS and the rest of the stack are downstream of it. Changes flow in one direction. This architecture earns its place because payroll is the only system whose output is checked by a counterparty every month, and that discipline tends to keep the record cleaner than anywhere else. The weakness is dual authority. The day a downstream system becomes the de facto source for a fact that payroll has not been asked to hold, the two systems both think they own the fact, and the team has to choose which one is right, by hand, every time. The architecture only works if the direction of change is enforced by design and not by convention.
A Spreadsheet-and-Willpower Stack With No System of Record at All
The company runs the people data on spreadsheets and the discipline of the team. This is the architecture of organisations that grew faster than their tooling, of acquisitions that haven't been integrated, and of teams that haven't yet had the conversation that forces the decision. It earns its place in the very smallest companies, where the team is small enough that one person knows every employee by hand. The weakness isn't subtle. The first time the company has to answer a question that requires agreement between two spreadsheets, the answer has to be built on the spot, and the people who can build it are the people who have to do the work that day. It doesn't scale, and it doesn't survive an audit.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Single cloud product, one owner, no board-level number disputes | Under two hundred | Suite, single product | None visible | Hold. Revisit at first sign of seam friction. |
| Suite plus one or two point solutions, seams held by effort | Two hundred to one thousand | Suite core, point solutions on one or two functions | Data copying, field drift, recruiter does not trust the time-to-hire number | Name the owner of each seam. Add an integration platform only if a seam has rotted twice. |
| Three or more systems in the talent stack, finance keeps a parallel headcount | One to three thousand | Mixed, no clear anchor | Board has noticed the headcount differs depending on who is asked | Pick an anchor. Either payroll-anchored or suite-anchored. Stop buying tools until the anchor is enforced. |
| Multiple entities, multiple countries, audit posture matters | Above one thousand, regulated | Mixed, often layered by acquisition | Legal record and people record disagree on key fields | Payroll-anchored stack with downstream tools subordinated by design. |
| Acquired the second business unit last year | Five hundred to two thousand | Two suites, joined by willpower | Neither system is wrong, neither is complete | Pick the survivor. Migrate the smaller entity. Do not run two stacks in parallel longer than one budget cycle. |
| HR team is the bottleneck on every people decision | Any size | Mixed, often best of breed | The HR team spends the week reconciling instead of deciding | The architecture is not the problem. The team is. Hire or reassign before changing systems. |
| No system of record, everything on spreadsheets | Under one hundred, fast growing | None | Cannot produce the headcount without manual work | Buy a single suite. Do not buy a best-of-breed stack. The organisation cannot operate the joins. |
| Best-of-breed stack, integration layer is one person's job | Above five hundred | Best of breed, joined by an integrator | Bus factor on the integration layer is one | Document every join. Name a second owner. Then decide whether the architecture is the right one. |
What Breaks at the Seams
| Fact that has to travel | Systems it travels between | What goes wrong when it does not | Who notices first |
|---|---|---|---|
| New hire starts next Monday | ATS, HRIS, payroll, access system, finance headcount model | The person has no email, no building access, and no record in payroll. Finance has not budgeted the headcount. | The new hire. Then their manager. |
| Employee moves team | HRIS, payroll, access system, finance model | The employee's cost centre is wrong, payroll is paying the wrong entity, access has not been revoked on the old systems. | Finance, at month end. |
| Compensation changes | HRIS, payroll, finance model, equity admin | Payroll is paying the old amount, finance has budgeted the new amount, equity is granting on the old number. | The employee. Then payroll. |
| Employee leaves | HRIS, payroll, access system, finance model, ATS (reopen the requisition) | The leaver still has access, payroll overpays into the notice period, the requisition is not reopened and the backfill is late. | The security team. Then finance. |
| Title or grade changes | HRIS, payroll, finance model, equity admin | Promotion is reflected in HRIS but not in payroll, equity grant is on the old grade, finance reports the old cost. | The employee. Then the compensation team. |
| Working pattern changes (hours, location, country) | HRIS, payroll, access system, finance model | Payroll is paying the wrong hours in the wrong country, access has not been reissued for the new location, finance has not adjusted the cost. | Payroll, at the next pay run. |
| Headcount as of a date | HRIS, payroll, finance model | Three different numbers. The board is asked to choose. | The board. |
The Migration You Are Actually Signing Up For
Architecture changes look like software decisions on paper. They're organisational decisions in practice. The cost that never appears on an invoice is the cost of the team's attention, and the cost that always appears under the migration line is the historical data question.
The historical data question is what happens to the employee records that lived in the system you're leaving. The answer depends on three things the vendor won't tell you up front. First, the shape of the export. Most systems can produce a CSV. Few produce a CSV in a shape another system can ingest without manual work. Second, the fields that don't have a clean destination. Compensation history, leave balances, performance records, and the fields you forgot you were tracking. Third, the system that owns the data during the transition. The migration isn't a weekend. It's a period during which two systems both claim to hold the record, and the team has to choose which one is right, by hand, for every disputed field.
The honest answer about implementation timelines is that they depend on data quality rather than on the software. Press any vendor on this and you'll get a range. The bottom of the range assumes clean data, one entity, no acquisitions, no parallel payroll, and a team that has nothing else to do. The top of the range assumes the opposite of each of those. The difference between the bottom and the top isn't a quarter. It's a year.
The attention cost is harder to estimate and easier to underestimate. The HR team that runs the migration also runs the business. The person who knows the data best is the same person who has to answer the most questions about it. The project absorbs the team for the duration, and the work the team was doing before doesn't get done. Plan for it. Don't pretend the project is a side activity.
A migration that goes well leaves behind a system that the team trusts, a set of artefacts that explain how the data moved, and a smaller number of seams than the company started with. A migration that goes badly leaves behind two systems that both claim to hold the record, a team that's exhausted, and a board that has stopped asking the headcount question because the answer is no longer credible.
What to Put in Writing
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| A one-page architecture map showing every system, the fact it owns, and the systems it sends that fact to | The HR operations lead | At the decision and at every material change | The drift where a system quietly becomes a source of truth without anyone deciding it should be |
| A record-of-truth register: one row per employee fact, one column for the system that owns it, one column for the system that reads it | The HR operations lead | At the decision, updated whenever a new system joins the stack | The dual-authority problem where two systems both think they own the same fact |
| A seam ownership register: one row per seam between systems, one column for the person who owns the seam, one column for the integration mechanism | The HR operations lead, signed off by the HR director | At the decision, reviewed quarterly | The silent decay where a seam rots because no one is on the hook for it |
| A migration plan with the historical data question answered in writing, including the fields that will not migrate and the decision for what happens to them | The project lead, signed off by the HR director and the CFO | Before the migration starts, not during | The migration that discovers the historical data problem on day forty and has to renegotiate the plan |
| A decision record explaining why this architecture was chosen over the alternatives, including what the alternatives would have solved and what they would have cost | The HR director, signed off by the CHRO | At the decision, kept in the HR file | The repeat of the decision by the next person in the role, who would otherwise rebuild the reasoning from scratch |
| A board pack that shows the headcount, by entity, as of the last working day of the month, produced by the system without manual work | The HR operations lead, signed off by the CHRO | At every board cycle | The board asking why the headcount differs depending on who is asked |
| A runbook for the day two systems disagree, naming who decides, how the decision is made, and how the disagreement is logged | The HR operations lead | At the decision, tested once a quarter | The disagreement that is resolved by the loudest voice, which is rarely the right one |
| An exit clause review: what the contract says about data export, data residency, and the period during which the vendor will help answer questions about the historical record | The procurement lead, signed off by legal | Before the contract is signed | The discovery, eighteen months after the contract ends, that the historical data is in a shape no one can read |
Questions to Ask Before You Commit
Ownership. Who owns the employee record of truth, in writing, and what happens to that ownership if you change vendors? A bad answer sounds like "the data lives in the system". The data lives wherever the team puts it. The answer you want names a system, a person, and a review cadence.
Seams. Show me, in this room, every place an employee fact is written down, and tell me which system owns it and which system reads it. A bad answer sounds like "we've integrations". Integrations are the mechanism. The question is which side of the integration is the source.
Bus factor. If the one person who understands the integration layer left tomorrow, what would break, and how long would it take you to notice? A bad answer is silence. The answer you want names a second person, a runbook, and a test that proves the second person can run the show.
Historical data. If we replaced the core system tomorrow, which fields wouldn't migrate cleanly, and what is your plan for each one? A bad answer sounds like "we can export everything". Export isn't migration. The answer you want names the fields, the destination, and the decision for what happens to the ones with no clean destination.
Migration. What is the shortest and the longest implementation you've seen for a company of our size and shape, and what made the difference? A bad answer is a single number. The honest answer is a range, and the difference between the ends is data quality and team capacity, not the software.
Audit. If a regulator asked for a particular record tomorrow, which system would you produce it from, and how long would it take? A bad answer is "we would have to pull it together". The answer you want names the system, the field, and a time in minutes.
Board number. How is the headcount, by entity, as of the last working day of the month, produced today, and which system produces it? A bad answer involves a spreadsheet and a person. The answer you want names a system and shows it being produced without manual work.
Roadmap. What is on your product roadmap for the next eighteen months that would change the answer to the question I just asked? A bad answer is a marketing deck. The answer you want names the changes, the dates, and the consequences for the seams.
Contract. What does the contract say about data export, data residency, and the period after termination during which you'll help us answer questions about the historical record? A bad answer is a standard clause. The answer you want is specific, in writing, and reviewed by someone who has lived through an exit.
Reference. Give me a reference at a company of our size and shape that has been on your product for at least three years and has been through the kind of change we are planning. Talk to them before you sign.
The Cost of Getting This Wrong
The cost that appears on an invoice is the licence, the implementation, and the migration. The cost that doesn't appear is the one that lasts longer. It's the cost of the team's attention, diverted to reconciling systems instead of running the business. It's the cost of the board's trust, lost one disagreed number at a time, until the board stops asking and starts assuming. It's the cost of the next HR leader, who inherits the stack and spends the first year rebuilding what the last one built, because the artefacts that would have explained the decision are missing.
The cost is also the cost of the question that never gets asked, because the architecture made it too expensive to answer. A company that can't produce the headcount without a manual build will stop asking questions that depend on the headcount. A company that can't produce the cost of a team without a parallel spreadsheet will stop asking questions about team cost. The architecture doesn't just cost money. It costs the questions the organisation is willing to put on the table. So the question to put to the room, before the contract is signed, is the one the architecture will have to answer for the next five years: what is the question we are most afraid to ask, and will this stack let us ask it?
When You Are Ready to Go Further
If the decision in front of you is more specific than this article can answer, that's the right place to be. The architecture question is settled by the smallest unit of disagreement you've actually had, not by the largest one you fear, and the smallest unit is something only your team can name.
HROpsLab publishes independent, side-by-side comparisons of the platforms in each category, written for HR leaders who already know the question they're trying to answer. The work is editorial. Nothing is sold. No software is supplied. No payroll is run. No advice is given. The comparisons exist because the suite-versus-best-of-breed debate is held as a philosophical one when it's actually a procurement one, and procurement decisions deserve evidence the vendor won't provide. When you're ready to put the architecture in writing, the comparison work is there.
Frequently Asked Questions
What is an HR tech stack?
An HR tech stack is the set of systems an organisation uses to hold employee data, run payroll, manage hiring, support learning, plan workforce, and produce the numbers the business asks for. It isn't a list of software. It's the set of places the same employee fact appears, and the question that defines the stack is which of those places is the source and which are copies. The stack is healthy when the answer is enforced by design and visible in writing. The stack is fragile when the answer is enforced by memory and lives in one person's head.
Does a small company need an HR tech stack at all?
A company below a few dozen people can run on the discipline of the team and a small set of tools, and often should. The stack becomes necessary when the company has more employees than one person can hold in their head, when the board or an external party asks for a number the team has to produce on demand, when more than one person needs to edit employee data at the same time, or when payroll has to be run in more than one place. Below those thresholds, the stack is overhead. Above them, it's the only way the work gets done.
How do I decide which system holds the record of truth?
The record of truth tends to gravitate toward the system whose mistakes are punished fastest. In most organisations that system is payroll, because the output is checked by a counterparty every month. In some organisations it's the HRIS, because the HRIS holds the org chart and the org chart drives decisions the business cares about. The test is which system's output the leadership team won't override when it disagrees with another system's output. That system is the record of truth, whether or not anyone has written it down. The decision has to be made, written down, and enforced by the direction of change between systems.
What does an integration layer do, and when do I need one?
An integration layer is the mechanism that moves data between systems and keeps them in agreement. It can be a commercial integration platform, a set of scripts maintained by a data team, or a managed service. You need one when the stack has more than two systems that hold overlapping employee data and the seams between them have to be maintained by something other than a person copying a value once a quarter. You don't need one when the stack is small enough that the seams can be held by effort, and when the effort is owned by named people with time in their week.
Should I buy the suite my payroll provider sells?
Often, yes, when the suite does the job and the company is below the size at which the suite starts to constrain a function. The test is whether the suite meets the needs of every function that touches employee data at a level the function will accept, not whether it meets the needs of HR at a level HR will accept. The risk of buying the suite is that escape gets expensive, and the larger the company grows, the more that price is collected. The risk of not buying it's that the seams rot and the team spends its week reconciling. The honest answer is that the suite is right until the day a function's needs exceed it, and that day is sooner than the vendor will tell you.
How do I tell if my stack is the problem or my processes are?
Take the smallest unit of disagreement you've actually had and ask whether a better stack would have prevented it. If the answer is yes, the stack is part of the problem. If the answer is no, the processes are the problem and a new stack won't fix them. The diagnostic that catches most cases is to ask who is on the hook when two systems disagree. If the answer is no one, the stack is fragile. If the answer is a person, the stack may be fine and the process is the thing to fix.
What do I do when two systems disagree about headcount?
Pick the system that holds the record of truth, in writing, before the disagreement happens. When the disagreement occurs, name the owner, give them the authority to decide, log the decision and the reason, and tell the other system which value to use until the source is updated. The discipline that prevents the disagreement from recurring is the one that names the source and the direction of change. The discipline that prevents the disagreement from being a crisis is the one that names the owner before the disagreement happens.
The work above was written for HR leaders who already know the question they're trying to answer, and who need the answer in writing before the room asks for it.
