Switching payroll systems mid-year without breaking your P9s

A payroll system only has to get one month right at a time. The KRA does not work that way. A P9 covers a full calendar year, and it has to reconcile with what was actually deducted and remitted across that whole year — including the months your new system has never seen.

So the risk in a mid-year switch is not the first payroll you run in the new system. That one is usually fine. The risk arrives in December, when you produce P9s that start from the month you migrated and quietly omit everything before it. Every employee's income looks understated, their tax paid looks understated, and the first person to notice is whoever is trying to file.

Less than people expect, but the list is not negotiable. Everything here changes a figure the KRA will eventually see, or a balance an employee will notice:

Note what is not on that list. You do not need every payslip PDF, every historical bank file, or three years of archived runs. The old system can keep those. What you need is enough to make this year's totals correct and this year's balances continuous.

This is the distinction that makes a mid-year switch safe, and the one most systems get wrong.

The months before your switch have already happened. The employees were paid. The deductions were remitted. The filings were made, by whoever was running payroll at the time. Loading those months into a new system must therefore record what happened — and must not pay anybody again, file anything again, or email a payslip for a month that was settled in March.

Mavuno HR treats them as exactly that. A month recorded as historical counts towards year-to-date figures and P9s, and is deliberately excluded from filing reminders, payout batches and automatic payslip emails. You tell it which month you became the system of record, and everything before that is a record rather than an instruction.

Tax gets the attention because the KRA is on the other end of it. Leave quietly costs more, because nobody notices until somebody resigns.

A new system that starts everyone on a full annual entitlement has just given your whole team their leave twice — once under the old system, where they already took some of it, and again under the new one. That is a real liability, and it crystallises the day you pay somebody out for untaken days they had in fact already taken.

The fix is to enter the balance each employee had remaining at the switch, not their annual entitlement. It is an opening balance, in the accounting sense, and treating it as anything else is how a leave liability appears from nowhere at year end.

Pick the cutover month first and write it down. Everything before it is history; everything from it onwards is live. Ambiguity here is what produces a month that gets paid twice or filed twice.

Load employees before months. A historical run needs someone to attach itself to, and an employee record missing a KRA PIN will fail validation whichever month you are loading.

Reconcile one month before loading twelve. Load a single historical month, then compare its totals against what the old system reported for that month. If they disagree, find out why before repeating the mistake eleven more times.

Run the first live month in parallel. Run it in both systems and compare before paying anyone. It is the only test that matters, and it costs one afternoon.

Check a P9 before December, not in December. Produce one for a single employee as soon as the historical months are in. If it covers the whole year and reconciles, the migration worked. If it starts at your cutover month, you have found the problem in August rather than in the filing window.

Sometimes the right answer is not to migrate now. If you are already in the last quarter, the old system is working, and nothing is actually broken, running the remainder of the year where you are and starting clean in January is a legitimate choice — and a much shorter project.

Migrate mid-year when the current system is the problem: when it is producing wrong figures, when the person who understood it has left, or when the cost of one more month of it exceeds the cost of moving. Do not migrate mid-year merely because a contract renews.

Mavuno HR is built for Kenyan payroll specifically — PAYE, NSSF, SHIF and the Housing Levy, with statutory rates applied from the pack in force for the month being run, not the month you happen to be sitting in. That last part is what lets a historical month recompute to what it actually was rather than to today's rates.

Mid-year migration is a supported path rather than a workaround: you set the month Mavuno becomes your system of record, load the earlier months as historical runs one at a time or by CSV, and your P9s and year-to-date figures cover the whole year. You can see what it costs or start a free trial and load a single historical month to see whether the totals reconcile before committing to anything.