A terminated employee is read-only
Clocking in, assigning a schedule or an absence policy, approving an absence that runs past the termination date and inviting a terminated employee to the portal now return 422 with the employee_inactive subcode. The team summary lists every employee employed during the month, with or without a schedule.
31 October 2026 — A terminated employee (status inactive) is now read-only: their data is kept
and can be read, but they accept no new operations. The six operations in the table return 422
business_rule_violation with the employee_inactive subcode and write nothing. Nothing changes for an
active employee and no operation is retired.
Operations in this release
| Operation | operationId | MCP tool | What changes |
|---|---|---|---|
POST /v1/companies/{company}/time-entries/clock-in | public-api.v1.time_entries.clock_in | clock_in | A terminated employee cannot clock in, not even on their termination day. An instant after the termination date still returns clocking_outside_employment_period. |
POST /v1/companies/{company}/work-schedules/{schedule}/assign | public-api.v1.work_schedules.assign | assign_work_schedule | A schedule is not assigned to a terminated employee. |
POST /v1/companies/{company}/absence-policies/{absence_policy}/assign | public-api.v1.absence-policies.assign | assign_absence_policy | A policy is not assigned to a terminated employee; with several employees, nobody is assigned. |
POST /v1/companies/{company}/absence-requests/{absence_request}/approve | public-api.v1.absence-requests.approve | approve_absence_request | An absence that ends after the termination date is not approved and stays pending. |
POST /v1/companies/{company}/employee-invitations | public-api.v1.employee-invitations.send | send_employee_invitation | The email of a terminated employee is not invited to the portal (param email). |
POST /v1/companies/{company}/employee-invitations/{invitation}/resend | public-api.v1.employee-invitations.resend | resend_employee_invitation | Their invitation is not resent either. |
GET /v1/companies/{company}/time-balances/team-summary | public-api.v1.time_balances.team_summary | get_team_time_balance_summary | One row per employee employed on any day of the month, with or without a schedule or portal account. |
Terminated employee
{
"error": {
"type": "invalid_request_error",
"code": "business_rule_violation",
"subcode": "employee_inactive",
"message": "El empleado está de baja y no puede fichar la entrada. Si sigue trabajando, reactívalo antes.",
"param": "employee_id",
"doc_url": "https://docs.factuarea.com/guides/errors#business_rule_violation",
"request_id": "req_01HKQS5NTIMEEMPINACTIVE03"
}
}You can still read their data, time entries and absences, edit their record, record or correct the days
they were employed while the month is open (POST /v1/companies/{company}/time-entries/manual), pause,
resume and clock out of a workday that was already open, close the month, reject or cancel their absences
and unassign a schedule or a policy. Reactivating them with
POST /v1/companies/{company}/employees/{employee}/reactivate gives everything back. Their portal user also
loses access to that company. See the error.
What to do. Branch on error.subcode. If the person still works for you, reactivate them before
repeating the call; if an integration backfills late clockings of someone already terminated, send them as
manual entries for the days they were employed.
Team summary
GET /v1/companies/{company}/time-balances/team-summary now lists every employee with at least one employed
day in the month, the same employees the monthly close freezes. Before, it only listed active employees with a
schedule in force and a portal account. Without a schedule, their days count 0 expected minutes and raise no
warnings; an employee terminated during the month appears with the days up to their termination. The shape of
each row does not change.