Calculate.co.nz NZ Calculators

nz_fbt_calculator

Work out New Zealand fringe benefit tax on a company vehicle, a low-interest loan, or another benefit.

Use for: 'FBT on a company car', 'how much FBT do I pay', 'fringe benefit
tax calculator', 'is the alternate rate cheaper', 'FBT on a staff loan'.

THE RATE IS THE EASY PART. What goes wrong is the taxable value, because
FBT is charged on a value derived from the asset, not on what the benefit
cost the employer.

For a vehicle the two methods give very different answers on the same car.
Cost price is 5% a quarter of the GST-inclusive price the employer paid and
NEVER FALLS as the car ages. Tax book value is 9% a quarter of the
written-down value, with a floor of $8,333. An older vehicle is usually
cheaper on tax book value; a cheap one can be dearer, because of the floor.
If someone is choosing, run both.

THE DAYS DIVISOR IS ALWAYS 90, under section RD 29(5)(a) of the Income Tax
Act 2007. It is not the number of days in the actual quarter. Do not
"correct" it to 91 or 92.

On the rate, be careful: 63.93% is the single rate, applies to every
employee whatever they earn, and needs no wash-up. 49.25% is lower but
available in quarters one to three ONLY, and using it obliges a quarter
four wash-up that can claw the saving back. NEVER present the alternate
rate as simply cheaper. quarter_four_washup_required says so for you.

annual_fbt is the quarter times four, which holds only if the benefit is
unchanged all year. A car bought mid-year is not.

Args:
    benefit_type: 'vehicle', 'loan' or 'other'.
    rate_method: 'single' (63.93%) or 'alternate' (49.25%).
    vehicle_value: Vehicle only. GST-inclusive cost price or tax book value.
    value_method: 'cost_price' or 'tax_book_value'.
    days_available: Vehicle only. Days available for private use, capped at 90.
    employee_contribution: Vehicle only. What the employee paid this quarter.
    loan_balance: Loan only. Average balance for the quarter.
    prescribed_rate_pct: Loan only. IRD prescribed rate, as a percentage.
    actual_rate_pct: Loan only. Rate actually charged, as a percentage.
    other_quarterly_value: Other benefits only. Quarterly taxable value.

Returns:
    Quarterly taxable value, the rate applied, quarterly and annual FBT,
    whether a quarter four wash-up is required, and the working.

Input Schema

TableJSON Schema

Name	Required	Default
`rate_method`	No	single
`benefit_type`	No	vehicle
`loan_balance`	No
`value_method`	No	cost_price
`vehicle_value`	No
`days_available`	No
`actual_rate_pct`	No
`prescribed_rate_pct`	No
`employee_contribution`	No
`other_quarterly_value`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

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 behavior disclosure, and it excels: it warns that taxable value is derived from the asset rather than cost, explains the two vehicle valuation methods and their different trajectories, states the days divisor is always 90 per RD 29(5)(a), and cautions that the alternate rate requires a quarter-four wash-up. It also notes that annual_fbt assumes the benefit is unchanged all year. This gives an agent the critical non-obvious rules needed to avoid miscalculation.

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 deliberately structured into purpose, usage signals, key conceptual warnings, rate caveats, arguments, and returns. Every sentence carries domain-specific value—there is no filler. The most critical pitfalls (days divisor, valuation methods, wash-up) are given prominent placement, and the front-loaded purpose helps an agent quickly categorize the tool.

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?

For a tool with 10 parameters, no required fields, no output schema, and no annotations, the description is exceptionally complete. It covers all parameter semantics, return values (quarterly taxable value, rate applied, quarterly/annual FBT, wash-up flag, working), and enough legislative grounding to prevent common errors. An agent has everything needed to invoke 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%, so the 'Args:' section is the only documentation, and it is excellent. It explains each parameter's purpose, which benefit_type it applies to, the required value format (e.g., GST-inclusive cost price, average loan balance, prescribed rate as percentage), and special constraints like days_available capped at 90. This fully compensates for the schema's lack of descriptions.

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 specific verb and resource: 'Work out New Zealand fringe benefit tax on a company vehicle, a low-interest loan, or another benefit.' It clearly differentiates this tool from the many NZ calculator siblings by naming the tax domain and the benefit types, leaving no doubt about what the tool computes.

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 'Use for:' section lists concrete example queries like 'FBT on a company car' and 'how much FBT do I pay', which conveys when the tool is appropriate. It does not explicitly name sibling calculators to avoid or state when-not-to-use, but the context is clear enough that an agent can select it for FBT questions.

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

All Calculate.co.nz NZ Calculators tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?