ERP Business Analyst, New Zealand

Mapping processes that are spread across apps

Growing New Zealand companies often run a capable ledger surrounded by specialist apps: one for inventory, one for jobs or field work, one for online orders, perhaps a CRM and a separate tool for purchasing approvals. Each app solved a real problem when it was added. Together they form a process nobody has drawn in full.

The first deliverable is a picture of that landscape. For every app I record what it is used for, which records it creates or updates, how and when it syncs with the ledger, and who fixes it when a sync fails. Then I map the main flows across those apps:

• Quote or order through to dispatch, invoice and payment.
• Purchase order through receipt, supplier bill and landed cost.
• Job or project from booking through time, materials and billing.
• Month end, including the manual checks finance runs between systems.

Pain points go straight onto the map: double entry, stock figures that disagree, approvals done by email. The future-state design then answers a practical question for each step. Does it move into a new ERP, stay in a specialist app that works well, or need a better integration? That decision is documented, not assumed. My ERP process mapping service describes the workshop method in more detail.

GST requirements your accountant can sign off

For a GST-registered business, the ERP has to code every transaction so that the figures for the return come out right without a spreadsheet in between. How GST applies to your transactions, and which accounting basis you use for it, are decisions for your accountant. My job is to make sure those decisions are written into the requirements and tested.

I prepare a GST scenario register with your finance lead and accountant. Typical entries include standard-rated local sales, zero-rated exports, goods imported with GST paid at the border alongside freight and customs charges, purchases from suppliers who are not registered, credit notes, bad debt write-offs and private or mixed-use adjustments where they apply. Each entry names the tax code expected, the ledger accounts it touches and the return line it should land in.

Two further points belong in the BRD. First, the basis your business accounts for GST on affects which report the return is built from, so the platform must support that basis rather than leave finance to adjust figures by hand. Second, if an Australian entity shares the system, its tax codes must stay completely separate. Every register entry becomes an acceptance test, and your accountant reviews the results before sign-off. The register sits within my ERP requirements gathering approach.

Peppol invoicing as a set of testable needs

E-invoicing in New Zealand runs over the Peppol framework, and some customers, particularly in the public sector or among larger organizations, may ask suppliers to send invoices that way. Its relevance to your business hinges on your trading partners, so the BRD starts by listing the customers and suppliers who use it or are likely to.

From there I write separate requirements for each direction:

• Sending: which invoices go out over Peppol, how the receiving business is identified, and the steps that follow a rejected or undeliverable invoice.
• Receiving: how incoming e-invoices arrive, whether they are matched automatically to purchase orders and receipts, and how mismatches reach the right approver.
• Master data: where business identifiers are stored on customer and supplier records, and who keeps them current.
• Route: whether the platform connects natively or through an access point provider, and who supports that connection.

During selection, each vendor demonstrates both directions with your documents. Each gap is logged in the fit-gap matrix alongside the proposed solution, whether standard feature, connector or manual step. My ERP gap analysis page explains how those gaps are weighed.

Trans-Tasman groups: one BRD, two sets of rules

When a business runs companies on both sides of the Tasman, requirements analysis has to serve two audiences. Group leadership, often based in Australia, wants one view of customers, products and results. Managers in New Zealand need a system that reflects local tax, payroll interfaces and reporting without workarounds.

I handle this by tagging every requirement with where it applies: both countries, New Zealand only or Australia only. Shared requirements cover common processes such as ordering, purchasing approvals and inventory control. Country-specific ones capture differences in tax coding, statutory reports, payroll journal formats and bank file layouts. A separate section deals with group matters:

• Which master data is shared and who owns it.
• How intercompany sales are priced, invoiced and reconciled.
• How NZD and AUD balances are revalued and rolled up for group reporting, as agreed with the group's accountants.
• Stock transfers between countries and the paperwork they require.

Interviewing stakeholders in both countries early stops the Australian template being assumed to fit New Zealand. Where the Australian company drives the project, my ERP business analyst page for Australia covers the requirements on that side, and my ERP business analysis service explains the overall method.

Fit-gap scoring and acceptance tests from your own data

Once the BRD is signed, every shortlisted platform is scored against it. Every requirement receives a rating: covered out of the box, covered by configuration, needs an add-on, needs a workaround or needs custom code, with a note on effort and risk. Keeping the current ledger alongside a new operational system is scored as an option too, because for some New Zealand businesses that is the sensible answer.

Platform-specific checks are on my New Zealand pages for Zoho, ERPNext, Odoo and Dynamics 365.

The same requirements drive user acceptance testing. Scripts use transactions taken from your own records: a local sale, an export, an import with landed costs, a Peppol invoice in each direction, a sale between the two entities in a trans-Tasman group, and the month-end reports finance relies on. Expected results are agreed before testing begins, and defects are logged, fixed and retested until finance is satisfied.

Because New Zealand is well ahead of India, I prepare test packs during my day and your team runs them in yours, with issues reviewed together in the overlapping afternoon hours. If you would rather have advisory oversight than detailed analysis, see freelance ERP consultant in New Zealand, or the main New Zealand ERP consultant page.