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 one working week 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.