The Payday Super change and what it meant
From 1 July 2026, the Payday Super reform requires Australian employers to pay super contributions into employee funds within 7 business days of every pay run, instead of once a quarter. For the roughly 200,000 businesses that run payroll through software, this is a frequency change more than anything else. Super now moves in step with every pay run instead of landing four times a year, which means a lot more individual payments, a lot more often, and a lot less room for anything to go quietly wrong along the way.
MSuper, the legacy system behind our super payments, was built for that old quarterly rhythm and was not ready for what Payday Super demanded of it. It did not have proper handling for partial payment failures, which was a manageable gap when payments only happened four times a year but became a real compliance risk once payments were happening on every single pay run. The volume and the frequency both needed a system with much more robust payment handling, and MSuper was not that system.
The decision was to rebuild the product as Pay Super, designed from the ground up to handle this new volume and frequency so our customers could stay compliant with the change.
Because this was a forced rebuild rather than an incremental update, it also opened up room to do more than the bare minimum. A few things stood out as worth fixing properly while we were already in there:
Self-service registration, so customers could manage their own details and control who on their team can see, create, and approve super payments, instead of needing to call support for every change.
Support for WPN (Withholding Payer Number) customers, who could not previously register or pay super through Pay Super at all. This mattered more than usual because the ATO's free clearing house, the Small Business Superannuation Clearing House, was closing, so these customers would soon need a commercial option instead of the free government one they were used to.
Clearer visibility into payment status, so customers can tell whether they are actually compliant, not just that something is "processing," which matters a great deal if they are ever audited.
A way to clear liabilities directly, rather than working around the product to get there.
I worked across all of it as the designer on this program. This case study walks through each piece, and the moments where the right answer took real back and forth with engineering, SuperChoice's API, and each other.
Rebuilding the Pay Super registration
The Problem
Registering for Pay Super meant going through support entirely. There was no way for a business to do it themselves, and the same was true afterwards: any change to registration details, however small, had to go through a support request too. The volume made that unsustainable on its own. Before self-service existed, we were seeing roughly 9,000 Pay Super sign-ups a month, and every single one was a case for support to process by hand. On top of that, customers were calling in for super change-of-details and payment-limit updates at a rate of around 450 calls a month, just to change something they should have been able to edit themselves in a few clicks.
Our existing registration was also a legacy wizard built on an older system (MSuper) that quietly excluded a category of business altogether. Employers with a Withholding Payer Number (WPN) instead of an ABN had no path to register at all, even though many of them already ran their payroll through MYOB. A WPN is typically held by organisations that need to withhold tax for employees but don't operate under an ABN, such as not-for-profits.
This mattered more than a missing form field would suggest. These were valid MYOB payroll customers who simply couldn't register for Pay Super, because it required an ABN they didn't have. When the ATO's SBSCH closed on 1 July 2026, they lost the fallback they'd been relying on. From that point, their only options were to pay super manually outside the product, or risk missing the new 7-business-day Payday Super requirement altogether. By estimate, this affected somewhere between 2,600 and 2,700 of our AU payroll customers, which made it both a compliance risk for them and a churn risk for us. In short, this wasn't just a feature gap. It was the difference between a valid MYOB customer staying with us, or being forced to either leave or manage their super payments outside the product entirely.
We'd heard requests about this directly from customers too, on MYOB's Community forum and in our own survey data, often enough that it wasn't a rare edge case. With 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.
For the registration form itself, the goal was to make it as easy as possible for customers to fill in their business details and bank details, and to manage who on their team could see, create, and approve super payments, all without needing to call anyone. That meant building both registration and editing directly into the product, covering things that had only ever existed as a manual support workflow. It also meant getting the validation right. Error messages needed to match the actual problem when a field was incomplete, rather than a generic rejection that left someone guessing what to fix.
Related but separate, part of the same rebuild was adding WPN as a supported option during registration, alongside the existing ABN field.
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. That was a direct cut to support volume that had only existed because there was no way to self-serve, and faster and easier for customers too. Being able to add and manage their own Pay Super users was a big win on its own, separate from the WPN fix. WPN-only businesses, previously locked out entirely, could also complete registration for the first time; by estimate, somewhere between 2,600 and 2,700 customers fall into that category. Registration also got observability it never had before, including an audit trail and correlation IDs, so the next round of "why did this fail" stopped being guesswork.
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, or 72.9%, an increase of 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 word. "Processing." That single status covered everything from "not yet sent" to "stuck and about to fail," with no explanation on failure, just a prompt to contact support with days rather than weeks left to act.
The 7 business day window made this worse, not better. Businesses were genuinely stressed about meeting it, because the real consequence of missing it was a fine, and some had already seen payments take close to a week to clear. With only one processing status to go on, it was common for a payment to sit there for 4 to 5 days. That felt like a very long time to someone watching the clock on a compliance deadline, even though we had no ability to change how SuperChoice's API actually processed payments underneath it.
Some of the confusion was specific to timing, and many customers genuinely did not understand why the process took as long as it did. That gap in understanding was real enough that MYOB later published an explainer article for customers, walking through what actually happens between authorising a payment and it landing in a fund.
Bank feeds made this worse for some customers. They could see the money leave their account and expected it to be processed straight away, but it still needed time to clear before reaching the fund, and that gap did not match their expectations at all.
The "Completed" status added to the confusion. It meant SuperChoice had finished its own processing step, not that the money had reached the fund, and the contribution could still fail after that point. Some customers took it at face value, only to see it later change to a failure, or to hear from an employee that the money still had not landed.
I validated this against real support data and in 7 customer usability sessions on payment status concepts. Seven sessions is not a large sample, but it was enough to hear the same complaints independently from small business owners and bookkeepers managing payroll from a handful of employees to several thousand.
The support data backs it up at scale. Pay Super contacts peaked at roughly 8,700 in July around go-live, dropped to about 3,208 in August, and in the 1 to 15 September extract of 1,374 cases, 61 were "payment pending or still processing," 21 were timing questions, and 18 were "status not updated."
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.
From there, I made a few specific changes. I replaced the "Completed" status with "Sent to fund," to more accurately communicate what was actually happening. SuperChoice can't tell us when a payment is actually received by the fund, and that was the real constraint we had to design around, so "Sent to fund" reflects what we can actually confirm rather than implying a certainty we didn't have. Alongside each status, I added copy explaining what was actually happening at that step and roughly how long it should take, for example that processing can take up to 4 business days. I also added an estimated date for when a payment would be authorised, to set expectations upfront and reduce the number of support calls that happened simply because someone did not know what to expect.
For an individual contribution, selecting it now shows a full timeline of its progress with timestamps, which doubles as an audit history and makes it much easier to track what happened to one specific payment rather than guessing from the batch status alone.
Testing it with real customers
The granular statuses and drill-down view went in front of customers as a prototype before build, across the same 7 sessions. The estimated date landed well from the start. One participant said it would be "very reassuring if you're not sure," which is exactly the uncertainty it was meant to close. The same participant responded just as well to the per-step explanations and timeline, saying it was "telling you what's happening at each step, which is definitely useful," and that it did not need to be visible from start to finish, just clear about where a payment actually was at that moment.
That reaction was not universal. Some customers said the fuller status descriptions were useful to read closely the first few times, but something they paid a lot less attention to once they understood what each status actually meant: "It's too much information. It's pretty clear [...] if you have 100 employees, that's definitely much more helpful. If someone is gonna call you, you can just click, check it." That tension went back to the PM rather than engineering. Each status originally carried a headline plus a fuller description, at the PM's request, specifically to cater for people new to the feature. I took the testing feedback back to the PM and proposed relying on help articles instead. The PM pushed back, because we still needed to serve first-time users properly, and we landed on a leaner version instead: headline plus a hoverable tooltip for detail, with links out for timing questions. The PM was happy with where it landed.
Marking liabilities as paid
The Problem
We heard this one through three separate channels, and it has a longer evidence trail than Act 1's. Customers raised it directly on MYOB's community forum. It showed up in our own CSAT survey data. And it came up independently in the monthly connect session we run with partners, practising bookkeepers and accountants. On the forum alone, the same ask came up across a customer-proposed Ideas Exchange item and several separate discussion threads: a way to mark a super obligation as handled when it was paid outside Pay Super, instead of it sitting stuck in the queue.
The reasons customers gave were consistent across all three channels. Some manage their super accounting inside MYOB but actually pay their super contributions through a third-party platform. Some had a duplicate sitting in the queue because a payment had been reversed. And some record self-managed super fund (SMSF) contributions in MYOB but prefer to pay them elsewhere. In every case, because the contribution was never actually paid through MYOB, it never cleared out of the queue on its own, so the customer just wanted a way to get it out of view.
Leaving those items sitting in the queue was not just untidy, it was a real risk. A list with items that genuinely needed action mixed in with items that did not created confusion about what actually needed to be paid. And that confusion had a sharp edge to it: the risk that someone would pay and process a contribution they were never meant to touch.
CSAT verbatims back this up, spanning almost two years, sustained demand, not a single complaint:
2024-09-12: "Needs the ability to mark superannuation as paid if it was paid manually, so it doesn't keep appearing."
2025-03-27: "Sucks that when I pay super on my own, I can't mark it off as paid."
2026-07-10: "After paying super directly to worker super account, I'm unable to mark super payments as 'paid' unless I sign up for Super Payments."
2026-08-31: "I don't need for MYOB to pay my staff, or to pay super, so how do I make super in dashboard say it's paid?"
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.
The first version of this feature did exactly that: it recorded a transaction to "clear" the liability. It made sense on paper, until it conflicted with Bank Feeds auto-reconciliation and existing clearing/reversing logic elsewhere in the product.
What I did and why we pivoted
I'd presented that first version to stakeholders including the Bank Feeds and Reconciliation team, and it was in that review that the conflict surfaced. That caught a wrong direction before it shipped rather than after. The clash came from two systems trying to represent the same payment. Pay Liabilities created a new accounting transaction to clear the super liability, while Bank Feeds separately imported the real bank withdrawal and tried to auto-reconcile it against that same obligation. Running both risked duplicate, unmatched, or difficult-to-reverse entries. The real problem was never super or Bank Reconciliation themselves. It was using a second transaction to represent a payment that had already happened outside the product.
Our team believes the proper fix is to actually clear the liability this way, and it is already built that way on the desktop product. The business decided not to build it for this product though, because it would have needed effort from several other teams to make it work, so the compromise was to hide it instead. I reframed the whole feature around that compromise. Instead of recording anything, "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. That compromise does come with a real cost. It means the experience is inconsistent between the desktop and browser versions of the product.
Outcome
Before calling this finished, I put the flag-only, hard-blocked, reversible design in front of practising accountants and bookkeepers who work closely with MYOB. They confirmed it matched how they actually handle super paid outside the product, and that it solved a genuine problem — a cleaner mental model for what "clearing" something means in a payroll product, and a reusable pattern the team can point back to. Build is on hold pending reprioritisation, so there's no production outcome yet — but catching the Bank Feeds conflict before it shipped is the pivot I'd point to first when talking about this program.