With the introduction of Single Touch Payroll, a large amount of data is now being consumed by the ATO in real-time, with a minimum of checks and balances. How correct is this data that Government departments will be relying upon or making important decisions about, the results of which may be incorrect or, at the least, flawed? Why is there no Assurance framework yet provided to minimise the potential risks associated with the Governmental consumption of this big data?
How did we get here?
Single Touch Payroll started with consultation between the ATO, many stakeholders and those that carry the primary responsibility of ensuring that the requirements could and would be met, Software Developers (later to be renamed to Digital Service Providers (DSP) by the ATO). This process involved the identification of the data fields based on current forms plus a number of new fields. DSPs were asked scenario-based questions to expand upon what was originally deemed required, as the ATO understands Taxation but had little to no comprehension of the Payroll process. A Business Implementation Guide (BIG) was developed that grouped the scenario-based topics and defined ‘High-Level’ rules, but time constraints ended the detailed design very early, with only limited scenarios defined. DSPs were then tasked with implementing STP within their individual payroll solutions.
This collaborative effort was prompted by new Legislation that came into force at the end of 2016 and supported the process. The required fields were finalised in February 2017.
Why do we need Assurance?
The devil is in the details for payroll. Presently there is no way for a Digital Service Provider (DSP) to be completely sure that what is being sent to the ATO is correct. There is no surety that the data being supplied by Employers is being reported as intended by the ATO. The current necessity is for the DSP to interpret the high-level requirements and translate them into detailed requirements, with no definitive way of checking the output - which is a fundamentally flawed process. Each payroll or taxation requirement is complex and is subject to an individual's interpretation, which obviously can be wide and varied. Different Payroll Software makes various assumptions, delivering widely varying results for the same data and scenario.
Product Verification Testing (PVT) is currently provided by the ATO, but this process results in a major bottleneck, as it is ultimately a manual process requiring manual interpretation by non-payroll professionals. Additionally, a key failing of this current process, as DSPs make changes or add additional functionality to their payroll solutions, is that the entire process has to be constantly undertaken: another cumbersome burden. Automation of this process is required: an Assurance Framework.
With an Assurance framework, all DSP’s would be able to test the same data and scenarios that should result in the same value outcomes.
With an Assurance framework, all DSPs could test the same data and scenarios that should result in the same value outcomes: Testing 101. Depending on the level of complexity within their solutions, there would be corresponding test packages. Additionally, this would be an automated process with little to no human intervention, providing obvious benefits.
An Assurance framework also greatly assists with the requirement for Payroll Compliance and has the benefit of being changed or expanded upon as legislation changes.
What is the difference between Conformance and Assurance?
Conformance is the current method for ensuring that the data is formed correctly and that the fields are valid and, therefore, able to be consumed by the ATO However, it does not mean that the data is correct for the scenario performed.
Assurance is a framework that tests for accuracy.
Conformance is required because if the message sent to the ATO is not technically valid, the system cannot consume it. Assurance is a framework that tests for accuracy, ensuring that what is being reported doesn't result in GIGO (Garbage In, Garbage Out) being sent to the ATO.
What is required?
Test scenarios are required. Payroll Solutions consumes these and then reports to the ATO, where it checks what was sent, what was received (and where), whether it matches, yes or no, and, if not, what should have been received. Different payroll systems have wide-ranging capabilities; therefore, each DSP would use a test package relevant to its functionality.
Why has an Assurance Framework not been provided already?
The technical environment already exists in the External Vendor Testing Environment (EVTE), so it is not difficult to build on what already exists: there is no need to “reinvent the wheel.” Many of the required scenarios are also available and are already used by DSPs to implement Single Touch Payroll.
Over the past 12 months, there have been collaborative efforts between DSP’s and the ATO resulting in an agreed position as to the importance of Assurance.
Over the past 12 months, collaborative efforts between DSPs and the ATO have resulted in an agreed-upon position on the importance of Assurance and the move forward with implementing a framework. A significant amount of work has already been completed, but at some point, the process “hit the wall” and stopped.
What are the risks if Assurance is not provided?
From 1 July 2018, all Employers with 20 or more employees must report compulsorily, and as Deferments expire, this will significantly increase the volume currently sent. None of this data has passed any Assurance checks. It represents the various DSP interpretations of requirements.
Inevitably, Employers with 19 or fewer employees will be required to start reporting (a Bill is currently before Parliament), and those that don’t already have solutions will look to the market for them. There will be a number of new entrants, and if there is no Assurance framework, this could result in a large volume of data being reported incorrectly, ultimately worthless.
Government is making decisions on the data that is being consumed and if that data is not correct then it is not going to provide a true reflection of reality.
The government is making decisions based on the data being consumed, and if that data is not correct, it will not provide a true reflection of reality. In a worst-case scenario, this could result in significant financial losses or, at the least, a social outcry combined with negative media publicity. The reliability of the data being supplied should be of paramount importance to us all.
Assurance Certification would also be a market-driven requirement which I believe most DSP’s would embrace and it would disadvantage those that don’t.
There is certainly no expectation of an “ATO Approval Rating” and an understanding of the potential legal ramifications and liabilities associated with such a process, but there are major and necessary benefits with an Assurance Certification Framework that don't impinge on these liabilities. It would be as simple as providing a tiered test rating indicating which test scenarios have been completed (and passed) by the DSP, not a difficult task. Assurance Certification would be a voluntary process, but obviously, there would be benefits within the Marketplace for those DSPs that complete this process, allowing potential customers to easily and confidently compare payroll solutions. It would benchmark solutions, ensuring DSPs deliver the same output for the same data and scenarios. Assurance Certification would also be a market-driven requirement, which I believe most DSPs would embrace, and it would disadvantage those that don’t.
Everybody involved with Single Touch Payroll needs the “green” light on Assurance, so ATO delivers what we all need to be assured of with STP.
Comments