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 to 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 upon current forms plus a number of new fields. DSP’s 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. DSP’s were then tasked with the implementation of STP within their individual payroll solutions.
This collaborative effort was a result of new Legislation which came into force at the end of 2016 supporting the process, with the required fields being finalised in Feb 2017.
Why do we need Assurance?
The devil is in the detail 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 obviously a fundamentally flawed process. Each payroll or taxation requirement is complex and is subject to an individuals interpretation, which obviously can be wide and varied. Different Payroll Software makes different 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 ultimately it is a manual process requiring manual interpretation by non-payroll professionals. Additionally, a key failing of this current process, as DSP’s 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 what 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 DSP’s would be able to test the same data and scenarios that should result in the same value outcomes: Testing 101. Depending on the level of complexity within their individual 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 to ensure that the data is formed correctly and fields are valid and therefore able to be consumed by the ATO…but it does not mean that the data is CORRECT for the scenario performed.
Assurance is a framework that tests for accuracy.
Conformance is a requirement because if the message that is being sent to the ATO is not technically valid, then it is unable to be consumed by the system, whereas 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: these are consumed by Payroll Solutions, then are reported to the ATO, where it checks: this is what was sent, this is what was received (and where), does it match, yes or no and if not, this is what should have been received. Different payroll systems have a wide-ranging capability, therefore, each DSP would use a test package that was relevant to their functionality.
Why has an Assurance Framework not been provided already?
The technical environment exists already in the form of the External Vendor Testing Environment (EVTE), so it is not difficult to build on what is already existing: there is no need to “reinvent the wheel”. Many of the required scenarios are also available and are already used by DSP’s for the implementation of 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, there have been collaborative efforts between DSP’s and the ATO resulting in an agreed position as to the importance of Assurance and to move forward with the implementation of 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, the requirement is for all Employers with 20 or more to be compulsorily reporting and as Deferments expire, this will result in a significant increase to what is being 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 be looking to the market to provide 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 and is 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.
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, which in a worst case scenario 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 not an 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 doesn't impinge on these liabilities. It would be as simple as providing a tiered test rating that would indicate 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 DSP’s that complete this process, allowing potential customers to easily and confidently compare payroll solutions. It would benchmark solutions, ensuring that DSP’s are all delivering the same output for the same data and scenarios. 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.
Everybody involved with Single Touch Payroll needs the “green” light on Assurance - so ATO, deliver what we all need to be assured with STP.
Comments