Transforming traditional payroll processes into streamlined, efficient systems with NetSuite and ZonePayroll
Most businesses running an ERP alongside a separate payroll product accept a set of ongoing costs without ever naming them. A journal prepared and posted every cycle. A clearing account reconciled and its differences investigated. An integration that needs monitoring. Labour cost figures that are only as current as the last thing somebody posted.
None of that is dramatic and none of it appears in a business case. It is simply the tax you pay for having the operational record and the financial record in two places, and it is charged every fortnight for as long as the arrangement persists.
Running payroll natively inside NetSuite removes that tax rather than reducing it. This article sets out what the combined architecture actually looks like, what changes operationally, and what it takes to get there.
The word gets used loosely, so it is worth being precise, because the distinction determines everything that follows.
An integrated payroll product is a separate system with a connection to your ERP. It has its own database, its own employee records and its own security model. Data moves between the two on a schedule, in a file or over an interface, and somebody owns making sure that movement happened and was correct.
A native payroll application runs on the ERP platform itself. Employee records, pay runs and the resulting accounting entries live in the same database as your customers, your inventory and your general ledger. There is no movement of data because there is nowhere for it to move to.
ZonePayroll, formerly Infinet Cloud Payroll, is built this way for NetSuite. The architectural point matters more than any individual feature, because it is what removes the reconciliation, the integration monitoring and the data lag simultaneously.
Following a single pay cycle through the combined system makes the difference concrete.
Hours and variations enter the system, either directly or from a time capture source. Employee records, rates, classifications and leave balances are already there, because the employee is a record in NetSuite rather than in a separate application.
The pay run calculates gross to net, applying award interpretation, allowances, overtime, leave accrual and superannuation on the defined ordinary time earnings base. Nothing has been exported at any point.
When the run is finalised, the accounting entries post. Not prepared, not exported, not journalled by somebody the following week. They post, with the account and the dimensions already attached, as part of finalising the run.
Single Touch Payroll reporting submits to the Australian Taxation Office on or before the payment date, payslips are available through self service, and the bank file is produced. The next time anybody looks at the general ledger, the labour cost is already there and already correct.
This is the change finance teams notice first, and it is worth understanding why the reconciliation exists in a split arrangement at all.
Where payroll is separate, the journal is a summary. It represents the pay run but is not the pay run, and the two can diverge. A late adjustment processed in payroll after the journal was prepared. An accrual estimated rather than calculated. A termination processed in one place and not reflected in the other. A correction applied to a prior period.
Each of those produces a difference in the clearing account, and somebody has to find it, understand it and resolve it. That work is genuinely skilled, it recurs every period, and it appears in no cost comparison anybody has ever built.
Where the entries are the pay run rather than a summary of it, there is nothing to diverge. The clearing account reconciliation of the usual kind does not exist, because the two things it reconciles are the same thing.
For a finance team with a tight close timetable, removing a recurring reconciliation with unpredictable investigation time is worth more than the hours suggest, because it removes variance from the close rather than only effort.
The second change is that labour cost becomes available at the same granularity as everything else, which changes what analysis is practical.
NetSuite's dimensional structure applies subsidiary, department, class and location to transactions independently of the account. Where payroll posts through that structure, labour cost carries those dimensions automatically.
That means cost by department, by site, by project or by entity is a report rather than an exercise. It sits in the same profit and loss as revenue and materials, at the same time, without anybody exporting or mapping anything.
For businesses where labour is a significant and variable cost, meaning distribution, manufacturing, professional services and construction, this is frequently the argument that decides the question. Understanding whether a customer, a project or a site is genuinely profitable requires labour cost in the same view as everything else, and assembling it manually means it happens occasionally rather than continuously.
A quieter benefit that shows up in administration rather than in reporting.
In a split arrangement, an employee exists twice. Once in the ERP for expense claims, approvals, project time or whatever else the business uses, and once in the payroll system. The two records have to be kept aligned, and they drift.
Somebody changes departments and it is updated in one place. Somebody leaves and access is removed from one system. A name change, an address change, a bank detail change, each has to happen twice or be synchronised by something that has to be maintained.
Where there is one record, none of that applies. Onboarding creates one employee, offboarding removes one, and the department they sit in is the department their labour cost posts to because it is the same field.
This is not the headline benefit and it removes a category of small recurring administration that nobody counts and everybody performs.
The architecture is only useful if the payroll itself is correct for Australian requirements, and those requirements are genuinely local.
Single Touch Payroll Phase 2 requires income disaggregated into components rather than reported as a single gross figure, with allowances by type, overtime separated from ordinary earnings, paid leave identified as leave, and employment and taxation conditions reported including the cessation reason when somebody leaves.
Superannuation guarantee must be calculated on ordinary time earnings rather than gross pay, with the earnings base correctly defined for each payment type, and contributions received by the fund by the quarterly deadline rather than merely sent by it.
Modern award interpretation covers minimum rates by classification, allowances, overtime, penalty rates, span of hours and break provisions, and coverage depends on the work performed rather than on job titles.
A payroll application built for Australia treats these as first class requirements. One adapted from an overseas product tends to be weakest exactly where the exposure is highest.
The most important thing to understand about any payroll system, native or otherwise, is that the software is not the compliance control. The configuration is.
Any capable product calculates correctly against whatever it was configured to do, including where the configuration is wrong, and it does so consistently for years without anything appearing amiss. A superannuation earnings base that excludes an allowance it should include produces a shortfall every quarter, and no system flags it.
The decisions that determine correctness are award coverage established against the awards that actually apply, allowances categorised correctly for tax, superannuation and reporting, ordinary hours and overtime defined so the superannuation base is right, and leave accrual reflecting the real pattern of work for part time and variable hours staff.
None of that is validated by the platform and none of it is done by the vendor. It is set during implementation and quietly governs everything afterwards, which is why the implementation deserves more scrutiny than the product selection.
The operating model changes slightly when payroll and finance share a system, and being explicit about roles avoids confusion.
Whoever runs payroll owns the cycle, meaning inputs, processing, review and finalisation. Their work now posts directly to the ledger, which raises the stakes on the review step and removes the separate posting step.
Whoever administers NetSuite owns the configuration, the roles and permissions and the accounting mapping. Payroll data is sensitive, and permission design matters more when payroll sits in the same system everybody else uses.
Finance owns the accounting treatment and the review of what posted, which is now a review of entries rather than a preparation of them.
And somebody owns the release cycle, because NetSuite updates twice a year and payroll is one of the things worth testing in the release preview account before the update reaches production.
This is the one genuine complication introduced by putting payroll in the same system as everything else.
In a split arrangement, payroll data is protected by being in a different system that most people cannot access at all. In a combined arrangement, it is protected by role design.
That means the permission model has to be deliberate. Salary information, bank details and tax file numbers should be visible only to the people who need them, and NetSuite's permission model is granular enough to achieve that provided somebody sets it up properly.
It also means segregation of duties needs thought. The person who can change a pay rate should generally not also be the person who approves and finalises the run, and in a small team where perfect segregation is not achievable, that should be a deliberate decision with a compensating control rather than an accident.
The practical test of any of this is what changes in a period end, and the differences are specific.
The payroll journal preparation step disappears, along with the wait for payroll to be finalised before the journal can be prepared.
The clearing account reconciliation of the usual kind disappears, along with the investigation time when it does not balance.
The accrual for the part period at the boundary becomes calculable from the system rather than estimated, because the underlying data is there.
And the labour cost figures in the management pack are current rather than as at the last posting, which means the pack can be produced earlier without waiting for payroll to be journalled.
For businesses trying to compress a close from two weeks to a few days, removing one dependency with unpredictable timing is disproportionately useful.
The combined architecture suits some situations considerably better than others, and being honest about that matters.
It suits businesses already running NetSuite, where the marginal step is adding payroll to a platform that already exists rather than adopting two things at once.
It suits businesses where labour is a significant cost that needs analysing by dimension, since that is where the reporting benefit concentrates.
It suits businesses whose close timetable is under pressure, because the reconciliation removal is a direct contribution.
It suits less well where payroll is genuinely simple, meaning a small salaried team with no award complexity, and the existing arrangement causes nobody any difficulty. In that case the reconciliation is small and the case for change is weak.
Adding payroll to an existing NetSuite account is a smaller project than an ERP implementation and it is not trivial, and the work concentrates in two places.
The first is discovery and configuration. Award coverage, classifications, allowance treatments, leave policies, pay cycles and anything unusual about how the business pays people, all established, documented and configured. This phase regularly surfaces existing issues, which is uncomfortable and better than carrying them forward.
The second is data migration. Employee records, leave balances, superannuation fund details and year to date figures. Year to date accuracy is the critical piece for a mid year move, because Single Touch Payroll reporting builds on it.
Between those sits the accounting mapping, meaning each payroll component posting to the right account and dimension. That is what delivers the reporting benefit, and getting it right at setup avoids restating later.
The control that makes any payroll transition safe is running both systems for at least one complete cycle and comparing line by line.
Not gross totals, but each employee's gross, tax, superannuation, allowances, deductions and leave movement. Differences will appear, and each one gets explained rather than accepted.
Some differences are configuration in the new system, which is exactly what the exercise is for. Some, more usefully, are errors in the old arrangement that nobody had noticed, and finding those is worth the effort on its own.
Two cycles is better than one where the cycles differ, and choosing cycles that include a termination, some overtime and a mix of employment types produces more information than a quiet fortnight would.
Payroll carries its own calendar constraint, separate from the financial year.
The end of the payroll year is materially cleaner, because year to date figures reset and the most error prone part of the migration largely disappears.
A mid year move is entirely achievable and requires year to date figures to migrate accurately, which is real work rather than a data load, and it needs proper attention.
Avoid your own peak period, and avoid the weeks around end of financial year processing, because both create pressure at exactly the point when checking matters most.
Where the wider NetSuite programme timing and the payroll timing conflict, phasing payroll separately is usually better than compromising either.
The case for native payroll is not that the calculations are better. It is that the arrangement removes a recurring reconciliation, an integration to maintain, a duplicate employee record and a data lag, all at once and permanently.
Whether that is worth a transition depends on how much those things currently cost you, which most businesses have never counted.
Our piece on making the switch to native payroll covers the transition in detail, and the Infinet Cloud rebrand covers the product background.
Our payroll and bookkeeping service covers running the combined arrangement, and our guide to Australian payroll compliance covers the obligations the configuration has to satisfy.
If you are running NetSuite with payroll somewhere else and want a view on what moving would involve, get in touch.
