The rates change and the spreadsheet does not
Most statutory errors are not misunderstanding the law — they are a formula copied from last year’s file after a rate quietly changed.
Keep statutory work under control
Computed Every Run
PF with pension split, ESI with its wage limit and period rule, state-wise PT, LWF in the right months, TDS across the year.
Artefacts From The Same Run
Payslips, bank file, registers and return inputs all derive from the run you approved — they cannot disagree with each other.
Rates Are Versioned
Effective-dated configuration, so last March computes with last March’s rates when you reopen it.
Most statutory errors are stale formulas
Very few compliance failures come from misunderstanding the law. They come from a spreadsheet formula that was right last year, copied forward after a rate changed, and never questioned because the output still looked plausible.
That is a version-control problem wearing a compliance costume, and it is fixed by dating the rates rather than by knowing the law better.
Effective-dated, so history stays correct
Rates are versioned with the date they take effect. A change in October applies from October — it does not retrospectively rewrite the months already computed and filed.
This matters the moment anybody recomputes a past period. A system that applies today's rates to last March produces figures that disagree with what was actually filed, and then somebody spends a day working out which version is real.
Artefacts from the same run
Payslips, the bank file, the registers and the return inputs all derive from one computation. They cannot disagree with each other, because there is only one set of numbers.
Where they are generated separately — a payslip from one place, a register from another — they eventually diverge, and the divergence is found by whoever is least well placed to explain it.
The calendar is the other half
Computing correctly is necessary and not sufficient. The obligations have dates, and missing a date is its own failure. An obligation calendar with a filing ledger records what was due, what was filed, and when — so the answer to "did we file that" is a record rather than a search through email.
From computation to filed
Computed on every run
PF, ESI, PT, LWF and TDS from versioned, effective-dated rates.
Artefacts from that run
Payslips, bank file, registers and return inputs — one set of numbers behind all of them.
The calendar
Obligations with their dates, so nothing is remembered rather than tracked.
The ledger
What was filed and when, recorded — so the question can be answered rather than searched.
Keep statutory work under control FAQs
Does Klok file the returns for us?
No. It produces the return inputs and files — the ECR for PF, the ESI and PT outputs, the 24Q inputs — and records what you filed and when. There are no portal e-filing APIs to submit on your behalf, and any vendor claiming otherwise is worth questioning.
What happens when a rate changes mid-year?
The new rate is added with its effective date and applies from there. Months already computed keep the rates they were computed with, so nothing already filed is retrospectively altered.
Does it handle multiple states?
Yes — professional tax and labour welfare fund resolve by workplace, which is what the legislation actually requires.
What if we are already behind?
Start with the current period computed correctly, then work backwards. Trying to reconstruct two years before running a single correct month is how remediation projects stall.
Does this mean we stop worrying about compliance?
No, and any vendor saying otherwise is overselling. It means the filings are drafted from the record and the obligations are on a calendar — the panic usually comes from assembling data late, not from the rules.
Who actually files?
You do. Klok produces the formats; a human reviews and files, because no Indian portal offers an e-filing API that would allow anything else.
Try it on your own payroll
Fourteen days, no card, and every record exports back out if you decide against it.