'Don't look at me’ is the response so far from most of the key vendors, but can they really wash their hands?
Google and Facebook famously attempted for many years to weasel their way out of responsibility for any legal issues arising from content on their sites by saying they were not media companies, just data conduits of some description.
They very clearly are media companies. Advertising is their main revenue model.
And that’s the position most governments and regulators are starting to take in managing these digital platforms. I.e. they need to take some responsibility for the havoc some of their published data can cause.
In the last week, The Medical Republic asked most of the major practice management system (PMS) vendors in the country whether they felt they had a role in helping their clients work out issues with payroll tax by, say, reconfiguring how data flows into in their products and various downstream software integrations, and, into their own limited financial reporting and invoice generating modules.
Some didn’t answer or they said they’d prefer not to comment. Others took the position that Facebook and Google took originally on their content: we just collect and distribute data.
One commented:
“We are not aware of any issues with the way data is stored and then reported/extracted from [company] in relation to the recent issues highlighted with contractor vs employee. Whilst we capture the billing information within our systems, the disbursement/payroll/payment process for providers occurs outside of our systems and is managed by the Practice directly.”
TMR is not sure this statement is entirely accurate. All the major PMS vendors create and issue invoices on behalf of their practices. Invoices are an integral part of a spectrum of important documentation used in financial and tax reporting.
Can the PMS vendors really step back and say they are just collectors and processors of data here? And even if they can, should they be taking that position, or should they be looking a bit harder at the problem nearly all their clients are facing, and trying help more?
All the payment flows of the major PMS vendors (and their downstream partner integrations) between their practices and the doctors working in that practice (“tenant doctors” we will call them) are mostly now problematic if you examine the major precedent cases on payroll tax, in particular, Thomas and Naaz, and Optical Superstore.
Of course a practice and its contractors are ultimately responsible for their own tax compliance, not their software vendor.
But what if it’s nigh impossible to correct your flows and compliance without getting better data out of your software?
Why won’t software vendors engage with their clients and develop configurations and data flows that go some way to helping them with the problem?
One vendor told us:
“Practices could benefit from some really clear guidelines, resources and education being provided by their Peak Bodies around these topics, supported by clear factual information and evidence from both the ATO and Services Australia”.
Sage words, as there is a lot of confusion at the moment, and not a lot in the way of clear guidelines, although the problem seems to be that the law developing around payroll tax is proving to be very complex.
The ATO recently sent TMR advice that pretty much said interpretations on whether a group is working in a tenant/landlord arrangement or an employer/employee one are primarily case by case because one has to look at the “entirety” of a setup.
Perhaps this vendor, while still trying to distance themselves from the problem for now by saying practices would benefit, is really saying that there’s not a lot they can do until clearer guidelines start appearing.
The question being put by some practice managers now is, are the configurations in the software they use optimised for what we now understand about compliance and payments data in every way possible, and if not, why not?
As clients they are entitled to ask, at least.
The RACGP threw a full petrol tanker of fuel on the payroll tax fire a week or so ago by coming out with a financial update in which they declared the following:
“Where independent contractor doctors work at a practice, each doctor should have their own PRODA account and issue invoices with their own ABN (not the practice’s). If the doctor uses the practice’s PRODA account,that doctor may not be viewed as an independent contractor.”
This statement caused an immediate uproar on the practice management socials with a lot of commenters suggesting the RACGP had things wrong. The RACGP has not retracted the paragraph, despite quite a bit of outrage.
Some of the comments appeared to be coming from one or two of the software vendors.
The statement raises a whole series of issues for the software vendors because it is advice from the peak GP body which looks counter to the way many PMS systems collect data and process invoices.
One of the major PMS vendors wrote to TMR several weeks ago on the issue of PRODA and pointed out that Services Australia itself had told them that all doctors could use the PRODA account of the PMS vendor to process their Medicare claims.
We presumed from the comment that this (big) vendor has lots of practices doing this.
Services Australia did issue a statement to this effect and until last week it offered this advice on its site, so you can understand the confusion.
But Services Australia in making this statement are being either cheeky or naive. You can process all your doctors on one centralised PRODA account in the technical sense. Services Australia is OK with that.
But you probably can’t if you want to comply with payroll tax law.
The rule is one PRODA account, one ABN.
If you believe the RACGP (and Thomas and Naaz), every tenant doctor needs to put their ABN on their invoice. Hence why the RACGP is probably saying every doctor also needs their own PRODA account.
Clearly now, whatever way the money flows, a tenant doctor must issue an invoice to their patient first, using their own ABN and if you can only have one ABN per PRODA account they are going to need a PRODA account. A practice can’t issue an invoice on their ABN to the patient on behalf of their tenant and because a tenant doctor needs to put his or her ABN on the invoice, they will need to process that through their PRODA account, not a common practice PRODA account.
It doesn’t appear that the major PMS systems are configured to manage this problem properly.
If this is the case, then potentially, the payment flow configurations on some of the PMS systems is wrong in payroll tax terms. I.e. you can’t process multiple tenant doctor payments either on the practice bank account, its ABN, or for that reason, the PMS PRODA account.
You can do it technically. But it looks like it’s going to potentially create a trail of evidence that your payment flows are not payroll tax-exempt.
The next problem software vendors have potentially might be a much bigger one.
It feels like it wouldn’t take much for a PMS vendor to reconfigure its processes to account for a doctor’s own ABN, and their own PRODA account (the hard part will be actual payment flows because strictly, the precedent cases are saying the actual money should first flow to the bank account of the tenant doctor, and none of the PMSs can track that).
Most of PMS systems integrate with downstream software products that manages a practice’s financial accounting, tax reporting and payroll in a much more detailed manner. In the case of one big PMS vendor, they also own the downstream financial software.
All of the major PMS vendors offer integration to third party software that offers a service of integration to Xero and reconciliation (maybe not actual receipted to bank reconciliation though) and it looks like a lot of practices are using software like this.
In the case of one of these downstream vendors at least, the processes in place and the overall setup of payment flows do not look like they are in line with the principles of Thomas and Naaz and Optical Superstore, in that all reconciliations are centralised into one practice account and one practice accounting system. This means the practice is taking the cash and all the payment for a tenant doctor first, subtracting their service fee after the fact, and remitting what is left back to the tenanted doctor.
This is probably the reverse of an ideally compliant payment flow.
While TMR understands that there are circumstances where practices can still manage to centralise their payments to their tenant doctors (they need very comprehensive alignment in their tenant doctor service agreements and other things), Thomas and Naaz pretty clearly got nabbed because their supposed tenant doctors were getting paid from central accounts which were centrally managed.
In the case of one of these software vendors, one of the once-appealing features of the software for practices and its tenanted doctors – that it linked live to the PMS and through that to the practice accounting software so that it could inform the doctors in the practice in real time when they earned money, even in small increments – now looks like it could be used by an SRO as one possible indicator that a practice was more in an employee-type relationship than a contractor one.
Not only does the money flow look similar to Thomas and Naaz, it is now largely at odds with what the RACGP has posted as advice for its practices and doctors – that each doctor should have their own PRODA account and ABN and issue invoices first to the patient via these.
This particular software and the money flow in it may still end up compliant, but the aligned service agreements with doctors would need to be significantly updated to account for what is going on, and likely, there would need to be some flow where a tenant doctor uses their ABN and PRODA for the Medicare processing prior to everything hitting the PMS and its downstream accounting and payroll application.
While all the major PMS systems either refused to comment or maintained that they were just data platforms, not part of the financial reporting process, at least one revised their data fields in the last few months to make it possible to associate an ABN with a contractor.
Although in some respects its a good thing that this PMS vendor is watching and trying to adapt, you have to ask, what ABN was on all the patient invoices prior to them adding functionality to associate a contractor with an individual ABN?
Part of the problem for all parties is that the law as far as payroll tax is concerned is only now starting to become clear, and some would say it still isn’t very clear.
Software vendors are being caught off guard, just as practices are being caught off guard.
And even through all of this, as the ATO advises on the law deciding if you are in an employee or contractor relationship, you need to look at the sum of the whole, not the individual parts. And payment flows are just one part of a bigger equation in determining overall compliance.
Like everyone, the software vendors need time to assess the rules, consult their clients and adjust.
But surely they are going to have to adjust in the end here, not sit on the fence denying there is a problem.
Arguing that you are just a data repository or collector, and there is “nothing to see here”, would likely in the end start losing you clients.
The vendors aren’t that capital rich, so they are naturally very cautious about what development they need to do. No one is going to pay a PMS vendor, or a downstream specialist accounting vendor, more money to fund the development that helps them help their clients become better at compliance. Doctors should probably acknowledge this, and pay more, but that is just not how it works.
In one respect, the software vendors should not be surprised that their clients would like a product that works in line with emerging law.
Some vendors are out there now on the practice management socials saying there are already “proven” and “cost-effective” technical solutions to the problem and not to panic.
One even posted that articles like this are panicking people unnecessarily and are not to be trusted (please don’t trust us, go and check with a professional).
That same vendor’s product works using centralised payment workflows, as described above.
One wonders if this problem isn’t so big that one of the vendors decides to bite the bullet and lead the market by getting on top of the issue (it would take a lot of research, consulting and development work) and coming to market with a product that really can help their clients sort out the problem.
Either that or perhaps one of the very big clients of these products, one of the big corporates perhaps, is going to demand something more updated and suitable.
Software alone will never sort the payroll tax problem out of course.
It’s complex and involves all aspects of running a practice, including how a practice sets out their engagement terms with their tenant doctors.
But most of the practice software vendors could probably help a lot more than they currently are.
Note: As we keep saying, we aren’t experts, we just talk to lots of them, and cobble this stuff together. So don’t, if you can help it, trust everything in this article and act on any of it without first seeking out a good professional who is up to date on this problem and, getting some advice on your particular setup.
