ERP Requirements Consultant, New Zealand

Sizing a specification for a New Zealand business

A specification for a New Zealand distributor, manufacturer or service firm does not need to be long, but it does need structure. I group requirements under the flows the business runs: quote and order to payment received, purchase order to supplier paid, stock and dispatch, export orders, job or production costing, and month-end with the GST return. Shared sections then cover payroll handoff, hosting, access, integrations and data.

Each line has five parts, and none is optional:

• A reference number that implementers quote back in their response.
• A statement of one thing the system must or should do.
• A ranking under Must, Should, Could or Won't.
• The proof: what a tester will see when the line works.
• The person in your business who owns it.

Ranking is where small teams gain the most. When only a handful of people can test and train, knowing which lines are truly essential protects the go-live date. Must covers what you need to trade, pay people and file returns. Should covers what saves real effort but has a fallback. Could is nice to have if it comes standard. Won't is a parked idea, recorded so it is not quietly added back by an implementer keen to help.

The workshop approach behind the content is set out under ERP requirements gathering, and the analysis that feeds it is on the New Zealand ERP business analyst page.

GST, invoices, records and Peppol as checkable lines

The statutory section is written so that each line either passes or fails in testing. Your accountant or tax advisor confirms the wording; I do not decide how GST applies to your sales or purchases.

• Coding. The system applies the GST codes your advisor defines for standard-rated, zero-rated and exempt supplies, and for imported goods and services, with defaults held on items, customers and suppliers.
• Invoice content. Sales documents carry the details your advisor confirms the current GST rules require, and the system stores what it needs from supplier invoices to support input tax claims.
• Return support. A GST report that reconciles to the general ledger and drills down to individual transactions, plus a filing route your advisor is comfortable with, whether direct from the software or prepared and filed separately.
• Records. How long financial records must remain accessible, based on your advisor's guidance, with locked periods and a full export route.

Peppol sits in the same section. Government agencies in New Zealand have been moving toward receiving e-invoices over Peppol, and some private buyers are following. I write lines for exchanging invoices through an access point, checking data before sending and handling rejected messages, then your team chooses the priority. If your customers have not raised it yet, a Should with a clear route is often a sensible position; the decision and its reasoning are recorded either way.

Payday filing, KiwiSaver and leave: where payroll stops

Many New Zealand businesses of this size keep payroll in dedicated software that files employment information with Inland Revenue each payday and calculates KiwiSaver deductions and leave entitlements. The ERP specification should not repeat that work; it should fix the handoff so nothing falls between the two systems.

The payroll section covers:

• Wage journal. How it arrives after each pay run, in what format, and split by entity, department, job or cost center.
• Deductions and contributions. Which control accounts receive PAYE, KiwiSaver and other deductions, and the report that proves the ledger agrees with payroll.
• Leave liability. How accrued annual leave and other entitlements are posted at month-end. Holiday pay calculations can be complex, so the specification states that payroll software and your payroll advisor own the calculation, while the ERP holds the liability.
• Time data. Whether hours booked to jobs in the ERP feed payroll, or the other way round, and who corrects errors.

Currency and language lines sit alongside. Exporters need NZD as the functional currency with AUD, USD or other currencies for pricing, bank accounts and revaluation. Customer and employee records should also store names with macrons correctly, so Māori names print and search as written; it is a small line, but one worth testing explicitly.

Hosting, support hours, integrations and data migration

Non-functional lines are written as questions that each implementer and vendor must answer in their own words:

• Hosting. In which country production data and backups are stored, whether a New Zealand or Australian region is offered, and how the vendor helps you meet the Privacy Act as your advisor interprets it.
• Support hours. New Zealand starts its working day ahead of Australia and well ahead of most other regions, so many vendor help desks open after your staff have already started. The specification states the hours you need covered and asks how urgent issues are handled before overseas desks open.
• Access. Sign-on method, role design for small teams where one person wears several hats, and a change history on ledgers and master records.
• Performance. Behavior at month-end and during seasonal peaks such as harvest, export season or the run-up to Christmas, where relevant.

Integrations are described one by one: bank feeds and payment files, the payroll journal, eCommerce, freight and courier systems, any job or inventory app being retired, and a reporting tool. For each, I record the source, the destination, the trigger and the person who fixes it when it breaks.

Migration lines set out what comes across from Xero, MYOB or the current add-on apps, how much history is worth moving, who cleans the master data and how opening balances and the open GST period are agreed before sign-off.

Linking requirements to demos, tests and the contract

A specification only protects you if its reference numbers are used. I keep a simple traceability sheet: for each line, the demo scenario in which an implementer must show it, the fit verdict for each option considered, and the acceptance test your team will run before go-live. The New Zealand ERP selection page describes how those scenarios are used to compare options, and ERP RFP consulting explains the response format implementers complete. When you sign with an implementer, their scope can name the specification version it is based on.

Version control stays light but strict. Every edit after signing is logged with the reason and the approver, and the version number changes. Each section owner signs off their part, and the business owner or sponsor signs the whole.

Gaps that put New Zealand specifications at risk include:

• Leave liability left out, so month-end balances drift from payroll.
• No support-hours line, leaving early-morning issues waiting on another time zone.
• Add-on app data ignored in migration scope.
• Every line ranked Must, which hides what the go-live really depends on.

Workshops run remotely and are booked in New Zealand afternoon hours, which overlap with my working day; visits can be added by arrangement. I receive no commission or referral payment from any software vendor or implementer. For wider ERP advice, see ERP consulting in New Zealand or the New Zealand hub.