Skip to main content
Glama

Calculate.co.nz NZ Calculators

nz_paye_due_dates_calculator

Work out when a New Zealand employer must pay PAYE and file the pay run.

Use for: 'when is PAYE due', 'PAYE payment dates', 'payday filing deadline',
'employer tax due date NZ', 'do I pay PAYE twice a month', 'PAYE due date
falls on a weekend'.

PAYING AND FILING ARE DIFFERENT DEADLINES and missing either has its own
consequences. Answer both, and say which is which.

Payday filing is due within TWO WORKING DAYS of the payday itself. The
payment is due on the 20th of the following month for a monthly payer, or on
the 20th and the 5th for a twice-monthly payer.

WHICH PAYER YOU ARE IS DECIDED BY PAYE PLUS ESCT SENT TO INLAND REVENUE OVER
THE PRIOR TWELVE MONTHS, not by the size of the payroll and not by headcount.
The threshold is $500,000 of DEDUCTIONS. A business paying $2m in wages is
usually still a monthly payer, so never infer the payer type from turnover or
staff numbers; ask for the deductions figure.

Both dates shift off weekends and national public holidays including
Mondayised ones. Where a shift happened, payment_due_shifted_from and
payday_filing_due_shifted_from show what it moved from, so the answer can be
checked rather than taken on trust. Regional anniversary days do NOT move a
PAYE date and are deliberately excluded.

paper_filing_due comes back every time because paper filers work to a
different rule, ten days from the end of the month.

Holiday dates are held for 2026 and 2027 only. Outside those years this
returns an error rather than guessing, because a due date computed against
holidays nobody checked is worse than no answer.

Args:
    pay_date: The date employees are PAID, ISO format YYYY-MM-DD. The
        payday, not the end of the pay period.
    annual_paye_and_esct: PAYE plus ESCT over the prior 12 months.
    electronic_filer: Whether payday filing is electronic.

Returns:
    Payer type and why, the payment due date, the payday filing due date,
    what either was shifted from, and the paper filing deadline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pay_dateYes
electronic_filerNo
annual_paye_and_esctNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral disclosure and does so richly. It explains payment vs filing deadlines, payer-frequency rules, weekend/holiday shifting, exclusion of regional anniversary days, the paper-filing fallback, and the deliberate error return outside 2026-2027 rather than guessing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely informative, with clear sectioning, bolded key warnings, and no filler. Every sentence carries operational value for a complex calculation involving two deadlines, a payer classification rule, holiday shifts, and error behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is remarkably complete. It specifies what will be returned, what fields indicate shifted dates, which years are supported, when an error is returned instead of a guess, and which edge cases are intentionally excluded. An agent has enough context to invoke the tool and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. Each of the three arguments is explained with meaningful semantics: pay_date is the actual payday, annual_paye_and_esct is the threshold-relevant deductions figure, and electronic_filer indicates filing mode. It also explains the critical payer-type threshold rule that gives the annual figure its purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Work out when a New Zealand employer must pay PAYE and file the pay run.' It also gives example queries that distinguish this date calculator from siblings like nz_paye_calculator, which is about PAYE amounts rather than due dates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use-for queries and explains when the tool should be invoked. It clarifies that paying and filing deadlines are distinct and that payer type must not be inferred from turnover. However, it does not explicitly name sibling tools that should be used instead for non-date PAYE calculations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources