Single Touch Payroll Worksheet CSV layout problem

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


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.

OK, that’s fixed that issue thanks. After re-importing the settings, the employee had two Full time entries in the drop-down. Selected the first one and saved. Re-ran the STP worksheet and exported. The basis of employment is now just F as needed.

I contacted Single touch who confirmed

  • W1 in the BAS includes Jobkeeper
  • W1 in Single touch payroll to the ATO includes Jobkeeper
  • Gross pay in single touch payroll to the ATO does not include JobKeeper

I did not confirm the other allowances however their response does reinforce the ATO documentation Aust localisation inconsistent with ATO requirements

For those using Manager v21.6.57 Single Touch payroll

Payroll number

  • shows - Employee Key (a random hexadecimal number)
  • Not - Employee Code (the payroll number assigned to that employee)

I’m no sure how the ATO responded to changed employee numbers or if your employees see a random number on the MyGov web site. This can be readily fixed but involved entering the entire report transformation again by hand as cloning report transformations has been disabled (view screen removed).

W1 is yet to be fixed. I’m not sure how to fix this in the new No Code interface.

Employee submissions are period not YTD based. Hopefully that’s OK for most users. For me it precluded using later versions of Manager for STP submissions, it’s just to fragile for a production environment.

The latest version (21.6.60) is fixing employee payroll number issue. I didn’t realize it cannot be changed.

So at this point, the only outstanding issue is that employee figures are for the period (not YTD).

1 Like

How is progress on this?
I assume you have asked Single Touch to compensate for limitations in Managers Report transformations by converting YTD W1 and W2 to period incremental since last ATO submission.

Single touch are almost certain to have a longer QA test cycle prior to live production release than Manager. Have you been given any indication of how long they will take such as months or not at all?

By the way, there was an error in the prior financial year start date calculation.

  • A payment can not be made to the ATO in a new financial year without finalising the prior financial year STP.

  • As such if a pay period is for a week or fortnight ending on the 2 July 2021 and is paid on the 2 July 2021 then

  • The 2020/2021 financial year final STP must have already been sent in and the group certificate issued not including the payment on 2 July 2021

  • The STP submission on the 2 July 2021 must be for
    W1 & W2 period of 2 weeks ending on 2 July 2021
    Employee YTD for the period 1 July 2021 to 2 July 2021 if just one pay slip not including the prior financial years payslips.

From a code perspective the fyStart is set based on report.To not report.From
So the relevant code snippet is:

{% assign fyStart = report.To | set_day: 1 | set_month: 7 %} 
{% if fyStart > report.To %}
    {% assign fyStart = fyStart | add_years: -1 %}
{% endif %}


{% assign fyStart = report.From | set_day: 1 | set_month: 7 %} 
{% if fyStart > report.From %}
    {% assign fyStart = fyStart | add_years: -1 %}
{% endif %}

Unfortunately editing Report Transformations code was broken some time prior to Manager v21.6.17

Which means STP csv file must be manually created during the first pay period of each year.

Batch update appear to have been broken at a similar time.

The work around is to

  • Change the pay period start date in Manager STP worksheet to 1 Jul 2021 (ie bring if forward so Report.From is in the current financial year)
  • Create the CVS file
  • Edit the CVS file so it had the correct start date
  • Submit the edited cvs file
  • Hope this gets fixed properly.

Hi @lubos & @Patch I’m about to lodge my STP for the first time.
I’ve created the SCV files in Manager, exported to a directory, ready for uploading.

There are some steps provided on the Manager STP reports, but these are not exhaustive:

I’ve created a Single Touch Light account, and was about to register my Entity but it recommended to create a sandbox account to test first, so I’m doing that now.

In the Single Touch Light Sandbox I’m attempting to register my Entity, but came across this step

Do you have guidelines for this?
P.S. and are the issues above now resolved?

My understanding is that it doesn’t matter what checkboxes you have checked. For import it makes no difference.

Selected the CSV file generated by Manager and got this error.


The reason for the error was that I wanted to change the file name to something period identifiable, so I could distinguish different CSV files for different pay periods.

However when renaming the file on export, it changed the file extension from .CSV to just .file

When select export button:
If I leave the file name as default with no date identifiers then it will save as .CSV:

However if add date identifiers to name leaving the .CSV below:
It saved as just .file and STP will not recognise this and STP will not recognise this:

However with a little bit more care to add back the .csv extension to the edited file name it works

I’m thinking making the file name include date identifiers by default would be a good idea.

Lastly I couldn’t find anywhere to select between date ending and period from/to, but it seemed to do this from data within the file, is this correct?

I think I found the period setting here …

You are correct, when editing the file name you have to ensure you leave the file extension / type.

The ATO requirements is

  • employees data must be reported year to date
  • employee data can be corrected by updating year to date at the next pay run
  • employee data in prior financial years can be corrected by an “update event” (zero period W1 & W2)
  • Manager reporting year to date to single touch which is then sent as is to ATO ensures this functionality and associated error correction option are usable.

The ATO has also tacked on employer W1 and W2 reporting. This can be only be corrected prior to the next payroll event. The same information is reported with BAS submissions. For a reason which is not clear to me they require period amount for Single touch payroll reporting.

You are correct the STP implementation in Manager’s current implementation uses period reporting of employee data to Single touch, forcing them to calculate the year to date based on all prior submissions in a financial year. As a result.

  • errors found and corrected in Manager will not be corrected in the ATO records.

  • if there is a payroll error at any time in a year the only way of knowing is to compare Managers year to date to the ATO records

  • correction requires calculating the difference between the actual year to date and the ATO year to date and hand creating a difference cvs file, or manually typing correct year to date into single touch’s manual entry screen (changing to YTD prior then back to period after.

In my opinion the new Manager STP interface is simply not robust enough for use in a live business environment.

Would dearly like to have a chat offline on this.
I’ve just closed out 2020/2021 FY and submitted to ATO - done.
Everything for STP in Manager is prepared, created .csv files, next step to submit, but not confident yet

Year to date is equal to period reporting for the first submission, so is not an issue initially.

Submission via Single touch is not as hard as they make it sound. All data can be checked prior to submission. Unfortunately the single touch web site does not support going back if you navigate to the detail display page. The work around is just re-enter your last entry screen.

By the way
I use the current version of Manager only on a test bed.

I’m using an older version of Manager in my live production system until this is fixed. If it takes to long then I will need to find an alternative accounting system.

@lubos Doing my head in, there is so much chatter in forum about this STP and ATO has so much requirements, I’m not sure what bugs are fixed and which are not.

I just saw a convo above of fixing an invisible character by boobook, which they said is resolved, but I just checked and I’ve got it in Ver 21.7.24, and yes I did re-install the localisation for STP

I can’t get my head around the YTD versus period reporting bit, lost all confidence in lodging until bugs ironed out

@lubos can you confirm if @Patch observations above have been addressed?

Great idea

I contacted them too and asked

Their response was

Which I assume means Single touch will not be supporting year to date for employer figures (W1 & W2) any time soon.

Is there any chance the date of the start of financial year could be added as a Manager Business parameter so year to date could be calculated on pay slips and report transformation for all jurisdiction? Alternatively could support of parameters be added to report transformation so start of financial year could be calculated in a country specific report transformation.

1 Like

@Patch thanks for requesting this feature from them. I’m looking at all country-specific requirements at once and where figures need to be lodged with government departments digitally, I need to approach this differently. I’m working on something new.

1 Like

That is really appreciated.

While you are doing so, please consider supporting arithmetic of interim values.

Perhaps it is just me, but I put a high value on accounting software producing exactly what is required by the tax authority, including rounding they specify is required. Localisation Rounding support

Also I suspect it is easier to just do exactly the calculations the tax authority specifies, rather than having to think of how the calculations specified by the tax authority can be transformed into operations Manager supports. Even when this can be mostly be done, it requires abstract mathematical thinking, which adds another layer of complexity in implementing country specific reports.

The challenge is for Managers report writer to support enough power to implement the range of country specific reporting requirements, and still be easy to program. I suspect community conversation illustrating the difficulty / ease in writing such reports is key to wider use. It enables users from different jurisdiction to see what is involved in a forum users writing these reports.

1 Like

@Lubos, it is brave to acknowledge that the new approach may not lead to the results and therefore think this over and work out something different and better. Einstein would have loved this tack. Keep it up!

1 Like