PKWT contract-expiry reminders must be automatic: what a working one looks like
A PKWT that passes its end date without a decision carries legal consequences. A per-period register and 30/60/90-day lists per unit keep hundreds of end dates under control, without surprises.
Every PKWT (fixed-term contract) has a term, and you have to decide whether to renew or end it before that date arrives. In a factory or an outsourcing company with hundreds of contracts ending on different dates, a manual reminder is always late at some point, and a contract that keeps running past its term risks being read as a PKWTT (permanent contract), so the money owed changes from compensation pay to severance. That is why PKWT contract-expiry reminders must be automatic: built from a per-period contract register and sent to the unit head who decides.
The spreadsheet loses because end dates are stored per person
A spreadsheet can count dates. It loses for three reasons. First, end dates are stored per person rather than per contract period, so a renewal overwrites the history. Second, nobody's job is to open it every week. Third, the list never reaches the person who has to decide: the unit head who actually knows the employee.
A working PKWT reminder has five elements
- A contract register per period. One row per contract period: start date, end date, type, and the base wage at the time. An employee renewed twice has three rows, not one row whose date keeps changing.
- 30/60/90-day lists per unit. The system generates them automatically on a fixed date each month and sends them to unit heads, not only to HR. Each unit head sees the names that are their responsibility.
- Renewal history. The number of renewals and the total term are visible per person, so the maximum term is not crossed unnoticed.
- A recorded decision. Every name on the list is closed with one of three decisions: renew, do not renew, or convert to PKWTT. A name with no decision 14 days out appears as an exception.
- Links to evaluation and payroll. A renewal creates a new period in the register; an ending triggers the compensation calculation from wage components flagged as fixed.
Each role reads a different list, at a different time
| Role | What they see | When |
|---|---|---|
| Unit head | Names in their unit ending within 60 days, with an evaluation button | The 5th of every month |
| HR | All units; names with no decision 14 days out; total term per person | Every working day |
| Payroll | Contracts ending this month with compensation calculated | Before period close |
| Owner | Share of contracts decided at least 30 days before the end date, per unit | Monthly |
One number shows whether the reminders work
Track the percentage of contracts whose decision is recorded at least 30 days before the end date. In a factory that has just set up the register, this usually starts below half and climbs above 90 percent within three months once the list reaches unit heads. A number that stays low points to a wrong mapping of unit heads, not to the employees.
In HRKita, the contract register and reminders are part of employee data
The per-period contract register, the per-unit expiry lists and their reminders live in HRKita's employee data, and tiered contract evaluation reads the same register. The reminder does not replace the decision. It makes sure the right person decides before the date, and that the decision is on record. See the contract register and reminders in the core HR and payroll module, and the evaluation flow in the performance and evaluation module.