TL;DR
- Employee offboarding software coordinates the things that must happen when somebody leaves: access removed, equipment returned, seats released, records closed.
- You do not need it while one person can hold the whole departure in their head. That stops being true somewhere around a hundred people, earlier if you are distributed.
- Three categories claim the term and they do genuinely different work. Buying the wrong one is the most common and most expensive mistake here.
- The part that breaks is almost never the checklist. It is the handoff between the person who knows somebody is leaving and the people who have to act.
- Build the business case from your own last twenty leavers rather than a vendor's figures. It takes an afternoon and the number is usually larger than the software.
- Equipment is the step that fails most, because it is the only one that needs a human in another country to do something.
The Resignation That Nobody Finished
A senior engineer resigns on a Tuesday in March. Notice is four weeks, the handover is thorough, the leaving drinks are nice. On his last Friday somebody in IT disables his email and his identity account, which is the step everybody remembers because it is the one that feels like security.
In June, Finance queries a line on the design tool renewal. The seat count is two higher than headcount. One of them is his.
In September somebody needs a spare machine for a contractor and looks for his laptop. It is not in the cupboard. The last record says it was assigned to him. There is a Slack message from April where somebody asked if he had posted it back and he said he would sort it that weekend. Nobody replied.
Best tools for HR Operations
In November the access review for an audit finds he still has an account on a logging tool bought by his team directly, which was never connected to the identity provider and therefore never touched when the account was disabled.
Nobody was careless. Email was disabled on the right day. What failed is that a departure touches four or five systems owned by four or five people, and only one of those people was told in a way that triggered an action.
The real issue is not that a checklist was missed. It is that there was no single moment where somebody could see all of it at once.
When You Do Not Need This
While one person can hold the whole thing. In a company of thirty, the ops person knows who is leaving, knows what they have, and closes it out. A document works. Software would be overhead.
When the friction is visible but survivable. Around sixty to a hundred people you start getting the seat that billed for two extra months and the laptop that took six weeks. Annoying, correctable, not yet systemic.
When it becomes a liability rather than an annoyance. Past roughly a hundred, or any size with people in several countries, the gap between what you think was closed and what actually closed stops being checkable by memory. That is the threshold, and it is about the number of handoffs rather than the number of people.
The edge case that overrides all of the above is contractors. A company with fifteen employees and forty contractors on rolling engagements has a departure problem at a scale its headcount does not suggest. Engagements end quietly, often without anybody filing anything, and contractor equipment is the single most frequently unreturned category.
What Teams Actually Need
"What does this person actually have?"
Not what the system says. What they have. That is a device, a set of application seats, physical access, and any accounts outside your identity provider that a team bought on a card.
It matters because every other step depends on this one being right, and it is usually the step with the weakest data. If your answer comes from three systems that disagree, offboarding will be guesswork regardless of what software you buy.
"Who is supposed to do what, and by when?"
Write it down with names and timings. Access removal on the last day. Equipment collection triggered at notice rather than at departure. Seat release at the next billing boundary rather than whenever somebody notices.
It matters because undefined ownership does not produce no action, it produces duplicated action on the easy parts and none on the hard ones.
"How do we get the laptop back?"
The honest answer in most companies is an email and hope. Decide in advance whether you send packaging, book a collection, or use a vendor who handles it, and decide what happens when somebody does not respond.
It matters because this is where the actual money is. A seat billing for three extra months is tens of pounds. A machine that never returns is the whole replacement cost plus whatever remains on the disk.
"When does access actually end?"
Not when the account is disabled. When every account is disabled, including the ones bought outside IT. Those are the ones that persist, because nothing automatic knows about them.
It matters because an audit will find them, and because a live account belonging to somebody who left is the clearest possible example of a control that exists on paper and not in practice.
"How do we know it is finished?"
Somebody has to confirm closure rather than assume it. The most common failure in this whole area is a process with no completion check, so nothing is ever formally unfinished and therefore nothing gets chased.
It matters because the alternative is discovering gaps in June, September and November, as above.
Run the Twenty-Leaver Audit Before You Buy Anything
The advice above says to find out where your process breaks rather than reasoning about it. Here is the exercise, and it is the single most useful afternoon you can spend before looking at any employee offboarding software.
Take your last twenty departures. Twenty is enough to show a pattern and few enough to check by hand. For each one, answer five questions with evidence rather than memory.
| Question | Where to check | What a bad answer looks like |
|---|---|---|
| Did every account close, including unconnected apps? | Identity provider plus card statements | Any live account for a leaver |
| When did the last software seat stop billing? | Vendor invoices, month by month | More than thirty days after departure |
| Did the device come back, and when? | Asset register plus physical check | No confirmed return, or over six weeks |
| Was anything written off? | Finance records | Write-offs happening silently |
| Who confirmed the departure was finished? | Any completion record | Nobody, which is the usual answer |
Three numbers come out of this and they are the whole business case. The count of seats still billing more than a month after a departure, multiplied by twelve, is your annual software leak. The count of devices never returned, multiplied by replacement cost, is your hardware loss. The count of live accounts belonging to leavers is your audit exposure, and that one is not a money number, which is why it tends to be the one that moves a decision.
Almost every team that runs this finds the failures concentrate in one or two steps rather than spreading evenly. That concentration is what tells you which category of tool to look at, and it frequently rules out the category you were about to buy.
The second finding is usually about the fifth row. Most companies have no completion check at all, which means no departure is ever formally unfinished, which means nothing is ever chased. That is fixable with a spreadsheet column and costs nothing.
The Trigger Is the Part Worth Fixing First
Everything downstream of a departure can be perfect and still fail if it starts late or does not start at all.
In most companies the signal that somebody is leaving travels by conversation. A manager tells HR. HR tells IT, usually in the same week but not always. Somebody mentions it in a channel. Each of those is a person remembering to do something during a week when the thing on their mind is the resignation itself.
A better trigger has three properties. It fires from a system rather than a person, usually the moment a leaving date is entered in the HR record. It reaches everybody who has to act at the same time rather than in sequence. And it creates something visible that stays open until closed, so an unfinished step is obvious rather than silent.
None of that requires buying anything. A form that writes to a shared tracker, fired by whoever records the leaving date, delivers all three. Plenty of companies with good offboarding have exactly that and nothing more.
What buying adds is the automatic half: deprovisioning that happens without a human, retrieval that is booked rather than requested. That is worth real money at scale, and it is worth almost nothing if the trigger is still a person remembering to send a message.
So the sequence is: fix the trigger, measure again, then decide whether you have a software problem. Teams who buy first frequently find the new platform inherits the old trigger and the same steps keep failing.
Contractors Are a Different Problem Wearing the Same Clothes
This deserves its own treatment because the standard process assumes a resignation, and contractor engagements do not produce one.
An engagement ends because the work finished, or because it quietly stopped, or because a budget ran out. Often nobody files anything. Frequently the hiring manager considers it concluded and HR never knew the person existed in the first place, because they were engaged through procurement rather than recruitment.
Meanwhile the contractor may well hold a laptop, several application seats and access to your systems, and in distributed companies they are statistically the least likely group to return equipment. The reason is not dishonesty. It is that nobody ever asked, because no process fired.
The fix is structural rather than technological. Put an end date on every engagement at the moment it starts, treat the arrival of that date as identical to a resignation, and make extending an engagement an explicit act rather than a default. That single change closes more exposure than any platform, and it costs a field in whatever system records engagements.
A second, smaller fix: decide at engagement time whether this person gets company hardware at all. For short engagements the answer is often no, and a contractor working on their own machine with access scoped tightly removes the hardest part of the problem entirely.
The Three Categories That Claim This Term
HR offboarding modules
Part of your HR system. They manage the people process: notice, final pay, exit interviews, documents, and sometimes a checklist that notifies other teams.
When it is right: when your problem is the administrative and legal process around a departure, and when your HR system is already the authoritative record of who works here.
When it fails: they generally do not touch devices or software seats in any real way. A notification to IT is not the same as an action, and a checklist item marked complete by the person who sent the email is a record of intent.
Identity and access platforms
Tools that provision and deprovision accounts, usually tied to a directory, often able to reach into connected applications.
When it is right: when the risk you are managing is access. These do the security half properly, and automated deprovisioning across connected applications is genuinely valuable.
When it fails: two ways. Anything not connected to the directory is invisible, which is exactly where orphaned accounts live. And they have nothing to say about physical equipment, which is the step that actually fails most often.
Asset and equipment platforms
Tools that track devices and, in some cases, physically collect them.
When it is right: when your leaking step is hardware, which for distributed companies it usually is.
When it fails: they are not HR systems and they do not manage access. And there is a real division inside this category between software that records a device and vendors who will physically retrieve one, which matters enormously if your leaver is in another country.
Getting the Laptop Back
Equipment is named repeatedly above as the step that fails most, and it is the one piece of employee offboarding software cannot solve by itself, because the final action belongs to a person who no longer works for you.
Four approaches exist and they are not equally good.
Ask and hope. An email on the last day saying please post it back. Costs nothing, works for people who are leaving on good terms and live somewhere with a convenient post office, and fails silently for everybody else. Most companies are doing this and describing it as a process.
Send packaging. A prepaid, labelled box arriving before the last day, so returning the machine requires one action rather than six. The improvement is large and the cost is small, because the barrier was never willingness, it was the faff of finding a box and working out where to send it.
Book a collection. A courier arrives at an agreed time. More expensive, substantially more reliable, and the only approach that works well when somebody is leaving unhappily, because it removes the need for them to initiate anything.
Use a vendor who retrieves. Equipment lifecycle providers handle collection, wiping, storage and redeployment as a service, which matters most when the leaver is in a country where you have no entity and no practical way to arrange anything locally.
Three details decide whether any of these work. Timing: trigger collection at notice rather than on the last day, because the last day is the worst possible moment to ask somebody for a favour. Condition: say what should come back, because chargers, dongles and the second monitor are the items that quietly do not. Consequence: decide in advance what happens if a machine does not return, and whether you will deduct, invoice or write off, because deciding afterwards is a conversation nobody handles well under pressure.
And one thing to avoid. Making the final payslip conditional on equipment return is a tempting lever and it varies enormously in whether it is permitted, by jurisdiction and by circumstance. Take local advice before writing anything like that into a policy, rather than copying a clause from another company's handbook.
What an Auditor Actually Asks For
Several sections above mention audit exposure without saying what the question sounds like, which makes it easy to under-prepare for.
The request is usually narrow and factual. Give me a list of everyone who left in a defined period. For a sample of them, show me when each access was removed, with evidence. Show me what assets they held and what happened to each one.
That is it. The scope is narrower than most teams brace for, and the standard of proof is higher. Nobody asks whether your process is good. They ask you to produce dated evidence for a sample, and the difference between a comfortable review and an uncomfortable one is entirely whether that evidence exists as a record or has to be reconstructed from memory and message threads.
Three things reliably cause findings. Accounts in applications outside the identity provider, still live, because nothing automatic touched them. Assets with no resolution, neither returned nor written off, sitting in a register as though they were still in service. And completion recorded by the person responsible for the task rather than confirmed independently, which an auditor will treat as unverified.
The useful consequence is that preparing for this is the same work as fixing the process. A dated completion record per leaver, with the five steps above evidenced, answers the question directly. Good employee offboarding software produces that record as a by-product. A spreadsheet maintained honestly produces exactly the same record, which is why the tool matters less than the discipline.
The Leaver's Side of This
Worth a short section, because almost every write-up of this topic treats departure as a risk to be managed and the person as the risk.
Most people leaving want to hand things over cleanly. They are also, in their final fortnight, finishing work, handing over, saying goodbye and thinking about something else entirely. A process that relies on them remembering to initiate several administrative steps during that fortnight is badly designed, and it will fail more often with conscientious people who are simply busy than with anybody acting in bad faith.
So the design principle is to require as few actions from them as possible. Packaging that arrives rather than instructions to find a box. A collection booked rather than a request to arrange one. A clear single list of what needs to come back, sent once, early, rather than three separate chasing messages in the last week.
There is a second-order benefit that is easy to dismiss and real. People who leave well talk about the company afterwards, sometimes to candidates and sometimes to customers, and a scrappy departure process is one of the few experiences almost guaranteed to be shared. An offboarding process that feels organised costs no more than one that feels chaotic.
The rejoining case makes the same point sharply. A meaningful share of leavers come back, and the ones who do remember how the exit was handled with considerable clarity.
How to Choose: Five Questions
Where does your process actually break?
Take the last twenty leavers and find out, rather than reasoning about it. Most teams discover one step accounts for most of the failures, and it is usually equipment.
Who finds out first that somebody is leaving, and what happens automatically when they do?
If the answer is that a person tells other people, your process is only as reliable as that person's week. The trigger is the part worth automating before anything else.
How many of your applications are connected to your identity provider?
Count them, then count your actual applications. The gap is your orphaned-account exposure and no amount of offboarding software closes it if the applications are not connected.
Can you physically get equipment back?
Different question from whether you can track it. A record telling you precisely which machine is missing in Porto is not a solution to the machine being in Porto.
What would an auditor ask you for?
Usually evidence that access ended and that assets were recovered or written off, with dates. If you cannot produce that today, that is the requirement, and it is more specific than "better offboarding".
The Options
HR system modules. BambooHR, HiBob, Personio and similar all include offboarding workflows. Best for the people process. Where they struggle is anything physical or any application outside their integrations.
Identity platforms. Okta, Entra ID and equivalents handle access deprovisioning properly. Best for security. Where they struggle is unconnected applications and all hardware.
Setyl. Asset and spend records joining hardware, software seats and people, starting from $300 per month on its entry tier with higher tiers quoted. Best when you want to see what a leaver holds across both hardware and software in one view. Where it struggles is that it is a record rather than a logistics service, so it tells you a machine is outstanding without getting it back.
Josys. Devices and SaaS applications managed together, joined by the person. Publishes no rate. Best for the same joined view with a management emphasis. Where it struggles is the same boundary: it does not ship or collect anything.
Torii. SaaS management and spend. Publishes no rate. Best for the software seat half specifically, which is the cheapest leak but the easiest to close permanently. Where it struggles is hardware, which is largely out of scope.
RemoAsset. Equipment lifecycle covering buying, renting and leasing, with shipping, retrieval, storage and wiping, and a register of what it handled. Disclosure: RemoAsset is our own product. We build it, which is why its limits are stated here as plainly as everyone else's. Best for the step most teams actually fail, which is physically recovering a machine from somebody who has already gone. Its Subscription tier is the only tier that publishes a figure, from $1,499 per year, with everything else quoted. Where it struggles: it does no network discovery, so a device nobody enrolled through it is invisible to it, and it does no software licence management, so the seat half of offboarding stays outside it entirely. For that half you want one of the four above.
Three Ways Teams Buy the Wrong Thing
The TL;DR claims that buying the wrong category is the most common and most expensive mistake here, so it is worth setting out the three shapes it takes. All three are recoverable, and all three cost a year.
Buying for the step that is visible rather than the step that is failing. Access removal is the step everybody thinks about, because it sounds like security and it is the one with a clear moment attached. It is also, in most companies, the step that already works for connected systems. Meanwhile equipment is leaking and software seats are billing quietly. Teams buy an identity platform, improve the thing that was already fine, and are genuinely surprised a year later that departures still feel messy.
The audit above is the protection against this. It replaces an instinct about where the problem is with a count.
Buying a record when the problem is physical. This one is specific to distributed companies and it is expensive. A platform that joins devices, seats and people gives you an excellent view of exactly what a leaver in another city is still holding. It does not get any of it back. Teams who buy employee offboarding software expecting retrieval, and get visibility instead, end up with a more precise description of the same loss.
The test is simple. Ask whether your problem is that you do not know what is outstanding, or that you know exactly what is outstanding and cannot do anything about it. Those need different purchases.
Buying a platform to compensate for a missing trigger. The most common of the three. The process fails because nobody is told in time, and the team concludes the process needs software. The new platform is configured, launched, and then fed by exactly the same human remembering to do exactly the same thing, so the same steps fail on the same schedule with a nicer interface in front of them.
This is why the sequence above puts the trigger first. It is the cheapest fix available and it determines whether anything bought afterwards actually works.
There is a fourth pattern worth naming even though it is less common, which is buying for a scale you do not have. Enterprise platforms in this area carry genuine implementation effort, and a company of ninety people can spend six months configuring something that a well-maintained tracker would have covered. The tell is a vendor conversation that opens with workflow design rather than with what is currently going wrong.
The honest summary is that employee offboarding software is a reasonable purchase for a specific set of problems and an expensive way to avoid defining a process for everything else. The audit tells you which situation you are in, and it takes an afternoon.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One office, low turnover | Under 60 | Ops owns a document | Nothing systemic | Keep the document, add a completion check |
| One office, growing | 60 to 150 | HR and IT split it | Seats billing after departure | Connect applications to identity first |
| Distributed, few leavers | 40 to 100 | Ops owns it | Equipment not returned | Retrieval capability, RemoAsset or similar |
| Distributed, high turnover | 100+ | HR, IT and Ops | Everything, inconsistently | Joined record, Setyl or Josys, plus retrieval |
| Heavy contractor use | Any | Managers engage directly | No departure signal at all | Fix the trigger before buying anything |
| Audit pressure | Any | Any | Cannot evidence closure | Identity platform plus a dated completion record |
What "Finished" Actually Means
The article keeps returning to a completion check, so it is worth defining one, because "offboarding complete" is a status that most systems will happily record without anything being true.
A departure is finished when five things are evidenced, each with a date and each confirmed by somebody other than the person who was supposed to do it.
| Step | Evidence that it closed | Who should confirm |
|---|---|---|
| Access removed | No active account in any system, connected or not | Whoever runs the access review |
| Equipment recovered | Device received and logged against its serial | Whoever holds the asset register |
| Software seats released | Next invoice shows the reduced count | Whoever owns the vendor relationship |
| Records closed | Final pay, documents, exit record complete | HR |
| Asset resolved | Returned and reissued, or formally written off | Finance |
The last row is the one almost nobody has. A machine that did not come back is either recoverable or it is a loss, and leaving it in neither state is how asset registers fill with fiction. Deciding to write something off is not an admission of failure, it is the thing that keeps the register honest.
Notice that every confirmation sits with a different function. That is deliberate and it is also why this fails without a shared view: five people each closing their own step, none able to see the others, and no single place where a half-finished departure looks half-finished.
A reasonable implementation of all this is one row per leaver with five columns and a date in each. That is genuinely sufficient up to a few hundred people, and it is a far better starting point than a platform configured around a process nobody has defined yet.
The First Ninety Days With a New Process
If you do change something, the sequence matters more than the tool, and most of the value lands before any software is involved.
Weeks one to three. Run the twenty-leaver audit. Fix the trigger so that recording a leaving date automatically creates a visible, open item. Add the completion check as five columns. Do nothing else. A surprising number of teams stop here permanently and are right to.
Weeks four to eight. Close the access gap. Build the list of applications outside your identity provider by going through card statements and asking each team what they bought, then connect what can be connected. This is tedious, it is the least popular task in this entire area, and it removes the exposure that an auditor will actually find.
Weeks nine to twelve. Address whichever physical step your audit showed failing. If equipment is going missing, this is the point to decide between sending packaging yourself, booking collections, or using a vendor who retrieves. Measure the recovery rate before and after, because this is the one change where the effect is immediately visible.
One caution about sequencing. Resist the urge to run all three phases at once, which is the instinct when the audit results are fresh and somebody senior is paying attention. Each phase changes behaviour in a different team, and running them together makes it impossible to tell which change produced which improvement. It also tends to mean the tedious middle phase, the application list, gets quietly dropped when the first phase delivers a visible win.
Then measure again with the next twenty leavers. If the numbers moved, you have your answer about whether a platform is still needed. If they did not, you now know precisely which step is resisting, which is a much better brief to take to a vendor than a general sense that offboarding could be tidier.
The Cost of Getting This Wrong
There are three layers here and companies reliably see only the first. It is also the smallest, which is why the budget conversation and the actual exposure so rarely meet in the same room.
The countable cost is small and easy to dismiss. A few seats billing past their usefulness, a laptop or two a year that does not come back. Most finance teams would not notice it inside a quarterly variance.
The second layer is the time, and it is larger. Every unfinished departure generates work months later at the worst possible moment: during an audit, during a renewal negotiation, during a security review. That work is always urgent, always done by somebody senior, and always more expensive than doing it on time would have been.
The third layer is the one that actually matters and it is a control problem rather than a cost. An organisation that cannot demonstrate that leavers lose access is an organisation whose access controls do not work, regardless of how good they look in a policy document. That is a finding in an audit, a question in a due diligence process, and occasionally something worse.
So the question is not what your offboarding gaps cost. It is this: if somebody asked you to prove that everyone who left in the last twelve months has no access to anything and returned everything they held, how much of your answer would be evidence and how much would be assumption?
The Data on the Machine
One step sits between recovering a device and reissuing it, and it is routinely skipped because the machine is physically back and therefore feels resolved.
A returned laptop holds whatever its last user had on it: cached files, saved credentials, local copies of things that were supposed to live somewhere central. Until it is wiped, recovering it has moved the exposure from somebody else's home to your cupboard rather than removing it.
Three things belong in the sequence. A documented wipe, recorded against the serial number rather than performed and forgotten, because the record is what you will need later. Release from device management, or the machine reappears as a managed device for its next holder. And removal of any account or activation lock, which has to happen while you still have access and is close to impossible afterwards.
That last one causes more avoidable waste than it should. A machine still locked to a departed person's account is unusable by anybody, and the window to clear it cleanly is while the account still exists. Sequencing it after account deletion turns a reissuable asset into a paperweight, which is an unforced error and a surprisingly common one.
When You Are Ready to Move Beyond the Checklist
A checklist is not the problem and software does not automatically fix anything. Plenty of companies run clean offboarding on a template because one person owns it and finishes it. Plenty of others own three platforms and still have orphaned accounts.
The distinction that matters is not whether the process is written down. It is whether anybody can see, at a glance, which departures are unfinished right now. A checklist tells you what should happen. It does not tell you what has not happened yet, and that second question is the one that actually prevents loss.
What changes the answer is when the work stops being visible to one person. When departures outnumber what somebody can track alongside their actual job. When people leave from places where nobody can walk to their desk. When the applications in use outnumber the ones anybody has a list of.
At that point what you are buying is not a checklist with a login. It is a single place where the state of a departure is visible, and an automatic trigger from the moment a resignation is recorded. Those two things fix more than any feature list, and if your current process has both, software will add less than you expect.
Frequently Asked Questions
What is employee offboarding software?
It is software that coordinates what has to happen when somebody leaves: removing access, recovering equipment, releasing software seats and closing records, usually with a workflow and an audit trail. The term covers at least three different product categories that do genuinely different parts of that job, which is why shortlists in this area so often contain tools that are not comparable.
Do we really need offboarding software?
Probably not below about a hundred people in one location with modest turnover, because a maintained template and one person who finishes the job will cover it. The case strengthens when departures outnumber what one person can track, when people leave from places nobody can visit, or when somebody starts asking for evidence rather than assurance.
What does employee offboarding software cost?
It varies enormously by category and most vendors quote rather than publish. Setyl publishes an entry tier starting from $300 per month with higher tiers quoted, which is one of the few public reference points available. Build your own business case from your last twenty leavers instead, counting seats that billed after departure and devices never returned, because that number is specific to you and usually larger than the licence.
Which step fails most often?
Equipment recovery, particularly in distributed companies, because it is the only step that requires a person in another place to do something voluntarily after they have stopped working for you. Access removal is usually handled well for connected systems. Software seats leak quietly. Hardware is the step where the loss is both largest and most visible.
How do we handle offboarding for contractors?
Deliberately, because the usual trigger does not exist. Contractor engagements end without a resignation, often without anybody filing anything, so the first requirement is a signal that an engagement has finished. Put an end date on every engagement at the start and treat its arrival as the same event as a resignation, otherwise nothing downstream will ever fire.
What about applications that are not connected to our identity provider?
Those are where orphaned accounts live, and no offboarding tool can close an account it cannot see. Build the list by reviewing card statements and asking teams directly, then either connect what can be connected or maintain a manual list for the rest. The manual list is unglamorous and it is the only thing standing between you and an audit finding.
How long should offboarding take?
Access should end on the final day and seats at the next billing boundary, both of which are achievable. Equipment is slower and depends on geography, so the useful measure is not a target but a tracked number with somebody accountable for closing it. What matters more than speed is that nothing is left in an ambiguous state where nobody believes it is their job to chase.
