The boundary is the hire date. An applicant tracking system ends at the accepted offer; an HRMS begins when that person becomes an employee with a payroll input, a leave balance and a statutory identity. Without an HRMS that work still happens - it just happens in spreadsheets nobody audits. Small teams can defer it deliberately, not accidentally.
At the accepted offer, and the boundary is sharper than it looks. Everything before it is candidate data: an application, a resume, interview feedback, scorecards, source and stage history, all belonging to a person who has no employment relationship with you and may never have one. [Applicant tracking software](/ats) is built around that asymmetry - many people, most of whom will not become employees, moving through stages that end in a decision. The moment an offer is accepted the questions change entirely. Nobody asks which stage an employee is at. They ask what the person is paid, who approves their leave, which entity employs them and what happens when they resign.
Fewer fields than people expect, and they are dull ones. Legal name exactly as it appears on identity documents, contact details, the accepted role title and grade, agreed compensation, start date, work location and legal entity, reporting manager, plus whatever identifiers your payroll setup needs. Interview feedback and pipeline history stay behind, because they belong to the hiring record and mostly should not follow someone into their employment file. Designing this handover rather than improvising it matters because it is the last moment the data is clean. Anything re-typed here becomes the record everything else reads from, and a name entered differently from the identity document resurfaces as a failed bank transfer or a rejected filing.
The work does not disappear, it relocates - usually into a spreadsheet on one person's drive and a mailbox full of approvals. Payroll inputs get assembled by hand each cycle from several sources. Leave balances live wherever somebody decided to keep them, so they get argued about at exit instead of checked. Nobody can produce a headcount as at a past date, because there is no dated record of joiners and leavers, only a sheet reflecting today. An [HRMS](/hrms) is what converts those into records with owners, permissions and history. Until then the organisation runs on the memory and diligence of whoever holds the file, and both of those leave when that person does.
When volume is genuinely low, policies are simple, and one named person owns the whole thing. A handful of employees in one location under one set of rules can be administered carefully by hand for a while, and pretending otherwise wastes money a small team needs elsewhere. The condition is that the deferral is a decision, with an owner and a defined moment to revisit it, rather than something that simply never came up in a meeting. Deferring also costs far less if you keep manual records in the shape a system will eventually want - one row per person, dated changes, no merged cells - because the migration then becomes an import rather than a reconstruction.
Watch for questions you cannot answer quickly. How many people were employed at the close of the last quarter. What leave is owed across the team. Whose probation confirmation is due. How fast you can produce evidence when someone disputes a deduction. Any of those requiring a hunt through email is a signal. Two more matter more than they appear: employing people in a second location, which usually pulls in obligations that differ from the first, and the first exit that goes badly - full and final settlement is where every gap in the record turns into a conversation about money with someone who no longer works for you.
Partly, and precision helps here. Onboarding features inside a hiring product typically cover the pre-joining tasks: document collection, offer acceptance, form completion, equipment and access requests. That is genuinely useful and closes a real gap. What it does not do is maintain the employment record afterwards. Once the checklist completes, an onboarding module has finished its job, whereas the record it produced needs to keep changing for as long as the person is employed. Standalone [onboarding software](/employee-onboarding-software) sits on the same boundary. So the module removes manual work at the joining moment; it does not remove the need for somewhere the person continues to exist.
One direction, one trigger, one owner. The hiring system pushes to the employment record on offer acceptance and not before, because a pipeline full of maybes should never create employee rows. Map the fields explicitly and decide which system wins for each one after the handover - almost always the employment record, since it keeps being corrected while the hiring record is frozen. Decide too what happens on a rescinded offer or a no-show, because that path is what produces phantom employees. Whether the connection is a live integration or an export someone runs matters less than whether it is defined at all. An undefined handover is re-keying, and re-keying is where records start disagreeing.
Pitch N Hire is an applicant tracking system built for recruiters and hiring teams. If this answer described something you want to run properly, the ATS is where it lives.
Free for 1 user · No credit card · Talk to a real hiring expert
Get a personalized walkthrough of Pitch N Hire on your own roles and workflow. No slides, no obligation.
Prefer to talk? Book a demo · Talk to sales · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
