Skip to main content
Glama

Calculate.co.nz NZ Calculators

nz_contractor_vs_employee_calculator

Compare contracting with salaried employment in New Zealand, on what is actually kept.

Use for: 'should I go contracting', 'contractor rate vs salary', 'what rate
do I need to match my salary', 'is contracting worth it NZ'.

ALMOST EVERYONE COMPARES THE TWO HEADLINE NUMBERS AS THOUGH THEY WERE THE
SAME KIND OF NUMBER. They are not. An employee's package includes things a
contractor has to fund out of the rate:
  - Employer KiwiSaver, at least 3.5% from 1 April 2026, less ESCT. A
    contractor gets no match, so the same percentage costs them all of it.
  - Annual leave, ten sick days and eleven public holidays. Around 45 of
    the 260 working days in a year.
  - The ACC work levy, which an employer pays and a contractor does not.

SO TWO COMPARISONS COME BACK. cash_difference is take-home against
take-home, and it is the one that FLATTERS CONTRACTING because it ignores
all of the above. package_difference is the honest one. It is common for a
contract to be well ahead on cash and behind on package. If you quote only
the first you have given bad advice, so quote both and say which is which.

breakeven_contract_income answers the question people actually have, which
is what they need to charge to be no worse off. Lead with it when someone
is deciding on a rate.

annual_contract_income is the year's TOTAL invoicing, not a rate to be
multiplied up. billable_weeks only expresses the implied weekly and daily
rate.

GST is excluded: over $60,000 of turnover registration is compulsory, but
GST is collected and passed on rather than earned. Also worth saying out
loud, because it has no dollar figure and is not nothing: an employee has
notice periods and personal grievance rights, and a contractor does not.

Args:
    annual_gross_salary: The salaried offer, gross.
    annual_contract_income: Total expected to invoice for the year, GST exclusive.
    annual_business_expenses: Deductible expenses for the year.
    billable_weeks: Weeks expected to bill. Used only for the implied rate.
    acc_work_levy_pct: ACC work levy as a percentage. Varies a lot by industry.
    employer_kiwisaver_rate_pct: Employer contribution, minimum 3.5%.
    own_kiwisaver_rate_pct: Their own rate, applied to both sides.
    annual_leave_days: Annual leave in the employment offer.
    has_student_loan: Applies to both sides.
    claim_ietc: Whether the independent earner tax credit is claimable.

Returns:
    Both sides costed line by line, the difference on cash and on package,
    which wins on each, and the breakeven contract income.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claim_ietcNo
billable_weeksNo
has_student_loanNo
acc_work_levy_pctNo
annual_leave_daysNo
annual_gross_salaryYes
annual_contract_incomeYes
own_kiwisaver_rate_pctNo
annual_business_expensesNo
employer_kiwisaver_rate_pctNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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 fully carries behavioral disclosure. It warns that cash_difference flatters contracting while package_difference is honest, states annual_contract_income is total invoicing not a rate, explains billable_weeks only yields an implied rate, and calls out GST exclusion plus non-monetary employee rights. This goes far beyond a generic calculator description.

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 tightly structured: purpose, usage quotes, the central cash-vs-package distinction, parameter meanings, and returns. The capitalised warnings draw attention to the single most dangerous misinterpretation, and every section earns its place given the tool's complexity and the absence of annotations.

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?

Covers user intent, all parameter semantics, output semantics (two differences, breakeven, which wins, line-by-line costing), and key caveats. Since there is no output schema, the 'Returns' section sufficiently describes the result shape for an agent to select and interpret the tool 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%, and the description comphensates with meaningful definitions for all 10 parameters. Notable semantic additions: billable_weeks is 'used only for the implied rate', own_kiwisaver_rate_pct 'applied to both sides', and acc_work_levy_pct is flagged as varying by industry. This avoids serious misuse of the numbers.

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?

Opens with a specific, distinctive purpose: 'Compare contracting with salaried employment in New Zealand, on what is actually kept.' It also lists natural-language use cases ('should I go contracting', 'contractor rate vs salary') that anchor the tool clearly among the sibling NZ calculators, and the comparison object is unique in that sibling set.

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?

Provides explicit usage contexts via the 'Use for' block with realistic user queries, and advises leading with breakeven_contract_income when someone is deciding on a rate. It doesnot explicitly name sibling alternatives or state when-not-to-use, but the domain is distinct enough that this is minor.

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