Make payroll management easy with ZonePayroll in NetSuite. Streamline your processes for efficient and accurate payroll.
Moving payroll is the systems change most businesses put off longest, and for understandable reasons. Payroll has to be exactly right, the consequences of getting it wrong are immediate and personal, and the people who understand the current configuration are usually the same people who would have to run the transition.
It is entirely doable and it rewards preparation more than almost any other project of comparable size. This article covers what a move to ZonePayroll on NetSuite actually involves, in what order, and where the difficulty genuinely lies rather than where people expect it.
The usual trigger is not dissatisfaction with the existing payroll application. It is the accumulated cost of payroll living outside the ERP.
Every cycle, somebody posts a journal, reconciles a clearing account and investigates the differences. Every month end, the same again. That work is invisible in any cost comparison and it is not small.
Labour cost, usually the largest cost in the business, arrives in the general ledger as a summary rather than as coded transactions, which means labour by department, project or location is either unavailable or assembled manually.
And the employee exists twice, in the payroll system and in the ERP, with the two drifting apart quietly because nobody notices when they do.
ZonePayroll is built as a SuiteApp, which means it runs inside NetSuite rather than connecting to it, and the consequences follow from that architecture.
The pay run posts directly to the general ledger. There is no interface, no file, no journal to enter, and therefore nothing to reconcile between two systems because there are not two systems.
Every pay component carries the same dimensional coding as the rest of your ledger, so labour cost by department, class, location or project is a standard saved search at transaction level.
The employee is one record, so a change of department or manager happens once and everything downstream follows.
And permissions, audit trail and approval workflow come from the platform rather than being maintained separately, which removes a whole category of administration.
Timing affects the difficulty of this project more than any other decision you will make about it.
The start of a financial year is by a clear margin the cleanest option. Year to date figures start from zero, which removes most of the migration and reconciliation burden and makes the Single Touch Payroll position straightforward.
Mid year is entirely possible and costs more in verification. Year to date balances have to be migrated accurately for every employee and every pay component, and they have to reconcile exactly, because errors there affect every subsequent submission for the rest of the year.
Avoid periods that add variables. An award rate change, a peak trading period, or a month where key people are on leave all make a difficult verification harder than it needs to be.
And allow more time than the software timeline suggests, because the application configuration is rarely the long pole.
The genuinely difficult part of a payroll migration is not technical. It is establishing exactly how your current payroll interprets your obligations.
Which award applies to which employee, and at what classification. Which allowances apply, in what circumstances, and whether they attract superannuation. How overtime and penalty rates are calculated for each group. How leave accrues for part time and casual staff.
In most businesses this is undocumented and lives in the head of whoever has run payroll for the last decade. Extracting it is the work, and it cannot be done by the software vendor or the implementation partner alone.
Businesses that budget properly for this phase move smoothly. Businesses that assume the configuration can be copied from the old system discover during parallel running that nobody knows why the old system did what it did.
Data preparation is straightforward in principle and worth doing carefully.
Employee master data needs to be current and complete. Tax file number declarations, superannuation fund details, bank accounts, addresses, employment type and start dates.
Leave balances need to be accurate and agreed, including any that are tracked outside the payroll system, which is more common than people expect for long service leave.
Year to date figures, where you are moving mid year, need to be extracted at the component level rather than as totals, because Single Touch Payroll Phase 2 reporting depends on the disaggregation.
And this is a good moment to clean up records for terminated employees, since carrying years of inactive records into a new system serves no purpose.
The configuration decisions that matter most are the ones with compliance consequences, and they deserve explicit review rather than replication.
Pay code setup determines Single Touch Payroll Phase 2 reporting, since gross must be disaggregated into overtime, allowances, bonuses, paid leave and salary sacrifice. A code categorised incorrectly produces a submission that is wrong in a way nobody notices until the ATO does.
Ordinary time earnings determination drives superannuation, and the treatment of allowances, overtime and bonuses is not uniform. Getting this wrong misstates super for every employee simultaneously.
Award interpretation covers classification mapping, allowance eligibility and penalty rate application, and it is where most underpayment remediation originates.
Leave accrual rules, particularly for part time and casual staff and for long service leave across states, produce errors that compound silently for years before surfacing at termination.
Parallel running is the control that makes a payroll migration safe, and it is frequently done in a way that proves less than people assume.
Comparing net pay totals is not sufficient. Two systems can arrive at the same net through different combinations of gross, tax and deduction, and the difference matters for reporting even when the payment is identical.
A proper parallel compares at component level for every employee. Gross by pay code, tax, superannuation, each deduction and leave movement, with every difference explained individually rather than netted off.
It also needs to cover the awkward cases deliberately rather than by chance. A termination, a back pay, a leave payment, a salary sacrifice arrangement, somebody who crossed a threshold.
Two cycles is a reasonable minimum and three is better where the payroll is complex. The cost of an extra cycle is small against the cost of discovering a systematic error after cutover.
The cutover itself is short and it rewards planning in the same way any cutover does.
Agree the last pay run on the old system and the first on the new, and communicate both dates widely so nobody is surprised.
Freeze changes in the old system at a defined point, because a change entered after the extract creates a discrepancy that surfaces weeks later.
Confirm the Single Touch Payroll position, including that the new system is correctly registered and that the year to date figures it will report match what has already been submitted.
And decide in advance what would cause you to defer, because making that call under pressure the night before is how bad decisions get made.
This is the part most projects underinvest in, and payroll is the one system where every employee is a user with a direct personal stake.
Tell people what is changing and when, well in advance, and be specific about what stays the same. Most employees mainly want to know that they will be paid the same amount on the same day.
Explain what a payslip will look like if the format changes, because an unfamiliar payslip generates a wave of questions that is entirely avoidable.
Where there is a self service portal, introduce it deliberately rather than assuming people will find it, since a portal nobody uses removes none of the administrative load it was bought to remove.
And have somebody available to answer questions in the first cycle, because the volume is predictable and the alternative is those questions landing on whoever is least equipped to answer them.
The finance team is the group whose work changes most, and mostly for the better.
The payroll journal disappears as a task, since the pay run posts directly. So does the clearing account reconciliation, which for many teams is several hours per cycle plus the month end investigation.
Labour cost reporting becomes available at the same granularity as everything else, which for project based or multi entity businesses is frequently the main reason for the move.
Superannuation and tax liabilities appear in the ledger as they accrue rather than being posted after the fact.
The trade off is that finance now sees payroll detail it did not previously see, which occasionally raises questions about access and confidentiality that are worth settling during configuration rather than after.
Bringing payroll onto the main platform raises a legitimate concern about who can see what, and it has a straightforward answer.
NetSuite's role and permission model handles payroll data the same way it handles anything else, which means access can be restricted to named roles at field level.
The practical configuration usually gives payroll administrators full access, gives finance access to the posted totals and the dimensional detail without individual pay data, and gives managers access only to their own team where that is wanted.
Setting this up properly at the outset is considerably easier than retrofitting it, and it removes the objection before it becomes an obstacle.
It also produces a better position than most separate payroll systems, where access tends to be all or nothing.
Treat the first live run as an event rather than as business as usual, even after successful parallel cycles.
Allow more time than the process will eventually need, and have the implementation partner available rather than on call.
Review at component level rather than approving on the total, since this is the run where a configuration difference would show up.
Confirm that the Single Touch Payroll submission was accepted and that the figures are what you expect, rather than assuming that no error message means no problem.
And confirm that the general ledger postings landed where they should, with the right dimensional coding, because that is the benefit you moved for.
Two later milestones deserve the same attention as the first pay run and usually get less.
The first month end is where the accounting side is genuinely tested, including the accruals and the reconciliation of the balance sheet accounts payroll now feeds directly.
The first superannuation quarter is where the fund payment process is tested end to end, including that contributions reach funds by the deadline, since the received by date is what counts rather than the payment date.
Both are worth walking through in advance rather than discovering, and both are considerably easier the second time.
Payroll is not a system you configure and leave, because the rules underneath it change every year.
The annual wage review flows into modern award rates from the first full pay period after the operative date, which means somebody has to know which classifications are affected and apply the change on time.
Superannuation guarantee rate changes apply based on when payment is made rather than when work was performed, which catches out payrolls spanning the change.
Tax scales, thresholds and reporting requirements all move periodically.
Make this somebody's explicit responsibility, whether that is your provider or a named person internally, because where it is nobody's job the changes get applied late, and late is the same as wrong for the periods in between.
A payroll migration is a real project rather than a switch, and it is considerably more predictable than most systems projects because the requirements are well defined and the verification method is unambiguous.
The two decisions that matter most are timing, where the start of a financial year is worth waiting for, and how seriously you take the work of documenting your current award interpretations.
Get those right and the rest is process.
Our pieces on ZonePayroll and what the rebrand means and the benefits of on platform payroll cover the wider case, and Australian payroll compliance covers the obligations any configuration has to satisfy.
If you would like to talk through what a move would involve for your business, get in touch.
