Background
Payday Super was coming. From 1 July 2026, employers would need to get superannuation contributions into employee's super fund within 7 business days of every pay run, instead of quarterly. Around this time, the ATO was winding down the Small Business Superannuation Clearing House (SBSCH), the free government tool many small businesses had relied on, which meant a wave of them would be registering with commercial products like ours for the first time.
That combination meant MYOB's Pay Super product used by over 100,000 small businesses, accountants, and bookkeepers had three things it needed to handle well before the deadline landed:
Let any eligible business register, including ones the old flow did not allow
Tell people, clearly and in real time, whether a payment was actually going to land inside a 7 business day compliance window
Give people a way to manage the noise of much more frequent payments without breaking the accounting underneath.
I worked across all three as the designer on this program. This case study walks through how I approach each piece and the moments where the right answer took real back-and-forth with engineering, SuperChoice's API, and each other to get to.
Rebuilding the Pay Super registration
The Problem
Registering and managing your details on Pay Super meant going through support entirely, there was no way for a business to do it themselves. This alone generated a steady stream of avoidable contact for something that should have been self-service from the start.
On top of that, our existing registration was a legacy wizard built on an older system (MSuper) that excluded a category of business altogether. This included employers with a Withholding Payer Number (WPN) instead of an ABN. These employers had no path to register at all. Our customers have raised this gap repeatedly, both on MYOB's Community forum and in our own survey data. With the government's SBSCH winding down and more first-time businesses coming to us, that gap mattered more than it used to.
What I did
The rebuild had two jobs: give businesses a way to register and manage their own Pay Super details without going through support at all, and unlock the WPN path that had been structurally missing.
The self-service piece meant building both registration and editing directly into the product. Covering things that had only ever existed as a manual support workflow, like updating business, banking detail, and managing their Pay Super users.
Outcome
Businesses could now register for Pay Super and manage their own details end-to-end, instead of routing every registration and every change through support. This was faster and easier for customers, and a direct cut to support volume that had only existed because there was no way to self-serve.
The 3,500 businesses who were WPN-only, previously locked out entirely, could also complete registration for the first time. Registration also got observability it never had before such as audit trail and correlation IDs.
The platform-level numbers back this up. On 29 June, the day before go-live, 107,263 payroll files (57.68% of the active base) were on Pay Super. By 31 August that was 132,686 (72.9%), up 25,423 files, climbing steadily through the weeks between.
Making payment statuses visible
The Problem
Once Payday Super took effect, the question a business needed answered was simple: is this payment going to reach the fund in time, and do I need to do anything? Our product answered that with one a one word status: "Processing". This covering everything from "not yet sent" to "stuck and about to fail," with no explanation on failure, just a prompt to contact support.
I validated this against real support data and in 7 customer interviews. In each of the sessions we heard the same complaint that it's stuck on 'processing' too long and that it was unclear when the super payments would get to the fund.
The support data backs it up at scale: Pay Super contacts peaked at roughly 8,700 in July, dropped to about 3,208 in August, and in the 1–15 September there were 1,374 cases. All of these were about payments taking too long and it was unclear what 'Processing' meant.
What I did
This wasn't a labelling exercise. Our product had no visibility into most of the payment lifecycle that lived inside SuperChoice, the external clearing house that actually moves the money. Before designing any statuses, I had to map what SuperChoice's API could tell us, where the gaps were, and where our own systems needed to catch up.
That meant working through discovery with engineering, status by status through the real lifecycle (authorisation, debit, SuperChoice holding funds, disbursement, fund receipt), asking what SuperChoice actually returns and what we could reliably surface versus infer. Failures were hardest: partial, full, and refund cases don't surface the same way or at the same point, and some old statuses depended on parts of the system no longer in use.
Once that mapping existed, the design got more familiar: a batch covers many employees whose contributions can land at different stages. I designed the batch-level status to always show the least-progressed or most-broken state, rather than an optimistic aggregate, with a filterable per-contribution view underneath. Where SuperChoice's own granularity was more detailed than a business owner needed, I grouped it into the handful of states that answer their real questions — where's my money, will it make the deadline, do I need to act.
Testing it with real customers
The granular statuses, worst-case-first ranking, and drill-down view went in front of customers as a prototype before build, across the same 7 sessions.
A second piece went through the PM rather than engineering. At the PM's request, each status originally carried a headline plus a fuller description, to cater for people new to the feature. Testing showed that extra detail mattered less once someone was familiar with the statuses: "It's too much information. It's pretty clear ." I took that back to the PM and proposed relying on help articles instead. The PM pushed back and so we landed on a leaner version with a headline plus a hoverable tooltip for detail, with links out for timing questions. The PM was happy with where it landed.
Stay in control: Clear Liabilities
The Problem
Marking super as paid is one of the most requested features raised in MYOB's community channels. Whether customers were clearing super manually, paying through an external clearing house, or asking for the same thing on another product, the ask was the same: a way to mark a super obligation as handled when it was paid outside Pay Super, instead of leaving it stuck in the queue.
UMUX verbatims back this up, spanning almost two years. It was constantly raised by our partners who were practising accountants and bookkeepers.
Payday Super meant more frequent pay runs generating more frequent super obligations, all landing in the same work queue. Some of those obligations get settled outside of Pay Super entirely, and previously there was no way to get them out of a user's view without recording an actual transaction against them.
What I did
Our first version did exactly what customers asked: it recorded a transaction to mark the super as paid and cleared the liability. It made sense on paper, but when we presented it to stakeholders, including the Bank Feeds and Reconciliation team, the review showed it conflicted with Bank Feeds auto-reconciliation and with existing clearing and reversing logic elsewhere in the product. Because we caught this before shipping, we were able to change direction. We pivoted to a different approach: "clearing" a liability became a pure visibility flag. Clear it, and it disappears from your work queue and balances, but nothing touches your ledger, accounts, or reconciliation state. Uncheck it, and it comes right back.
