Single touch payroll is a requirement to send payroll information to ATO. It applies to everybody after July 1 so it applies to dealers who use c9's payroll module.

STP is a train-wreck.  C9 currently doesn't have a working STP solution. I am dedicating all my time to solving the problem. I am confident I will solve the problem and I have 3 possible solutions being developed in parallel. Whichever gets finished first will be the one c9 will intialy use. I currently do not have a timeline for delivery. Delivery by July 1 is possible but not certain.

Why doesn't c9 have a solution right now?

STP reporting is conceptually simple. It is essentially a payroll summary plus some other simple additional information that needs to be submitted with each payday. Collating this information is easy and the work to collate it took less than a day to engineer and the supporting code already exists in latest version of c9.

The problem is getting the data to the ATO. The ATO expect the data to be transported to them across a formidably complex technology stack typically used only by massive enterprises tamed by teams of dedicated computer programmers. In their own recognition of how impossible the task is for small operators the ATO developed a plan b) for people like c9. The problem is their plan b) is not working.

Update #1: just made contact with a new possible vendor and looks really promising. Putting option 1) back on the table for completion prior to July 1.

The solution for smaller payroll vendors and why it is a failure

The ATOs plan b) is to encourage bigger companies with technology capacity to meet their requirements to provide a commercial product to smaller operators to help them comply : to offer it as a service. So idea is I work with a 3rd party to help me make changes to c9 to send data from c9 to their simplified systems and their systems marshal it into more complex delivery expectations of the ATO, all for a small reasonable fee.  There are a number of companies that claim to provide this, the problem is, essentially no-one can actually offer this. Or at least none of the many people I've talked to can.

So months ago I did some basic research and identified a couple of companies who can offer a solution. Contacting them I was reassured all I need to do is synthesize data into a CSV file or into a web API and send it to them. Basically a days work, 2 max. So I figured I can leave it until May or June to make it happen which provides ample margin. Their websites say, become single touch compliant in 10 minutes for only a few $ a month. Awesome.

But that isn't the reality of it.  Two problems:

1) it isn't nearly as simple as they represent it to be.   Sending data to the ATO the ATO still require me to identify c9 as the enabling technology. These other companies do not carry that mantle. There is still a requirement to seek compliance from the ATO and for the ATO  to whitelist c9. So all they are simplifying from my point of view this the enabling technology and this alone. In some respects this even adds complications, because a compliance process involves using a 3rd party technology stack to perform proscribed testing through and requires their ongoing and engaged input to help progress through this.  And yet these 3rd party vendors provide no meaningful materials to support this effort, no documentation or guides on how to move through that process. There is no plan for roadmap to simplify this.  Which brings me onto problem 2)

2) the 3rd parties are getting smashed by requests from the likes of c9 trying to rush to compliance at this late hour, thinking like me the task is simple enough it can be left to a few weeks before required date. I've tried to contact multiple vendors, emails go unanswered and phones literally ring out. For all intents and purposes there are no 3rd parties that can help achieve compliance. No-one helps, no-one answers so they might as well not exist at all.

Key one I am trying to work with, who I believe are positioned as the largest vendor in this space, have been very friendly helpful to the extent that can spare the time. But it is obvious they are completely unprepared for the deluge of work that has suddenly come upon them and inadequate processes and tools to cope with it, let alone a product that even works.

Solutions c9 is developing

So, how is c9 coping with this.  We are working on 3 solutions in parallel.

1) Continue to work with a 3rd party

We are continuing to try and work with one of the key 3rd parties. I am at a point where I want to actively test but their systems are not setup to allow me to begin testing ATO requires and their systems return error codes to that effect. If have, at time of writing this, for a week now being trying to contact them to resolve but no progress.

2) Wait for same 3rd party to provide a new product

The same 3rd party have promised a new product, called Single Touch Lite, which removes compliance obligations so we can just send them CSV files and be done with it. So in theory a truely setup in 10 minutes job.  Their engineers told me it will be ready in a few days. They are now saying 3 weeks. Which is cutting it fine to July 1, especially since it will be a new, immature product. This solution is entirely at the mercy of their capacity to actually deliver a working product.

3) Integrate into the ATO

They said it was impossible, the head of a dedicated IT team in a major multi national who specializes in providing enabling technology ATO demand said attempting this is a waste of time and his team have taken years to build a product.  But I am currently working on performing integration myself directly from c9.

I have made significant progress to the goal of this, beyond what I reasonably expected to be able to achieve and I estimate I am about a 1/3rd of the way there. Currently my progress is stalled pending support from the ATO, who are also slow to react and reply at this time, in part because the sheer complexity of the underlying technology. My current roadblock relates to low level cryptographic / authentication requirements of the system. But if things keep going as well as they have been, and if the ATO provide responsive and meaningful support it might just be possible to deliver a working product by July 1 that does direct integration.

To summarize some of the challenges involved with this:

• Literally over a thousand pages of technical and functional documentation spread across multiple documents (several dozen) and supporting sources.
• Existing enabling technologies that partially/completely implement this already costing thousands to 10s of thousands of dollars a year to use
• The ATO provide some sample code in a SDK (software development kit), but the key kit is substantially old and obsolete and only small parts of it remain useful for an effort like mine.  They have a new SDK but they cannot share it with little guys like c9 because of licensing restrictions.
• A completely lack of any materials or how to guides to help navigate all this. It is a firehouse of information, poorly organized and some parts missing so requires careful inference to build out and turn into a coherent product

Summary of progress, expectations and other comments

Realistically, for a July 1 readiness, option 2) is the most likely outcome which puts c9 at the mercy of delivery schedule of a company who are clearly overworked. But longer term c9 is committed to complete direct integration into the ATO (option 3) which if the planets align can happen before July 1 but more realistically will push out into later in the year. I am very confident that option 3 will happen within a gentler timeframe of a few months.

In parallel with all this, I will soon start talking to relevant people about applying for extensions / delays for STP reporting. The circumstances of everything around STP compliance is simply unreasonable for small businesses and small software vendors like c9. In spite of everything that makes this endeavour needlessly complex c9 has a credible pathway forward there is strong liklihood that pathway will come to a conclusion before July 1.

Some closing thoughts on this.

• The IT head I mention above from a large multinational shared his opinion with me, which is also my view, the ATO should not of done this to small businesses. The technology demands they make may or many not be reasonable to make on massive organizations such as the 3+ major retail accounting products that operate in Australia but in no way reasonable to place such burdens on smaller operators like c9
• The same person shared with me some further insights. Including that he deals with medium sized organisations who started out working with 3rd parties to deliver STP but ended up being dissatisfied with the service offered and switched to delivering STP data directly (with the help of his very heavy and very expensive product)
• The ATOs plan to support 3rd parties fulfill the need for small operators is shaping up to be a failure: the ATO should of been more actively involved with this 3rd parties to ensure delivery was actually feasible and this was actually working.

Beyond direct integration with ATO

Once I achieve whitelisting with a direct integration solution, I plan to share all supporting source code + methodologies on github under OSS (All java based). No-one should suffer through what I am going through to make this happen.