What is an HRIS

An HRIS, a human resources information system, holds the authoritative record of every person employed by a company: who they are, what they are contracted to do, what they are paid, who they report to, when they joined and, eventually, when they left. That is the whole idea. Everything else an HR system does, and there is a lot of it, is either an operation performed on that record or a report derived from it.

This sounds modest until you notice how many decisions depend on it. Payroll pays from it. Access is granted from it. Leave entitlement is calculated from it. Headcount, cost and structure reporting all read it. Compliance evidence hangs off it. Once several processes read the same record, being the single authoritative copy is not a feature of the system, it is the entire value: the alternative is several copies that disagree, and an argument about whose version is right before any question can be answered.

Historically the three meant different things. HRIS was the record system: people, roles, documents, reporting lines. HRMS added the operational processes on top, such as leave, time, and payroll. HCM was the strategic layer above both: recruitment, performance, learning, succession and workforce planning. In that framing an HRIS was the foundation and HCM was the full stack.

In practice the distinction has collapsed, because almost every serious product now spans all three and the labels became marketing choices rather than category boundaries. It is more useful to ignore the acronym and ask two questions of any system: does it hold the authoritative employee record, and which processes read that record directly rather than through an import. A product that owns the record and connects the processes is doing the job, whatever the three letters on the box say.

The core record is smaller than most people expect. Identity and contact details, employment terms including start date, contract type and working pattern, role and reporting line, pay and any allowances, leave entitlement and balance, and the documents that evidence all of it. Add the events that change any of these over time, because a record that only knows the present cannot answer how someone got here or what they were paid last year.

Two things are commonly put in the core record that should not be. The first is anything that belongs to a process rather than a person, such as an individual leave request or a single review; those reference the record, they do not live in it. The second is any figure that can be calculated, such as tenure, age or leave remaining. Storing a derived value guarantees it will one day disagree with the facts it was derived from, and the stored copy is always the one that is wrong.

A spreadsheet is a genuinely reasonable employee record for a very small team, and pretending otherwise is how people end up buying systems they cannot yet use. The honest signals that it has stopped working are specific rather than about size. Two people maintain versions that differ. Someone has to be asked a question the file should answer. A leaver still appears in a report. Nobody can say what a figure looked like three months ago. Personal data sits in a file anyone with the link can open.

That last one matters more than the rest combined. Employee records are among the most sensitive data a company holds, and a spreadsheet has no concept of who may see which field. A manager needing a team list does not need salaries, and a system that cannot make that distinction forces a choice between over-sharing and manual copies. When you find yourself maintaining a redacted second version of the file for wider circulation, the spreadsheet has already failed.

Start with the record rather than the feature list. Can it hold your actual employment reality, including part time patterns, multiple entities, several countries and the contract types you really use, without a free text field standing in for structure. Does it keep history, so a change is an event rather than an overwrite. Can permissions be set per field, so the team list and the salary are not the same access decision. These are difficult to retrofit and easy to check early.

Then ask what reads the record directly. Every process that has to be told about a change separately is a place where copies drift, so the question that separates systems is whether recording a promotion once updates pay, structure, approvals and reporting, or whether it starts four tasks. Finally, ask how data gets in and out. An import that only runs once is a trap, and an export you cannot run yourself is a system you do not really own the data in.