> ## Documentation Index
> Fetch the complete documentation index at: https://docs.timetracker.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Offboard an employee

> A complete checklist for someone leaving: close their open time, reassign their tasks, revoke every route back in, transfer ownership and free the seat.

Offboarding is mostly hygiene, and every step exists because leaving it out strands something.

Work through this checklist **before** you remove the person. Once the membership is gone, some of it is much harder to clean up.

<Info>
  **The example:** Sarah Lin is leaving Northwind Studio. Tom Whitfield (Admin) offboards her. Priya Raman (Project Manager) handles her work in flight.
</Info>

## Before you start

<Warning>
  **If the person leaving is the Owner, they must transfer ownership first.** A workspace cannot be left without an owner, and removing the sole owner is refused. Do the transfer before anything else on this page.
</Warning>

| Step                         | Who               | Capability      |
| ---------------------------- | ----------------- | --------------- |
| Transfer ownership           | The current Owner | Owner only      |
| Approve or reject their time | Priya (PM)        | `time.approve`  |
| Reassign tasks               | Priya (PM)        | `task.edit`     |
| Revoke invitations           | Tom (Admin)       | `invite.revoke` |
| Remove the member            | Tom (Admin)       | `member.remove` |

## The checklist

<Steps>
  <Step title="If they are the Owner, transfer ownership">
    Only an Owner can hand ownership on, and a workspace must always have exactly one. The Owner is the only role that can delete the workspace, so this cannot be skipped or worked around.

    Pass ownership to someone who is staying and who can actually exercise it – an Admin, not a Contractor or a client portal contact.

    → [Change someone's role](/team/change-someones-role) · [Roles and capabilities](/concepts/roles-and-capabilities)
  </Step>

  <Step title="Stop their clock and check for a running timer">
    A timer left running keeps accruing against a workspace they can no longer open.

    Ask them to stop and save any running timer before their last day. If one is still running when you remove them, it is discarded rather than turned into hours – nobody reviewed that span, and inventing a time entry on someone's way out puts unverified hours into a billing record.

    → [Using the timer](/time-tracking/using-the-timer) · [Delete a time entry](/time-tracking/delete-a-time-entry)
  </Step>

  <Step title="Deal with their unsubmitted time">
    This is the step people forget, and it is the one that costs money. Unsubmitted time cannot be approved, and unapproved time cannot be invoiced.

    Before they go:

    1. Have them submit every outstanding week themselves. → [Submit a timesheet](/timesheets/submit-a-timesheet)
    2. If they have already gone, an Admin submits on their behalf. → [Submit on behalf of someone](/timesheets/submit-on-behalf-of-someone)
    3. Priya approves or rejects everything in the queue. → [Approve a timesheet](/approvals/approve-a-timesheet)

    <Warning>
      Do this **before** you remove them. Once the membership is gone they cannot submit, and the roster no longer offers them as a person to submit for.
    </Warning>
  </Step>

  <Step title="Clear anything routed to them for approval">
    If Sarah was an approver, submissions routed to her are waiting on somebody who is about to disappear.

    Reassign approval duties to another manager, and make sure that manager's supervision scope actually covers the same people. A capability says you **may** approve. Scope says **whose** time.

    → [Approval permissions](/approvals/approval-permissions) · [Supervision scope](/concepts/supervision-scope)
  </Step>

  <Step title="Priya reassigns their open tasks">
    Every task assigned to Sarah needs a new owner, or it silently stops moving.

    Filter tasks by assignee, then bulk-reassign them. Do the same for tasks where she is the only person who knows anything – add a comment with context before you reassign.

    → [Assignees](/tasks/assignees) · [Bulk actions](/tasks/bulk-actions) · [Filters and sorting](/tasks/filters-and-sorting)
  </Step>

  <Step title="Reassign their planner blocks">
    Work planned into their calendar for the coming weeks is capacity you no longer have. Move it or delete it, so next week's plan is honest.

    → [Plan work blocks](/planner/plan-work-blocks) · [Capacity and workload](/planner/capacity-and-workload)
  </Step>

  <Step title="Deal with their expenses and leave">
    Any expense they submitted needs approving or rejecting. Any approved leave in the future needs cancelling if it no longer applies.

    → [Approve an expense](/expenses/approve-an-expense) · [Approve time off](/time-off/approve-time-off) · [Leave balances](/time-off/leave-balances)
  </Step>

  <Step title="Revoke every outstanding invitation for them">
    **An open invitation is access.** An invite still sitting in their inbox lets them walk straight back in with the role you are about to take away.

    Check the pending invitations list for their email address and revoke anything you find.

    → [Pending invitations](/team/pending-invitations)

    <Note>
      Removing the member also closes any outstanding invitation to that email address in the same action, so this is a belt-and-braces check rather than a step you can get wrong. It is still worth looking, because an invite to a personal address they also used will show up here.
    </Note>
  </Step>

  <Step title="Check who reported to them">
    If Sarah was somebody's manager, that pointer has to go somewhere. Reassign her reports to their new manager, so the hierarchy never points at somebody who is gone.

    → [Member record](/team/member-record) · [Supervision scope](/concepts/supervision-scope)
  </Step>

  <Step title="Take them out of the client portal, if they had access there">
    If they were also a contact on a client account, remove that separately.

    → [Remove portal access](/portal/remove-portal-access)
  </Step>

  <Step title="Tom removes the member">
    Now the clean-up is done, remove them from the workspace.

    → [Remove a member](/team/remove-a-member)

    Removing a member does all of this in one action:

    | It does                                          | Why                                                   |
    | ------------------------------------------------ | ----------------------------------------------------- |
    | Discards any running timer                       | It cannot be stopped by anyone once they are gone     |
    | Closes an open time clock session                | Same reason                                           |
    | Releases anything routed to them for approval    | So a submission is not waiting on a ghost             |
    | Revokes outstanding invitations to their address | An open invite is access                              |
    | Revokes any mobile or widget device tokens       | A device token is access, and it outlives the session |
    | Clears them as anyone's manager                  | The hierarchy must not point at somebody gone         |
    | Removes them from every group                    | Group membership grants reach                         |
    | Frees the seat                                   | One fewer billable person                             |

    <Note>
      Their **tracked time stays**. Historical entries, approved weeks and invoices are untouched, because they are your business records. What goes is their access and their personal workspace details.
    </Note>
  </Step>

  <Step title="Check the seat count">
    On a paid plan, the seat change applies at your next renewal. On Free, removing someone brings you back under the 3 person limit and lets you add somebody new.

    → [Seats and billing](/team/seats-and-billing) · [Seats](/billing/seats)
  </Step>
</Steps>

## A copy-paste checklist

| Done | Step                                           |
| ---- | ---------------------------------------------- |
| ☐    | Ownership transferred, if they are the Owner   |
| ☐    | Running timer stopped and saved                |
| ☐    | Every outstanding week submitted               |
| ☐    | Every submitted week approved or rejected      |
| ☐    | Expenses approved or rejected                  |
| ☐    | Future leave cancelled if it no longer applies |
| ☐    | Open tasks reassigned                          |
| ☐    | Planner blocks reassigned or removed           |
| ☐    | Approval routing moved to another manager      |
| ☐    | Their direct reports given a new manager       |
| ☐    | Pending invitations to their address revoked   |
| ☐    | Client portal access removed, if any           |
| ☐    | Member removed                                 |
| ☐    | Seat count checked                             |

## Common questions

<AccordionGroup>
  <Accordion title="What happens to time they already tracked?">
    It stays. Time entries, approved weeks and invoices are business records and are not deleted with the person. Reports covering past periods still show their hours.
  </Accordion>

  <Accordion title="Can the Owner just leave?">
    Not without transferring ownership first. A workspace must always have exactly one Owner, and removing the sole owner is refused. Transfer, then leave. See [Leave a workspace](/account/leave-a-workspace).
  </Accordion>

  <Accordion title="Should I remove them or deactivate them?">
    Remove them when they have genuinely left. Deactivating is for a pause – a long leave, a suspended account – where you expect them back and want their setup preserved. See [Remove a member](/team/remove-a-member).
  </Accordion>

  <Accordion title="They still have the app on their phone. Is that a problem?">
    No. Removing the member revokes their device tokens, so the app and the widget stop being able to reach the workspace. See [Mobile app](/integrations/mobile-app).
  </Accordion>

  <Accordion title="Someone left months ago and we never cleaned up. What now?">
    Work the same checklist in the same order. The unsubmitted time is the part that has genuinely aged – you may need an Admin to submit and approve it, or to accept that those hours will never be billed.
  </Accordion>

  <Accordion title="Does removing someone reduce my bill immediately?">
    The seat count updates, and on a paid plan the change applies at the next renewal. See [Seats and billing](/team/seats-and-billing).
  </Accordion>

  <Accordion title="What if they are leaving the company but keeping a client portal login?">
    Those are two separate things. Remove the staff membership, and manage the portal contact from the client's page. See [Remove portal access](/portal/remove-portal-access).
  </Accordion>
</AccordionGroup>

## Related guides

<CardGroup cols={2}>
  <Card title="Onboard a new employee" icon="user-plus" href="/guides/onboard-a-new-employee">
    The forward version of this checklist.
  </Card>

  <Card title="Manage contractors" icon="handshake" href="/guides/manage-contractors">
    Ending a freelance engagement.
  </Card>

  <Card title="Month-end close" icon="calendar-days" href="/guides/month-end-close">
    Do not let a leaver hold up the close.
  </Card>

  <Card title="Export hours for payroll" icon="file-export" href="/guides/export-hours-for-payroll">
    Their final hours for the last payroll run.
  </Card>

  <Card title="Weekly timesheet routine" icon="calendar-check" href="/guides/weekly-timesheet-routine">
    Approving weekly means less to clean up.
  </Card>
</CardGroup>