HR design for multi-vendor outsourcing: who holds whose data
One factory, three outsourcing vendors, one attendance machine. Unless it is decided who holds which data, three payrolls go wrong in three different ways in the same month.
In factories and depot networks, the company's own employees and workers from two or three outsourcing vendors often scan the same attendance machine and work on the same lines. Every month, three payroll teams in three companies then calculate from three different copies of the data. The problem is not the software: HR design for multi-vendor outsourcing starts by deciding who holds which data.
Each kind of data in multi-vendor outsourcing has one source of truth
| Data | Source of truth | Recipient | Why |
|---|---|---|---|
| Identity and contract | Vendor (the employer) | User company: name, NIK (employee number), placement only | The vendor is legally responsible for the contract and BPJS (social security) |
| Shift schedule and attendance | User company (owner of the machine and the line) | Vendor: one file per period, per vendor | The work actually happens at the user company's site |
| Overtime (SPKL, overtime work order) | User company: the order and the approval | Vendor: approved actual hours | Whoever orders the overtime approves it |
| Salary scheme and payroll | Vendor | User company: cost recap per placement | Wages are a matter between the vendor and its employee |
| Discipline and SP (warning letters) | Vendor, on reports from the user company | — | Sanctions are only valid from the employer |
The monthly flow locks attendance on day 20 and vendor payroll on day 25
- Day 1: the vendor sends the list of active placements (joiners, leavers, line transfers).
- Throughout the month: the user company submits and approves SPKLs in its system; vendor employees confirm at the same kiosk as the company's own employees.
- Day 20: the user company validates attendance per vendor and locks it.
- Day 21: the user company sends the attendance and actual-overtime files, one file per vendor, containing only that vendor's people.
- Day 25: the vendor runs payroll; the cost recap per placement goes back to the user company as the basis for checking the invoice.
Three design mistakes invite disputes and UU PDP risk
- The user company stores the vendor employees' salaries. This is unnecessary, and dangerous under the UU PDP (Personal Data Protection Law): the user company becomes the controller of data that is none of its business. A cost recap is enough.
- The vendor receives the entire attendance file. Vendor A sees the working hours of vendor B's people. Separation per vendor is not a courtesy; it is an obligation.
- The vendor approves overtime. The vendor is not on the production floor. Approval at the vendor means approval after the event, and the entire value of the SPKL is lost.
Read the employee data protection obligations on the data security and UU PDP page.
The data-owner table belongs in the outsourcing agreement
Attach the table above to the outsourcing agreement, with the position titles of the data owners on both sides. Invoice disputes almost always begin with a table row that was never written.
In HRKita, vendor employees join the same SPKL and are exported per vendor
For outsourcing companies, HRKita separates companies and brands with access rights per company: one user sees only their own clients. On the host factory's side, the system identifies vendor employees by their vendor and placement. They take part in the same SPKL and kiosk, and their data is exported per vendor at attendance validation. Invoicing between vendor and user company stays in each party's own finance system; HRKita provides a recap that both sides can reconcile. See HRKita for outsourcing companies.