Nobody evaluates HR software by asking what it will be able to tell them in 2029. Demos are about now: this is the leave request, this is the approval, this is the org chart. Every feature is presented in the present tense, because the present is what a demo can show.
Then the questions arrive, and they are all about the past.
What did this person earn in March two years ago, because an auditor is asking. Who approved this change, because the person who made it has left. What did the leave policy say when this employee signed their contract, because they are disputing a balance. Which entity employed them before the transfer, because service continuity is in question. Who had access to this record last spring, because a customer’s diligence process wants to know.
Not one of those is a feature request. They are all the same request: read the record as it stood on a date that has already gone.
The present is the easy part
Here is why this is the thing to buy for rather than a nice property to have.
The current state of your HR data is recoverable from other sources. If your HR system vanished tomorrow, you could reconstruct today’s headcount from the payroll file, today’s salaries from bank transfers, today’s org chart by asking twelve people. It would be an unpleasant week, and you would get there.
The past is not recoverable. Once a salary field has been overwritten, the previous value is gone from the only system that held it. Nothing else in the company recorded that a promotion was agreed in April but entered in June. No other source knows what the carry-over rule said in 2025 before somebody edited the policy document in place.
So the durable value of an HR system is not that it holds what is true. It is that it holds what was true, in a form that can still be read years later by somebody who was not there.
What that requires, concretely
Three properties, and they are separable.
Effective dating. A change carries the date it takes effect, which is often not the date it was entered, and the previous value is retained rather than replaced. A promotion agreed in June and keyed in August takes effect in June, and the record can still say what the person’s title and salary were in July. Reporting for a past period reflects what was true then, not what is true now.
An append-only log of actions. Who did what, when, from where. This is a different thing from effective dating and it does not replace it. Effective dating tells you what the salary was; the log tells you who changed it and when. A product with a log but no effective dating can tell you that something changed without being able to tell you what it was before, which is an oddly useless kind of evidence.
Versioned documents and policies. Not just the current handbook, but the one that was live when this person acknowledged it. An acknowledgement of an unversioned document is close to worthless the moment the document changes.
Together, these are what make a record readable at a date. Individually they each answer a fraction of the questions, which is why products that have one of the three often feel like they should be enough and are not.
The four moments this pays for itself
Due diligence. An acquirer or an investor asks for employment history, compensation history and the current position of every person. If your compensation data is a single current number per person, that question turns into an archaeology project across payroll files and email. Companies do get through it. They get through it slowly and with a data room caveat.
A dispute. A leaver disputes a leave balance, or a notice recovery, or a bonus they say was agreed. The company position is only as strong as its record of what was agreed and when. A conversation in a chat thread that has scrolled away is not a record.
A regulator or an auditor. The question is nearly always time-bounded: what was true in this period, and can you show it. Retention obligations exist precisely because the past is what gets examined. The Indian version of this is in the DPDP Act and employee data, and the general version in HR data security and compliance.
A customer’s security questionnaire. “Who had access to employee data in this period” is a standard question and it is a past-tense question. Answering it requires a log you can read yourself rather than a promise that one exists. How to answer an HR security questionnaire covers what reviewers are actually testing.
Notice that in all four cases the person asking is outside your company, and in all four cases “we cannot answer that” is not a neutral outcome. It is itself the finding.
How to test it in twenty minutes
Two moves, both of which you can do in a trial.
Backdate something. Enter a compensation change or a role change with an effective date in the past. Then check three things: whether the system accepts it at all, whether a report for that past period reflects it, and whether the previous value is still visible somewhere. A product that silently applies the change as of today has told you what kind of record it keeps.
Read the export. Take a full export and look specifically for history. Does compensation come out as a sequence of rows with effective dates, or as one current figure per person. Do employment changes, transfers and terminations come out with their dates. Do the documents come with versions.
The second test is the more revealing, and it generalises. An export is the honest description of what a product believes it holds, which is why start your shortlist with the export is the first move we recommend in any evaluation. If the export is a snapshot, the product is a snapshot, whatever the interface implies.
Where this sits beside the audit log argument
We have written before that the audit log is not an enterprise feature: the record of what happened is written either way, so charging to read it bills a customer for evidence of what was done to their own data at the moment they most need it.
This is the same principle one layer down. Effective dating is not a premium capability either. It is a decision about how the data model works, made once, near the beginning, and it is nearly impossible to add convincingly later, because retrofitting history means inventing dates you do not have. A vendor either built the record this way or did not, and no amount of roadmap fixes the years already overwritten.
That is worth saying plainly during an evaluation, because it is one of the few architectural properties a buyer can actually verify in a trial.
What we do
In Capstan, changes are effective-dated: promotions and transfers take effect on their date and history is queryable, which is a property of the core rather than a tier. Every action in the workspace lands in an append-only activity log, updates and deletes revoked in the database rather than discouraged by convention, and the workspace admin opens that log themselves, filters it by action, record type or date, and exports it for their own auditor without asking us for anything. It is on every plan, including the free one, for the reason above.
The full export is a tar of JSON and CSV and it includes module data whether or not the module is currently enabled, so switching something off never puts the history out of reach.
Two honest limits. Effective dating makes the record readable at a date; it does not make your data correct, and a system faithfully preserving a wrong salary from 2025 is preserving a wrong salary. And none of this helps for the period before you adopted a system, which is the argument for adopting one earlier rather than later, made properly in build or buy your first HR system.
The short version
Buy for the questions you will be asked, not the ones you are asking. The demo is about the present, and the present is the part you could reconstruct anyway.
Test the backdated change. Read the export for history. Check the log is yours to read. Those three take an afternoon, and they tell you whether you are buying a record or a snapshot.