TL;DR
- The core decision: whether you need a system of record or a system that does a job, because those are different purchases and get confused constantly.
- When doing nothing is right: when one person maintains the spreadsheet, knows it's right, and nobody else needs to read it.
- What has to be true: somebody can say which system holds the correct answer to who works here, and be believed.
- How the options split: by what the system is authoritative for, not by how many modules appear on the pricing page.
- Decision rule: if two systems can disagree about whether somebody is employed, you have a record problem, not a feature problem.
- Outcome to expect: fewer arguments about numbers, because the numbers finally come from somewhere.
The Headcount Question Nobody Can Answer
Somebody senior asks how many people work here. It sounds like the easiest question in the organisation.
Finance says one number, because finance counts anybody being paid this month. HR says a different number, because HR counts anybody with a live contract, which includes two people on extended leave and excludes three contractors finance is paying. The person who maintains the spreadsheet says a third number, because their sheet was accurate on the first of the month and four things have happened since.
All three are defensible. None of them is wrong, exactly. And there's no way to settle it, because nobody ever decided which of the three is supposed to be right.
Best tools for HRIS Software
That is the problem an HRIS exists to solve, and it is a smaller and more specific problem than the category's marketing suggests. An HRIS is a system of record for people data. It holds the authoritative answer to who works here, on what terms, reporting to whom, since when. Everything else the category offers sits on top of that foundation and is worth very little if the foundation is wrong.
Most disappointment with these systems comes from buying one as something else. Teams buy an HRIS expecting a payroll engine, a reporting tool, a workflow automation layer, or a way of making HR look like it has caught up with the rest of the business. Then they get a system of record, which does not feel like any of those things in the first month, and they conclude the product underdelivered.
So the useful question before any of this is not which system to buy. It's whether the thing you actually need is an authoritative record, or whether it's a specific job done well, because the answer changes what you should be looking at entirely.
When You Genuinely Do Not Need to Act Yet
Your current setup is genuinely fine. One person maintains a spreadsheet, they know it's accurate, and the number of people who need to read it is small enough that questions get answered by asking them. This is not a failure state. A spreadsheet owned by a competent person is more reliable than a badly configured system, and considerably cheaper.
Friction is starting to show. Two people now maintain versions, somebody asked for a number and got a stale one, or the person who owns the sheet took leave and nobody could answer a basic question that week. These are the first real signals. They usually justify agreeing where the authoritative copy lives rather than buying anything.
It has become a real cost. Numbers disagree often enough that meetings stall on reconciliation, a leaver kept appearing somewhere they shouldn't, or somebody spends a recurring chunk of each month rebuilding the same view by hand. At this point the absence of a record is producing measurable waste, and that's a different case from wanting a better tool.
The edge case that forces it. You need to evidence something about employee records, you operate somewhere with specific obligations about personal data, or an audit has asked a question you can't answer from what you hold. Requirements around what must be recorded, who may access it, how long it's kept and how it moves between countries differ sharply by jurisdiction and have been changing in several places. Establish what applies where you operate and take local advice, then let that define the requirement rather than working backwards from a product.
Five Questions This Reader Asks at 11pm
What does HRIS stand for, and does it matter? Human Resource Information System. The expansion tells you almost nothing useful, which is the honest answer, because the words describe a category rather than a capability. What matters is the second word: information. It's a system for holding and serving information about people, and any product that positions itself around workflows or engagement while treating the record as an afterthought will disappoint you in a way that's hard to articulate at the demo stage.
Is an HRIS the same thing as payroll? No, and this is the most common confusion in the category. Payroll calculates and pays. An HRIS holds the facts payroll needs: who is employed, on what terms, at what rate, with what changes effective when. Some products do both, which is convenient and blurs the distinction unhelpfully, because it lets teams assume the record is correct on the grounds that people got paid. People get paid from whatever payroll holds, which may or may not match reality.
Do we need one at our size? Size is the wrong variable and everybody uses it anyway. The variable that matters is how many people need to rely on the same answer without asking a person. Two people who sit together don't need a system. Forty people spread across three locations, where a manager needs to know who reports to them and finance needs a headcount that matches, need one considerably more than the number of employees suggests.
What data goes in it? Less than vendors imply and more than teams expect. The core is the employment relationship: identity, contract terms, position, reporting line, dates. Around that sits everything else people want to store, and most of it should live elsewhere and point back. The test is whether a field describes the employment relationship or describes an event that happened during it, because the first belongs in the record and the second usually belongs in the system that produced it.
Will it replace our spreadsheets? Some of them, and not the ones you expect. It'll replace the master list, which is the one that matters. It won't replace the analytical sheets people build to answer a specific question, because those exist precisely because they do something the system doesn't, and they'll keep being built. That's fine as long as they pull from the record rather than maintaining their own copy of it.
What Sits Inside the Record, and What Sits Beside It
The single most useful thing to get right early is which data belongs in the core record and which belongs in a system that references it. Teams that get this wrong end up with a record so wide that nobody maintains it.
| Data | Belongs in the core record | What goes wrong when it lives elsewhere |
|---|---|---|
| Identity and contact details | Yes, authoritative | The same person known differently in four places |
| Employment terms and changes | Yes, with effective dates | Nobody can reconstruct what was true last quarter |
| Position and reporting line | Yes, authoritative | Org charts and approvals silently diverge |
| Pay rate and its history | Yes, as terms; the run belongs to payroll | The record says one thing, the payslip another |
| Absence balances and requests | Referenced, not held | Two balances, both defensible, neither trusted |
| Documents and signed agreements | Linked, with the record as the index | Files nobody can find when somebody asks |
| Performance and development notes | Beside it, not inside it | A record too sensitive for the people who need the basics |
| Recruitment history before hire | Beside it, linked at start | A record cluttered with people who never joined |
The last two rows cause the most trouble in practice, and for opposite reasons. Performance material dragged into the core record forces an access problem: the people who need to look up a phone extension shouldn't see a performance note, so permissions get tightened, and then the basic lookups everybody needed become awkward. Recruitment data pulled in at the wrong moment leaves you with a record full of candidates, which quietly breaks every count you run.
A note on the fourth row, because it catches people. Holding pay terms in the record is right and it does not make the record a payroll system. The record says what was agreed and when it takes effect. Payroll says what was actually paid. Those can differ for entirely legitimate reasons, and an organisation that treats them as the same thing loses the ability to notice when they shouldn't.
What you hold, who can see it and how long you keep it are also not purely design choices. Obligations around employee personal data differ by jurisdiction and by sector, and several have shifted recently. Establish what applies where you operate, with local advice, before you decide the shape of the record rather than after.
Five Diagnostic Questions You Can Self-Assess Against
If two systems disagree about somebody, which one wins? Ask it about a real person. If the answer is that somebody would go and check, you have no system of record, whatever you own. This one question separates organisations that have an HRIS from organisations that have bought one.
Can you reconstruct what was true three months ago? Not what you believe was true. Whether the system can show you the position, the reporting line and the terms as they stood on a date. Records that only hold the current state are considerably less useful than they appear, because every question about change becomes unanswerable.
How does a change get in? Trace one. Somebody gets promoted: who types it, into what, and what happens downstream. If the honest answer involves a message to one person who then updates several places from memory, that person is your system of record and they're going on holiday at some point.
What happens on the last day? Leavers are where records rot. If somebody leaving requires a person to remember to close access, update the count, and stop the payroll instruction separately, one of those will eventually be missed, and the one that gets missed is usually the access.
Who can see what, and did anybody decide? Most access models are accidents of implementation. Somebody needed a report once, got a permission level, and kept it. This matters more as the record widens, and it's worth deciding deliberately rather than discovering later. What you're obliged to control differs by jurisdiction, so treat this as a question with a local answer rather than a general one.
Six Things People Buy an HRIS For, Reviewed
Replacing a spreadsheet that has become dangerous
The most honest reason and the most common. The sheet works until the person who owns it is unavailable, until two versions exist, or until somebody pastes over a formula and nobody notices for a month. It earns its place as a trigger because the risk is real and the fix is the core of what these systems do.
Where it falls short is the expectation that follows. A spreadsheet is instantly editable by somebody who understands it, and a system is not. The first months after a migration frequently feel slower, because things that took one person thirty seconds now involve a form, a field that won't accept the value, and a permission somebody has to grant. That's the cost of the record being defensible.
Go in expecting the speed to drop before it improves, and tell whoever sponsored the purchase that too.
There's a second expectation worth setting at the same time. A spreadsheet tolerates ambiguity quietly, because a human reading it applies judgement to the odd row that looks wrong. A system does not, so migration surfaces every record that was never quite right: the person with two start dates, the contract type nobody could categorise, the leaver who was never marked as one. That clean-up is the real work, it lands on your team rather than the vendor's, and it is the single most common reason these projects run past their date.
Getting employees to update their own details
Somebody changes address once and tells three people, and only two of them act on it. Pushing that to the individual is sensible, because the person who moved is the only one who definitely knows. It earns its place on data quality more than on time saved.
Where it falls short is the assumption that people will do it. Updating your own record is a task with no deadline and no consequence for the individual, so it happens when something forces it, which is usually when a payslip goes to the wrong place. Adoption for this specific task is reliably worse than teams expect, and chasing it is awkward because the person is doing you a favour.
Tie it to a moment that already matters to them and it works. Leave it as a general invitation and it won't.
It also matters which fields you open up. Address and bank details are worth pushing to the individual because they are the only reliable source. Job title and reporting line are not, because those are organisational facts rather than personal ones, and letting people edit them produces a record that reflects what everybody believes their job is rather than what was agreed.
Producing headcount numbers somebody trusts
The reason finance usually supports the purchase. It earns its place because the reconciliation work it removes is genuinely expensive and genuinely recurring, and because arguments about numbers consume senior attention out of all proportion to the stakes.
Where it falls short is that the system doesn't create agreement, it just holds one. If nobody has decided whether a person on extended leave counts, or whether a contractor appears, the new system will produce a number with the same ambiguity in it and more authority behind it. That's arguably worse, because a confidently wrong number stops the conversation.
Write the definitions down before go-live. It takes an afternoon and it's the part that determines whether anybody trusts the output.
Automating an approval that keeps getting missed
Something requires sign-off, the sign-off happens by message, and occasionally it doesn't happen at all. Routing it through the system makes it visible and creates a record of who approved what. It earns its place where the approval has consequences and the current process leaves no trace.
Where it falls short is scope creep. Approval routing is easy to build and easy to add to, and a year later there are eleven approval chains, four of which route to somebody who has changed roles. Nobody audits them because nobody owns them collectively.
Automate the approvals that matter and leave the rest as conversations. Write down what each chain is for, so it can be deleted later without anybody being afraid to.
Holding documents and records in one place
Contracts, signed agreements, letters confirming changes. It earns its place because the alternative is a shared drive where naming conventions decayed years ago, and because being able to produce a document when somebody asks is occasionally important rather than merely tidy.
Where it falls short is that storage is not organisation. Uploading files into a system attached to a person is better than a folder tree, and it still leaves you with whatever was uploaded, including three versions of the same contract with no indication which was signed. The system indexes; it does not curate.
Decide what the record is the index for, and what it simply stores. Retention and access obligations differ by jurisdiction, so establish those locally before designing the structure.
Satisfying somebody senior who wants HR to look modern
Worth naming because it's a real driver and rarely stated. Somebody has seen a demo, or a peer has one, and there's a general sense that the function should be more systematic. It earns its place occasionally, because that sponsorship is what unblocks a budget for work that genuinely needed doing.
Where it falls short is that it produces no requirements. A purchase driven by appearance has nothing to evaluate against, so it gets decided on demo quality, and the team inherits a system configured to show well rather than to fit. The failure appears in month four as a series of small mismatches nobody can attribute.
If this is the actual driver, use the sponsorship and supply the requirements yourself. The budget is real even when the reasoning isn't.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One owner, accurate sheet, few readers | Under twenty | Single location | None | Change nothing |
| Two versions of the list exist | Any | Any | No agreed authoritative copy | Decide which copy wins, in writing |
| Numbers disagree in meetings | Any | Several systems | Definitions, not tooling | Write the definitions first |
| Owner of the sheet is a single point of failure | Any | Any | Knowledge in one person | A record others can read and change |
| Managers cannot see their own team | Over one hundred | Multiple teams | No served view of the record | A system with a manager view |
| Changes reach some systems and not others | Any | Several systems | No propagation from one source | Establish the source, then connect |
| Cannot show what was true on a past date | Any | Any | Record holds current state only | Effective dating in the core record |
| Audit or evidence request you cannot answer | Any | Regulated or multi-country | Obligations, not convenience | Establish requirements locally, then specify |
| Somebody senior wants a system, no stated problem | Any | Any | Sponsorship without requirements | Supply the requirements before shortlisting |
The third row is the one worth catching before you spend anything. When numbers disagree, the instinct is to buy something that produces a single number, and that works only if somebody has decided what the number counts. Most organisations discover after purchase that headcount was never defined, and the new system simply automates one of the three defensible answers without anybody agreeing it was the right one.
The last row is more common than teams admit. It isn't a reason to refuse, because the sponsorship is genuinely useful and rarely available twice. It's a reason to do the requirements work quickly, before the demos start setting expectations nobody wrote down.
The Question the System Has to Answer
Who works here sounds like it has one answer. It doesn't, and the gap between the question and the answer is where most of the difficulty in this category lives.
Consider the ambiguities in a single organisation. Somebody has accepted an offer and starts in three weeks: employed or not? Somebody is on extended leave and will return: counted or not? Somebody works through an agency, sits with your team and uses your systems: yours or not? Somebody resigned last week and works a notice period: current or leaving? Somebody has two part-time positions in different departments: one person or two?
Every one of those has a defensible answer in both directions, and the correct answer differs by what the number is for. A capacity conversation wants the person on extended leave excluded. A cost conversation might want them included. An access review wants the notice-period leaver flagged. A legal question about who you employ may treat the agency worker differently from how your team experiences them.
This is why a system of record is a decision rather than a purchase. The product provides fields and the ability to serve consistent answers. It cannot tell you what your organisation means by employed, and if it could, the answer would be wrong for at least one of the conversations above.
The practical approach is to define the base record precisely and let the views differ. The record holds facts: this person, this contract type, these dates, this position, this status. Then each consuming question applies its own rule to those facts. Headcount for capacity excludes certain statuses; headcount for cost includes others. Both come from one record, both are reproducible, and when they disagree the disagreement is explainable.
What breaks this is storing the interpretation instead of the fact. A field called active that somebody sets by judgement rather than derives from dates and status will diverge from reality within months, and every number built on it inherits the drift.
Where the Record Goes Wrong
| The failure | How it shows up | What would have to change |
|---|---|---|
| No agreed authoritative source | Three answers to one question | Decide the source, field by field |
| Current state only, no history | Cannot reconstruct a past date | Effective dating on the core fields |
| Interpretation stored as a fact | A status somebody sets by judgement | Store facts, derive the view |
| Leaver process has separate steps | Access left open after departure | One event, propagating outward |
| Record widened without an access model | Basic lookups become restricted | Decide what sits inside and beside |
| Changes entered by one person from memory | The record is really a person | A route anybody can use |
The third row is the subtle one and it does the most long-term damage. A field that somebody maintains by opinion looks identical to a field the system derives, right up until they disagree. Because it looks authoritative, nobody questions it, and by the time somebody notices, every historic report built on it is suspect.
The fourth row is worth acting on regardless of what you buy. Departure is the moment when several systems need to act, and it's the moment most likely to be handled by somebody remembering. Access that stays open after somebody has left is the failure with consequences attached, and it's usually not discovered by the organisation.
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 buying anything | Three defensible answers to one question |
| What headcount counts and excludes | HR with finance | Before go-live | Automating an undecided definition |
| What sits inside the record and beside it | HR | During design | A record too wide for anybody to maintain |
| How a change enters, per change type | HR | Before go-live | The record being one person's memory |
| What happens on the last day, in order | HR with IT | Before the first leaver | Access outliving employment |
| What you are obliged to hold and for how long | HR with local advice | Before design | Designing against assumed requirements |
The second row costs an afternoon and determines whether anybody trusts the system afterwards. Get HR and finance in a room, take the awkward cases (notice periods, extended leave, agency workers, dual positions), and write down what each is counted as and for which purpose. Nobody enjoys this meeting. Every organisation that skips it has the same argument repeatedly for years.
Questions to Ask Before You Commit
On purpose. Are we buying a record or a job done? A bad answer is both.
On authority. Which system wins a disagreement? A bad answer is that it depends.
On history. Can we see a past date? A bad answer is that reports are kept.
On definitions. What does headcount count? A bad answer is everybody.
On change. How does a promotion get in? A bad answer names one person.
On obligations. What must we hold, where we operate? A bad answer is a general one.
What Getting This Wrong Costs
The first cost is the recurring argument, which is expensive precisely because it looks trivial. Senior people spend time reconciling numbers instead of deciding things, and the reconciliation produces no lasting improvement because the underlying ambiguity survives every time. An organisation can run this loop for years and never attribute the cost to a missing decision.
The second cost is the decision made on a wrong number. Most of the time the disagreement is visible and somebody catches it. Occasionally a plan gets built on a figure that counted the wrong population, and the error surfaces after commitments have been made. That's rare and it's the reason the boring definitional work is worth doing before anybody needs it.
The third cost is the one with genuine exposure attached. Employee records that nobody can produce on request, access that outlived employment, or personal data held somewhere nobody remembers all become problems at the moment somebody asks a formal question. Obligations here differ by jurisdiction and by sector and several have been tightening, so the position you're in is a local question rather than a general one. Establish it with proper advice, because this is the category where getting it wrong is not merely inefficient.
So before looking at any product, settle three things. Which system is supposed to be right, what the counts mean, and what you're actually obliged to hold. A system bought before those answers exist will encode whatever confusion is already present, and give it an authority it hasn't earned.
When You Are Ready to Go Further
None of this needs a purchase to begin. It needs a written statement of which system is authoritative for each field, a definition of headcount that HR and finance both signed, and a traced route for how one ordinary change gets into every place it needs to reach.
Do that first and two things happen. Some organisations find the spreadsheet was fine and the problem was an undecided definition, which is a genuinely good outcome and costs nothing. The rest arrive at a vendor conversation with requirements instead of impressions, which changes what the demos are able to do to you.
The step after that, once a record exists and is trusted, is to stop building views by hand. A count that somebody rebuilds each month is a count that will eventually be rebuilt wrong, and the fix is to serve it from the record rather than to be more careful.
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 an HRIS?
It's a system of record for people data, which means it holds the authoritative answer to who works here, on what terms, reporting to whom, and since when. The expansion of the acronym, human resource information system, is less useful than the second word in it: the point is information, held once and served consistently. Everything else these products offer sits on top of that foundation, and if the foundation is wrong, the features built on it inherit the error. Most disappointment in this category comes from buying one expecting a payroll engine, a reporting tool or an automation layer.
What is the difference between an HRIS and payroll?
Payroll calculates and pays; an HRIS holds the facts payroll works from. The record says who's employed, on what terms, at what rate, with which changes effective when. Payroll says what was actually paid in a given run. Some products cover both, which is convenient and blurs a distinction worth keeping, because it encourages teams to assume the record must be right on the grounds that people got paid correctly. People get paid from whatever payroll holds, and that can drift from the record for entirely ordinary reasons if nothing reconciles them.
Does a small company need an HRIS?
Size is the wrong test, though everybody uses it. The question that matters is how many people need to rely on the same answer without asking a person. If one competent owner maintains a spreadsheet and the handful of people who need it can simply ask them, that's a working arrangement and it's cheaper and faster than a system. The signals worth acting on are a second version appearing, the owner becoming a single point of failure, or numbers disagreeing often enough that meetings stall while somebody reconciles them.
What data should an HRIS hold?
The employment relationship itself: identity, contract terms and their history, position, reporting line and dates. The useful test for anything else is whether a field describes the relationship or describes an event that happened during it, because the first belongs in the record and the second usually belongs in the system that produced it and should be referenced rather than copied. Performance notes and pre-hire recruitment data are the two that most often get pulled in wrongly, the first creating an access problem and the second quietly corrupting every count.
Will an HRIS replace our spreadsheets?
It should replace the master list, which is the one that matters, and it won't replace the analytical sheets people build to answer specific questions. Those exist because they do something the system doesn't, and they'll keep being built no matter what you buy. That's acceptable as long as each one pulls from the record rather than maintaining its own copy, because a sheet with its own copy of the data is a second record and will diverge. Expect the master list to move and the working sheets to persist.
Why do our headcount numbers never match?
Almost always because nobody wrote down what headcount counts. The ambiguous cases are consistent across organisations: somebody who has accepted an offer but not started, somebody on extended leave, an agency worker who sits with your team, somebody working a notice period, somebody holding two part-time positions. Each has a defensible answer in both directions, and the right answer genuinely differs depending on whether the number is for capacity, cost or access. The fix is to store the underlying facts and let each view apply its own rule, rather than storing somebody's interpretation as though it were a fact.
How long does it take to get value from an HRIS?
Longer than the demo implies, and the first months frequently feel slower than what came before. A spreadsheet is instantly editable by somebody who understands it; a system involves a form, a field that rejects a value, and a permission somebody has to grant. That friction is the cost of the record being defensible rather than convenient, and it's worth saying out loud to whoever sponsored the purchase before they experience it. Value arrives when people stop rebuilding the same view by hand, which happens once the record is trusted rather than once it's populated.
Who should own the HRIS internally?
One named person who owns the configuration and the definitions, which is a different job from administering users. The failure that recurs across organisations is that a system is configured well during implementation, the person who understood the decisions moves on, and nobody maintains the reporting lines, the field definitions or the approval routes afterwards. Within a couple of years the system describes an organisation that no longer exists, and people quietly go back to spreadsheets. The ownership matters more than the product choice, and it costs a standing hour a week rather than a role.
The system doesn't decide what you mean by employed. It just makes one answer official.
