People Platform: how we build it

Contributions follow the entity, not the country — and seventeen people are set up wrongly today

You told us KPI Media has three employing companies: Singapore, Indonesia and Malaysia. A few of the Jakarta staff sit under the Indonesian company and pay BPJS. The rest sit under the Singapore company and contribute nowhere.

That breaks an assumption the whole payroll engine was about to be built on. The plan you first read said a person's contribution scheme was decided by where they work. It is not. Two people at neighbouring desks in Jakarta fall under different schemes depending on which company employs them, and nothing about where they sit tells you which.

The workbook has all twenty-two Indonesians marked as BPJS, and all thirty-two marked as employed by KPI Media Pte Ltd. Both are defaults nobody filled in — the same pattern as every identity document being labelled “passport”. Taken literally, we would have deducted BPJS from seventeen people who should have nothing deducted, every month, from the first live payroll.

Anwar has since named the five who do contribute and file: Novicto, I Wayan Raka, Shahira, Putu Dewi and Kartika. Because BPJS requires an Indonesian employer, naming those five also names the Indonesian company's payroll — which answers what this box previously called the single most important thing outstanding. Five under the Indonesian entity, seventeen Indonesians under Singapore, two Malaysians under Malaysia, the rest under Singapore. HR should still confirm it in their own words rather than have it read off a contribution list, but nothing is waiting on it.

One clarification, because it is easy to talk past. KPI Media is one business — one team, one culture, one set of clients — that employs people locally through entities in Indonesia and Malaysia. Both statements are true at once, and only the second one reaches the payroll engine. “Same company” describes the organisation; the platform needs to know who signs each employment contract, because that is what decides the deductions and the year-end form. Nothing about this changes how the business thinks of itself.

Two refinements came out of the same conversation. Contributions and tax withholding are now two separate settings rather than one — someone can sit outside BPJS and still have Indonesian tax withheld, and a single field cannot say that. And any individual can be set to something other than what their company implies, which is what scheme_override is for: it requires a written reason and shows on the record as a deliberate exception. Nobody needs one today. It exists so that the next genuine exception is recorded as an exception, instead of being typed over the top of a fact — which is precisely how twenty-two rows came to be wrong in the first place.

Why the override table should stay almost empty

Approval normally follows the reporting line exactly, with nothing recorded anywhere. approver_override exists for the genuine exceptions — chiefly that the CEO reports to nobody, so his own leave has to reach someone. If that table starts filling up, it is a signal the reporting line has stopped being true, and the fix is the org chart rather than more overrides.

Directors' fees go through payroll. Dividends do not.

You asked for both as new lines. They are three different kinds of money and only two of them are ours to report.

A directors' fee is taxable and belongs on the year-end form, but carries no CPF — it is paid for holding office, not for work done. So it is a payroll line with its own rules. One thing worth knowing: a directors' fee is taxable in the year it is voted at the AGM, not the year it is paid. If a fee is approved in one year and paid the next, it belongs on the earlier year's form, so we record both dates.

A dividend is a return on shares. Under Singapore's one-tier system it is tax-exempt in your hands, touches no contribution, and does not appear on a tax form at all. Putting it through payroll would mean teaching CPF, the levies, the tax brackets and every year-end form to individually ignore it — and each one that forgot would be a filing error rather than a display bug. So it is recorded, its year-to-date figure is shown, and it never enters the payroll engine. It is also kept out of total staff cost, because a dividend is not a cost of employing anyone.

Anwar can approve a run he prepared — but not quietly

Two of your answers pulled in opposite directions. One said Anwar needs to prepare and approve payroll himself if Arul and Agus are both away. The other said only one of the four can ever be on leave at a time, so that cannot happen.

We found something while checking: Anwar can already do both steps today. Not because anyone granted it — directors hold every permission, and that quietly includes preparing payroll as well as signing it off. The two-person check has never actually been a rule.

So we are doing both things. The system will refuse to let one person do both steps, and Anwar can push through anyway with a written reason that notifies you. He is never blocked; it simply cannot happen invisibly. And the leave module will enforce the rule you described, refusing a leave request from any of the four that overlaps another's — which turns the reason four approvers is safe into something the system guarantees rather than something everyone remembers.

The honest cost: four people's holidays are genuinely constrained, yours included.

What your year-end leave rule does, in your own numbers

You gave two worked examples and they pin the rule exactly. At the close, annual leave and off-in-lieu are one pool. Five days carry forward, filled from off-in-lieu first. Leftover off-in-lieu burns. Leftover annual leave is encashed up to ten days, and the rest burns.

Filling from off-in-lieu first is the version that pays people more. In your own second example — ten days off-in-lieu and twelve days annual leave — taking off-in-lieu first carries five, burns five, and encashes ten. Doing it the other way round would encash only seven. The ordering is worth three days of cash to that person, so it is worth confirming it was deliberate.

The number nobody has seen yet: about 57 days of off-in-lieu burn at the first close, across 22 people. The company is carrying 178.5 off-in-lieu days and nothing has ever removed a single one — Natalie holds 11.5, Luck and Ferrin ten each. Those days were earned by working a public holiday or a weekend, which is not the same as an unused grant expiring, and people will not experience it as the same thing. This is the main reason the October announcement matters, and why it should come from you rather than from Finance.

The cutoff you proposed does close the gap cleanly. Applications shut on 19 December — Finance starts payroll on the 20th, so it has to be the day before, not the same day — and anything that moves afterwards, a cancelled booking or off-in-lieu earned over Christmas, rolls into January as a fresh day in the new year. The closed year never reopens, and the December payslip can carry the encashment because the balance is final when it is computed.

Balances are calculated, never stored

The current tracker stores some balances and calculates others, and one figure the whole post-March calculation depends on is typed in by hand. That is why balances drift. In the new system every balance — days remaining, off-in-lieu held, benefit spent, direct reports, next review cycle — is worked out from the underlying records each time it is shown. It cannot fall out of step, because there is nothing to fall out of step with.

Claiming $130 against $70 of cap left

The first edition of this plan rejected that claim outright. The employee would have had to resubmit at $70 — holding a receipt that says $130. A claim whose amount disagrees with its own receipt is the thing an auditor stops on, so that was wrong.

A claim now carries two figures: what was asked for, and what was agreed. $130 claimed, $70 approved, $60 not reimbursed and visible as such. The receipt still matches the claim. The payment still matches the approval. Nothing has to be pretended.

Finance can also part-approve on the uncapped categories — "you claimed $400 for the dinner, we will cover $250". That is a judgement rather than arithmetic, so it requires a written reason. Where a cap is simply being applied, no reason is typed: the system states the arithmetic itself, and asking Finance to retype what the platform already knows produces boilerplate rather than explanation.

Two consequences worth stating. The cap is consumed by the approved amount, not the claimed one — that $130 claim uses $70 of the year's allowance, not $130. And the approved figure is always SGD, so a cap is spent exactly and cannot drift; what reaches an Indonesian account is that SGD figure converted at the month's declared rate, which moves the rupiah a little either way.

The receipt itself keeps its own currency. A receipt for IDR 1,700,000 is recorded as IDR 1,700,000 and never converted, because the whole value of attaching it is that the claim and the document agree. So a claim carries a local claimed amount and an SGD approved amount, and that asymmetry is on purpose.

These stack. They are not tiers you move between

You asked whether Arul and Agus can still submit claims and request leave like anyone else, and whether the same holds for you and Anwar. Yes — and it already does.

Access is added, never swapped. All four of you hold the ordinary employee access shown in the first card below, and Finance or Super Admin access sits on top of it. Arul submits a claim the same way anyone else does; it simply gets approved by Agus rather than by himself, because the database refuses an approval from the claimant at either stage.

That was true in the first edition too — the four cards below read like a ladder, which was our mistake in drawing them, not a gap in the design.

Super Admin sees everything — so the controls are on acting, not on seeing

A Super Admin can read every table in the platform, salary and bank details included. That is a deliberate choice: the two people holding it run the company, and a control that hides the payroll from the CEO would be theatre rather than security.

What the role is constrained on is signing. Every claim needs two signatures from two different people, so a Super Admin cannot stand in for the Finance stage on a claim they will also finalise. Nobody, at any level, approves their own claim — and there is no override on that one. And the audit log and the leave award ledger are append-only for everyone: the highest access in the system still cannot erase what it did.

Payroll is the one place with a door rather than a wall. Finance prepares a run and cannot release it. A Super Admin releases it, and can also prepare it when there is no alternative — but not without saying why, and not without the other Super Admin being told. That is the difference between the two controls: a claim's second signature protects against self-dealing, so it is absolute; a payroll run's second signature protects against an unnoticed mistake, and a control that could stop payroll happening at all would be worse than the risk it removes.

The practical consequence is that four people can open a bank account number rather than two. Every one of those opens is logged with a name and a timestamp, which is what makes broad read access acceptable rather than merely convenient.

Benefit caps stay flat at $150 medical and $100 flexi

You wrote: "This card limit needs to be changed across all employees. Change benefits to follow Scale instead. Scale 1-3 $25, 4-6 $50, 7-9 $75."

We read that as being about card limits throughout — $25 and $50 are literally the card values in use today, and $25 a year of medical cover would be a cut from the current $250. So the bands went to the cards, and the benefit caps were left alone.

Anwar has confirmed this reading: the scale bands apply to card limits only, and benefits stay flat. The one place where we had not followed your words as written is now closed, and it turned out we had read you correctly.

Both of the things we asked you for are now closed

Benefit caps. Confirmed flat at $150 medical and $100 flexi; the scale bands apply to card limits only. We had read you correctly.

Backup retention: 35 days. This is what makes the five-year destruction rule real rather than decorative — deleting a bank account number from the live system does nothing about the copy in a backup. Backups exist to recover from disaster, not to keep records, and the five-year obligation is met by the live system. Thirty-five days covers a full payroll cycle plus a week, so we can still recover from something discovered at the following month's close. Backups are encrypted, and access to them is logged.

The deadline is gone — and “rename PM to PML” would have been the wrong thing to do

The first edition carried one hard deadline: HR had to rename PM to PML in the tracker before the export was taken, or parental leave would silently turn into annual leave and quietly eat people's balances.

Looking at it properly, PM was never being renamed. It keeps its meaning — Annual Leave, Afternoon, half a day, deducts from the balance. PML is a new code for parental leave. A blanket rename would have converted every afternoon half-day anyone has ever taken into non-deductible parental leave, handing back days people had already spent. That is the original problem pointing the other way, and it is what “just rename it, it's the same” produces.

The two are mechanically distinguishable: parental leave is a full day, an afternoon is half a day, and HR confirms they have never been logged otherwise. So the split happens in code at import, and nothing has to happen in the tracker at all. The export can be taken whenever it suits. The import refuses to run and names the rows if it finds a PM row that is neither half a day nor a full one — the rule rests on a recollection, and a recollection that turns out to be wrong should stop the import rather than quietly mis-file someone's leave.

This project no longer has a hard deadline.

One thing we would raise even though you did not ask

Deferring the appreciation app is right — nobody has specified it yet. But two things about it are worth knowing before it is picked up, because both are easy now and awkward later.

Redeemed credits are taxable pay, not an expense claim. Nobody spent anything — it is a reward, so in Singapore it is employment income: CPF-able and on the year-end form. If a redemption arrives as an ordinary claim it will default to "reimbursement" and quietly escape both. The override in Figure 4 handles it, but somebody has to set it deliberately.

Earned credits appear never to expire. That is the same shape as off-in-lieu — a balance that only ever grows, and becomes an obligation the day someone leaves. You have just decided off-in-lieu burns. It is worth deciding the same question for credits before the balance is three years deep rather than after.