Separation

Separation manages employee exits such as resignation, termination, retirement, end of contract, redundancy, or other approved departure reasons.

Separation should be controlled because it affects employment status, payroll, asset return, access, final settlement, benefits, and reporting.

The separation workspace is exposed through the lifecycle/relations area and is capability-composed: the current route accepts either HR Onboarding and Transitions or HR Employee Relations. The underlying HR workforce record and each action still require their own permissions; payroll, benefits, documents, assets, and payment handoffs have separate package and authorization requirements. This broad route condition must not be interpreted as proof that every downstream step is enabled or completed. See Capabilities and Access and Lifecycle and Manager Workspaces.

Workspace Reference

Workspace	How Users Reach It	Main Actions
Workforce Setup	HR -> Setup -> Workforce Setup	Configure clearance items before exit workflows begin.
Employee Management	HR -> Operations -> Employee Management	Use Initiate Separation, Start Clearance, Create Settlement, and complete-exit actions from the employee detail where available.
Employee Lifecycle And Relations	HR -> Operations -> Employee Lifecycle And Relations	Review related disciplinary, grievance, relation, promotion, transfer, or salary history before final exit.
Payroll Processing	HR -> Operations -> Payroll Processing	Confirm final payroll, deductions, benefits, and final settlement payment readiness.

Separation Record

A separation record normally captures:

• Employee.
• Separation type or reason.
• Notice date.
• Expected last working day.
• Approved last working day.
• Notes or supporting information.
• Current separation status.

Review the employee’s active contracts, leave balances, benefits, assets, disciplinary matters, and payroll status before completing separation.

The current form makes separation type, effective date and reason mandatory. It offers resignation, termination, retirement, end of contract, redundancy, death and other. Notice date and last working day are optional in the form, but the settlement routine requires a last working day (falling back to the separation effective date if present). When editing, separation type is locked; the form allows the reason, notice/effective/last-working dates and exit-interview result/notes to be updated. Interview notes are required when the interview is marked complete.

Approval status and separation workflow status are separate. An approved row may still be in clearance; approval does not mean that employment has ended. The Exit Workflow displays states such as INITIATED, CLEARANCE_IN_PROGRESS, CLEARANCE_COMPLETE, SETTLED, COMPLETED and CANCELLED alongside approval. Follow the lifecycle history and source record rather than interpreting an approval chip as the final employment status.

Separation Field Implications

Field Or Area	Meaning	User Impact
Employee	Person exiting the organization.	Drives employment status, payroll, assets, access, and final settlement.
Separation Type Or Reason	Why the employee is leaving.	Supports reporting, approval routing, notice requirements, and policy checks.
Notice Date	Date notice was given or recorded.	Helps calculate notice compliance and final working arrangements.
Expected Last Working Day	Planned final day before approval.	Supports handover, payroll cutoff, and clearance planning.
Approved Last Working Day	Final date accepted after review.	Drives final settlement, payroll cutoff, and status change.
Clearance Status	Progress of required exit items.	Blocks completion until assets, documents, access, and sign-offs are handled or waived.
Final Settlement	Current implementation calculates a non-negative amount payable to the employee; a negative result is rejected.	Review the source calculation and approved policy before payment; any employee recovery must use a separate authorized workflow.

Clearance

Clearance tracks items the employee must complete or return before exit is finalised. Clearance items are configured in HR setup and may include company property, access cards, documents, loans, knowledge transfer, keys, uniforms, or departmental sign-off.

Clearance should show who is responsible and whether each item is completed.

Start and work the clearance queue

1. Configure clearance-item definitions in HR → Setup → Workforce Setup before creating exit records. Name each requirement clearly and assign a responsible unit where setup permits.
2. Obtain separation approval. In the Exit Workflow, Start Clearance is shown for an approved separation in INITIATED state when clearance has not already been generated.
3. Start clearance once. The system creates a row for each applicable configured clearance definition; do not create duplicate separation or clearance records to make the list appear populated.
4. Open each item, confirm the owner, and update its status and notes with an accurate outcome. For a company asset, use the asset register and custody/ return evidence as the authoritative record. For access, confirm the actual account disposition with the access owner. For a loan, confirm the shared Loans account and the agreed recovery mechanism; a checklist item does not repay the balance.
5. Resolve exceptions through an authorized decision. Do not mark an item complete merely because a request was sent or a manager verbally confirmed it.
6. Confirm the separation reaches CLEARANCE_COMPLETE before the UI enables settlement creation. Reopen the exit detail and verify all required items and their notes.

The current UI gates the settlement button on CLEARANCE_COMPLETE. The checked-in settlement procedure validates separation existence, business-unit scope, non-cancelled status and calculation inputs, but the procedure reviewed for this guide does not itself query that every clearance row is complete. Treat the UI gate as an operational control, not proof that the database independently enforces every clearance prerequisite; this needs a backend and runtime control check.

Final Settlement

Final settlement records the final amount payable under the currently implemented calculation, subject to its limits. The HR form presents earned pay, leave pay, deductions and other adjustment as optional amount fields. Leave all four blank to request the source-based calculation. Supplying even one amount switches the procedure to manual override; missing components are not automatically filled from their source records. That path requires an override reason and the separate OVERRIDE_HR_FINAL_SETTLEMENT_CALCULATION permission (unless the actioning user is a platform super-admin). The current create form does not expose an override-reason field, so do not use amount overrides through this form until the gap is resolved and tested.

Current source-based calculation

With amount fields omitted, the current database routine:

1. Requires a valid separation in the user's business unit and a last working day (falling back to the separation effective date if present).
2. Finds an approved payroll enrollment that covers that date. Without one, calculation stops.
3. Reads the enrollment's basic salary, currency and pay frequency. For a monthly enrollment it prorates basic salary by eligible calendar days from the later of the salary effective date or first day of the month through the last working day, divided by days in that month. The current non-monthly branch uses the enrollment's full basic salary rather than applying that monthly calendar-day formula.
4. Reads positive balances for approved paid leave types and calculates leave pay as basic salary × paid-leave days ÷ days in the last-working-day month.
5. Adds outstanding principal, interest, fees, penalty and tax across the employee's linked approved Loans accounts in ACTIVE or IN_ARREARS state as a deduction, plus approved, unconsumed recovery adjustments effective on or before the last working day.
6. Adds approved, unconsumed one-off earning adjustments effective on or before the last working day, then calculates net as earned pay + leave pay + other earnings − deductions. A negative result is rejected rather than recorded as an employee receivable.
7. Stores a calculation snapshot with the salary enrollment, salary effective date, basic salary, date counts, leave days, loan balance, approved recovery, unconsumed earnings and source cutoff.

This calculation does not by itself establish gratuity, notice pay, redundancy compensation, statutory tax/benefit deductions, employer benefit contributions or every allowance. Those depend on approved tenant policy and applicable legal/contractual rules. This is implementation behavior, not a certification of Uganda law or a complete final-pay calculation. HR and Finance must specifically confirm whether deducting the linked Loans account's full outstanding balance is permitted and intended for the employee before relying on that amount.

The form allows selecting an approved payroll run, but the selected run is not a substitute for checking that its period, status and employee values correspond to the separation. Review calculation detail and source cutoff. If a component or source is wrong, correct the owning HR/Loans record or use an authorized, documented override after the UI supports its reason and permission workflow.

Review and approve

Creating a settlement produces a DRAFT settlement with a generated reference and stored calculation details. The settlement row's workflow state is separate from the separation. A reviewer should compare each component with the last approved payroll enrollment, leave ledger, Loans account, recovery and one-off adjustment sources. Check business unit, currency, last working day, pay period and employee link.

An authorized reviewer approves a draft/pending settlement. The creator cannot approve their own settlement. Resolve discrepancies before approval; approval is not payment and does not itself generate a payment transaction.

Payment

Only an approved settlement can be paid, and the settlement creator and approver cannot execute the same payment. The payment form asks for a payment reference and shared payment channel, Cash or Bank. The procedure resolves Cash to the CASH_AT_HAND tag and Bank to CASH_BANK; each must resolve to its own approved account mapping for the service and currency.

After creating the shared outbound payment transaction, the procedure posts the configured final-settlement GL rule and requires a successful POSTED GL batch before marking the settlement PAID. It stores payment and GL identifiers and advances the separation to SETTLED. Read back the payment transaction, channel, reference, GL batch lines/status and settlement record; do not rely on the success toast alone.

Accounting boundary requiring policy confirmation

In the checked-in pay_hr_final_settlement procedure, the payment GL rule debits HR_PAYROLL_GROSS_EXPENSE and credits the resolved cash/bank account. The settlement-creation procedure stores the calculation but does not post a separate settlement-payable journal. Therefore the current source path is not the accrued-payable workflow (debit expense/credit payable at approval, then debit payable/credit cash or bank at settlement). Do not describe the current design as having that two-stage payable accounting unless another verified posting path supplies the accrual. Finance must confirm the intended accounting before this is treated as production-complete.

The routine rejects a negative net settlement, so this UI payment flow does not create a receivable or recover money from the employee. If the calculation indicates money owed by the employee, use only an approved recovery/Loans or receivables workflow after Finance confirms the correct posting path; do not force a negative value into this settlement form.

Completing Separation

Complete separation only after:

• The separation record is approved where required.
• Clearance is complete or exceptions are approved.
• Final settlement is approved and paid or otherwise resolved.
• Access and assets have been handled.
• The employee status should genuinely change to separated.

Settlement payment changes the exit workflow to SETTLED; do not assume this is identical to the employee lifecycle status becoming SEPARATED. Complete the relevant lifecycle transition using its authorized action and effective date, verify that the employee timeline reflects it, and separately review the linked user account. Employee access may need to be deactivated, but account disposition is not a substitute for the employment lifecycle event.

Worked exit example

Assume an employee's approved monthly basic salary is UGX 1,200,000, the last working day is the 15th of a 30-day month, the salary was effective before the month began, and the employee has two positive paid-leave days. Under the current source formula only, earned basic pay is UGX 1,200,000 × 15 ÷ 30 = UGX 600,000; leave pay is UGX 1,200,000 × 2 ÷ 30 = UGX 80,000. Before other items, the subtotal is UGX 680,000. If linked approved Loans balances total UGX 100,000 and there are no other approved adjustments, calculated net is UGX 580,000.

This is illustrative arithmetic only. It excludes statutory/contractual items the routine does not calculate and is not legal, tax or payroll advice. Verify the actual dates, salary enrollment, approved leave ledger and loan balances before using any real settlement.

Common Mistakes

• Marking an employee separated before payroll or clearance is resolved.
• Paying final settlement before approval.
• Ignoring outstanding loans, advances, or assets.
• Using the wrong last working day.
• Forgetting to remove or review system access.
• Creating a new separation record instead of updating the active one.
• Treating the source-based result as a complete statutory calculation.
• Entering one manual amount and assuming the other components will still be automatically calculated.
• Assuming a settlement payment debits a payable when the current procedure's GL rule debits gross expense directly.
• Assuming SETTLED automatically disables the employee's login or completes every lifecycle action.

Good Practice

Treat separation as a checklist-driven workflow. HR, finance, IT, and the employee’s department should each complete their part before the employee record is closed.

Related Guides

• Capabilities and Access
• Employees
• Lifecycle and Manager Workspaces
• Payroll
• Benefits and Total Rewards
• Travel and Expenses
• HR Reporting and Analytics