← systeric.com Interwise / Docs
Open App →

Compliance as a Calendar

Nobody is surprised by the tide. It is published, it arrives on time, and people still get caught out, because knowing that the water moves is not the same as having read the table for today.

Indonesian payroll regulation works the same way. The changes are announced, they arrive on a rhythm you can predict a year ahead, and the reason a company is caught short in January is almost never that the rule was secret.

This page is about the shape of that stack and its rhythm. For the actual numbers currently wired into the engine, see Compliance Reference.

The stack, and how fast each layer moves#

Indonesian law is hierarchical, and the practical value of knowing the hierarchy is that it tells you how often each layer changes and therefore what you have to watch.

UU — statute decades PP — government regulation years PMK / Permenaker often rates & circulars every year
The layer that almost never moves is the one everybody quotes. The layer that moves every year is the one that changes what we have to ship, and it is the narrow one at the top.

UU, the statute. UU 13/2003 on manpower, substantially amended by UU 6/2023 (Cipta Kerja). This is the foundation and it moves rarely, but when it moves it moves everything above it.

PP, government regulations. Where the statute becomes operational. PP 35/2021 covers fixed-term contracts, working time, overtime and termination. PP 36/2021, amended by PP 51/2023, covers wages. The BPJS programmes each have their own: PP 44/2015 (JKK and JKM), PP 46/2015 amended by PP 60/2015 (JHT), PP 45/2015 (JP), PP 82/2018 (Kesehatan), PP 37/2021 (JKP).

PMK and Permenaker, ministerial regulations. Where the method is specified. PMK 168/2023 and PP 58/2023 define the current PPh 21 withholding regime including the TER tables; PER-2/PJ/2024 covers the filing mechanics. Permenaker 1/2017 requires a wage structure and scale.

Rates, circulars and annual announcements. The layer that moves constantly: minimum wage decisions each year, BPJS ceiling adjustments, THR circulars before each Idul Fitri, filing deadline notices.

Every citation here is our current understanding and must be re-verified against JDIH Kemnaker, peraturan.go.id or pajak.go.id before it drives code.

The year has a shape#

The rhythm matters more than the list, because it is what lets you prepare instead of react.

  • Late in the year, provincial and district minimum wages are announced for the year ahead. Salaries at the floor have to move, and so do the structures they sit in.
  • January, new rates take effect. Tax tables, contribution ceilings and minimum wages all land at once, and the first run of the year is the one most likely to be wrong.
  • Before Idul Fitri, THR is due, by regulation, to be paid at least a week before the holiday. The date moves each year with the lunar calendar, which means the deadline moves and cannot be hardcoded.
  • Mid-year, ceilings and programme parameters occasionally adjust.
  • December, the annual tax settlement. Eleven months of flat withholding are reconciled against the true annual liability, producing refunds and top-ups. It is the hardest run of the year and the one customers most fear.
  • After year end, annual filing and the evidence a company needs if it is examined.

What this actually means for a vendor#

Three things follow, and they are more useful than any list of regulations.

Nobody has an information advantage. The regulations are public and every competitor reads the same gazette on the same day. There is no proprietary knowledge here, which means compliance coverage is not a moat. Anyone can catch up on any single rule.

The differentiator is latency. The gap between a rule taking effect and a customer being able to run correctly under it is the only thing that varies between vendors. Most of the pain in this market is not vendors who do not know about a change; it is vendors who take two months to ship it, during which their customers are doing it by hand.

A regulation change is a migration, not a config edit. A new rate does not just apply going forward. It raises immediate questions about periods already run, corrections to already-filed returns, and which historical rate a retroactive adjustment should use. A system that stores only the current rate cannot answer any of those, and will quietly recompute history the moment somebody opens an old run.

Why this matters to our strategy#

We have said the moat is explanation rather than coverage, and this is where that gets tested, because compliance is the thing every competitor will claim and every buyer will ask about.

The claim survives if you take it precisely. Coverage is table stakes: a payroll product that gets PPh 21 wrong is not in the market at all. What coverage cannot do is win, because it is copyable within one release cycle. What is not copyable is a customer who reads the December settlement, sees each employee’s refund or top-up with a reason attached, and does not build a spreadsheet to check it. That is a product property, not a regulatory one.

The one place where speed is genuinely strategic is January. A customer whose first run of the year is correct and explicable, on the first attempt, has just had the single most anxious payroll of their year go quietly. That is worth more than any feature we could ship in the same weeks, and it is why the regulatory calendar should be visible on our roadmap rather than handled as interrupts.

There is a second advantage we should not waste. We run our own payroll on Interwise, so we feel each change on our own staff before a customer does. That converts a compliance obligation into an early warning system, and it only works if we are not late for ourselves.

What this means for what we build#

  • Rates are dated data, never constants. Every rate, ceiling and table needs an effective period, and every calculation must resolve the rate that applied to the period being computed rather than the rate that applies today.
  • Recomputing an old period must reproduce the old number. If reopening a March run under new rates changes March, we have destroyed the audit trail and every explanation we ever gave about it.
  • Never hardcode a moving date. THR is tied to a lunar holiday. Filing deadlines shift. These belong in configuration with a calendar, not in a constant.
  • Plan capacity around the calendar. November and December are not ordinary sprints, and January is not a good month to be carrying an unshipped rate change.
  • Explain a change to the customer, not just implement it. When a rate moves, the affected employees and the size of the effect should be shown before the run, so the customer learns about it from us rather than from an employee’s complaint.