Payroll calculation automation

Your payroll system's missing feature shouldn't be you.

Two levels of automation. First, far more is handled in configuration than other payroll systems allow – pay codes, code groups and informational codes that calculate automatically. Then, for whatever's left, a custom rules layer holds the edge cases a standard system can't. Built for AU and NZ.

In short

Affinity automates calculations at two levels. Level 1 is configuration – pay codes, code groups and informational codes that calculate automatically across your whole workforce, replacing rules other systems would force you to build or run by hand. Level 2 is a custom rules layer for the genuinely non-standard cases – multi-period averaging, thresholds, caps and comparisons – modelled once and run every pay. Get in touch to map your rules.

When a rule doesn't fit a preset, you become the workaround

Standard systems cover the common cases inside a single pay period. Everything else gets held in someone's head and re-run by hand, every cycle.

Rules no preset covers

Total-remuneration super treatments, service-based rate progression, annual mileage thresholds, award-specific allowances, and rolling super averaging comparisons between part-time and full-time.

The manager carries it

You rebuild and re-check the same calculation every cycle. The constant fear is the one missed edge case that surfaces on a payslip.

It shouldn't be manual forever

A non-standard or multi-period rule shouldn't mean a manual process forever. The system should hold the rule, not the person.

Level 1 · Configuration

Most of it is automatic before you write a single rule

Affinity automates far more at configuration level than other payroll systems – many things that would be a custom rule elsewhere are just how a pay code or code group is set up here. These building blocks do the work first; the custom rules layer only handles what's left.

Pay elements (pay codes)

The collective term for allowances, deductions, pay codes, leave codes, super/KiwiSaver codes and informational codes – each configured for its role and calculation. Dozens of built-in options control how each one behaves: cost- and hours-exclude for costing and analytics, full-deduct vs reduce when funds are short, leave loading, 50% (half-pay) leave, public-holiday handling, zero-pay codes that still trigger a payslip, and more.

One configurable building block for every payment, deduction and accrual – with calculation behaviour set in config, not custom code.

Code groups

Bring codes together to drive calculations and outcomes. An auto-calc code group is set up once, globally, and is then checked automatically for every employee – no per-employee setup. Code groups can total or average units, total dollars, take an average or the greater of a rate, calculate a rate by summing allowances or informational codes, and add or deduct units, values or both (every pay element has a positive and a negative group).

Configure a calculation once and it applies across the whole workforce automatically – work that would otherwise be a custom rule.

Informational codes

Codes that carry or trigger information without paying. They act as unlimited accumulators and buckets – period, month-to-date and year-to-date balances such as total weekend overtime hours across a year or the number of days worked – usable as inputs into other calculations and reports.

Track and reuse balances (e.g. to distribute weekend work fairly or drive an entitlement) with no manual tally.

Auto-calc & silent triggers

Global auto-calc groups apply a treatment whenever its conditions are met – auto-calc super on bonuses, for example. A payment can also silently trigger another: pay a neutrally-named special leave and it triggers the tracked domestic-violence leave behind the scenes, so it never appears on the payslip.

Sensitive or conditional logic runs automatically and discreetly, set once at config level.

Costing & cost-centre splits

Split costs across cost centres by percentage, by value or by units worked, overridable at payment level – so an allowance can follow the hours worked in each cost centre rather than a flat 50/50.

Accurate cost allocation without manual apportioning.

Behaviour you set in config, not code

A sample of the calculation behaviour controlled by configuration – not an exhaustive list.

Costing & analytics control

  • Cost-exclude / hours-exclude per code
  • Cost-centre split by value or by units
  • Allowance split by units worked

Leave & deductions

  • Leave loading
  • 50% (half-pay) leave
  • Full-deduct vs reduce when funds are short
  • Public-holiday handling

Payslip & day-worked control

  • Zero-pay codes that still produce a payslip
  • Payments that don't count as a day worked

Salaried + clocking

  • Ignore ordinary clock times for salaried staff
  • But still selectively pay OT, public holiday or weekend
Level 2 · Custom rules

When config can't express it, a custom rule can

Multi-period and organisation-specific rules come with awards, EBAs, the Holidays Act and multi-entity structures. Affinity's payroll specialists model them once and run them every pay – you're not left to wire it up alone.

How a rule becomes automatic

Three controlled steps – from your rule to every pay.

1. Define the rule

Affinity works with you to document exactly how it should operate – who it applies to, what earnings are included, how comparisons are determined, and what happens at thresholds or caps.

2. Configure and test it

Affinity turns that into a controlled payroll calculation rule and tests it against historical pays and your expected outcomes before it is activated.

3. Run it automatically each pay

Each cycle, Affinity performs the comparison, applies the correct treatment, and records the explanation.

Multi-period calculations standard systems push to spreadsheets

A few of the genuinely differentiated cases – averaging, thresholds, caps and comparisons that span more than one pay period. These are just examples.

Rate progression by service

AU/NZ

Pay rates auto-increment after set months of service (for example 3, 12, 24 months) using the rate service date.

Annual mileage threshold

AU

Mileage reimbursement switches from non-taxable to taxable automatically once the 5,000 km annual threshold is reached.

Comparison-and-cap

AU

Performs a full-time comparison each period, selects the correct super treatment, applies the result and records the explanation.

…and many more. These are just a handful – if the data and logic can be expressed, Affinity can model it once and run it every pay.

Custom rules sit in the processing pipeline as controlled, customer-specific calculation logic and do not interfere with system upgrades.

Have a rule in mind? Let's map it.

The cost is the workaround itself

Every manual rule you carry is hours, risk and exposure that compounds as rules multiply.

Hours rebuilding the same calculation each cycle.

The risk of a missed edge case surfacing at the payslip.

Audit exposure from logic that lives in spreadsheets.

A process that can't scale as rules multiply.

The rule is documented, tested and automatic

The manager checks an explanation rather than rebuilding a calculation. The system holds the rule, not the person.

And as the business changes, new rules are added the same controlled way – defined, tested against history, then run automatically every pay.

Best for

Organisations with complex, multi-period or organisation-specific pay rules – awards and EBAs, multi-entity, total-remuneration packages, industry-specific allowances – that off-the-shelf presets can't model.

Frequently asked questions

What is a pay code (pay element) in Affinity?

Pay element is the collective term for the building blocks of a pay – allowances, deductions, pay codes, leave codes, super and KiwiSaver codes, and informational codes. Each one is configured for its own role and calculation. Some process automatically every period from the employee masterfile; others are entered as needed through timesheets.

What are code groups, and what are they used for?

A code group brings pay elements together so they can drive a calculation or a report, change how something behaves, or affect an outcome. They can total or average units, total dollars, take an average or the greater of a rate, calculate a rate by summing allowances or informational codes, and add or deduct units, values or both. For example, a code group can trigger an extra payment automatically whenever one of a set of particular allowances is paid.

What is an auto-calc code group?

An auto-calc code group is set up once, globally, and is then checked automatically for every employee – with no per-employee setup. If its conditions are met for someone, the treatment applies. Auto-calc super is a common example: it can apply super to bonuses automatically. A payment can also silently trigger another – for instance a neutrally-named special leave can trigger the tracked domestic-violence leave behind the scenes so it never shows on the payslip.

What are informational codes?

Informational codes carry or trigger information without making a payment. They also act as unlimited accumulators – period, month-to-date and year-to-date balances such as total weekend overtime hours across a year or the number of days worked – which can feed into other calculations and reports, and can appear on payslips.

Can Affinity handle a pay rule that is unique to our organisation?

Yes. As long as the data and logic can be expressed, the rule can be implemented as a controlled, customer-specific calculation in the processing pipeline.

Can Affinity automate calculations that span multiple pay periods?

Yes – averaging, thresholds, caps and comparisons, and many more besides. Examples include service-based rate progression, the 5,000 km annual mileage threshold that switches reimbursement from non-taxable to taxable, and full-time super comparison-and-cap treatments.

Will a custom rule break when the system is upgraded?

No. It runs as controlled, customer-specific logic in the processing pipeline and does not interfere with system upgrades.

How is a custom rule built and tested before it goes live?

In three steps. Affinity documents exactly how the rule should operate, configures it as a controlled payroll calculation and tests it against historical pays and your expected outcomes, then activates it to run automatically each pay – recording its explanation every cycle.

Tell us the rule your system can't hold.

If the data and logic can be expressed, Affinity can model it once, test it against history, and run it automatically every pay.

Explore Core Payroll, Award Interpretation, Payroll IQ and Reporting & Data.