Custom Software Development for Australia

Modern awards are the hardest business logic in Australia

Most countries have a minimum wage and some overtime rules. Australia has an award system, and it is a different order of complexity. An employee's entitlement depends on which award covers their industry and role, their classification level within it, the hours they worked, which day of the week those hours fell on, whether a shift crossed a threshold into overtime, whether breaks were taken and when, whether allowances apply, and whether a penalty rate applies to part of a shift and not the rest.

Software that gets this wrong does not fail loudly. It produces a plausible number every fortnight that is slightly incorrect for a subset of staff, and the error compounds silently across every pay run until somebody audits it. That is precisely why award underpayment surfaces in this country as a large historical liability discovered years later rather than as a bug report — including at organisations with sophisticated systems and no intent to underpay whatsoever.

Our position when a client asks for rostering or payroll functionality is therefore unusually direct. This logic has to be specified against the actual award text, encoded as explicit and testable rules rather than as conditionals scattered through the code, and covered by a test suite built from real worked examples including the awkward ones — a shift crossing midnight into a public holiday, a broken shift, an employee who changed classification mid-period. If a client is not willing to fund that rigour, we would rather integrate with a specialist payroll product than build a system that quietly gets it nearly right.

Superannuation is a system obligation, not a payroll footnote

Superannuation guarantee contributions have to be calculated on the correct earnings base, at the applicable rate, and paid to each employee's chosen fund by the required deadlines. It is routinely treated as an appendix to payroll, and it is the appendix that generates liabilities, because the consequences of paying late or short are not simply the shortfall.

For a system, this means several things need to exist as first-class data rather than as fields somebody fills in. Which earnings are included in the calculation base, since not everything an employee is paid counts. Each employee's fund and member number, kept current. The payment deadline for each period and whether it was met. And a record of what was calculated, what was paid and when, that can be reconstructed later.

The failure mode we see most often is a business whose payroll system calculates super correctly and whose payment process lives in a spreadsheet and a bank portal. The calculation is right, the payment record is informal, and nobody can produce a clean history when it is asked for. Closing that loop inside the system is unglamorous work and it is the difference between a compliance question that takes ten minutes and one that takes a fortnight.

Specifying against reality, in an overlapping working day

Bespoke software fails on specification more often than on engineering, and in Australia the specific version of that failure is a system built from how the business believes it operates rather than from how it actually does. The award interpretation described in a meeting is the clean version; the real one includes the arrangement with the long-serving employee, the site that runs different shift patterns, and the exception someone agreed to in 2019 that nobody has written down.

So we specify against artefacts. Show us last fortnight's actual timesheets and the pay run that came out of them, including the ones that needed manual adjustment — those adjustments are the requirements. Show us the spreadsheet somebody maintains to make the current system work, because it is a specification for the feature that is missing. Show us the report your accountant asks for in the shape they ask for it.

The four-and-a-half-hour difference makes this workable in a way it is not with Europe or North America. Your afternoon is our morning, so a question about an odd timesheet gets answered the same day, a demo is a conversation rather than a recording, and a misunderstanding costs hours instead of a week. For a project type where late-discovered misunderstandings are the main risk, that overlap is worth more than any process we could put around it.

Questions worth asking any vendor

These apply to us as much as to anyone else bidding for your work.

• If the system touches pay, ask which awards it will interpret and how that logic will be tested. "We will handle the rules" without a test strategy is how underpayment liabilities are built.
• Ask for the pay logic to be demonstrated on a shift crossing midnight into a public holiday. It is the standard case that separates real award handling from a rate table.
• Ask whether a pay run can be edited after it has been reported. If it can, the reported version and the system version will diverge and nobody will be able to explain it.
• Ask whether the supplier is proposing to reimplement STP reporting or integrate with a payroll platform. The second answer is usually the better-value one.
• Ask whether ABNs are validated against the register at entry and re-checked periodically, or accepted as typed and discovered wrong when an invoice bounces.