Author: David Jenkins, NZPPA CEO

The Employment Leave Act 2026 takes effect on 6 August 2028. Its success will be judged not by whether its policy can be explained, but by whether payroll can implement every statutory entitlement accurately, repeatedly, and transparently.

The Employment Leave Act Needs a Payroll Specification—not More General Guidance

The Employment Leave Act 2026 represents one of the most significant changes to New Zealand payroll processing in decades. It replaces the Holidays Act 2003 with a predominantly hours-based framework involving new definitions, statutory tests, formulas, payment rules and record-keeping obligations.

Employers and payroll providers have a two-year implementation period before the Act comes into force on 6 August 2028. That period will be sufficient only if MBIE provides the detailed technical information needed to design, configure, integrate and test compliant payroll processes early enough for the work to be completed properly.

Publishing general guidance, explanatory webpages and isolated examples will not be enough. MBIE must provide a comprehensive payroll specification for the Employment Leave Act and commit to maintaining it throughout implementation and for the life of the legislation.

We cannot repeat the experience of the Holidays Act

The history of the Holidays Act provides a clear warning. MBIE has acknowledged that uncertainty in the legislation, variation in working arrangements and inconsistent or incomplete applications contributed to high levels of non-compliance. Between November 2015 and June 2020, Labour Inspectorate activity resulted in more than $237 million in remediation payments to approximately 227,300 employees.

MBIE’s own regulatory analysis found that reliance on employer judgement and poor implementation in payroll systems had caused widespread and often unintentional non-compliance. It also described provisions in the Holidays Act as unclear, complex, difficult to apply across diverse working arrangements and difficult to systematise in payroll software.

The failure was not simply because employers or providers did not take their responsibilities seriously. A major contributing factor was that the law and supporting guidance did not always translate into clear, repeatable payroll processes. Different organisations and providers developed different interpretations, assumptions and workarounds. Those differences became embedded in systems and continued across years of payroll processing.

The lesson from the current Act

If legislation cannot be translated into a single, repeatable payroll process, ambiguity becomes configuration. Configuration becomes thousands of transactions. Those transactions become systemic non-compliance and remediation.

The new Act must not be implemented in the same way. If every provider, employer, consultant and adviser is left to develop its own operational interpretation, New Zealand will again produce numerous technically plausible but materially different payroll outcomes.

General guidance is not a payroll specification

MBIE and Employment New Zealand have already identified important system changes. Payroll will need to separate standard, additional and casual hours; accrue and deduct leave in hours; calculate the Leave Compensation Payment; apply new leave-payment rules; produce clearer pay statements; and retain records showing how leave and pay were calculated.

That information is useful, but it describes the destination rather than the processing rules required to reach it.

For example, saying that a system must correctly identify standard hours does not explain what payroll must do when:

• an employment agreement contains a range rather than a fixed number of hours
• guaranteed hours differ from rostered or actual hours
• hours move between days or pay periods
• an employee has multiple roles with the same employer
• a notional roster applies
• an hour may potentially fall within more than one classification
• standard hours change retrospectively
• the agreement, roster, timekeeping system and payroll contain conflicting information.

Similarly, stating that payroll must apply the correct leave hourly rate does not provide a complete implementation rule for every salary, wage, piece-rate, commission and allowance arrangement.

The specification must cover the complete payroll process

The specification cannot focus only on formulas. Payroll calculations sit at the end of a decision chain. Before a payment or deduction can be calculated, payroll may need to identify the employment arrangement, classify the hours, select the authoritative data source, apply an entitlement test and determine the hours to which the calculation applies.

At a minimum, the specification should address:

• definitions and classification rules for standard, additional and casual hours
• the hierarchy between employment agreements, work rosters, notional rosters and actual time records
• annual- and sick-leave accrual, including eligible unworked periods and balance limits
• the 12.5% Leave Compensation Payment and its relationship with ordinary pay, overtime and allowances
• the statutory tests determining whether and when leave may be taken
• full-day and part-day leave hours
• otherwise working-day tests and the supporting evidence required
• relevant public-holiday hours and public-holiday payment
• alternative-leave accrual, taking, payment and cash-up
• the common leave hourly rate, including salary, wages, piece work, commission and qualifying fixed allowances
• multiple roles, terminations, closedowns, agreed closures, restructuring and employee transfers
• leave-balance conversion and every transitional interface with the current Act
• pay-statement and payroll-record requirements
• precision, rounding and minimum-rate comparisons
• retrospective corrections, recalculation and effective dating
• exception handling, manual overrides and audit evidence.

Every requirement needs an implementable structure

For each subject, the specification should identify:

• the relevant statutory provision and binding rule
• the required input data and its authoritative source
• the sequence in which tests and calculations must be applied
• included and excluded hours, payments and periods
• the formula or decision logic
• the required payroll output and balance movement
• calculation precision and rounding
• pay-statement presentation
• record-keeping and audit requirements
• worked examples and expected results
• the treatment of exceptions, insufficient information and errors.

This would give providers a common foundation for development. It would also give employers, payroll practitioners, auditors and advisers an objective standard against which software and payroll processes could be assessed.

Without it, providers will be forced to turn high-level statements into their own functional specifications. Employers will then be expected to determine whether those privately developed interpretations comply with the Act, even though the legal liability remains with them.

It must reflect how payroll actually works

A legally accurate description can still be unusable in payroll. Payroll processes large employee populations through repeatable and highly automated cycles. Information moves between employment agreements, HR systems, rostering platforms, timekeeping applications and payroll. A change to one input may affect accruals, leave deductions, payments, public-holiday decisions, balances, payslips and historic records.

The specification must therefore answer practical processing questions:

• Which system or document is the authoritative source for each input?
• What happens when two sources contain different information?
• At what point is an hour classified, and can that classification change later?
• Which downstream transactions must be recalculated after a retrospective correction?
• What evidence must support an override?
• How must payroll respond when required information is missing?
• What must be visible to the employee on the pay statement?
• What must be retained so the outcome can be reproduced years later?
• How should an employee understand and challenge the result?

These are not minor software-design details. They determine whether the statutory entitlement is processed correctly. Payroll should not be left to resolve them after systems have already been developed.

Subjective outcomes require MBIE leadership

No employment statute covering the full range of New Zealand working arrangements will eliminate judgement completely. Some cases will not fit neatly into a standard example or where more than one interpretation may seem possible.

However, subjectivity cannot become a reason for MBIE to avoid taking a position. Where competing interpretations could produce different leave balances, deductions or payments, MBIE must lead. It should consult payroll practitioners, employers, unions, software providers and employment-law specialists, but that process must end with clear operational guidance.

“Consider the circumstances” is not enough

Payroll may need to decide whether leave accrues, whether four or eight hours are deducted, whether an allowance is included, or whether an alternative-leave entitlement arises. A general direction to consider the circumstances does not produce a compliant transaction.

Where the Act genuinely requires an employer decision or agreement, the specification should still identify what must be considered, what evidence is required, who makes the decision, when it must be made, how it is recorded, when it must be reviewed and how payroll processes the result.

The objective must be one consistent payroll outcome wherever the material facts are the same. An employee’s statutory entitlement should not depend on which provider processes the pay or which adviser interprets the provision.

Examples must be complete enough to build and test

Examples are valuable only when they contain enough information to reproduce the result. A useful payroll example should show:

• the employment arrangement and relevant agreement wording
• the work roster or notional roster
• the hours worked, not worked and classified
• the pay rates, commission, piece-work earnings and allowances
• the statutory test and reference period
• every calculation step
• the leave-balance movement
• the payment and pay-statement outcome
• the records and evidence that must be retained.

The examples must include difficult cases, not only employees working eight hours a day from Monday to Friday. Providers need authoritative test cases covering variable patterns, multiple roles, part-days, overnight and split shifts, public-holiday boundaries, salaries, piece work, commission, fixed allowances, additional hours, casual hours, insufficient history and retrospective changes.

A document containing only straightforward examples may appear comprehensive while failing precisely where the greatest compliance risks arise.

The specification must be authoritative and controlled

Providers and employers must be able to distinguish the law from MBIE’s interpretation, recommended practice and optional system design. Each statement should therefore be identified as one of the following:

• a statutory requirement
• MBIE’s authoritative operational interpretation
• recommended practice
• an optional design approach
• an unresolved matter awaiting further guidance.

The specification should be publicly accessible, searchable, downloadable and version-controlled. Every release should include an effective date, change log, cross-references to the Act, updated examples and test cases, and a clear statement of whether a change affects previously processed outcomes.

Important interpretations must not be changed silently on a webpage. Providers and employers need controlled notification, enough time to assess the impact and a process for determining whether systems, balances or historic payments must be corrected.

Technical support cannot end on 6 August 2028

MBIE has committed to providing further guidance during the implementation period. That is welcome, but technical support cannot be treated as a temporary project that ends when the Act commences.

The first live payroll cycles will expose issues that policy development and controlled testing cannot fully anticipate. New arrangements will emerge. Providers will discover interaction problems. Employers will identify gaps and conflicting outcomes. Decisions of the Employment Relations Authority and courts may also affect how provisions must be applied.

MBIE should establish a permanent technical-support function containing:

• a dedicated team with payroll, system, employment-law and policy expertise
• a formal channel for submitting interpretation and implementation questions
• published answers where an issue could affect more than one organisation
• stated response and escalation timeframes
• regular technical forums with payroll stakeholders
• a public register of open, resolved and deferred issues
• controlled updates to the specification and standard test cases
• urgent notification of material interpretation changes
• post-implementation monitoring of common errors and system limitations.

The team must include people who understand payroll processing, system configuration, data, integrations and retrospective recalculation. Legal and policy expertise is essential, but it cannot substitute for operational payroll knowledge.

The specification should underpin software testing

A payroll specification would provide the foundation for meaningful testing of payroll software. Providers should be expected to demonstrate their calculations against a common set of scenarios and expected results, including ordinary cases, boundary conditions, exceptions and retrospective changes.

Testing should identify:

• the software version and configuration tested
• the specification version used
• the requirements and scenarios covered
• the tests passed and failed
• known limitations and exclusions
• manual workarounds and customer dependencies
• unresolved defects
• the provider’s remediation and support commitments.

This would not remove the employer’s legal responsibility. It would create transparency and make it more difficult for a provider to rely on a general assurance that its software “will be compliant”. Employer responsibility must be matched by genuine provider accountability and authoritative government support.

The cost of ambiguity will fall on employers and employees

Without a specification, each provider will interpret it differently. Employers will have to assess those interpretations, configure their processes and carry the liability if the outcome is wrong. Large organisations may purchase specialist legal and technical advice, while smaller employers will be more dependent on provider defaults and general guidance.

The result could be different statutory outcomes for employees with materially identical circumstances simply because their employers use different payroll systems. That is not an acceptable basis for minimum employment standards.

Ambiguity also creates avoidable costs: duplicated development, delayed implementation, defensive legal advice, manual workarounds, inconsistent testing, employee disputes and eventual remediation. The cost of producing and maintaining a robust specification will be substantially lower than correcting another generation of systemic payroll errors.

MBIE must own the technical implementation outcome

The Employment Leave Act may be intended to create a clearer and more workable leave system, but legislation does not implement itself. Success will depend on whether every requirement can be translated into an accurate, repeatable, explainable and auditable payroll outcome.

MBIE must do more than publish general information and leave providers to decide how the Act should operate. It must produce and maintain a comprehensive payroll specification, supported by authoritative interpretations, complete worked examples, standard test cases and a permanent technical-support function.

The specification must be written for those who will implement and operate the Act: payroll practitioners, software developers, testers, employers, auditors and advisers. It must be detailed enough to build from, clear enough to test against and authoritative enough to resolve competing interpretations.