Choose and Implement ERP for NZ Construction Firms: A Practical Guide

Most ERP guides for construction read like product brochures. They list features, sketch a generic implementation timeline, and stop short of the questions that actually decide success: how does the system handle progress claims and retentions; what happens when a variation lands mid-project; how do subbie payments and HSW records flow through; and what does it really take to go live without losing a month of productivity?

This guide is built for New Zealand construction CFOs, finance managers, and ICT leaders who are past the awareness stage and into the hard work of selecting and implementing an ERP. It covers the six ERPs most commonly shortlisted by NZ construction firms, the criteria that separate them, a six-phase implementation path with realistic durations, and the questions to ask any implementation partner before signing.

What's in this guide

• Why construction ERP is fundamentally different from generic ERP

• What an ERP for NZ construction must actually do (functional, compliance, and integration requirements)

• The six ERPs most commonly shortlisted by mid-sized NZ construction firms

• A five-step evaluation framework to shortlist credibly

• A six-phase implementation path with realistic durations and watchpoints

• The most common implementation pitfalls — and how to avoid them

• How to choose an implementation partner (and the questions that separate the credible from the noisy)

• A short FAQ answering the questions we hear most often

Transparency note: Avanza Solutions is a New Zealand-based MYOB Acumatica implementation partner with a construction specialism. We've kept this guide criteria-led so the framework, the implementation path, and the questions hold up regardless of which ERP you choose.

Why construction ERP is different from generic ERP

Generic ERPs are built around a transactional ledger: orders, invoices, stock, payroll. That works for businesses where the unit of work is a product. In construction, the unit of work is a project — and projects behave differently. They're won before they're scoped, costed before they're certain, delivered over months or years, paid in stages, and reconciled long after they finish. That changes what the system has to do.

Project-centric, not transactional

Every cost, hour, dollar, and decision needs to land against the right project, the right job phase or cost code, and the right contract — automatically, every time. Generic ERPs treat the project as a reporting dimension; construction ERPs treat it as the organising principle.

Job costing that finance and site can both trust

Estimated cost vs committed cost vs actual cost vs forecast at completion — four different numbers, all needing to live in the same system, all needing to update as POs are raised, hours are captured, and variations are approved. If finance and site work from different numbers, the ERP isn't doing its job.

Progress claims and retentions

NZS 3910 contracts (and their cousins) drive monthly progress claim cycles, retentions held against milestones, and a complex pattern of GST timing and payment schedules. Generic AR doesn't model this; construction-grade ERPs do, with claim certificates, retention release schedules, and the audit trail to back them.

Subcontractor management

Subbies make up a large share of project cost. The ERP needs to manage subbie payment schedules, retention deductions, GST treatment, insurance and HSW compliance records, and the difference between PAYE staff and contractor payments — without finance and site teams chasing each other in spreadsheets.

WIP and revenue recognition

Long-running projects need WIP tracking, percentage-of-completion or cost-to-cost revenue recognition, and the ability to recognise margin in line with NZ IFRS or the simpler revenue rules used by smaller firms. The ERP needs to support whichever your auditor expects, without month-end becoming a manual rebuild.

Multi-site, multi-entity, multi-project

Most mid-sized construction firms run several active projects across multiple sites, sometimes through several entities (a parent and JV vehicles, or NZ and Australian operations). Real-time visibility into project margin across the portfolio — at any moment, not just at month-end — is what separates a controlled business from a reactive one.

What an ERP for NZ construction firms must actually do

Boil the requirements down and they fall into three groups: the functional must-haves, the NZ-specific compliance load, and the integration footprint.

Functional requirements

• Estimating-to-budget handover. Estimates from your tendering tool (Buildxact, Xact, an internal Excel model) need to land in the ERP as a budget against cost codes — without re-keying.

• Job costing with cost codes and phases. Multi-level cost code structures, configurable per project type (vertical, civil, fit-out), with the ability to roll up to portfolio reporting.

• Procurement and commitment tracking. Purchase orders against cost codes, commitment vs actuals, and visibility of uncommitted budget remaining at any moment.

• Progress claims and certificates. Generate, send, and track NZS 3910-style claim certificates with retention schedules and payment terms.

• Subcontractor payment runs. Schedule of payments with retentions, GST on retention release, insurance certificate tracking, and statement reconciliation.

• Variations and EOTs. Variation orders linked to original budget, approval workflow, and clear margin visibility on variation work specifically.

• Plant and equipment costing. Internal hire rates, plant utilisation, and recovery of plant cost against jobs.

• Time capture from site. Mobile-friendly timesheets, allocated to project and cost code, feeding payroll and job cost in one capture.

• Forecast at completion. Project managers' updated cost-to-complete forecasts feeding the ledger, so margin reporting reflects current reality not historical actuals.

NZ compliance requirements

• GST handling on retentions. GST timing on retention release follows IRD treatment for construction; the ERP needs to handle this natively, not via journal.

• Pay Day Filing and KiwiSaver. Native NZ payroll with Pay Day Filing to IRD, KiwiSaver employer and employee contributions, ESCT, and Holidays Act-compliant leave calculations (a known pain point for construction with hourly site staff and irregular hours).

• PAYE vs schedular payments. Correct treatment of contractor payments under schedular payment rules versus PAYE staff.

• Health and safety records. Inductions, SWMS, hazard registers, and incident records ideally tied to the project record, even if the operational tool sits outside the ERP.

• Trans-Tasman compliance. If you operate in Australia, BAS, STP, and award interpretation come into play — handled either natively or via integration.

Integration footprint

No ERP does everything. The realistic question is which integrations matter most. For NZ construction firms, the common ones are:

• Estimating: Buildxact, Xact, Cubit, internal Excel models

• Project management: Procore, Aconex, Workbench (when used as a PM layer alongside another ERP)

• Document management: SharePoint, Procore, Aconex

• HSW: SiteApp, HazardCo, Vault, internal systems

• Banking: ASB, BNZ, ANZ, Westpac payment integrations

• Reporting: Power BI, Velixo (Excel-based reporting on top of the ERP)

ERP options most often shortlisted by NZ construction firms

There are roughly six platforms that consistently make NZ construction shortlists in 2026. We've kept these summaries short because the real value of this guide is in the framework and the implementation path that follow — but here's a quick orientation to each.

MYOB Acumatica Construction Edition

Cloud ERP with a dedicated Construction Edition covering project accounting, job costing, subcontractor management, daily field reports, change orders, and progress billing. ANZ-localised by MYOB with native NZ payroll (Pay Day Filing, Holidays Act, KiwiSaver). Resource-based licensing rather than per-user, which suits construction firms with fluctuating site headcount. Strong NZ partner ecosystem with construction specialism.

Best fit: Mid-sized NZ construction firms ($20m–$300m revenue) running multiple active projects, with serious job costing and subbie management requirements, that want native NZ payroll and ANZ multi-entity support without per-user licence pressure.

Workbench

NZ-built construction ERP with deep adoption among local construction and engineering firms. Strong on job costing, project accounting, and subcontractor management — built specifically for the NZ market. Often deployed as a project management and cost layer alongside a general ledger like Xero or another ERP.

Best fit: NZ construction firms wanting a domestically-built solution with deep local construction logic, particularly when project accounting depth matters more than enterprise-grade financials and integrations.

Sage 300 Construction and Real Estate (Sage 300 CRE)

A long-established construction ERP with mature job costing, project management, payroll, and document management modules. Stronger market position in North America but with NZ presence through partners. Generally on-premises or hosted rather than true cloud SaaS.

Best fit: Larger or more traditional NZ construction firms comfortable with a deployment model that's not pure cloud, valuing depth of construction-specific functionality over modern UX.

Vista by Viewpoint (Trimble)

Trimble's flagship construction ERP, with comprehensive project, financial, HR, and field operations modules. Strong global construction footprint, integration with Trimble's broader construction tech stack, and a mature ecosystem. Heavier implementation than the cloud-first options.

Best fit: Larger NZ construction firms operating across multiple regions, with sophisticated project management requirements and the appetite for a longer, more involved implementation in exchange for depth.

Jobpac (Trimble)

An Australian-built, Trimble-owned construction ERP widely used by tier-2 and tier-3 contractors across ANZ. Strong on project costing, subcontractor management, and progress claims, with ANZ localisation that matches local contracting norms.

Best fit: NZ construction firms operating across the Tasman, particularly those embedded in ANZ-wide supply chains or owned by Australian parents, where Jobpac's ANZ contracting fluency matters.

SimPRO

Trade and services-focused operations and project management platform with strong job management, quoting, and field service capability. Often used alongside a separate financial ERP rather than as a complete ERP replacement, particularly for firms that mix project work with reactive maintenance.

Best fit: Trade-led NZ construction businesses (electrical, mechanical services, fit-out) with a heavy mix of project and reactive maintenance work, where field service capability is a primary driver.

A note for civil contractors specifically: the shortlist often narrows quickly to MYOB Acumatica Construction Edition, Workbench, Vista, and Jobpac. Plant utilisation, mass-haul cost recovery, and progress claim complexity tend to filter out platforms that aren't built for civil from day one.

How to choose: a five-step evaluation framework

Most construction ERP evaluations fail in one of two ways: they over-index on the feature checklist (every vendor ticks every box; the differences are in the depth) or they over-index on the demo (which is always polished). A structured five-step approach holds up better.

1. Define the operational drivers, in writing. Write down the three problems the ERP must solve in year one. Examples: 'real-time job margin visibility across all active projects'; 'eliminate subbie payment errors that cost us X last year'; 'monthly progress claim cycle reduced from ten days to three.' This list filters the shortlist before any demo.

2. Build a longlist of six to eight platforms. Use the six above plus any others suggested by peers, industry associations, or auditors. Keep it generous at this stage — eliminating early closes off options you might need later.

3. Run a structured first round. One-hour vendor briefings against your written drivers, not generic demos. The question is not 'what can the system do' but 'how would the system specifically handle our progress claim cycle, our subbie management, and our job margin reporting'. Vendors that can't answer concretely are off the shortlist.

4. Demo on your scenarios, not theirs. For the three or four platforms that survive, ask each partner to demo your scenarios — your project structure, your cost codes, your claim format, your subbie payment run. Observe how easily they can configure these versus how much customisation they're talking about. Customisation talk in the demo means customisation cost in implementation.

5. Reference-check the partner, not just the platform. Two manufacturing or construction references from the implementation partner, in your size bracket, that have gone live in the last 18 months. Reference calls reveal the true implementation experience — including the things the sales team won't say.

How to implement: the six-phase path

ERP implementation timelines vary by scope and complexity, but for mid-sized NZ construction firms a typical end-to-end implementation runs five to nine months. The phases below are the path most projects follow, with realistic durations and the watchpoints that decide whether each phase delivers.

Phase 0: Readiness | 2–4 weeks

Before kickoff, establish that the business is ready. The work in this phase is internal: confirming executive sponsorship, naming the internal lead, agreeing the success criteria, and getting honest about data quality.

Activities

• Executive sponsor and steering group named

• Internal project lead identified and given protected time

• Success criteria documented (the three operational drivers from your evaluation)

• Initial data quality assessment of master data (chart of accounts, cost codes, customers, suppliers, employees, plant register, active projects)

• Implementation budget approved with a 15–20% contingency

Watchpoints

• An internal project lead with no protected time is the single most reliable predictor of overrun. If you can't free this person up, delay the project.

• Master data quality is almost always worse than people think. Plan for cleanup as a parallel workstream, not an afterthought.

Phase 1: Discovery and design | 4–8 weeks

Joint workshops between your team and the implementation partner to translate operational drivers into a configured solution design. This is the most important phase: decisions made here shape everything that follows, and rework later costs five to ten times what it costs to get it right now.

Activities

• End-to-end process workshops covering quote-to-cash, procure-to-pay, project lifecycle, payroll cycle, and month-end

• Cost code structure designed (this single decision drives every report you'll ever produce)

• Chart of accounts redesigned to match the new system's structure and your reporting needs

• Document templates designed: progress claim certificate, subbie payment schedule, PO, customer invoice

• Integration architecture confirmed (estimating, PM, HSW, banking, reporting)

• Solution design document signed off in writing by both parties

Watchpoints

• If your partner skips workshops in favour of 'we'll show you the standard configuration', expect rework later. Workshops are how you uncover the edge cases that matter.

• Cost code structure deserves more time than people give it. A weekend's deeper thinking now saves a year of bad reports later.

• If a process is genuinely odd, fix the process before configuring the ERP around it. Customisation to enshrine bad processes is a common failure mode.

Phase 2: Build and configure | 6–12 weeks

Partner-led configuration of the system to match the agreed design, with parallel client-side preparation for migration and training. This phase is when the system starts to feel real.

Activities

• Core ERP configuration: GL, AR, AP, payroll, project accounting, procurement

• Cost code structure built and tested

• Document templates built (progress claim, subbie schedule, PO, invoice)

• Workflows configured (PO approval, variation approval, claim approval, subbie payment runs)

• Integrations developed and unit tested

• Initial reporting configured (project margin dashboard, WIP report, debtor aging)

• Client-side: master data cleanup completed; training plan finalised

Watchpoints

• Scope creep is the most common cause of overrun in this phase. Every new requirement should be a written change request with cost and time impact.

• If the integration with your estimating tool is being treated as 'we'll get to it later', escalate immediately. Estimating-to-ERP handover is a non-negotiable for construction.

Phase 3: Data migration and UAT | 4–6 weeks

Migrate cleaned master data and open transactions, then run user acceptance testing on the configured system with real users running real scenarios.

Activities

• Master data migrated: COA, cost codes, customers, suppliers, employees, plant, active project budgets

• Open transactions migrated: open POs, AR, AP, retentions held, WIP positions

• Trial balance reconciliation against legacy system

• User acceptance testing: end users running scripted scenarios across each major process

• Defects logged, prioritised, and fixed

• User training delivered (role-based, not generic)

• Cutover plan finalised

Watchpoints

• UAT with real users on real scenarios is non-negotiable. UAT done by the consultants and signed off by a manager who didn't actually test is a disaster waiting for go-live.

• Underestimated scope: open retention positions and WIP migration are routinely the messiest parts of the data migration. Allow time for these specifically.

Phase 4: Go-live | 1–2 weeks (cutover)

The hard switch from old to new. With good preparation this should be controlled and predictable; without it, this is when implementations fall over publicly.

Activities

• Cutover weekend: final data refresh, system switch, opening balance reconciliation

• Go/no-go decision based on agreed criteria (NOT on schedule pressure)

• Hypercare support: partner consultants on-site or on-call full time for the first one to two weeks

• Daily stand-ups to triage issues

• First progress claim cycle and first payroll run executed in the new system, supervised closely

Watchpoints

• If go-live criteria aren't being met, delay rather than push through. A one-month delay is recoverable; a public failure is not.

• First payroll run is always tense. Run a parallel payroll for the first one or two cycles if possible — the cost is small relative to a payroll error in front of staff.

Phase 5: Stabilisation and optimisation | 2–6 months post go-live

The system is live. Now the real work begins: bedding in processes, refining reports, and iterating on the things that didn't quite land in the initial implementation.

Activities

• Hypercare period (typically 30 days) with partner support on-call

• First month-end completed in the new system, with partner support

• Reporting refined based on real usage

• Workflows tuned (the configuration that looked right in design always needs adjustment in reality)

• Training reinforced: the second-pass training delivered six weeks post-go-live consistently lands better than the first

• Phase 2 backlog scoped (the items deliberately deferred from the initial scope)

Watchpoints

• Don't disband the project team at go-live. The first month-end and the first quarter-end are when the real issues emerge.

• Resist the urge to add scope in stabilisation. Stabilise first; then add. Scope added during stabilisation undoes the bedding-in process.

Common pitfalls (and how to avoid them)

Underestimating data migration

Open POs, retention positions, WIP, plant register depreciation, project budgets, and active subbie commitments are all messier than they look. Treat data migration as a parallel workstream from Phase 1, not a Phase 3 sprint.

Skimping on training

Generic train-the-trainer is rarely enough for site-based teams. Role-based training, delivered close to go-live, with a follow-up pass six weeks later, is what makes adoption stick.

Not involving site staff

ERPs designed entirely by finance and ICT often fail at site. PMs, foremen, and QSs need a voice in design — not because they decide finance configuration, but because they decide whether the system gets used.

Big-bang vs phased — making the wrong call

Big-bang go-live is right when the integrations between modules are deep and a phased approach would create temporary workflows that themselves cost money. Phased is right when the business can tolerate one part of the system going live before another. Most NZ construction firms benefit from a 'big-bang within a single entity, phased across entities' approach.

Customisation creep

Every customisation is a future upgrade tax. The default position should be 'configure to standard, change the process if needed'. Customisation is acceptable for genuine business differentiators; it's not acceptable for 'we've always done it this way'.

Choosing partner on price, not capability

The cheapest implementation quote is almost always the most expensive implementation. The questions to ask are about team experience, method, references, and what their last three implementations actually cost — not the headline daily rate.

How to choose an implementation partner

The platform decides what's possible. The partner decides whether you get there. For NZ construction firms, the implementation partner is often the more important of the two decisions, and yet it gets less rigorous attention than platform selection.

What to ask any prospective partner

• How many NZ construction implementations have you led in the last three years?

• What's the size and shape of those clients — revenue, project count, employee count?

• Can we speak to two of them as references, ideally including one that didn't go entirely smoothly?

• Who specifically will be on our project team, and what's their experience? 

• What's your method? Walk us through your workshop approach in Phase 1.

• How do you handle scope changes during implementation?

• What does 'go-live' mean to you, and what does hypercare include?

• Show us your implementation plan template and your project governance approach.

Red flags in partner conversations

• Vague answers to 'show us your last three implementations'

• Reference clients all from outside construction or all under $5m revenue when you're a $50m firm

• Standard project plan with no construction-specific phases

• Quotes that look meaningfully cheaper than peers — usually means scope is missing

• No clear product specialism (jack of all trades, master of none)

• Sales-led pitch with the implementation team only meeting you after contract

Common questions

Which ERP systems work well for construction companies in NZ?

The six platforms most commonly shortlisted by mid-sized NZ construction firms in 2026 are MYOB Acumatica Construction Edition, Workbench, Sage 300 Construction and Real Estate, Vista by Viewpoint, Jobpac, and SimPRO (for trade and services-focused firms). Selection depends on revenue size, civil versus vertical mix, multi-entity requirements, and whether native NZ payroll matters.

What is the best ERP for New Zealand construction firms?

There's no single answer because the best ERP depends on the operational drivers — civil contractors with heavy plant utilisation have different needs from vertical builders, and trade-led services businesses different again from main contractors. For mid-sized NZ construction firms wanting a true cloud platform, native NZ payroll, deep job costing, and resource-based licensing, MYOB Acumatica Construction Edition is one of the most commonly shortlisted options. Workbench is a strong alternative for firms wanting a domestically-built solution. Vista and Jobpac are common in larger or trans-Tasman firms.

Which ERP implementation services specialise in New Zealand construction companies?

A small number of NZ partners specialise in construction ERP implementation, with construction-specific delivery teams, reference clients, and methods. The right partner depends on which platform you're implementing — partners typically specialise in a single platform — and your specific construction sub-sector (civil, vertical, fit-out, services). Avanza Solutions is a NZ-based MYOB Acumatica partner with a construction specialism. For other platforms, ask for two NZ construction references in your revenue band before signing.

How long does a construction ERP implementation take?

End-to-end, most mid-sized NZ construction implementations run five to nine months, with the heaviest work in the discovery, build, and migration phases (Phases 1–3 in the framework above). Smaller implementations with a tight scope can complete in four months; broader transformations involving multiple entities, integrations, and significant data migration sit at the upper end.

Can construction ERP integrate with Procore or Buildxact?

Yes. Most modern construction ERPs integrate with the major construction-tech tools, either through pre-built connectors or via API. Procore integrations are common for project management workflows, and Buildxact integrations cover the estimating-to-budget handover. Confirm specific integration depth (real-time vs scheduled, two-way vs one-way) during the evaluation, not after contract.

Do these ERPs handle progress claims and retentions properly?

The construction-specific platforms (MYOB Acumatica Construction Edition, Workbench, Sage 300 CRE, Vista, Jobpac) handle progress claims, retention schedules, and GST treatment on retention release natively. Generic ERPs without construction modules typically rely on workarounds. If you're contracting under NZS 3910 or similar, native progress claim functionality should be a hard requirement, not a nice-to-have.

Next steps

If you're at the start of an ERP evaluation, three resources make the next steps faster:

• Construction ERP Evaluation Checklist. A printable checklist covering the criteria in this guide, formatted for vendor scoring.

• Construction ROI Calculator. An interactive tool that estimates the financial return from moving to a modern construction ERP, based on your project count, headcount, and current ways of working.

• Construction ERP Handbook. A more detailed reference covering job costing, progress claims, subbie management, and revenue recognition in modern construction ERP.

Talk to a NZ construction ERP specialist

Avanza Solutions implements MYOB Acumatica for mid-sized New Zealand construction firms, with a delivery team experienced in civil, vertical, and fit-out construction. If you'd like a structured walkthrough of the platform against your specific operational drivers, request a working demo built on your project scenarios, or read the CAMEX Civil customer story for a real-world example of MYOB Acumatica deployed in NZ civil construction.

A note on this guide

This guide reflects Avanza Solutions' analysis of the construction ERP options most commonly shortlisted by mid-sized New Zealand construction firms in 2026, and the implementation path we recommend based on the projects we've delivered. The ERP recommendations and implementation guidance are our opinion, based on our experience implementing, evaluating, and competing against these platforms in the NZ market.

Product capabilities, licensing models, integrations, and partner ecosystems change frequently. We've worked from publicly available vendor information and our direct knowledge of the ANZ market as at May 2026, but we recommend verifying specific claims — particularly around licensing structures, ANZ localisation depth, and module inclusions — directly with each vendor before making a shortlist decision.

As noted at the top of this guide, Avanza Solutions is an MYOB Acumatica implementation partner with a construction specialism. We've made every effort to keep this guide fair and criteria-led, and the implementation framework is the same one we'd recommend to any business evaluating construction ERP, regardless of which platform they choose. 

Last reviewed: May 2026.