Bulk pay-scheme adjustment per depot: raising pay for 600 people without editing 600 rows
When the minimum wage changes by district, you adjust the pay scheme per depot, not thousands of employee rows: proposal, cost simulation, approval, then application on the effective date.
Every January, a distributor with 25 depots in eight districts receives eight new minimum-wage figures, each for a different set of depots, with allowance schemes that also differ by brand. If every employee is a row to edit, January becomes the month with the most payroll errors. A bulk pay-scheme adjustment per depot moves that work: you edit the scheme, not the people.
Pay follows a scheme, so one adjustment changes everyone in it
In HRKita, a person's pay is not a stand-alone figure. It follows a pay scheme set for a combination of depot, brand and grade. The scheme holds basic pay and every allowance component, each flagged as fixed or variable. When you adjust the scheme, everyone in it changes on the same date, by the same figure.
A bulk adjustment runs in five stages, from proposal to audit
- Proposal. HR selects the depot or brand, the component that changes, and how: a new value, a percentage increase, or a fixed-amount increase. HR also sets the effective date.
- Simulation. The system shows the list of people affected, old pay, new pay, and the total added cost per month per depot. This is the figure taken to the owner.
- Approval. The proposal is approved in tiers. A rejected proposal is kept as a rejected proposal, with its reason.
- Application. On the effective date the new scheme replaces the old one. The old scheme stays readable for earlier periods, so back pay and corrections are calculated from the right figures.
- Audit. The system records every scheme change: who proposed it, who approved it, and from what value to what value.
The three most common cases use the same flow
- A new UMK per district. HR raises one proposal per depot. Basic pay for the lowest grade rises to the new UMK (the district minimum wage), and the grades above it move according to the wage structure, not by the same percentage.
- A new allowance for one brand. HR adds the component to that brand's scheme only; other brands are untouched.
- Migration from an old scheme. When two depots merge, HR moves people to the new scheme with a per-person simulation of the difference before the proposal is approved.
Preparation before January decides whether the adjustment is right
- A list of depots with their correct districts, because the UMK follows the district where people work.
- A wage structure that states how the grades above the minimum move when the minimum rises. Without it, UMK increases flatten the whole structure within three years.
- One owner's decision on the effective date and on back pay if the decision comes late.
The system does not hold an official table of UMK figures per district. HR enters the UMK figures from the governor's decree every year. Sales incentives calculated from targets are a separate component run per client according to its scheme, and are not part of this bulk adjustment.
In HRKita, the owner decides on the same simulated figures that get applied
The owner receives one table: depot, number of people affected, added cost per month, and added cost per year including the effect on THR (the religious holiday allowance). The table comes from the simulation, not from a rebuild in Excel, so the owner decides on the same figures that will be applied. The effect on the employer's BPJS contributions is added by HR from a calculation outside the system, because in HRKita BPJS contributions are calculated outside the system and uploaded per period (see the BPJS explainer and calculator).
The difference between the simulation and January's actual payroll should be zero. If it is not, someone moved between schemes in between, and that move is recorded in the audit trail. See how schemes and payroll connect on the Core HR & Payroll page, or book a demo and bring your depot list.