Integration Consultant, New Zealand

Keep Xero and connect around it, or move the ledger?

The first integration decision in many New Zealand projects is architectural. You can keep Xero as the ledger and connect inventory, job, CRM and store apps around it, or move accounting into an ERP that already contains those functions and integrate fewer things. Both are legitimate. The choice changes the integration work completely.

Keeping Xero means many small connections, each with its own sync rules, and a careful decision about which app owns customers, items and stock. It works well when the apps are strong in their own areas and volumes are moderate. It strains when several apps all want to create customers, when stock costing must flow back to the ledger accurately, or when an Australian entity needs the same setup.

Moving the ledger into an ERP reduces the number of internal connections, but the remaining ones to banks, payroll, Peppol, stores and brokers still need full design, and a migration from Xero has to be planned with your accountant.

I lay out both options with the flows each one needs, the cost drivers, the support burden and the risks, so directors can decide on evidence. The decision often overlaps with platform selection, covered on my ERP selection consultant New Zealand page, and product detail sits on pages such as Zoho Books New Zealand and Odoo Accounting New Zealand.

Bank batch files, direct debits and settlements

Payments are where integration errors cost money fastest, so I design them first. New Zealand banks accept supplier payment batches as files uploaded through their business platforms, and each bank documents its own layout. The design covers:

• Supplier payment batches. How the batch is generated from approved bills, who releases it, how the particulars, code and reference fields are filled so suppliers can match the payment, and how a rejected line returns to payables.
• Direct debit collections. Customer authorities, collection schedules and dishonored debits, each with a route back to the customer account. Your bank confirms the rules for authorities and notices.
• Incoming payments. Bank feeds matched to invoices using the reference customers supply, with an exceptions list for payments that arrive with only a name.
• Card and online settlements. Payouts net of fees and refunds, separated into sales, charges and adjustments before matching to the deposit.

Bank account changes for suppliers get their own control: restricted to named roles, confirmed with the supplier through a known contact and logged. Each file format is validated with the bank before go-live, and the first live payment run is compared line by line with the old process. Where an Australian entity pays its own suppliers, its bank files follow Australian formats and are specified separately rather than squeezed into the New Zealand design.

Payday filing, Peppol and the GST data trail

Three connections link the ledger to obligations your advisors oversee, so I design them with care and leave the rules themselves to those advisors.

Payroll. New Zealand employers report pay information to Inland Revenue through payday filing, normally from the payroll product. The ledger needs a journal mapped to departments, jobs or entities, with PAYE, KiwiSaver contributions, student loan and other deductions landing in clearing accounts that should net to nil once Inland Revenue and the funds are paid. New pay codes without a mapping are stopped and flagged rather than parked somewhere nobody looks.

Peppol. If customers or suppliers trade through Peppol, the design names the access point, how customers are addressed, how received e-invoices are paired with purchase orders and receipts, and how rejections and credits flow both ways. Whether it applies to you depends on your trading partners; your advisor and major customers can confirm.

GST data. GST-bearing transactions start life in many places: the online shop, the till, the job app, the expense tool. I trace each source into the ledger, check that tax codes map consistently, including zero-rated exports and GST on imports recorded through the broker's data, and list any figures adjusted by hand before the return. Your accountant reviews the list and decides the treatment.

These three flows are tested with real data from a full pay period and a full GST period before cutover, with finance reconciling totals. Cutover itself avoids pay days and return preparation. Product-specific GST settings are covered on my platform pages; this work is about the joins between systems.

Australian entities, customs brokers, stores and freight

Growth beyond New Zealand adds integration work that is easy to underestimate:

• Australian entities. Intercompany orders, stock transfers and invoices between the New Zealand and Australian companies, each in its own currency, with matching intercompany balances. If the entities run on different systems, a consolidation feed is specified too. Australian payroll, tax and bank formats are designed as their own flows.
• Customs brokers. Importers and exporters exchange data with brokers: commercial invoice values, tariff classifications, origin and the duty, GST and fees that come back. Those charges need to attach to the matching goods receipt so landed cost is right. Declarations and classifications stay with the broker and your advisor.
• Online stores. Shopify and WooCommerce orders, refunds and payouts, with product codes, bundles and GST-inclusive pricing mapped carefully, and a decision on individual versus summary posting.
• Freight. Carrier bookings need addresses, weights and services, and return tracking and costs so freight is charged against the right order. Rural delivery and inter-island shipping often carry their own surcharges, which should be visible in margins.

Each flow gets a written specification: trigger, direction, frequency, mapping, error handling and owner. That document guides the developer, sets the test cases and is the first thing to reread whenever a broker, carrier or app is swapped. For trans-Tasman groups, the requirements side is covered on my ERP business analyst New Zealand page.

Method, roles and support once live

The method is chosen per flow. An app marketplace connection may be enough for common pairings, provided it passes your awkward cases: a part refund, a multi-currency invoice, an order with a bundle. When many apps trade data and failures need one dashboard, a middleware layer such as Make, n8n, Zoho Flow or Zapier earns its cost. Custom API work suits volumes or rules no connector covers, at the price of ongoing maintenance. Plain file exchange remains reasonable for bank batches and payroll journals. The wider reasoning is on my ERP integration page.

Responsibilities are written into the plan:

• Mine: writing requirements and ownership rules, preparing mappings and test cases, picking methods, checking delivered work and arranging test windows with banks, brokers, carriers and app providers.
• The build team: your developers, an integrator or the partner, who create, release and document each connection and correct defects.
• Yours: approving each flow, reconciling the parallel run and owning flows day to day.

Every flow must validate data before writing it, retry within limits, reject duplicates and alert a named person on failure. Small teams benefit most from this discipline, because there is rarely a spare person to notice a quiet failure.

Sessions take place in your afternoon, when the time difference gives overlap, with written updates between them; visits by arrangement. Sales-side design is on my CRM consultant New Zealand page, and for wider advice my ERP consulting work in New Zealand or the country overview. The general method is on system integration.