New Zealand Payday Filing

Key Features

AL extension packaged for your Business Central version — deployable as a per-tenant extension on SaaS or installed on-premises, with an `app.json` targeting your current release wave

Table extensions on `Employee` for IRD number, tax code, tax code declaration date, KiwiSaver membership and contribution rate, ESCT rate and student loan status, with validation on entry

PAYE, ACC earners' levy, student loan and KiwiSaver calculation codeunits driven by versioned, effective-dated rate tables — an ordinary tax-year change is data entry, not a code change

Employment information (EI) payload generation per posted pay run, with a job queue entry that submits to Inland Revenue and stores the response, correlation id and status against the run

Employee details filing for starters and departures generated from the employee record, so a new hire does not need a separate manual notification

Amended submissions linked to the original filing rather than overwriting it, giving an auditable trail of what was filed, corrected and when

Pay run posting to the general ledger against your own G/L accounts and dimension defaults, so wage clearing, PAYE payable and KiwiSaver payable reconcile inside Business Central

Leave accrual and balance tracking for annual leave, sick leave, public holidays and alternative holidays, with configurable accrual bases and a visible leave liability

Bank payment file generation in your bank's layout (ANZ, ASB, BNZ, Westpac or a specified format), produced from the posted pay run

Payslips as Business Central report objects — printable, emailable, and extensible with your own RDLC or Word layout

Year-end summary reporting built from posted pay run data rather than a re-keyed export

Dedicated permission sets separating payroll administrator, approver and read-only finance roles, so pay data is not exposed to every Business Central licence

API pages exposing pay runs, pay lines and leave balances over REST API v2.0 / OData v4 for Power BI, Power Automate and Dataverse

Published integration events at calculation, posting and submission points so your own extensions hook in without modifying our objects or base application code

Application Insights telemetry on submission attempts, failures and retries, so a failed filing surfaces before Inland Revenue chases it

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Inland Revenue requires employment information (the EI return) within two working days of every payday, plus new and departing employee details, and it expects the figures to reconcile to what you actually paid. Dynamics 365 Business Central ships strong general ledger, dimensions, bank reconciliation and approval workflow, but no New Zealand payroll and no IR filing. The usual answer is a separate payroll product: you run pay in one system, export a CSV, journal a summary into Business Central, and spend every month-end explaining why the wage clearing account does not tie out. Nobody owns the number, leave liability lives in a spreadsheet, and a payday correction means touching two systems and hoping they agree.

ECOSIRE builds a New Zealand payroll and payday filing extension that lives inside Business Central. It is a proper AL extension — table extensions on Employee for IRD number, tax code, KiwiSaver status and ESCT rate; new tables for pay runs, pay run lines, leave balances and IR submission history; page extensions that put payroll fields on the pages your team already uses; and calculation codeunits written against IR's published PAYE, ACC earners' levy, student loan and KiwiSaver rules. Rate tables are effective-dated data, not hard-coded constants, so a tax-year change is a configuration update rather than a redeployment. Every pay run posts real journal entries with your own dimensions and G/L mapping, so gross wages, PAYE payable, KiwiSaver payable and net pay reconcile in Business Central without a manual journal.

The filing side is the part most buyers care about. Posting a pay run produces an employment information payload and a queued submission; a job queue entry submits it and records the IR response, correlation id and status against the pay run, so you can prove what was filed and when. Employee details filings for starters and leavers are generated from the same employee record. Where a correction is needed, the extension keeps the amended submission linked to the original rather than overwriting history. Bank files are produced in your bank's format, payslips render as Business Central report objects you can print or email, and year-end summaries come out of the same posted data rather than a re-keyed spreadsheet. API pages exposed over the standard REST API v2.0 / OData v4 surface let Power BI, Power Automate or a Dataverse flow read pay run and leave data without a database connection, and dedicated permission sets keep payroll visible only to the people who should see it.

Because payroll rules bend to each employer, this is built to order rather than downloaded. We start with a scoping call, then confirm in writing your pay frequencies, allowance and deduction types, leave policies (annual leave, sick leave, public holidays, alternative days and how you treat average weekly earnings), KiwiSaver and ESCT handling, bank file format, G/L and dimension mapping, and whether you run Business Central SaaS or on-premises. That written scope becomes the build. Typical delivery is two to four weeks from confirmed scope. You receive the AL source, an installable package for your Business Central version and release wave, UAT on a sandbox with your own employee data before anything touches production, a documented rollback, and a support window after go-live.

We do not claim this is a shortcut around your obligations. You remain the employer of record and the filer; the extension makes filing a by-product of running pay in Business Central instead of a second job in a second system.

What you get

Complete AL source code for the extension, compiled and tested against your specific Business Central version and release wave

Installation and configuration on your environment — sandbox first, then production — including rate tables, G/L and dimension mapping, permission sets and job queue setup

Technical documentation: object ranges, table and page extension inventory, integration events, API page endpoints, and the calculation logic with its rule sources cited

End-user guide covering pay run entry, approval, posting, filing, corrections, leave and payslips, plus a live training session for your payroll and finance team

UAT on a staging sandbox using a copy of your real employee data, with a signed-off test script and a documented rollback plan before production deployment

Post-go-live support window covering defect fixes, filing issues and configuration questions, with the duration agreed in the scope document

Handover of the private Git repository with full commit history, branch and tag convention, and build instructions so another developer can take it forward

Configuration workbook recording your pay codes, leave policies, bank format and mappings as delivered, so future changes start from a known baseline

Who this is for

Finance Manager at a 30–200 employee NZ business

Owns month-end and is tired of a wage clearing account that never ties out because payroll lives in a separate product. Wants gross wages, PAYE and KiwiSaver posted with real dimensions so the P&L is right on the first pass, and wants leave liability to come from a system rather than a spreadsheet.

Payroll Administrator responsible for IR compliance

Files employment information every payday and personally carries the risk of a late or wrong return. Needs filing to happen as part of posting the pay run, needs proof of what was submitted and accepted, and needs corrections to be traceable rather than silently overwritten.

IT Manager or Business Central partner consultant

Has to support whatever gets installed. Wants a real AL extension with a clean object range, integration events instead of modified base objects, permission sets that survive a licence review, and source code in a repository they can build themselves — not a black box that blocks the next release wave.

Operations Director at a multi-site or seasonal employer

Runs weekly and fortnightly cycles across sites with mixed permanent and casual staff. Needs allowances, alternative holidays and average weekly earnings handled to their actual policy, and needs pay cost visible by site dimension without exporting to Excel.

How New Zealand Payday Filing Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your payroll rules	Built from your written scope — your allowances, leave policy and pay frequencies are the specification	Exactly what you specify, but you write the specification and carry every rule you forgot	Fits the vendor's model of a typical NZ employer; anything unusual becomes a workaround	No New Zealand payroll capability at all
Payday filing to Inland Revenue	EI and employee details generated from the posted pay run, submitted via job queue, response and status stored	Achievable, but you build and maintain the payload, transport and error handling yourself	Usually included and generally reliable, though correction handling varies by vendor	None — you file from a separate payroll system or by hand
General ledger reconciliation	Posts to your own G/L accounts and dimensions, so wage clearing ties out without a manual journal	As good as your mapping design; usually the part that gets rushed	Typically a summary journal or import file, with dimension detail commonly lost	Manual journal from an external payroll export, reconciled by hand each period
Upgrade safety across release waves	Table and page extensions plus event subscribers only — no base object modification; tested against your next wave	Depends entirely on developer discipline; modifying base objects is a common shortcut	Vendor handles compatibility, but you wait on their release schedule when a wave breaks something	Nothing to break, because nothing is there
Source code and lock-in	Full AL source and the Git repository handed over — another developer can take it forward	You own it outright, and you also own every future fix and rule change	Compiled app under subscription; you cannot read it, change it, or take it elsewhere	Not applicable
Data and permission separation	Dedicated permission sets for payroll administrator, approver and read-only finance roles	Only if permission sets were scoped; frequently an afterthought	Vendor-defined roles, usually adequate but not always aligned to your org chart	Payroll data sits outside Business Central entirely
Cost shape	One-off build with a defined support window, then optional support — no per-employee subscription	Developer day rate up front, plus unbudgeted maintenance every tax year	Recurring per-employee or per-tenant subscription that scales with headcount	No extension cost, but a separate payroll subscription plus recurring manual reconciliation effort
Time to running payroll	Two to four weeks from confirmed scope, including sandbox UAT with your own data	Months in practice once specification, build, testing and rework are counted	Fast to install, then weeks of configuration and workarounds to match your policies	Immediate — but you are still running payroll somewhere else

Frequently Asked Questions about New Zealand Payday Filing

How long does delivery take, and what does the timeline depend on?

Typical delivery is two to four weeks from confirmed scope. The clock starts when your written scope is signed off — pay frequencies, allowance and deduction types, leave policies, KiwiSaver and ESCT handling, bank file format, and G/L and dimension mapping — not when you first enquire. A single-frequency payroll lands at the shorter end; multi-entity, multi-site or unusual leave policies push toward the longer end. If scoping reveals work beyond that range, we tell you before you commit, not afterwards.

Can I just download and install this today?

No. This is not an existing Microsoft AppSource download. ECOSIRE builds the extension for your Business Central version and your payroll rules after you request a quotation, then installs, tests and supports it. That is deliberate: New Zealand payroll rules bend to each employer's employment agreements, and a generic download would leave you configuring around it forever.

What happens when Inland Revenue changes PAYE thresholds or KiwiSaver rules?

Rates and thresholds live in effective-dated configuration tables, so an ordinary tax-year change is entered as data with a start date — no redeployment and no downtime. Where a change alters the calculation itself or the filing schema, that is a code change: during your support window we deliver it as part of the agreement, and after the window it is a quoted maintenance item. Because you hold the source and the repository, you are never locked into us to make it.

How does support and updating work after go-live?

You get a defined post-go-live support window, agreed in writing during scoping, covering defect fixes, filing failures and configuration questions. Beyond that, you can take an ongoing support agreement or maintain it yourself — you receive the full AL source and the Git repository with history, so any competent Business Central developer can build and extend it. We also recommend testing the extension in a sandbox against each Business Central release wave before Microsoft applies it to production; we can run that check for you under a support agreement.

Does it work on Business Central SaaS as well as on-premises?

Yes. On SaaS it deploys as a per-tenant extension through the admin centre or your partner tooling; on-premises it installs as a compiled app against your service tier. Tell us your deployment model and version at scoping, because a few things genuinely differ — job queue behaviour, outbound HTTP call configuration and telemetry destination — and we build for the one you actually run instead of making you adapt.

Does this replace my accountant, or make ECOSIRE responsible for my filings?

No. You remain the employer of record and the party responsible for what is filed with Inland Revenue. The extension calculates and submits based on the rules and data you configure and approve; we build it correctly and document the logic and its sources so your accountant or payroll adviser can verify it. We recommend they review the configuration during UAT — that review is part of our standard test script.

Can it integrate with our rostering, time clock or Power BI?

Yes. Pay runs, pay lines and leave balances are exposed through API pages over the standard REST API v2.0 / OData v4 surface, so Power BI, Power Automate and Dataverse read them without a database connection. Inbound timesheet or rostering data can arrive through a configurable staging import or an API page, depending on your source system — bring it to the scoping call so it is sized into the quote rather than discovered mid-build.