SAP AU PY - Future-Proof STP

SAP Single Touch Payroll (STP) Solution with CPI

One of the questions I am asked most often from SAP AU PY customers is about the SAP CPI (Cloud Platform Integration) component of the Single Touch Payroll end-to-end solution. Customers want to know if they can use their existing connectors: the answer is NO.

There's a reason for that, but before I get into that, I want to talk about the issue for which CPI is the solution:

Future of Digital Government Services

The Single Touch Payroll (STP) Pay Event is only the first step in the digital journey upon which the government is embarking. There are other STP real time services that are currently available or in design, and others that are in the planning stages. The Australian Taxation Office (ATO) is the leader in this space: as you would expect and as they aspire to be. But there are other federal agencies lined up to consume your data and state governments are champing at the bit. However, whilst there are many government takers, the DSPs (digital software providers: software developers) only have so many hours in their days, so these agencies have to take a number and wait in line for their turn. Government co-design takes time and money and DSPs are otherwise occupied right now with the STP Pay Event.

For SAP, the Pay Event is the first service because it is a mandatory compliance requirement - and customers need to get a handle on the new world of real-time reporting and ATO scrutiny of your data, each time you pay employees. SAP will decide if/when to roll out other optional services, such as: Tax File Number Declaration, Employee Commencement etcetera. (IMHO, the Employee Commencement service needs a LOT of work to become an acceptable service for SAP customers). The ATO also has plans for future phases of STP, where the dataset will be expanded to include data for other agencies, but that is subject to government approval.

You probably haven't read or seen anything about this, as ATO tend to only make this information available to DSPs. DSPs are reluctant to share this vision with customers, as some of it is not yet official policy and it's seen as something government should take the lead on communicating, as it is a government initiative.

So, why am I sharing? I believe that SAP AU PY customers need to be provided with the full context of information to enable them to make informed decisions. Short-term vision can result in bad decisions and higher costs, so painting a long-term vision is what I consider to be the responsible course of action.

Why CPI?

Gone are the days when there's a simple file specification, like is currently the case for the Payment Summary Annual Report (PSAR) on ATO's software developers page. That was the format details for a flat file for you to manually upload into the ATO business portal. But now, the government policy is to align the reporting obligation with the natural business process. Reporting directly from your payroll to the ATO as part of your current pay production process, with all of your confidential data, requires a dedicated focus on security. Hence, in co-design with the software industry, ATO determined that the best method to address the myriad of options for delivering STP securely is via ebMS3/AS4 with XML payload. Your employee data must be protected from data breaches and other security vulnerabilities and this is why the ATO developed an operational framework that all DSPs must address if they want to consume ATO services. This framework includes detailed technical and business operational requirements of DSPs that SAP has met for STP for their CPI solution only:

• Authentication - verifying the identity of the those who access tax and super data
• Encryption - locking data to secure it: end-to-end; in transit; at rest - different options for different types of senders, end-to-end is the highest encryption
• Supply chain visibility - identifying all of the players in the chain of transmission of tax payer identities, tax and super data from creator to receiver, for those not connecting directly to ATO (SAP CPI connects directly)
• Certification - establishing, obtaining and maintaining an industry-wide standard of DSP acceptable business practices assessed via iRAP, ISO/IEC 27001, OWASP ASVS3.0, SOC2
• Data hosting - ensuring that the connector software is on-shore, off-shore strictly by ATO exception
• Personnel security - staff security integrity check processes, with ongoing monitoring
• Encryption key management - handling of the government identity connection method, currently AUSkey
• Security monitoring practices - monitoring network, application and transaction layers for security compliance

This is expensive and on-going. The stakes are very high when it comes to protecting tax payer identities, tax and superannuation data. For SAP, CPI meets those requirements. Should you wish to choose an alternative solution, you will have to ensure that your alternative meets these requirements.

If not CPI...?

There are ATO-whitelisted Sending Service Providers (SSP) with whom you can enter into a commercial relationship and provide your data to them to send to the ATO on your behalf. You should consider these factors:

• Cost Model - is it based upon file size or something else? Is this fixed, or do they control price increases? What will be your indicative costs per month: for your pay cycles/business structures; when you have to send lots of updates to correct data, or to finalise, issue amendments?
• Error Handling - how do they charge for message responses from ATO, technical response issues, resolution of rejected messages and at what cost?
• Encryption - what standard of encryption do they offer: end-to-end; at rest; in transit?
• Supply Chain - do they partner with other businesses in the handling of your data: do others have access to your data?

In other words, if you don't send your data to ATO and instead give it to someone else to manage, you are still accountable for your obligations, so you need to be informed and ask questions. You need to understand what your risk exposure and costs will be in comparison to the security and fixed cost of SAP CPI.

Flexibility for the Future

So, when SAP introduce future services: optional as well as mandatory, CPI is a fixed subscription cost with significant data capacity that will accommodate the increase in data, up to their limits, at no additional cost. PI edition of CPI has big capacity per month, Enterprise edition is limitless. If you opt for an alternative to SAP CPI, what is your cost commitment into the future as government digital reporting grows?

As I said, it's best to be informed about options, as ATO hasn't published easy-to-follow guidelines to assist employers to understand these technical matters. Obviously, I think CPI is the better option, as there are so many benefits and opportunities for businesses by using CPI, other than just STP Pay Event compliance. But you will have to make your own decision for your business and circumstances.

Thorough research is warranted to step outside of the SAP-recommended approach.