Single Touch Payroll Worksheet CSV layout problem

[lubos]

This has been fixed in the latest version (21.6.44)

However, please read new instructions before importing CSV to SingleTouch website.

Before your first upload, on SingleTouch website, you need to go to View Entities, then click Entity Details on entity you are uploading for and make sure Employee values reported field is set to Period. Not Year-to-date.

[Patch]

@lubos Interesting choice.
Doesn’t that make it harder to correct errors?

• Year to date mean just the current data in Manager needs to be accurate to ensure the totals reported to the ATO and employee are correct.

• Period means every period uploaded needs to be correct for the year to date reported to the employee and ATO to be correct. An accurate year to date is essential for electronic group certificate submission.

[boobook]

Thanks for the update. I don’t know if it might be an issue, but the double quotes around strings are no longer there.

More importantly, there’s something odd in the Basis of Employment column

[lubos]

This is implemented on top of new approach to report transformations where it can be done without any coding.

For the sake of simplicity, new report transformations support reporting for single period only. This is why all the figures on new STP worksheet are for one period rather than two.

And Single Touch Lite supports period-only figures so I think this could be good enough.

Edit: New report transformations still look a bit confusing to create. I’m still working on some improvements to make it more approachable.

[Patch]

I agree it simplified the coding / report definition.
The problem is it shifts the burden of use to the user.

Errors can be caused by data entry, upload timing, errors in Managers report transformation, changing government requirements.

All of which have occurred with just my experience. All of which were readily corrected with year to date and would require significantly more user expertise to correct with only period reporting.

Edit
Year to date values are often required in all businesses. Should start of financial year be a business parameter?

[lubos]

@Patch

The problem is it shifts the burden of use to the user.

I’ve considered this. But I think it’s just temporary issue.

For example, I don’t understand why STP needs business-wide totals for the period and then employee totals YTD. It would be better if they are consistent and ask for all figures YTD.

I will try to get in touch with SingleTouch to see if we can make all the figures YTD.

I just don’t want one report (STP worksheet) to ruin good thing - that is ability to create all report transformation without any coding.

[Patch]

@lubos

don’t understand why STP needs business-wide totals for the period and then employee totals YTD. It would be better if they are consistent and ask for all figures YTD.

The reason is because that is what the ATO has specified must be reported

Single Touch Payroll employer reporting guidelines

You are required to report a pay event to the ATO
…
You must report the year-to-date (YTD) values of gross salary or wages, allowances or other payments (as relevant), deductions and PAYG withholding for each employee included in that pay event.
…
You must report period gross salary or wages (BAS label W1) and PAYG withholding (BAS label W2) for all employee payments included in that pay event.

[Patch]

Also Managers definition of W1 is still wrong as it does not comply with the ATO reporting requirement.

• W1 does not just include payslipEaringsItems = Gross payments

The ATO requires most payslip earning Items are included in the W1 total, explained in more detail here Aust localisation inconsistent with ATO requirements

[lubos]

@Patch

The reason is because that is what the ATO has specified must be reported

I was referring to that. ATO made STP more complicated than necessary. They are asking for figures they can calculate themselves. And it is a mistake on their part.

They’ve done the same mistake with BAS in the beginning. Over the years they’ve simplified BAS reporting so they do not ask for figures they can calculate themselves. I expect the same will happen to STP eventually.

Until then, SingleTouch.com.au could implement some improvements I have in mind.

@Patch

Also Managers definition of W1 is still wrong as it does not comply with the ATO reporting requirement.

This will be fixed.

[Patch]

From Single touch File upload guide https://lite.singletouch.com.au/Support/FileUploads

Shown in red

Note: Most of the time, you can correct employee information in the next standard event. However if you need to make adjustments to an event in a previous financial year, you will need to use an update event.

• This error correction procedure applies and is trivial if YTD is used.

• If Manager uses period amounts to communicate to Single touch, which Single Touch then convert those to YTD to transmit to the ATO, then it becomed much more complicated. The user must understand how Single touch calculate values to send to ATO, ensure all period values are correct not just the last YTD, calculate the difference of all prior submissions to adjust the next period value by should any errors occur, and will corrupt reported data if any employee’s data is inadvertently included in 2 pay runs.

Getting this data wrong results in false data reported to the ATO, the ATO publishing false data to the employee, and the employer being liable for a fine.

In contrast I’m not convinced errors in the period W1 and W2 are as significant. Because the ATO can already calculate that and the data is repeated in the BAS submissions. There is also no way of correcting errors in the period W1 and W2 submissions for prior pay periods that I’m aware of.

In summary, it would be really appreciated if a way was found to continue to submit employee YTD quantities to single touch.

Edit
Year to date is also used for payslips. If a business parameter specified when the financial year starts, then perhaps it could be used for both.

[boobook]

Just in case you missed it, that recent update included bad data in the Basis of employment. See my reply Single Touch Payroll Worksheet CSV layout problem - #6 by boobook

[lubos]

@boobook not sure where this hidden character is coming from but go to Employees edit the employee and select basis of employment field again.

[boobook]

Just edited the employee and the problem is still there. The data is "F â " (in hex 46 20 E2 81 A0).

Using 21.6.44 on Windows (Australian language)

[lubos]

@boobook There are probably two identical options in drop-down. One is with this hidden character. You need to choose the other one from dropdown.

[boobook]

There’s only one Full-time option in the drop-down.

[lubos]

Go to Settings, click Import button and re-import Single Touch Worksheet.

Then check again for number of options in Payment Basis field.

[boobook]

OK, went to Settings, re-imported Single Touch Worksheet.

Still seeing the same Payment basis options when editing an employee. Still get the same odd data on exporting the STP worksheet.

Took a look in the custom fields, but I don’t see anything unexpected

[lubos]

After re-importing, if you edit an employee and look at Payment Basis drop-down, what do you see?

[boobook]

[lubos]

I just realized the issue was in the localization which contained this hidden character for some reason.

In the latest version (21.6.50), re-import Single Touch Payroll Worksheet. This should fix custom fields and should allow you to select under each employee Payment Basis which won’t have this hidden character.