Search

Are the days of the small payroll software developer numbered with Single Touch Payroll?

Updated: Jul 31


The introduction of Single Touch Payroll (STP) changed payroll software development forever. Real-time reporting was always a given once technology advanced sufficiently to meet the requirements for Government and broad market adoption. This advancement came with an increased cost.

What often started as a software venture with the founder being the programmer and a business partner, needed to be scaled to accommodate the new requirements. Resulting from the introduction of STP, the Digital Service Provider (DSP) had to decide whether to invest large sums of money in building a new solution, sell their business, or exit the market altogether. As some were unable to continue payroll development financially, and their business net worth did not make it an attractive proposition for purchase, they discontinued their products.

Moving from desktop applications to multi-tenant web apps is significantly more complex and costly when compared to building Windows forms-based programs.


The underpinning technology stack for web apps demands substantial work, knowledge and resources. There are also additional expenses with the framework required for web apps which Windows development does not need. Once deciding what Infrastructure as a service (IaaS) to use, AWS, Azure etc., the ongoing costs are then factored in calculating the COGS. You also need to build the base structure supporting multiple tenants before developing your payroll application. Windows development is, building once, copying and distributing the application to multiple users at a nominal cost.

For the ATO to receive and process Government-mandated data, there is an additional expense burden for the DSP sending the data.


As more Government agencies want to consume payroll information, the costs exponentially rise. Government reporting is a user-pays system wherein the DSP often engages the services of a third-party Sending Service Provider (SSP) and then passes the costs onto the user to meet their legislative obligations.

Understandably, with STP, DSPs must also meet the ATO's Operational Security Framework (OSF), requiring a minimum of ISO 27001 certification and ongoing audits. Web apps must have Multi-Factor Authentication (MFA), and the DSP must continually perform rigorous penetration testing. Whilst this change is imperative in providing a secure reporting environment, it is another cost burden for the DSP. Depending on their size, this requirement can be thousands of dollars and is an ongoing commitment.

STP Phase 2 requires a significant amount of work to rebuild payroll solutions.


With the introduction of STP Phase 2, many DSPs have to rebuild their solutions from the ground up due to the disaggregation of gross reporting requirements and underestimated the time to complete the scope of work required. If the DSP stored their data transactionally, the requirements are less demanding than if retained as accumulated totals. Also, extensive configuration options must be incorporated, allowing for a future proof solution. As we all understand, payroll requirements are ever-changing and constantly evolving.

Some DSPs dipped their toe in the water by providing a free payroll offering but have since discovered this scenario is a questionable long-term business model in sustaining the ongoing development costs.

There is now the consolidation of offerings within the market, with larger organisations acquiring payroll products. These acquisitions have several downsides:

  1. it reduces competition.

  2. the requirement for many teams supporting the development of multiple payroll products within one organisation.

There will be an internal rationalisation of the current offerings because payroll development for multiple products (like-for-like) is a substantial cost and will not improve.


Consolidation will be a problematic process in ensuring the target markets of these existing products (features and functionality) are supported and, in the process, not alienating their current customers. Also, due to the necessary expense of ongoing payroll development, there may be instances where DSPs who currently offer Accounting solutions in which payroll is bundled, decide to provide it separately. This change will allow for an increase in the subscription to cover development costs without adversely affecting their Accounting subscribers.

Originally Accounting and Payroll were most often offered as separate products before introducing the software subscription model. As Accounting has had limited changes throughout the years, albeit for the introduction of GST, there was little requirement for updates; therefore, the user did not need to pay for upgrades. This scenario was radically different for payroll. Some DSPs decided to combine the two products providing a source of income using the "compulsory" payroll changes as the driver for paid upgrades. Payroll must be kept up-to-date, which is not generally a requirement for Accounting. Since the introduction of GST, the most recent significant change is eInvoicing.

Developing payroll software is expensive and requires substantial resources along with extensive knowledge of the regulators' requirements.