SAP STP2 Implementation Guide V1.2 - Part2

2
PUBLIC
Single Touch Payroll Phase 2

Implementation Guidelines
Non-Concurrent Employer Solution (Non-CE)

Version: 1.2
Status: FINAL
TABLE OF CONTENTS
3.3 Functional Design .......................................................................................................................... 5
3.3.1 Changes introduced by STP2 ....................................................................................................... 5
3.3.2 Data Requirements......................................................................................................................... 6
3.3.2.1 Taxation Master Data ....................................................................................................................... 6
3.3.2.2 Transfer of YTD Amounts............................................................................................................... 15
3.3.2.3 Death Beneficiaries ........................................................................................................................ 17
3.3.3 Tables, Structures, Programs and Utilities ................................................................................ 18
3.3.3.1 Payroll Cluster ................................................................................................................................ 18
3.3.3.2 STP Overrides (RPCSTOQ0)......................................................................................................... 20
3.3.3.3 Wage Types ................................................................................................................................... 22
3.3.3.4 Mid-Year Go Live Utility.................................................................................................................. 26
3.3.3.5 Pay Event Generation .................................................................................................................... 28
3.3.3.6 Display, Finalise and Declare ......................................................................................................... 40
3.3.3.7 Send to the ATO............................................................................................................................. 42
3.4 Business Processes .................................................................................................................... 46
3.4.1 Pay Production, Post-Pay Production, Corrections ................................................................. 46
3.4.2 Corrections Framework ............................................................................................................... 46
3.4.3 End Of Financial Year .................................................................................................................. 47
3.4.4 Communication with Employees ................................................................................................ 47
3.4.5 Transfer of YTD Amounts ............................................................................................................ 48
3.4.5.1 Zero Out Method ............................................................................................................................ 48
3.4.5.2 Replacement Method ..................................................................................................................... 49
4 IMPLEMENTATION APPROACH ................................................................................................. 50
4.3 Support Pack Approach .............................................................................................................. 50
4.4 Stand-alone Project...................................................................................................................... 50
4.5 Initial Transition to STP2 ............................................................................................................. 51
5 TESTING APPROACH .................................................................................................................. 52
5.3 ATO External Vendor Testing Environment (EVTE) Requirements......................................... 52
5.4 Scenario Testing .......................................................................................................................... 53
5.5 Issue Reporting ............................................................................................................................ 55
5.6 Supporting Documents................................................................................................................ 55
TABLES
Table 5 - Permissibility of Tax Scales to Income Types .................................................................................... 8
Table 6 - Ongoing maintenance of tax infotypes (0188, 0817, 0227)................................................................ 9
Table 7 - Supported Tax Treatment Codes ..................................................................................................... 11
Table 8 - Changes to Existing SAP Model Wage Types ................................................................................. 22
Table 9 - SAP New Model Wage Types .......................................................................................................... 24
Table 10 - Child Support Variation Information ............................................................................................... 37
Table 11 - B2A STP Status and Sub-Status possibilities ................................................................................ 43
FIGURES
Figure 37 - New fields and validations for IT0188 Tax Australia ....................................................................... 6
Figure 38 - Pay Event after IT0188 retro change from SAW to FEI-be BEFORE MYGL2 .............................. 10
Figure 39 - Pay Event after IT0188 retro change from SAW to FEI-be and AFTER MYGL2 .......................... 10
Figure 40 - SAP STP2 Tax Treatment Framework.......................................................................................... 11
Figure 41 - "Gap Year" requirements for Prior FY Updates ............................................................................ 13
Figure 42 - IT0817 Income Tax Withholding Variation-AU .............................................................................. 14
Figure 43 - Transfer of YTD Amounts ............................................................................................................. 15
Figure 44 - Death Beneficiary: Pay Event Payee Layout ................................................................................ 17
Figure 45 - Death Beneficiary: Pay Event Income Stream Collection Layout ................................................. 17
2 | 56
Figure 46 - Death Beneficiary: Pay Event Allowances-Other/LSE/ETP .......................................................... 18
Figure 47 – Cluster Table: TAXP..................................................................................................................... 18
Figure 48 - Payroll Cluster: SABN ................................................................................................................... 19
Figure 49 - SABN approach to assigning payer .............................................................................................. 19
Figure 50 - Payroll Cluster: ACRT ................................................................................................................... 19
Figure 51 - ACRT groupings of wage types by ABN/Branch/Income Type/Country-Region Code/WHM Flag
[blank] .............................................................................................................................................................. 20
Figure 52 - Payroll Cluster: AETP Table ......................................................................................................... 20
Figure 53 - T5QSO STP Overrides modified for STP/STP2 use ..................................................................... 21
Figure 54 - Override File Upload Test Output ................................................................................................. 22
Figure 55 - Context of Wage Types Required for Disaggregation of Gross .................................................... 25
Figure 56 - Wage Type Readiness .................................................................................................................. 26
Figure 57 - PC00_M13_CLST_MYGL2 - Migration Utility for STP Phase 2 Go-live ....................................... 27
Figure 58 - EOFY Lump Sum E....................................................................................................................... 28
Figure 59 - STP2 Pay Event (RPCST2Q0 - Transaction PC00_M13_STP2_GEN)........................................ 29
Figure 60 - Pay Event Overview ...................................................................................................................... 30
Figure 61 - Pay Event Parent Layout .............................................................................................................. 31
Figure 62 - Pay Event Payee Layout ............................................................................................................... 31
Figure 63 - Pay Event Income Stream Collection Layout ................................................................................ 31
Figure 64 - Pay Event Allowances Other/LSE/ETP Layout ............................................................................. 32
Figure 65 - Pay Event Log: Payee-specific warnings and errors..................................................................... 32
Figure 66 - Pay Event Log - Foreign Tax Paid enforcement ........................................................................... 32
Figure 67 - Pay Event Payee Layout showing "space" replacing invalid characters ....................................... 33
Figure 68 - Structure of the unique Submission ID.......................................................................................... 33
Figure 69 - Inclusion of employees without a payroll cluster ........................................................................... 34
Figure 70 - Income excluded from STP2 ......................................................................................................... 34
Figure 71 - Top-Down Salary Packaging impact for OTE ............................................................................... 35
Figure 72 - Pay Event Selection Logic ............................................................................................................ 36
Figure 73 - Child Support Transition Additional Step ...................................................................................... 38
Figure 74 - RPCSTPDD (PC00_M13_STP2_DD Display, Finalize and Declare) ........................................... 40
Figure 75 - Display Payer Layout .................................................................................................................... 42
Figure 76 - Legal Declaration Statements ....................................................................................................... 42
Figure 77 - B2A unique object Id ..................................................................................................................... 43
Figure 78 - History of B2A object showing steps in process ........................................................................... 44
Figure 79 - Sample OSFB STP Overview ....................................................................................................... 44
Figure 80 - Display XML .................................................................................................................................. 45
Figure 81 - STP Pay Production Process including Post-Pay and Corrections............................................... 46
Figure 82 - Correcting Reported Data ............................................................................................................. 46
Figure 83 - Business Process: End of Financial Year ..................................................................................... 47
Figure 84 - Consider what your Employees Need to see about their Pay Details reported to Government.... 47
Figure 85 - Zero Out Method for Transfer of YTD Amounts ............................................................................ 48
Figure 86 – Replacement Method for Transfer of YTD Amounts .................................................................... 49
Figure 87 - Transitioning to STP2.................................................................................................................... 51
Figure 88 - Production Steps to Transition to STP2 ........................................................................................ 51
Figure 89 - STP2 Testing Approach ................................................................................................................ 52
Figure 90 - ATO EVTE Key Data..................................................................................................................... 53
Figure 91 - SAP for Me: Report a Case........................................................................................................... 55
3 | 56
DOCUMENT CHANGE CONTROL
Version Description Date
Draft 1.0 Initial Draft 22 February 2022
Draft 1.1 Updated for internal feedback in readiness for Pilot customers 8 March 2022
Draft 1.2 Restructured to incorporate configuration, functionality and business 31 May 2022
process in readiness for General Availability
ABOUT THIS DOCUMENT
This document is designed to support SAP Australian payroll customers to implement and operationalise the
Single Touch Payroll Phase 2 solution, released for the 2022/2023 financial year. It includes details of the
configuration required, functionality of the solution to meet the ATO requirements and recommended
business processes, where relevant.
As it is a significantly large document, hyperlinks and cross-references have been utilised to assist the
reader to navigate the document. Hyperlinks can be recognised through the use of SmartLink formatting.
Cross references between related topics are identified at the end of the paragraph or section by the following
formatting:
Refer to related topic Hyperlink to the section number and heading

Other cross-references in paragraphs are recognised through hyperlinks with SmartLink formatting.
PURPOSE
The purpose of this document is to provide:
• Information about the SAP Single Touch Payroll Phase 2 (STP2) solution design
• Details of the configuration required to support the operation of the solution
• Details about the functionality of the solution to assist customers with master data requirements,
business processes and error handling
• Recommended business processes, where relevant
4 | 56
3.3 Functional Design
There are significant functional changes to the payroll and master data beyond the configuration outlined in
the previous sections. These changes are required to support the extensive and detailed requirements the
ATO has defined for STP2. Unlike the initial phase of STP, this phase introduces the most significant impacts
for business as, to deliver the level of granularity required by Services Australia, the reporting is aligned with
the Fair Work Regulations 2009 S3.46 about separately identifiable components of pay.
This introduces a transparency for the business governance over payroll, taxation and superannuation.
There are interdependencies between fields and values and extensive complex validation rules that reinforce
the rules of STP2.
The following sections provide the detail needed by customers to understand the extent of the impact for the
processes, data and design of the STP2 solution.
3.3.1 Changes introduced by STP2

A summary of the changes in SAP functionality is provided below. The detail of these changes is defined
more extensively in the subsequent sections.
• Income Stream Collection – a common set of payment types are now grouped for each combination of
income type and country code. This grouping of payments is known as an Income Stream Collection.
Given the requirements to assign all wage type YTD amounts to this further segment for reporting, the
master data is recorded in IT0188 Tax Australia and will be captured in the pay cluster.
• Country Codes – some types of income are associated with other countries and the ATO needs to
uphold Australia’s tax treaties and other OECD commitments by ensuring income can be attributed to the
related countries. As such, country codes are mandatorily required for the relevant income types.
• Disaggregation of Gross – instead of reporting a summary of income, to meet Services Australia’s
social security administration requirements, income is now to be reported as separately itemized
components for all Income Stream Collections, aligning with existing Fair Work obligations. Allowances
are a complex area of this disaggregation, as it includes separately itemizing all-purpose allowances.
• TFN Declarations – instead of separately reporting TFN declaration details to the ATO by sending paper
forms or outputting the TFND report to be uploaded in ATO Online Services for Business, key details
have now been included in the pay event to be sent with current data every pay. The TFND must still be
collected by employers, but reporting is satisfied through the pay event rather than the pay event plus the
paper forms/TFN declaration report.
• Tax Treatment Codes – some of the detail from the TFND form plus other tax details from IT0188 Tax
Australia and IT0817 Income Tax Withholding Variation are now sent each pay to enable the ATO to
detect if the employee has not informed their employer about some key aspects of their tax
arrangements, thus preventing them from getting debt notices when they address their personal tax
matters at the EOFY.
• Child Support – instead of completing manual monthly remittance notices for child support deductions,
the child support deductions and child support garnishees can be reported via the pay event each pay.
The ATO pass the data straight through to Child Support, who reconcile it with the payments they receive.
• Employment Details – some of the detail from the Services Australia Employment Separation Certificate
are included in the pay event each pay to reduce the need for employers to manually complete the
separate form. This assists Services Australia to better assist those claim support payments from them.
• Lump Sum E FYs – the burden of providing the detail of which financial year the components of lump
sum E payments relate via letters to impacted employees has now been replaced by reporting the lump
sum E amounts per financial year in the pay event. By performing this EOFY activity once, employees will
have full visibility on their ATO Income Statement to assist them making any prior year tax return
adjustments, if relevant.
• Key Identifier Management – when employers transfer YTD amounts between BMS Ids or Payroll Ids,
there are two possible methods available to alert the ATO that balances have been transferred so the
Income Statement can be corrected and the PAYGW liability is effectively managed.
• Employees included in Pay Event – the current gap in STP has been closed for STP2 with respect to
employees with RFBA from prior financial years and no current financial year payroll cluster. The pay
event will now read both the payroll cluster and the overrides to include employees in the pay event.
5 | 56
• New Income Types – some new income types have been introduced to enable employers to claim
reporting concessions (both pay event and finalization) for classes of employees automatically through
the pay event rather than manual claims for each employee. Additionally, visibility of some vulnerable
workers is now possible through the introduction of a specific income type.
• Negative YTD Amounts – in some limited circumstances, such as for change of employer with a
recovery retro into a former employer or a prior financial year change to a payment, there may be
separately itemized components that show negative YTD amounts. Overall, the income is zero or
positive, but the lower level of discrete payments means that some negative amounts are possible.
• Payer Changes – the detailed design phase presented an opportunity for a deep dive into exact
meanings and purposes of some of the original fields from the introduction of STP, such as which payer
to report when there is a change of payer. “As at payment date” has now been clarified to mean the same
alignment as other payroll data: pay period end date. Previously, the ATO did not appreciate that “as at
payment date” only applies to tax data and all employment data is up to and including pay period end
date. This has now been aligned in STP2 with the logic of the bank file generation.
It is clear from the extent of these changes that the focus for STP2 is on the alignment with Fair Work
obligations, but it will also give the ATO insight into an employer’s approach to meeting their PAYGW and
superannuation guarantee obligations. The compliance of customer wage types will be integral to being able
to declare the pay event “true and correct”.
3.3.2 Data Requirements

The “extended dataset” of STP2 includes some new fields of data that have not previously been captured or
stored in payroll. It has also provided the ATO with an opportunity to provide more granular guidance on tax
and super as it relates specifically to payroll. The following sections outline how SAP has addressed these
requirements to minimise the impact on customers.
3.3.2.1 Taxation Master Data

This key data for payroll has been modified to form the foundation of the Income Stream Collection approach
to reporting payments. Tax infotypes are read differently by the payroll than all time and payroll master data.
These infotypes are read only AS AT PAYMENT DATE and not by effective date range (no partial period):
• IT0188 Tax Australia
• IT0817 Income Tax Withholding Variation-AU
• IT0227 TFN Australia
This has not changed for STP2 but has always been how the tax laws apply to payments. Given the move to
transparency of tax data in STP2, the most significant master data changes are to the tax infotype:
Figure 1 - New fields and validations for IT0188 Tax Australia
Tax Treatment
Code = RTXXX3
Char-1 and Char-2 (may be Char-3

Char-3. For example: and Char-5). For example:
• [blank] may = **X*** • Tax Scale 2 = RT****
if STSL tax scales
• Tax Scale 2H/2S = RTS***
not used HECSF
• Tax Scale 5 = RT*XFX
• Any value = **S***
• Tax Scale 6H/6S = RTSXH*
EXTAX Note: Char-5 is only populated from Tax Scales 5, 5H,
Char-4. For example: 5S, 6, 6H, 6S, else “X”
• Tier 1 (1%) = ***1XX

Char-6. For example:
• Tier 2 (1.25%) = ***2XX
• [blank] = *****X
• Tier 3 (1.5%) = ***3XX MEDEX NODEP
• 0 = *****0
• [blank] = ***X
• 1-9 = *****[1-9]
• ≥ 10 = *****A
Tax Offset Amount

(PAYEVNTEMP255)
6 | 56
The extent of the changes to IT0188 Tax Australia are as follows:
• New Tax Scales – to expand the support for workers who are taxed as per the following scales:
- Horticulturists and Shearers as per ATO NAT 1013 Tax table for individuals employed in the
horticultural or shearing industry:
o C1 H & S Resident with TFN
o C2 H & S Foreign Resident with TFN
- Seasonal Worker Programme as per ATO webpage QC 25161:
o SW Seasonal Worker Programme
- Actors who perform promotional activities, to complete options in NAT 1023 for actors:
o TP Actors Promotional Activity
- Working Holiday Makers who have not provided their TFN, as tax scale 4a/4b cannot be used:
o WN Working Holiday Makers – No TFN
- Income Excluded – for workers whose circumstances mean all payments are out of scope of STP but
is required to store pay results stored in the new format: per ABN/Branch, Income Type and Country
Code (if required):
o NR No Tax Non-Reportable STP
• Change of Tax Scale Purpose – where the current purpose of use includes more than one circumstance
that must now be discretely identified, so a new tax scale was created for other circumstances (NR),
leaving this one to be exclusively used for exempt foreign income only:
- 0 No Taxation
• Reinforcement of Tax Scale Purpose – where the current purpose of use is for a single circumstance
only, that customers have utilized for other purposes (such as additional tax or upwards variations) that
has adverse impacts for STP2, such as those for ATO approved downward variations only:
- 8 Flat Tax Percentage
- 9 Flat Tax Amount
• New Fields – where the critical fields for STP2 (Income Type and Country Code) are now to be recorded
with employee tax information due to the interdependency between income types and applicable tax
scales. Furthermore, such critical fields had to be included in an infotype that was exclusive to Australian
employers and was critical to the payroll process to ensure mandatory maintenance of such critical data:
- Income Type – refer to section Error! Reference source not found. Error! Reference source not
found.
- Country/Region Code – as for other SAP infotypes, the drop-down list displays the ISO-3166 Alpha-2
code and description of the country or region and is only required for income types WHM, FEI and IAA
• Supplemental Variations – the interdependency between fields on the tax infotype were clarified for
STP2 to better clarify which tax scales/options are permitted to have which variations, if permitted at all:
- Study & Training Support Loan (STSL) – if the employee has a government loan to cover their
education expenses, the loan is repaid through higher taxes when income thresholds are reached.
This variation occurs when the employee advises the employer of their loan, but the ATO may prompt
the employee to update their circumstances if employer was not advised.
- Medicare Levy Surcharge (MLS) – if the employee does not have private patient hospital cover and
their income is in excess of thresholds (single, no dependants; families), additional Medicare Levy
applies for tier levels specific to their circumstances. Income levels make the employee ineligible for
Medicare Levy Exemptions and Medicare Levy Reductions. This variation occurs only when the
employee advises the employer of their circumstances.
- Medicare Levy Exemption (MLE) – if the employee meets specific exemption criteria defined by
Services Australia or by their tax residency circumstances, and specific income thresholds, they may
be able to claim a half or full exemption from paying the Medicare Levy. Income levels make the
employee ineligible for Medicare Levy Surcharge however, half exemptions may also be entitled to
further Medicare Levy Reductions. This variation occurs only when the employee advises the
employer of their circumstances by claiming the exemption.
- Medicare Levy Reduction (MLR) – if the employee has combined family income less than income
thresholds specific to the number of dependants (spouse, children), different rates of reduction may
apply. This is available to those who have claimed a half Medicare Levy Exemption but may also apply
to those with an STSL debt to pause their repayments. Income levels make the employee ineligible for
7 | 56
Medicare Levy Surcharge and those who have claimed a Full Medicare Levy Exemption do not qualify
for further reductions. This variation occurs only when the employee advises the employer of their
circumstances by claiming the reduction.
• Field Name Changes – over the years, the ATO has changed the way they refer to some components of
tax but the IT0188 fields had not been updated. The scope of changes to IT0188 warranted a change to
these label names, whilst not changing the technical field codes:
- HECSF HELP/SFSS Contr. is now STSL (HELP/SFSS)
- EXTAX Private Health Insurance Extra Tax Percentage is now Medicare Levy Surcharge
- Tax exemption details is now Tax Reduction Details (screen section heading only)
- MEDEX Med. Levy exemption is now Medicare Levy Reduction
- TAXFI Tax rebate amt is now Tax Offset Amount (drop down field also changed, no longer used)
3.3.2.1.1 Validations
As tax data plays such a critical role in both payroll and STP2, there are extensive validations performed on
the tax data on IT0188, as follows:
• STP2 Transition – the customer STP2 transition date is delivered by SAP to be the default high date
(31.12.9999) in the T5Q_CONSTANTS table, but will, by default, enforce field validations for Income
Type and Country/Region Code from 01.07.2022 for any record that spans that date. It is strongly
recommended that all SAP customers, regardless of any further employer deferrals granted by the ATO,
maintain this data by copy/creating new IT0188 records with the mandatory fields. For those with
exceptional circumstances, in addition to a deferral to a subsequent financial year, IT0188 records would
need to be delimited to the start of the future financial year of deferral to prevent validation enforcement in
the 2022/2023 FY. The impact of validations will still occur for every creation and maintenance record
until the deferred go live year (future-dated records exist). That is significant business impact to avoid
meeting the new ATO requirements and may result in further master data requirements due to the
extended “gap years”. The new data requirements can operate independently of the STP2 solution.
• Default Income Type – feature 13INC allows customers to define the default income type for new
records created in IT0188, typically SAW Salary and Wages, saving keyed entry of data in most
circumstances. Business process work instructions should clearly identify the requirement for those with
income types other than the default income type.
• Permissibility of Tax Scales to Income Types – the ATO has defined a range of permissible income
types for the tax scales and these are enforced in IT0188 fields (TAXSC and INCTY):
Table 1 - Permissibility of Tax Scales to Income Types
Tax Scale Income Types Permissible

0 SAW
1, 1H, 1S SAW, CHP, IAA, FEI
3, 3H, 3S SAW, CHP, IAA
4A SAW, CHP, IAA, FEI
4B SAW, CHP, IAA
8, 9 SAW, CHP, IAA, WHM, FEI
C1, C2 SAW, CHP, FEI
IS, MC, SI SAW, CHP, FEI
SW SWP
T1, T2, TP SAW, CHP, IAA, FEI
W, WN, WU WHM
8 | 56
• Country Codes – only income types WHM, FEI and IAA require mandatory country/region codes, the
other income types are not permitted to have country/region codes. Additionally, for those income types
with mandatory country/region codes, these codes are not foreign countries and therefore not permitted:
- AU Australia
- NF Norfolk Island
- CX Christmas Island
- CC Cocos Islands
- HM Heard and McDonald Islands
As mentioned in the introduction to this section, the tax infotypes differ from all time and payroll infotypes in
that they are only read AS AT PAYMENT DATE . By including the Income Type and Country/Region Codes in
IT0188, for critical business use reasons, there are some impacts, as follows:
• STP2 Transition – the new IT0188 fields should be captured from the first payday in the 2022/2023 FY,
regardless of when the customer transitions to STP2 reporting. As such, new IT0188 records should be
created from 01.07.2022, regardless of the payroll areas, pay period start dates, pay period end dates
and paydays. This is because the ATO define a financial year to be all payments from 01.07 to 30.06 of
the following year. The tax infotypes are only read AS AT PAYDAY , so any payday on or after 01.07.2022
will read the new income type and country/region code fields.
• Ongoing Use – any new key infotype records usually align with pay period start dates, however,
depending on the payday of the payroll area pay periods, this may need to be amended for maintenance
of the tax infotypes (IT0188, 0817, 0227). This is not changed for STP2 but, given the critical reporting
inclusion of the tax data, it is imperative that customers understand the functional use of the data AS AT
PAYMENT DATE :
Table 2 - Ongoing maintenance of tax infotypes (0188, 0817, 0227)
Arrears Pay Arrears

Arrears
Pay for
Pay for PP07
PP06
Pay Period Pay Period Pay Period Payday Pay Period Payday
Start Date End Date Start Date PP06 End Date PP07
PP06 PP06 PP07 PP07
For tax data to apply for PP06, IT0188 IT0188 Tax Else IT0188 data is
record must be created from PPSD-PP07 AU
created for the current
pay period for Paydays
Advance Pay Advance Pay Advance Pay
for PP07 for PP08 within the Pay Period: ≥
PPSD and ≤ PPED
This also applies to IT0227,

Pay Period Payday Pay Period Pay Period Payday Pay Period Pay Period
Start Date PP07 End Date Start Date PP08 End Date Start Date
especially for those with TFN
PP06 PP06 PP07 PP07 PP08 exemption codes, as the ATO
analysis will relate the TFN
IT0188 Tax with Tax Treatment Codes
For tax data to apply for PP07, IT0188
AU
record must be created from PPSD-PP06
• Partial Period Factoring – as the tax infotypes are only read AS AT PAYMENT DATE , there is a one-to-one
relationship between the payment and the Income Type/Country Code to which it will be assigned. If
there is a circumstance where the Income Type/Country Code change is to occur mid-period, these must
be managed via manual overrides, splitting all reportable components (EVCL13 values) by reducing the
Income Type/Country Code that applied as at payday and creating it against the new Income
Type/Country Code that commenced mid-period. This may also require tax adjustments if the changed
Income Type is also associated with a different tax scale. This has always been required, given the
payment date effectiveness of tax data.
• Retroactive Changes – whilst retroactive changes to tax data are permitted to effect genuine errors and
oversights in PAYGW calculations, the Income Type and Country/Region Codes cannot be read into the
payroll for retroactive changes of those specific fields. That is, the storage of these fields in the pay
cluster can only be effected for the In-Period and cannot correct For-Periods impacted by the retroactivity.
This is due to quite complex rules for the payer (ABN/Branch) that enforce In-Period integrity and ignore
9 | 56
retroactive changes for STP reporting purposes only (retroactive changes trigger payroll accounting
changes), whilst recognizing retroactive wage type changes. Two moving parts are accommodated, but
three moving parts cannot be automated. There are two options to address the inevitable occurrence of
late notification of a change in circumstances that would warrant an Income Type/Country Code
retroactive change:
- Overrides – where all wage types impacted (EVCL13 values) within the Income Stream Collection are
reduced from the original Income Type and Country Code and created against the new, retroactive
Income Type and Country Code
- MYGL2 Utility – where the IT0188 record is retroactively changed, impacting the For-Period cluster for
TAXP, but ignored by the For-Period cluster for ACRT/AETP. Run the MYGL2 utility for the impacted
employee that will read master data and update the relevant clusters as if the IT0188 data was
changed in the effective In-Period. This will not address any PAYGW impacts that may be associated
with the change of Income Types/Country Codes (running pay will address tax calculation). This
cannot address any partial period factoring, as explained in the previous dot point. For example, an
employee is SAW and in PP20, advice is received that they are FEI in Belgium (be) from PP18.
IT0188 is retroactively changed and the payroll and pay event are run to show only one period is
assigned to FEI-be. MYGL2 is run (in test, validated, then live) to read master data and assign wage
types accordingly for three periods. The before and after pay events are displayed:
Figure 2 - Pay Event after IT0188 retro change from SAW to FEI-be BEFORE MYGL2
Figure 3 - Pay Event after IT0188 retro change from SAW to FEI-be and AFTER MYGL2
This functionality should be tested as part of the transition to STP2 before using it to solve Production payroll
issues of retroactive changes to Income Types and Country/Region Codes. Security access to MYGL2 may
be a factor for consideration for intended users of this business process.
3.3.2.1.2 Tax Treatment Code
As part of the ATO’s ongoing commitment to streamline reporting obligations for employers, key tax data will
now be reported via the pay event to relieve the employer of their obligation to separately report the TFN
Declaration forms. The employer must still collect TFND forms from employees (if provided) but instead of
sending them to the ATO via paper forms or Online Services for Business (output from the standard SAP
report RPCPBSQ0 Employment Declaration Details to the Australian Taxation Office), they will be included
in every pay event.
Submit actions will read tax data as at payment date.

Update actions will read tax data as at generation run date/time.
The ATO will analyse the relationship between tax data and payment types for submit actions only, as there
may be no relationship between historical payment data and the employee’s current tax data. The Tax
Treatment Code will be derived when the pay event is generated (reading data as at the relevant date). The
enforcement of validation rules for the tax data on the tax infotypes is to prevent error-handling and re-work
10 | 56
at pay event generation. Only permissible tax treatment codes may be reported. SAP has not adopted every
possible tax treatment code, as not every tax scale/option is accommodated:
• RDXXXX – NAT 1024 Tax table for daily and casual workers, as this requires assessment of the number
of shifts worked and extrapolation to weekly amounts
• ADXXXX - NAT 1023 Tax table for actors, variety artists and other entertainers for a specific number of
performances, as above
• VCXXXX/VOXXXX - NAT 3352 Tax table for payments made under voluntary agreements, as SAP does
not support contractors in payroll and the SAP STP2 solution has not been whitelisted for their use.
Figure 4 - SAP STP2 Tax Treatment Framework
NAT 1005/6/7 NAT 1023 NAT 1013 NAT 4466 NAT 75331 QC 25161 ß Common circumstances override other tax categories à
R (Regular) A (Actors) C (Horticulturists S (Seniors & H (Working W (Seasonal Worker F (Foreign N (No TFN) D (ATO-
& Shearers) Pensioners) Holiday Makers) Programme) Resident) Defined)
1 = RN T1 = ANXXXX C1 = CTXXXX IS = SI W = HRXXXX SW = WPXXXX 3 = FF 4A = NAXXXX 8/9 = DVXXXX*

2 = RT T2 = ATXXXX C2 = CFXXXX MC = SM WN = HFXXXX 4B = NFXXXX ETP-DB = DBXXXX
0^ = RT TP = APXXXX SI = SS WU = HUXXXX Logic when ETP-Death

Benefits are paid
1H/1S# = RNS 3H/3S# = FFS * Also influenced by IT0817

If HECSF ¹ [blank],
Income Tax Withholding
2H/2S # = RTS then SIS, SMS, SSS Variation-AU details
EXTAX: Tier 1 = R**1XX If Medicare Levy Surcharge, EXTAX: Tier 1 = S**1XX Char-1/2: Tax Scales
then ineligible for Medicare
EXTAX: Tier 2 = R**2XX Levy Exemption and
EXTAX: Tier 2 = S**2XX Char-3-6: default XXXX but for Regular,
EXTAX: Tier 3 = R**3XX Medicare Levy Reduction EXTAX: Tier 3 = S**3XX
Seniors & Pensioners, Foreign Residents:
If Medicare Levy Exemption Char-3: Tax Scales/HECSF# else X
5= RTXXF Not Available in SAP
Full (tax scale 5/5H/5S), For Regular, Seniors & Pensioners:
5H/5S # = RTSXF then ineligible for Medicare ATO has not released co-
Levy Reduction and efficients for Seniors & Char-4: EXTAX else X
6 = RTXXH Pensioners Medicare Levy For Regular only:
Medicare Levy Surcharge
6H/6S # = RTSXH Exemptions
Char-5: Tax Scales else X
Char-6: MEDEX/NODEP else X
NODEP: 0 = RT*X*0 Medicare Levy Reduction Not Available in SAP
NODEP: 1-9 = RT*X*[1-9]
where 0 = spouse, 1-9 and A # Refers to either/or Tax Scales/HECSF
are the number of
NODEP: ≥ 10 = RT*X*A dependent children * Refers to more than one possible value
^ Used for Exempt Foreign Income only
SAP will use the relevant tax data (update actions) or TAXP (submit actions) to derive the Tax Treatment
Code (function module HR_AU_TAX_TREATMENT_CODE):
Table 3 - Supported Tax Treatment Codes
Tax Tax Scale Description (Char1- STSL MLS (Char4) MLR (Char6) Tax Treatment
Scale 2 or Char3 or Char5) (Char3) Code
0 0 - No Taxation [blank]=X [blank]=X [blank]=X RT**X*
Else = S Else=tier level (1, Else = 0-9, ³10 = A
2, 3)
1 1 - No Tax Free Threshold [blank]=X [blank]=X [blank]=X RN**X*
2, 3)
1H TaxScale1with Accumulated HELP [blank]=X [blank]=X RNS**X*
Else=tier level (1, Else = 0-9, ³10 = A
2, 3)
1S TaxScale1with Accumulated SFSS [blank]=X [blank]=X RNS*X*
2, 3)
2 2 - Tax Free Threshold Claimed [blank]=X [blank]=X [blank]=X RT**X*
2, 3)
2H TaxScale2with Accumulated HELP [blank]=X [blank]=X RTS*X*
2, 3)
2S TaxScale2with Accumulated SFSS [blank]=X [blank]=X RTS*X*
Else = 0-9, ³10 = A
11 | 56
Tax Tax Scale Description (Char1- STSL MLS (Char4) MLR (Char6) Tax Treatment
Scale 2 or Char3 or Char5) (Char3) Code
Else=tier level (1,
2, 3)
3 3 - Non-Residents [blank]=X FF*XXX
Else = S
3H TaxScale3with Accumulated HELP FFSXXX
3S TaxScale3with Accumulated SFSS FFSXXX
4A 4A - No TaxFile No - Residents NAXXXX
4B 4B - No TaxFile No-Nonresident NFXXXX
5 5 - FULL Medicare Levy Claimed [blank]=X RT*XFX
Else = S
5H TaxScale5with Accumulated HELP RTSXFX
5S TaxScale5with Accumulated SFSS RTSXFX
6 6 - Half Medicare Levy Claimed [blank]=X [blank]=X RT*XH*
Else = S Else = 0-9, ³10 = A
6H TaxScale6with Accumulated HELP [blank]=X RTSXH*
Else = 0-9, ³10 = A
6S TaxScale6with Accumulated SFSS [blank]=X RTSXH*
Else = 0-9, ³10 = A
8 8 - Flat Tax Percentage DVXXXX
9 9 - Flat Tax Amount DVXXXX
C1 H & S Resident with TFN CTXXXX
C2 H&S ForeignResident with TFN CFXXXX
IS Senior Aus. Illness separated [blank]=X [blank]=X SI**XX
Else = S Else=tier level (1,
2, 3)
MC Sen. Aus. -Member of a couple [blank]=X [blank]=X SM**XX
2, 3)
NR No Tax Non-Reportable STP
SI Senior Australians – Single [blank]=X [blank]=X SS**XX
2, 3)
SW SW – Seasonal Worker Programme WPXXXX
T1 Actors without tax free thresh ANXXXX
T2 Actors with tax free threshold ATXXXX
TP Actors Promotional Activity APXXXX
W W - Working Holiday Makers HRXXXX
WN Working Holi Makers, No TFN HFXXXX
WU WU - Working Holi Makers Unreg HUXXXX
Where the colours indicate (text shade relates to cell shade):

• Gold – narrowed scope, other circumstances to use other tax scales (NR)
• Green – new tax scales
• Blue – new tax scale to accommodate other circumstances of existing tax scale use (0)
• Grey – option or value not permissible
All other tax scales are deprecated and cannot apply. If the pay event includes historically terminated
employees that have deprecated tax scales, create a new IT0188 record for the current period of the pay
12 | 56
event, managing any impact on their IT0003 Payroll Status (if not included in current FY pay clusters, reset
earliest master data change date).
The ATO has not released any Medicare Levy Exemption coefficients for Seniors & Pensioners and, until
they are available, neither Medicare Levy Exemption or Medicare Levy Reductions are supported for Seniors
& Pensioners. Although not a direct dependency (between MLR and MLE), there is an indirect dependency
(if MLE = F, then MLR cannot apply).
3.3.2.1.3 Country Codes
Country/Region Codes are required for the following Income Types:
• WHM – reflecting the country on their Visa (subclass 417 or 462), known as “home” country
• FEI – reflecting the country they are working in, where they have met the qualification period, where their
income is taxable, known as “host” country
• IAA – reflecting the country continuing to pay the employee, known as “home” country
SAP customers use a range of products, solutions, integrations and interfaces and this data may already be
captured in various systems or may not be captured at all. Customers must resolve the country code for their
specific circumstances. SAP cannot automate a solution for every customer circumstance.
Some new STP2 fields have specific validation rules based upon a fixed date (01.07.2020) determined by
the ATO. Some new fields must have values provided for any prior FY updates for the “gap years” between
01.07.2020 and the financial year of transition to STP2. SAP automates the solution for many of these, but
others require manual intervention, Country/Region Codes is one:
Figure 5 - "Gap Year" requirements for Prior FY Updates
STP Transition FY 1 July 2020 STP2 Transition FY
2
Text Colour Legend: Disaggregation of Gross is possible
for historical years (prior FY update)
User input of master data by reading EVCL13 values as at
Resolved by SAP logic generation date (run date/time)
Resolved by SAP logic (EVCL13
effective date) PAYEVNT.2018 PAYEVNT.2020
ß “GAP YEARS” à
SAW/CHP/IAA/SWP = SAW SAW/CHP/IAA/SWP = SAW Income Type

Where WHM Flag = Y, WHM Where WHM Flag = Y, WHM • New: CHP, IAA, SWP
EVCL13-GF/WF/TF = FEI EVCL13-GF/WF/TF = FEI • Deprecated: JPD
EVCL13-JG/JT/JW = JPD
Not reported IT0006 Addresses-2 Temp. Residence Country Codes
(WHM, FEI only as IAA = SAW) • WHM, FEI, IAA only
Pay/Update Date – 10yrs Pay/Update Date minus 10 years Lump Sum E Financial Year
SAW only SAW only ETPs (per Income Stream Collection)
Cannot be reported Cannot be reported < 01.07.2022 Child Support Deduction
Cannot be reported Cannot be reported < 01.07.2022 Child Support Garnishee
Historical country codes for WHM and FEI is one of the reasons customers should deploy the IT0188
changes from 01.07.2022, regardless of their transition to STP2 financial year, as the longer data
maintenance is delayed, more alternative data is manually required, such as IT0006 Addresses, subtype 2
Temporary Residence for any prior FY updates.
3.3.2.1.4 Downward Variations
Employees can apply to the ATO to request a downward variation on their rate of tax based upon their
personal financial circumstances. This approach takes advantage of known and expected refunds at EOFY
when the employee completes their tax return. Instead of waiting until then, employees may request to
reduce the tax their employer withholds each pay. The ATO has streamlined the process to ensure that
13 | 56
advice is aligned with the STP2 disaggregation of gross approach and to avoid misinterpretation of their
instructions.
There are many components that are taken into consideration for the variation of the employees’ in-service
(not upon termination) tax rates:
• Employee’s Tax Treatment – as per IT0188, these rates are applied to payments generally, with some
exceptions for payments that have a specific tax rate (ATO tax table). In SAP, these are payments
configured with PRCL21-0 Standard Taxation or PRCL21-S Salary Sacrifice.
• Marginally Taxed Payments – these payments are taxed in accordance with NAT 3348 Tax table for
back payments, commissions, bonuses and similar payments. In SAP, these in-service payments are
configured with PRCL21-6 Marginal Tax for Bonuses and Commissions or PRCL21-E Lump Sum E,
using IT0188 to determine the rate of tax to marginalize.
• Special Tax Rates in Service – a specific tax rate applied only to specific payments, such as Lump Sum
W payments. In SAP, this is configured with PRCL21-R Return to Work Payments and only relies on
IT0188 if the employee has failed to provide a TFN or claim an exemption from providing a TFN, where
the IT0188 tax scale (4a or 4b) applies instead. This is not a circumstance that would apply to an
employee applying for a downward variation from the ATO, as that is a prerequisite to the application.
• No Tax – for some concessionally taxed deductible expense allowances that meet the conditions of the
ATO measure (reasonable rate, amount and/or limit, present in an award in effect on 29.10.1986)
The ATO downward variation letter to the employer will specify the type of variation that may apply to the
employee:
• Salary and wages including overtime
• Directors’ Fees
• Bonuses and Commissions
• Allowances (that are taxed, the purpose of the downward variation)
• Termination Payments – unused leave on termination (lump sums and/or paid leave-U) and/or ETPs
• STSL refunds
These may not be mutually exclusive and may include or exclude multiple components. These variations are
complex, so SAP addresses all downward variation options on IT0817 Income Tax Withholding Variation-AU:
Figure 6 - IT0817 Income Tax Withholding Variation-AU
If the downward variation includes salary and wages but does not also include bonuses and commissions,
then the rate/amount of the salary and wages (including overtime) must not be varied on IT0188, as that is
critical for the marginal tax calculation and, instead, IT0817 must be used to specify the rate of variation for
salary and wages.
14 | 56
It is critical that this infotype is used specifically for the circumstances specified, given the use of IT0188 for
the components of pay, specified above. This is due to the Tax Treatment Code mapping for downward
variations, where:
• If IT0188 tax scale is 8 or 9, DVXXXX will be reported to indicate the downward variation. This will apply
the reduced tax rate for all payments configured with PRCL for standard tax, salary sacrifice and
marginally taxed payments (in service)
• If IT0817 Salary & Wages Tax % is not [blank] then DVXXXX will be reported to indicate the downward
variation. This will apply the reduced tax rate for all payments configured with PRCL for standard tax and
salary sacrifice, but will not reduce the tax on payments configured to be marginally taxed in service
For all other downward variations, if it does not also include a downward variation for salary and wages using
the above two methods, then the employee’s IT0188 normal Tax Treatment Code will be reported. For
example: RTXXXX.
Upward variations are not reported as ATO is monitoring only to ensure that minimum obligations are met.
3.3.2.2 Transfer of YTD Amounts

The ATO displays the latest Income Statement for the FY to taxpayers in ATO Online Services, based upon
the payment date (denotes the FY) and the run time/date stamp (latest “as at” date in payroll). It is displayed
as sent (no editing, collation, summary) for each combination of ABN, Branch, BMS Id and Payroll Id. When
any of those key identifiers change, a new Income Statement is displayed.
ABN and Branch have always been the foundation of reporting income to the ATO, however, the move to
digital services and the ATO performing the last step in the process means that decisions by the business to
transfer YTD amounts to different objects such as BMS ID and Payroll ID mean that there are additional
steps to be performed by the business to alert the ATO to these transfers.
Figure 7 - Transfer of YTD Amounts
ATO, as publisher of
Decisions made by the
Income Statements,
entity about their payroll
must be alerted to the
arrangements
transfer of YTD amounts
YTD Amount Australian Government
Taxpayer Income Statements
ABN/Branch ABN/Branch Instance of PY PERNR

Different branch
or ABN^
Pay Event
Instance of Different client or 2 methods to alert the ATO to ABN/Branch Different Payroll PERNR
Payroll/SAP client instance or product transfers of YTD amounts to new
key identifiers:
1. Zero Out
2. Replacement
ABN/Branch Same new PY New PERNR
Personnel Different
Number Personnel Number ^ The only valid circumstance to transfer YTD amounts across ABN/Branches is if the ABN/Branch reported was NOT the payer. If an
entity paid the payee and has reported through STP but subsequently assigns that expense to another entity, then the original entity is
the correct ABN/Br and does not require correction.
There are two options to advise transfer of YTD amounts in SAP via update actions:
1. Zero Out – requires access to the previous identifiers (payroll system and payroll number) and is
commenced prior to the transfer of YTD amounts by generating an update to zero out all financial
amounts from the original identifiers. Then the YTD amounts are transferred to new identifiers, payroll
run, submit action created. However, it requires the use of the new EVCL13 values for wage types to
“offset” the impact of the YTD amounts in the parent totals.
15 | 56
2. Replacement – the previous key identifiers are advised from the new identifiers after the YTD amounts
have been transferred. It is a one-time only update that will enable the ATO to “replace” the identifiers on
the existing Income Statement.
Different methods apply to specific circumstances and, in SAP, may not be used in some other
circumstances. Termination actions/reasons and therefore Cessation Types may also be a consideration
when performing these YTD transfers. Refer to section 3.4.5 Transfer of YTD Amounts.
In addition to the business processes required to be performed by the business, many aspects of the
planning and preparation for transfer of YTD amounts must be taken into consideration:
• Authorisations – ATO Access Manager permissions for the ABN/Branch impacted
• Access and Control – to the legacy payroll solution with the data that contains the original YTD amounts
• Migration – if all historical data for all employees, active, inactive and terminated are migrated to new
solutions
• Record Keeping Obligations – Fair Work require entities to retain access and control of 7 years’ worth
of employee data in accordance with the Fair Work Act and Fair Work Regulations.
• Long Service Leave – some states require the hours per week to be averaged over a number of
historical years and/or the rate of pay to be averaged over a number of historical years to meet the Long
Service Leave obligations of the various states and territories
• Prior FY Updates – if historical data is not migrated to the new system and you later discover that you
need to amend a record, how will it be performed?
• Related Entities – some employees work in more than one related entity on the same payroll within a
financial year. In SAP, the ACRT/AETP keeps that historical payer grouping. If one of those entities is
divested to a new buyer, who controls the remaining employees with historical results in the divested
entity? If an issue is found and corrections or amendments are required, who will perform them?
• Cessation Type – any employee included in the pay event that has a current termination record will
require a corresponding mapping to a Cessation Type. Will the new payroll solution have identical
mappings as the legacy payroll?
• All Employees All the Time – as SAP includes all employees in every pay, regardless of any “payments
subject to withholding”, if you have an extraordinary event that requires the transfer of YTD amounts to a
new PERNR, the old PERNR and its data must be addressed to resolve the issue of duplication
• Control of BMS Id – whilst SAP enables customers to manage their own BMS Id, customers must
understand the implications of transferring YTD amounts where the same amount reported by the
previous BMS Id is now reported by a new BMS Id, impacting not only the employee’s personal tax
matters, but the PAYGW liability of the entity.
When transferring in YTD amounts (to a new BMS ID or PERNR), there are different methods that can be
used to create the YTD amounts:
• Transfer-Specific Wage Types – where transition wage types are configured specifically for the purpose
of bringing in the closing balances from the legacy identifiers. These differ from the payroll wage types
they write to, keeping the amounts discretely identified, whilst updating the reportable production wage
types. These may be configured to be stored in RT/CRT (PRCL3/20/30) that will enable them to be
configured with the new EVCL13 values (P1, P2, P3, P4) that will ensure the parent totals are not
overstating the period amount by including the opening balances.
• Standard Wage Types – where the same wage types used in payroll are used to create opening
balances that just add to the same YTD amounts. This may adversely impact the range of technical SAP
wage types for averaging, taxation, superannuation and other cumulation amounts. If this method is used,
notational wage types should be created to reflect the cumulated totals that will ensure the parent totals
are not overstating the period amount by including the opening balances. If not automated in payroll to
cumulate, but are manually entered via override, if the opening balances are subsequently adjusted, the
parent totals won’t be adjusted accordingly.
There are so many possibilities for transferring YTD amounts across key identifiers that it is not possible to
define them all, however, it is important to note that timing is critical when alerting the ATO to transfers.
16 | 56
3.3.2.3 Death Beneficiaries
When an employee dies, there are a number of urgent and important activities that must occur in payroll to
effectively manage employment obligations, particularly given the sensitivity of the next of kin. Whilst the
process for managing death and death beneficiaries in payroll has not changed in any way for STPs, there
are some specific rules that apply to death beneficiary data:
• Payee Identity – both the deceased employee and their death beneficiary will appear in the pay event
with separate identities, even though the same PERNR is used. The death beneficiary will have:
- Commencement Date – SAP logic will provide the required default date of 01.01.1800, as there isn’t
an employment relationship with this payee
- Cessation Date – SAP logic will provide the same date as the deceased employee, as there isn’t an
employment relationship to cease
- Cessation Type – SAP logic will provide the same type as for the deceased employee (D), as an
employment relationship hasn’t ceased
- Employment Basis – SAP logic will provide the required default type (D), as there isn’t an employment
relationship with this payee
- Tax Treatment Code – SAP logic will provide the required default code (DBXXXX), as there isn’t a tax
scale to apply, as only ETP death beneficiary payments are made with their own, specific tax rate
- Tax Offset Amount – SAP logic will provide the required default value ([blank]), as this doesn’t apply to
death beneficiaries
- Name Details – user input of IT0021/subtype AU01
- Address Details – user input of IT0006/subtype QB/Q1 (depending on feature 13ETP)
- TFN – user input of IT0227/TBFFN (if none provided, same rules apply to tax at highest rate)
• Pay Event – The payee will appear in the three payee layouts:
- Payee – with the data outlined above
- Income Stream Collection – with no financial amounts, except for mandatory fields that will display
zero
- Allowances Other/LSE/ETP – the ETP death benefits paid
This is displayed in the following screen shots using test data where the address is the same as the
deceased employees address:
Figure 8 - Death Beneficiary: Pay Event Payee Layout
Figure 9 - Death Beneficiary: Pay Event Income Stream Collection Layout
17 | 56
Figure 10 - Death Beneficiary: Pay Event Allowances-Other/LSE/ETP
Refer to section Error! Reference source not found. Error! Reference source not found.
3.3.3 Tables, Structures, Programs and Utilities

Extensive changes have been made to various tables, structures, programs and utilities to support the STP2
reporting requirements. These are outlined in the following sections.
3.3.3.1 Payroll Cluster

Key changes have been made to several tables in the pay cluster to accommodate the STP2 reporting
requirements to report disaggregated Income Stream Collections.
3.3.3.1.1 TAXP Tax Table
The tax infotype changes impact the TAXP table in the cluster by:
• Including the new Income Type and Country/Region Codes from IT0188
• As the infotype is only read as at payment date, there will be no splits: only one income type and
country/region code will be stored per pay period
• Reflecting any retrospective changes to Income Type and Country/Region Codes from IT0188 in For-
Period tables
Figure 11 – Cluster Table: TAXP
3.3.3.1.2 SABN ABN Table

As STP requires the reporting of payments by payer, defined in SAP via T5QGP for each Personnel Area
and Personnel Subarea, this data is stored in SABN. As the rules of STP are to report the employer that
actually paid the income, regardless of if it is subsequently corrected to be another employer, all payments
are assigned to the ABN/Branch of the In-Period, ignoring For-Period reallocations.
In the initial phase of STP, the payer was defined by the ATO to be “as at payday”. The
years of STP2 design provided opportunities to further explore what the ATO meant by this
definition and, with the STP2 solution, this has been clarified to actually mean “pay period
end date”.
There is an indicator in SABN that identifies if the table was created via the payroll ([blank]) or via the
MYGL/2 utility (Y).
18 | 56
Figure 12 - Payroll Cluster: SABN
The change to the approach to payer at pay period end date applies to payroll clusters
created through running the pay but will not be adopted when MYGL2 utility is run.
Figure 13 - SABN approach to assigning payer
Advanced Payday
Within Period
Payday Payer defined as last
Arrears Payday day in period (ongoing =
PPED; terminated = last
active day of service)
WPBP Split
Splits
Payroll Cluster
Split Pay Period

End Date
Pre-DME Payroll cluster split is where the personnel
RPCDTAQ0 Feature Status action in T530 has Accounting split = “X”
that creates a separate pay result. Used for
DTAKT Active/Inactive change of employer.
If the action does not have the accounting
Note: this is ongoing behaviour, but Withdrawn split set to “X”, then change of employer is a
WPBP split only (single pay result) and only
will not apply to MYGL2 for transition one payer is identified.
of existing clusters in the FY
3.3.3.1.3 ACRT STP Cumulated Results Table

This table is based upon the CRT, TAXP and SABN tables, storing wage type results by ABN, Branch,
Income Type and Country/Region Code. The WHM Flag is for pre-STP2 results and will be [blank] for STP2
results.
Figure 14 - Payroll Cluster: ACRT
It stores the full financial year of results for all groupings of these key fields. That is, as a payer is changed,
new entries for wage types for the new payer are created. For every change in the key fields, new wage type
amounts are cumulated.
19 | 56
Figure 15 - ACRT groupings of wage types by ABN/Branch/Income Type/Country-Region Code/WHM Flag [blank]
Current Pay Period PP01 PP02 PP03 PP04 PP05
Same Payee
Current Payer 14088411787-001 16000023656-001 17088268884-001 19087046080-001 62483468038-001
14088411787-001 16000023656-001 17088268884-001 19087046080-001
14088411787-001 16000023656-001 17088268884-001
When the pay results for period 05 are

generated, there will be 5 groupings of 14088411787-001 16000023656-001
Historical Payers ABN/Branch, but may have more
groupings for each occurrence of Income
Type and Country/Region Codes for the 14088411787-001
wage types created.
3.3.3.1.4 AETP – STP Employment Termination Payments

This table is based upon the CRT, TAXP and SABN tables for wage types configured with EVCL13 values
defined in T5QPC, defining the ETP Code. It stores wage type results by ABN, Branch, Income Type,
Country/Region Code, WHM Flag ([blank] for STP2) and by ETP Code and Payment Date.
Figure 16 - Payroll Cluster: AETP Table
When overpayments are corrected, this table will show negative values, grouped by the Payment Date of the
correction pay period. However, this will error when the pay event is generated, as ETP amounts can only be
zero or positive amounts. Manual overrides are required to add the recovery amounts back to the correction
Payment Date and take them off the original Payment Date that was overpaid.
3.3.3.2 STP Overrides (RPCSTOQ0)

Overrides are required to record adjustments to the YTD amounts for STP/STP2 reporting. The same table
has been used for both phases, modified to add in new fields in STP2 (Income Type, Country/Region Code
and LSE FY) and to limit the use of fields that only relate to STP (WHM Flag). T5Q_CONSTANTS defines
the basis of the validation.
Saved entries cannot be modified, but can be excluded using the Exclude wage type checkbox option. Use
of this table is dependent on the configuration of the sequence numbers for overrides.
The override program is RPCSTOQ0, transaction PC00_M13_STP_OVR - Maintain Override Entries
Manually.
20 | 56
Figure 17 - T5QSO STP Overrides modified for STP/STP2 use
If STP year is:

• < FY of T5Q_CONSTANTS, then
WHM Flag is required.
• ³ FY of T5Q_CONSTANTS, then
WHM Flag cannot be provided
If Income Type = FEI or WHM and

STP year is:
• < 2021, then Country Code is not
required
• ³ 2021 but < T5Q_CONSTANTS
FY (aka “Gap Years”), then
IT0006-2 Temporary Residence is
required for Country Code
• ³ T5Q_CONSTANTS FY, then
IT0188 Country Code required
If prior FY update of a pay event that

includes existing LSE and STP year
is:
• < FY of T5Q_CONSTANTS, then
SAP logic in pay event will create
generic LSE FY for pay/update
date minus 10 years
• ³ FY of T5Q_CONSTANTS, then
MYGL2 utility will create /LME by
FY (exclusive WT use)
There is also functionality to maintain the override table via an upload file. This override file upload is
program RPUSTOQ0, transaction PC00_M13_STP_OVR_UPL - Maintain Override Entries through File. It
requires a tab-delimited text file with columns of data, no headers, as follows:
• PERNR
• ABN
• Branch
• WHM Flag (pre-STP2 only, not permitted for STP2)
• Wage Type
• Amount of adjustment (does not replace YTD amount, is included in sum of WTs with EVCL13 values)
• ETP Payment Date (optional, only for adjustments to ETPs, else [blank])
• Description of override (optional but strongly recommended to provide audit trail, else [blank])
• Income Type (STP2 only, not permitted for pre-STP2, else [blank])
• Country/Region Code (STP2 only for INCTY FEI, WHM, IAA, not permitted for pre-STP2, else [blank])
• Lump Sum E financial year (STP2 for up to 10 historical years, but can also be provided for prior FY
updates for pre-STP2 finalized data, else, if LSE overrides already exist for FY being updated (pre-STP2)
SAP logic in the pay event will show LSE FY of generation date (run date/time stamp) minus 10 years.
Else [blank].
The file upload allows for a test of the file format and data and will display the output for final user review.
Data is presented in a different sequence to the file upload sequence:
21 | 56
Figure 18 - Override File Upload Test Output
3.3.3.3 Wage Types

It is critical that all wage types that are assessable income must be reported to the ATO. Generally,
payments to employees are reportable EXCEPT for:
• Reimbursements – ATO define this as a compensation to pay back the employee for expending monies
on behalf of the business, for an exact amount, verifiable by receipt. This transfers the expense to the
business and is not reportable income of the employee.
• Overtime Meal Allowances that do not exceed the ATO reasonable amount – each year, the ATO
publishes a Tax Determination that specifies the reasonable amount expended on a meal for working
overtime in accordance with an award. If the amount paid does not exceed this amount, the payment is
not reportable.
• Travel Allowances that do not exceed the ATO reasonable amount – each year, the ATO publishes a
Tax Determination that specifies reasonable amounts per annual salary bracket, location, expense item.
This includes domestic locations, accommodation, breakfast, lunch, dinner and incidental expenses. It
also includes overseas locations, breakfast, lunch, dinner and incidentals but excludes accommodation. If
the travel allowances paid meet this extensive array of conditions for travel that requires the employee to
sleep away from their home, the payment is not reportable.
• Fringe Benefits – if there are payments made to employees that fit within the ATO’s definition of non-
reportable fringe benefits, the payment is not reportable. This does not include salary sacrifice amounts.
Customers should ensure that they report assessable income. Revised EVCL13 values have been delivered
as part of the STP2 solution.
Refer to Error! Reference source not found. Error! Reference source not found.
SAP has modified some existing model wage types for STP2:
Table 4 - Changes to Existing SAP Model Wage Types
Wage Description EVCL13 to EVCL13 PRCL & Cum

Type 30.06.2022 from Class
01.07.2022
ACAR Car Allow No Measure CA OC
AOTH Travel - Part Day OT ON
ATRA Awd Trans Alw<ATO NT/NS TR
ATVL Travel Allow <ATO NT/NS
E002 Car Allow No Measure OT OC
22 | 56
01.07.2022
G001 C/Km <ATO >5000 Bus Car CA CK
G002 C/Km <ATO <5000 Bus Car CA CK
G011 First Aid Allowance G1 AK

G021 Telephone Allowance OT AT
H011 OT Meal Allow>ATO NT/SG MA
H012 Uniform Allow OT OU
H021 Industry Allowance G1 AK
H022 Tool Allowance G1 AT
H023 Travel Allow >ATO TA

M106 Higher Duty Allowance G1 AK
PS02 First Aid Allowance (A) G1 AK
PS03 First Aid Allowance (B) G1 AK
PS04 First Aid Allowance (C) G1 AK
PS07 Dept. Liaison Officer Al G1 AK

F651 W/Comp - Recoverable G1 PW
F895 Defence Reserve Lve FP G1 PO
PPLV Govt Paid Parental Leave G1 PP
F101 Overtime @ 0.5 G1 OV

G031 Bonus G1 BC
G032 Commission G1 BC
GDIR Director’s Fee G1 DF
MRTW Return to Work Payment G1 GW

J056 SS - Super Non-SGC QAAV G1 SS
J057 SS - Super Non-SGC QASS G1 SS
J058 SS - Super Non-SGC QSSS G1 SS
J059 SS - Super Non-SGC QSAV G1 SS
E012 SS Motor Vehicle G1 SO PRCL 21 - S
J801 Child Support CS PRCL 64 - 1
J901 CS Garnishee CG
I041 Term-AL Ent >93 (T) Marg G1 PU
I043 Term-AL Acc >93 (T) Marg G1 PU
23 | 56
01.07.2022
E011 SS Super - Voluntary G1 SS PRCL 21 – S
Cum 41 [blank]
Cum 42 [blank]
Cum 72 [blank]
F501 Annual Leave G1 PO
F652 W/Comp - Non-Recoverable G1 PW
F701 Long Service Leave G1 PO
F801 Compassionate Leave G1 PO
F802 Bereavement Leave G1 PO
F810 Jury Duty G1 PA

F815 Study Leave G1 PO
F820 Maternity Leave Paid G1 PP
F910 Unpaid Leave G1 PO
F920 Maternity Leave Unpaid G1 PP
F990 Purchase Absence Payment G1 PO
Customers should compare and adjust changes from client 000 to all relevant clients and systems.
SAP has also provided some new model wage types to address the separately itemized allowances,
however, customers should assess their compliance requirements against the default delivered configuration
of these model wage types:
Table 5 - SAP New Model Wage Types
Wage Description EVCL13 to EVCL13 from

Type 30.06.2022 01.07.2022
G003 C/Km Bus Other Vehicle SG OT OC
G004 C/Km Private Car TX/SG OT ON
GQCT Liquor Licence TX/SG OT AQ
GCWK Cold Work Allowance G1 AK
G005 C/Km<ATO<5000 Private Car CA OC

GNAT Non-Award Transport Pymt OT OF
GLAU Laundry Allow<ATO Uniform LA
GLAC Laundry Allow<ATO Clthg OT OG
GTRV Travel allow > ATO TA
GNBN NBN Allowance OT OH
GPTF Public Trans Fares Allow OT OF
PRGA Parent Gross Adjustment P1^
PRGW Parent PAYGW Adjustment P2^
PCGA Parent CS Garnishee Adj. P3^
PCDA Parent CS Deduction Adj. P4^
F896 Emergency Services Lve FP G1 PA
F510 Annual Leave Cashout G1 PC
24 | 56
Wage Description EVCL13 to EVCL13 from
Type 30.06.2022 01.07.2022
F057 RDO – cashout G1 PC
G033 Bonus on overtime G1 OV
G034 Commission on overtime G1 OV
J502 Dedn - Workplace Giving WG
^ Parent adjustment model wage types can only be used with effective date ³ 01.07.2022 for STP2 only.
Customers should revisit their wage types for the extensive detailed requirements for PAYGW,
superannuation guarantee and STP2 reporting. Allowances, particularly all-purpose allowances, must be
separately itemized as follows:
• In-Service Payments – payments for the employment period, EXCEPT for the following items:
- Cashout of Leave in Service – as this is like a “bonus” and is reported as the total amount, allowance
components are not to be separately itemized and is reported in STP2 as either Overtime (EVCL13-
OV) for cashout of TOIL in service or as Paid Leave-C (cashout of leave in service) (EVCL13-PC)
- Overtime – as this payment is to remunerate the employee for working outside ordinary hours, any
loaded rates such as casual loadings or all-purpose allowances that form the hourly rate to calculate
the overtime at penalty rates is reported in STP2 as Overtime (EVCL13-OV)
• Termination Payments – payments made as a consequence of employment upon termination, such as
for the following items:
- Unused Leave on Termination – whether as a lump sum (A, B) or as paid leave (U) unused leave on
termination
- ETPs – as the payment is comprised of many components, all classified as an ETP, not to separately
itemize allowances or any other components
Figure 19 - Context of Wage Types Required for Disaggregation of Gross
Changed
Industrial
01/07 Instruments
Industrial
Instruments
* New *
Wage Types EVCL13 values Pay Event Fields
Wage Types EVCL13 values Pay Event Fields
• Identify and examine your industrial instruments as • When you do transition to STP2, you need only
the source of requirements for your wage types change the EVCL13 values of the new wage types
for the new/changed Pay Event fields
• Read the clauses to understand the circumstances
and conditions of payment • STP2 reports YTD amounts: the full financial year of
amounts against the new wage types are required to
• Review your tax, super, STP2 and other obligations be “true and correct”
• Create new wage types for the start of the FY • Avoid the complexity of forced retro: be ready for FY
The impact of getting ready for STP2 does not just involve the simple creation of a wage type, but is more
complex within the business to meet all of the complex and extensive employment obligations:
25 | 56
Figure 20 - Wage Type Readiness
Industrial Circumstances Current Wage New Wage Types

Instruments and Conditions Types Required
Communication Data Input or Valuation PAYGW S&W, OTE, Pay Slips Accounting Target
to employees Capture Bases Superable for Payroll Systems
and business
• Fair Work obligations are complex • Configuration of all other obligations

• Ensuring that you continue to meet those • Data input and capture of the new wage types
obligations when separately identifying the • Financial requirements such as postings,
components of pay is vital provisions may need to be changed
• Associated impacts of separating wage types into • Downstream systems that are a target for key
their components may impact significant areas of payroll data may be impacted
the business
3.3.3.4 Mid-Year Go Live Utility

SAP provides a utility to assist customers to transition between “approved forms” when the new solution is
deployed for a pay period other than at the start of the financial year. This utility functions by:
• Modifying - existing payroll clusters for specific tables only, by inserting new data, sourced from master
data and configuration, into the existing tables to support the new reporting requirements. New data
sourced from: IT0001, IT0188, T5QGP. Tables impacted are: SABN, TAXP, ACRT, AETP. This occurs as
a pre-requisite to operationally transacting with the new solution: the first step before running pay with the
new solution.
• Correcting – when a configuration or technical error has occurred that corrupted the STP-relevant tables
in the payroll cluster and the tables must be restored to the intended design and function.
• Streamlining – where retrospective changes to Income Type and Country/Region Codes have occurred
that are ignored, as intended, by the payroll schema, as an alternative business process to the manual
overrides required to correct the Income Stream Collection amounts.
• Reallocating – where retrospective payments (For-Period) are paid that are greater than 12 months from
the payment date (In-Period) that have created entries in the payroll cluster PASUM table that are, at the
EOFY, ³ the Lump Sum E threshold ($1,200), the utility will create an override upload file to reverse the
amounts from the relevant STP2 payment types and create the amounts per Lump Sum E financial year.
The utility may be run numerous times and is not limited, as per the initial phase of STP, to one-time-only
use. It is a new utility specifically for STP2, however, the original MYGL utility (transaction:
PC00_M13_CLST_MYGL) has been modified to ensure Lump Sum E override upload file is in the format of
the modified T5QSO table format, to accommodate different transition approaches.
The utility will NOT address the following transition issues:
• Wage Types – existing wage types only will be impacted by the different grouping requirements (ABN,
Branch, Income Type, Country/Region Code, WHM Flag) in the cluster and does not transform
aggregated data to disaggregated data. That is a customer responsibility, addressed as per section
3.3.3.3 Wage Types.
• Change of Payer – the change in approach to determine the correct payer from the initial phase of STP
(as at payment date), to the STP2 approach (as at pay period end date/payroll cluster split) cannot be
retrospectively addressed for the pay periods already completed in the financial year of transition, as per
section 3.3.3.1.2 SABN ABN Table.
• Overrides – it only considers the payroll cluster and does not include or address any T5QSO entries
26 | 56
A range of technical options are provided to enable users to run it in test mode, in background, to enable
currency to be filled via XDECI and to download the output for Lump Sum E upload files.
Figure 21 - PC00_M13_CLST_MYGL2 - Migration Utility for STP Phase 2 Go-live
3.3.3.4.1 Lump Sum E
The ATO requirements for Lump Sum E are complex and STP2 has introduced an additional requirement to
report Lump Sum E amounts by Financial Year, where the FY represents the For-Periods when the
payments were payable. This will relieve the burden on employers to manually produce letters to their
employees with Lump Sum E amounts, identifying the amounts per FY. In SAP, this will be performed at
EOFY only, as it is only required upon finalisation for income tax return purposes.
ATO provided extensive and detailed requirements for DSPs for Lump Sum E amounts but, unlike some
payroll products, no changes were necessary in SAP to meet those requirements, as the detailed
transactions and constant retrospective changes, both positive and negative, were already catered for in the
payroll cluster PASUM table.
27 | 56
Whilst the ATO STP2 requirements provided DSPs with two options for reporting Lump Sum E amounts (per
pay or EOFY), the EOFY approach is the method selected for the SAP STP2 solution. This is particularly
relevant for the customer volume and range of retroactive changes and is the least impact on business
processes for validation and reconciliation.
Figure 22 - EOFY Lump Sum E
PASUM
Pay Calculation Criteria for Stored as Potential EOFY: MYGL2 utility reads Creates Override Lump Sum E
Consideration Lump Sum E PASUM to assess if Lump Upload File included in Pay
Sum E conditions met Event, other
Payment Types
reduced
CRITERIA ASSESSMENT TIMING

• If For-Period payment date is > • Per ABN/Br, å WTs ³ $1,200 LSE threshold • On or before finalisation
12 months from In-Period
• å per financial year using For-Period to determine FY • EOFY only
payment date
• Reverse entries per ABN, Branch, Income Type, • Government needs to
• If For-Period amount difference
Country Code, WT EVCL13 value understand nature of
• If WT has relevant EVCL13 payments made each
• Create LSE per ABN/Br Income Type/Country Code
value (payment types only) pay, LSE only at EOFY
per financial year
3.3.3.5 Pay Event Generation

The STP2 pay event has been delivered as a new program/transaction from the initial phase of STP, as the
data structure, validation rules and logic are significantly different between the phases.
• Program - RPCST2Q0
• Transaction - PC00_M13_STP2_GEN - Single Touch Payroll - Phase 2 -> Generate Reporting Data
This program is used to create the PAYEVNT.2020 output data for both the submit and update actions. It is
one of the key outputs of payroll and represents a key employment obligation that is subject to a range of
penalties, including, but not limited to:
• Failure to Lodge (FTL) - if a submit action is not successfully sent for each payroll cluster that includes
payments subject to withholding. This is a sliding scale penalty that increases for each period of 28 days
delay in lodging.
• False or Misleading Statements – if the data you report is not “true and correct”, subject to a range of
factors that may mitigate the amount of the penalty
There are adverse impacts on other government agencies that use this data to administer their programmes.
As such, it is critical that customers understand their obligations and ensure robust governance over their
employment obligations.
New functionality of the STP2 pay event is as follows:
• Employees Read – both actions (submit and update) will now read employees that have a pay cluster in
the financial year and/or those with an override entry in T5QSO. This addresses the gap between the
Payment Summary functionality and the initial phase of STP.
• Test Data saved to Tables – the user has the option to save the test data to the database (STP2 tables:
T5Q_STP2_ER; T5Q_STP2_EE; T5Q_STP2_PAY; T5Q_STP2_LOG) to support extensive reporting of
the preliminary files and to restore the option to enforce live file only after exit (feature: 13STP).
• Save to File – the user has the option to save the output data as a local (PC) Excel file or to an
application server as part of the generation of the output by specifying path details.
• Replace Key Identifiers – one of the two options to alert the ATO to the transfer of YTD amounts is to
replace the key identifiers via a one-time update. This is performed after the first submit has been
successfully sent. The user can enter the previous BMS Id directly into the selection screen and nominate
an upload file (New [existing] PERNR à old [previous] PERNR) for previous Payroll Ids.
28 | 56
Figure 23 - STP2 Pay Event (RPCST2Q0 - Transaction PC00_M13_STP2_GEN)
Only appears
when Update
action selected
If selected, data will be saved in:

T5Q_STP2_ER
T5Q_STP2_EE
T5Q_STP2_PAY
T5Q_STP2_LOG
When the pay event selection screen pay period is entered, which employees and pay period is selected is
dependent on the following factors:
• Submit – regular pay periods and off cycle payment type/payment id/payment dates will select all
employees for the period based upon the entry details, unless the user excludes employees (not
recommended)
• Update – will select all employees in the last completed pay cluster for the financial year of the pay period
(regular) or payment type/payment id/payment dates (off cycle) entered. It will not read regular pay period
results where the control record has not been exited or maintained with integrity (release à exit), reading
T569U control record log. Other than for EOFY finalization, employees are typically specifically selected.
29 | 56
3.3.3.5.1 Pay Event Layouts
The following sections outline key details about how the pay event data is presented to users. There are 4
layouts displayed:
1. Payer
2. Payee
3. Income Stream Collection
4. Allowances Other/LSE/ETP
Figure 24 - Pay Event Overview
Parent
If the Sending Party is

not the Reporting Party
BMS Id Payer Details Payer Payroll Payer Period Payer Intermediary Intermediary
Details Totals Declaration Details Declaration
• Reporting Party • Payroll • Payer • Reporting • Intermediary

• Previous Identifiers Period Party • Intermediary Electronic
• Payer Name Totals Declaration Contact
• Payer Electronic Contact • Intermediary Declaration
• Payer Postal Address
Child Income Stream Collection Other Components
Payee Details Employment Payee Pay Income Type Country Code Payment Types Deductions Super Reportable
* * Conditions Period Details Entitlements Fringe Benefits
• Payee Identifiers • Period Start • Income Stream Type Code • Country Code • Deduction Items
• Previous Payee Identifiers Date • PAYGW • Foreign Tax Paid • Super Entitlement Year To Date
• Payee Name Details • Period End • Exempt Foreign Income • Reportable Fringe Benefits Amount
• Payee Demographic Date • Gross • Paid Leave • Allowance Items
Details • Final Event • Overtime • Bonuses and Commissions
Address Details
*
• Indicator • Directors’ Fees • Salary Sacrifice Submit: as at Pay/Update Date
• Electronic Contact • Lump Sum Payments •Termination Payments Update: as at Run Date/Time Stamp
• Employment Conditions
Details of these layouts are as follows:

• Payer – all ABN/Branches in ACRT/AETP and T5QSO for employees in the report selection will be
included, as per Figure 15 - ACRT groupings of wage types by ABN/Branch/Income Type/Country-Region
Code/WHM Flag [blank], except for any ABN/Br used only for Income Type EXC for income that is
excluded from STP2 reporting.
- Will randomly select an entry in T5QGP as at Pay/Update Date that has the same ABN/Branch
number as that sourced in the pay results/T5QSO. If one record differs from the others, it may be
selected to retrieve the data to report to the ATO. Uniformity of T5QGP records is essential.
- If T5QGP entry selected includes intermediary details, they are displayed
- Payer contact details (only) for prior FY updates will now (changed for STP2) read the T5QGP details
as at run date/time stamp to ensure the current contact details are included for prior FY amendments.
All other prior FY update T5QGP data will be read as at payment date
- Update actions will not include any Parent Period Total Amounts
- Submit parent period totals are calculated as current In-Period YTD amount less prior period (in same
FY) YTD amount. This is to cater for the complexity of moves between payers and payroll areas.
- Parent Period Gross Total does not include 3 payment types: Exempt Foreign Income, Lump Sum D
and Tax-Free Component of ETPs as these are exempt income, as per ATO requirements.
- Parent Period Totals do not include override amounts, except for EVCL13-P1, P2, P3, P4 to ensure
transferred YTD amounts are not overstated
- Layout will display all possible STP2 fields, even if they are not offered in SAP’s STP2 solution or not
included in the customer-specific solution, such as Withholding Payer Number (WPN); Full File
Replacement Indicator will always be FALSE; Previous BMS Identifier.
- Data saved in the T5Q_STP2_ER table for live and optionally for test files
30 | 56
Figure 25 - Pay Event Parent Layout
• Payee – will select payee details (non-financial) as at pay period end date of period selected for submit
actions and run date/time stamp for update actions.
- Will also include Other Components (deduction items, super entitlements, RFBA), as these amounts
do not form part of the Income Stream Collection and are, instead, reported for the payee, regardless
of income types and country codes
- Payee details (identity, TFN) will be selected as at pay/update date for submit actions and run
date/time stamp for update actions
- Data saved in the T5Q_STP2_EE table for employee data, T5Q_STP2_PAY table for the financial
components for live and optionally for test files
Figure 26 - Pay Event Payee Layout
• Income Stream Collection – will select all wage types in ACRT/T5QSO that have EVCL13 values that
are mapped to these payment types. Pay event fields are represented as columns and different income
type/country code combinations will be represented as separate rows. All possible fields will be displayed,
regardless of if they are delivered in SAP or in the customer-specific solution.
- It excludes those fields that are reported as tuples (further fields within fields), as these are displayed
as Allowances Other/LSE/ETP.
- Data saved in the T5Q_STP2_PAY table for live and optionally for test files
Figure 27 - Pay Event Income Stream Collection Layout
31 | 56
• Allowances Other/LSE/ETP – will select all wage types in ACRT/AETP/T5QSO that have EVCL13
values for government policy wage types (OT Allowances – Other), lump sum E (GE Gross Payment
Type E) and ETPs (extensive array of EVCL13 values).
- This data is presented separately as there is more than one associated field value that will be
displayed as rows rather than as columns.
- Data saved in the T5Q_STP2_PAY table for live and optionally for test files
Figure 28 - Pay Event Allowances Other/LSE/ETP Layout
3.3.3.5.2 Pay Event Logs

There are extensive and detailed ATO-specified field validations, character restrictions, field length
constraints, time constraints and interdependencies between field values. These have been detailed in DSP-
specific documents that SAP has enforced and been whitelisted for, after successfully completing a range of
mandatory tests for ATO review against requirements.
These validations may be visible to end users in the pay event logs where warnings and errors are listed to
identify the requirement that has failed the validation requirement. The details of the warnings and errors are
specified in the layout of the logs, that identify which layout, payer/payee/field is identified as an exception
and the Message Text provides sufficient detail to support using the output to create an override upload file,
if required. It cannot specify specific wage types, as the EVCL13 value is mapped to the pay event field.
Figure 29 - Pay Event Log: Payee-specific warnings and errors
Figure 30 - Pay Event Log - Foreign Tax Paid enforcement
32 | 56
Figure 31 - Pay Event Payee Layout showing "space" replacing invalid characters
If valid payee-details data exceeds the field length constraints of the pay event (limited fields only), data will
be reported but a warning is issued in the log to identify that the value has been truncated. This only applies
to fields where the employer does not usually have control and maintenance, such as for payee address,
where data is modified only to enforce ATO requirements rather than erroring, possibly preventing customers
from meeting their legal obligations due to employee-maintained data. Every modification is fully transparent
in the log.
It is strongly recommended that customers create a Pay Event error handling log to record the types of
warnings and errors experienced and identify the root cause and the solution. This will assist in governance
over the process that has a tight timeframe to resolve.
3.3.3.5.2.1 Key Pay Event Field Details:
The following points highlight some key issues to note about pay event fields:
• Submission Id – unique submission id is created for the payer data, grouped for each occurrence of
ABN, Branch, Payroll Area, Payment Date and the sequence numbers as per section Error! Reference
source not found. Error! Reference source not found.:
Figure 32 - Structure of the unique Submission ID
ABN Branch 3- Pay/Update

char Date 8-char
Submit action
Sequence
Number 8-char
UU to indicate
Update action
2-char;
Sequence
Number 6-char
ABN 11-char Payroll Area
Or WPN 2-char
• Employment Basis Code – this field is derived using the existing feature 13DEG that has been used for
the standard SAP report for the TFN Declaration forms (RPCPBSQ0 Employment Declaration Details to
the Australian Taxation Office). This addresses the full-time (F), part-time (P) and casual (C) bases. SAP
logic addresses the deceased (D) basis code, customers need not do anything other than maintain
relevant master data for death beneficiaries. Values L, V and N are Error! Reference source not found..
• Included Employees – as mentioned at the start of section 3.3.3.5 Pay Event Generation, employees
without a pay cluster can be included in the pay event with STP2 when overrides exist. This is typically
relevant for:
- RFBA – when terminated employees who have no payroll cluster for the current FY have reportable
fringe benefits amounts for that part of the FBT year that is in last financial year: from 1 Apr to 30 Jun
33 | 56
Figure 33 - Inclusion of employees without a payroll cluster
FBT Year
Prior Financial Year Prior Financial Year Current Financial Year
Fringe Benefits Tax year is 1 Apr – 31 Mar

ACRT
Income Tax financial year is 1 Jul – 30 Jun T5QSO
An employee may have FBT 1 Apr – 30 Jun and terminate within that
period, thus is not included in the subsequent financial year pay
results.
The STP2 Pay Event will include all those who have an ACRT amount
for WTs with relevant EVCL13 values and/or T5QSO entries. If an
employee was historically terminated and has no current FY ACRT, STP2 Pay
they will be included if there is a T5QSO Override entry for the FY. Event
• Excluded Pay Results – as mentioned in section 3.3.2 Data Requirements, a new Income Type has
been created to enable customers to manage specific scenarios:
Figure 34 - Income excluded from STP2
Tax Scale NR – Income Type EXC
FEI for Foreign Tax Residents Exempt Seasonal Worker

Programme employees
May have partial financial year Workers whose income is not
reportable income as an Australian “salary and wages” and therefore
Tax Resident (standard tax) Those SWP employees who meet
before/after becoming a Foreign the criteria to be exempt from not in scope of STP, such as:
Tax Resident (not taxed in AU). PAYGW. Due to programme and Visa § INB-Pensions
Need to segregate FTR from ATR changes from government policy § Partner disbursements
income to ensure only ATR income changes, these circumstances are
is included in the Pay Event. currently being defined by the ATO.
• Replacement Key Identifiers – can only be reported via a one-time only update action that will alert the
ATO to “mask” the previous key identifiers with the current key identifiers.
• Cessation – current withdrawn status only will be included in the pay event, read up to pay period end
date (PPED) plus 1 day, to ensure data for those terminated on the last day of the period is included in
the report.
• Tax Offset Amount – unlike almost all other pay event financial amounts that report YTD amounts, the
tax offset amount is the amount entered in IT0188 and it will be reported each pay until or unless the data
is maintained. Tax data is read as at payday only.
• Foreign Tax Paid – the ATO has tightened the reporting rules in STP2, although the validations were
already in place in SAP. For an amount to be reported as FEI, the employee will/must have satisfied the
qualification period (duration in that foreign country) and the income is taxable in that country. The payer
is obliged to report the value of their liability to the foreign country, even if it is not paid until a subsequent
financial year. An amount can be estimated each pay, or zero can be reported until the actual amount is
known. However, ATO requires the PAYGW amount to reflect the Australian withholding amount less the
foreign tax paid/payable. If zero is reported for Foreign Tax Paid, the full value of the PAYGW must be
34 | 56
paid to the ATO. When the Foreign Tax Paid amount is corrected to show the actual payable amount in
the FY, the PAYGW may be offset. Tax amounts (PAYGW, Foreign Tax Paid) must be whole dollars only.
• Exempt Foreign Income – IT0188 tax scale 0 has been repurposed for the exclusive use of those with
Exempt Foreign Income, however overrides are required, as the gross income must be reported as the
post-sacrificed amount and no separately itemized salary sacrifice amounts must be reported.
• Allowance Items – these are the most complex requirements of STP2, as the complexity of the Fair
Work obligations to separately itemize components of pay on the payslip married with the PAYGW,
superannuation guarantee and STP2 reporting requirements have to be accurate for Services Australia’s
use of data. The detail required to assess allowances for this purpose is dependent on the circumstances
and conditions in the industrial instrument compared against the specific and limited conditions for tax
concessions and the income classification for the purposes of assessing super liability. Not only is this
complex to assess compliance for Fair Work, PAYGW, Superannuation Guarantee, STP2 reporting and
Services Australia’s purposes, but will impact employees Income Tax Returns and the visibility by ATO of
what is deductible and what substantiation evidence is required. Seek qualified, experienced and skilled
assistance to ensure these complex and high-impact payments are correctly treated.
• Other Allowances – the way other allowances must be reported in STP has changed for STP2. Those
allowances that do not have a specific allowance type are to be reported using the category of other
allowance, rather than the 25-char text description of the wage type. That has been addressed by using
the EVCL13 value description in the Other Allowance Description field. The only allowances to be
reported as OT Other Allowances are those specifically nominated by government policy, such as for
JobKeeper, JobMaker etc.
• Salary Sacrifice – SAP uses the top-down method of salary sacrificing, where the value of the sacrificed
amounts is negative. RESC is generated by a super deduction wage type from T5QSF for the fund
assigned to the employee, using PRCL21-S to denote which salary sacrifice amounts are voluntary
(RESC)) and which are mandatory (PRCL21-0 – not RESC) will ensure that RESC is correctly reported.
However, it is important to note that ATO guidance references the inclusion of salary sacrifice as ordinary
time earnings assuming a bottom-up approach.
Figure 35 - Top-Down Salary Packaging impact for OTE
Pre-Sacrifice Salary or Wages

100,000
Cash Component
Salary Sacrifice - Superannuation

Cash Component SS -20,000
Top-Down methods must

Salary Sacrifice – Other include non-OTE sacrifices
Employee Benefits to calculate the correct OTE
-10,000 due to the negative
Cash Component amounts (100,000 – 10,000)
= 90,000 x 10%^
[^ 21/22 SG rate used]
Post-Sacrifice Salary or Wages
70,000
Calculated
Super Entitlement - Liability
9,000
Calculated in last pay of the month
SG
Super Entitlement - RESC
Automated each pay RESC 20,000
35 | 56
• Lump Sum Payments – there are only three (3) changes to lump sum payments with STP2:
- Lump Sum W – an infrequently used payment option to entice an employee to return to working for
your entity from strike action or another employer. It has always been reported in Gross, but has its
own tax table (NAT 3347) and tax rates (PRCL21-R). It has been separately itemized, along with many
other components of the aggregated Gross amount previously reported.
- Lump Sum E – now to be reported by financial years, relieving the entity of having to send employees
separate lump sum E letters.
- Income Stream Collection – payment summaries used to enable the identification of lump sum
payments for Foreign Employment Income, but STP did not. This required manual contact with the
ATO for those with lump sum payments and both INB (now SAW) and FEI income. Lump sum
payments are now another payment type in the Income Stream Collection, enabling discrete reporting
• ETPs – have now moved within the Income Stream Collection reporting and is able to discretely report
ETPs for different income types and country codes.
• Pay Periods Selected – the data that is selected, the effective date of data that is read into the pay event
and the value of specific fields is influenced by which action is selected: submit or update:
- Submit – if the pay period is a:
o Regular pay cycle, then the Pay/Update Date = configured payday and the Run Date/Time Stamp
= payroll area control record in T569U (live = exit status; test = last status)
o Off cycle payment, then the Pay/Update Date = In-Period pay result payment date and the Run
Date/Time Stamp = pay cluster date and time in the VERSION table
- Update – if the period in the payroll period selection has a pay date in relation to the SAP system date
that is in the:
o Current FY, then SAP will generate a current FY update where the Pay/Update Date and Run
Date/Time Stamp = SAP system date. It will read payroll results for the last completed (regular =
exited; off-cycle = cluster) pay result plus T5QSO overrides
o Prior FY, then SAP will generate a prior FY update where the Pay/Update Date, Period Start Date,
Period End Date = 30.06 of the financial year of the selected pay period payment date and the Run
Date/Time Stamp = SAP system date.
Figure 36 - Pay Event Selection Logic
SAP logic
in pay
event
SAP system System date
36 | 56
3.3.3.5.3 Child Support
STP2 has introduced the option to streamline the currently manual reporting of child support amounts to the
Child Support Registrar. The ATO passes this data to Services Australia without storing, saving or displaying
child support amounts in any ATO system. For those employees who are also customers of Services
Australia, defined in an internal (government) Mutual Client Register, the data is shared in near-real time.
Services Australia calculates a period amount by sorting the pay events by payment date and run
date/time stamp and deducting the previous amount from the current amount. In particular, Child Support’s
systems don’t include the concept of YTD amounts, so the period amount they calculate will align with their
current manual reporting solution requirements.
Although it is optional for DSPs to include functionality to report child support amounts, SAP recommends
that customers take advantage of this process to streamline the heavy administrative burden on employers
of the current manual reporting solution offered by Child Support. By mapping the existing child support
wage types to the new EVCL13 values (CG, CS), it will relieve employers of their obligation to manually
report and explain variances.
The current form (CS4964) variances can be determined by Child Support through the use of other data:
Table 6 - Child Support Variation Information
Variation Reason for Variation STP2 Indication

Code Description
DIDN Did not deduct No movement in child support YTD amounts but movement in
income fields YTD amounts
ADDI Additional deduction Period amount calculated by Services Australia is greater than the
amount expected
AFPM Amount from previous month Ascertained by calculated period amounts for prior periods that
indicated a shortfall amount
CAS Casual Employment basis code
LWP Leave without pay No movements in income fields YTD amounts
MULT Multiple reasons Can be determined as all income is provided each pay
NEM No longer employed Cessation date and type
PDP Previously deducted payment Calculated child support period amounts were higher in previous
periods
PEA Protected earnings Calculated child support period amounts can be compared against
movement in income and PAYGW to determine if PEA applies
S72A Deduction for S72A notice Child Support Garnishee amount included as a separate field
STRK Employee on strike Cannot be distinguished from LWP above
TERM Termination payment Cessation date and type and ETPs, Lump Sums and Paid Leave-
U (unused leave on termination)
WRKC Workers’ compensation Paid Leave – W (workers’ compensation)
There are some specific rules for managing Child Support through STP2 that may not yet be available on
any government websites, but was provided to DSPs to design their solutions:
• Payment – There is no change whatsoever to the payment due date for child support amounts, only the
reporting is changing. That said, there is one change for the payment of Child Support Garnishee
amounts, where, upon transition to STP2, the payment reference number used to pay the withheld Child
Support Garnishee amounts must be the employer reference number on the notice and not the customer
reference number that is unique to each employee. Child Support will need to issue a new notice that
includes the employer reference number for Child Support Garnishee employees you pay. Contact Child
Support to arrange a new notice before you transition, advising of your transition date.
• Transition – As there is no concept of YTD amounts in Child Support systems, they need to understand
each employee’s period amount of your first STP2 report that includes Child Support amounts. There are
two possible options to advise the employee period amounts:
37 | 56
- Current Form – use the current form to inform every employee period amount for the same period as
the first STP2 report that includes child support amounts.
- Update – as the SAP STP solution will only include the last completed (exited) pay period data for
updates, create a current FY update for those employees with child support amounts only that will
advise the YTD amounts from the last pay period in the current FY before your first STP2 pay period
submit. This should be performed as soon as possible after the MYGL2 utility, to ensure Child
Support has sufficient notice of your intent to send your first STP2 submit file that includes Child
Support amounts.
o Consider the timing of the first pay in STP2 compared with the child support period (withholding to
payment cycle) to manage the reporting of withheld amounts, ensuring none are missed
Figure 37 - Child Support Transition Additional Step
PP10 of 26 PP11 of 26
Ready to report STP2
U S
No Child Support
amounts in STP
Last PAYEVNT.2018 MYGL2 Utility First PAYEVNT.2020 Pay Calculation STP2: PAYEVNT.2020
PREPARATION UPDATE SUBMIT

• Prepare data for STP2 • Only those • All employees
employees with
• ABN/Br/Income • YTD amounts for PP11, enabling Child
child support
Type/Country Code Support to calculate the period amounts
amounts
SAP will include any child support Update: Payment Date = Submit: Payment Date of Pay Period
overrides AND YTD child support
Run Date/Time Stamp = when generated Run Date/Time Stamp of Period Exit
amounts from PP10 of 26 ACRT
• Child Support Amounts – It is critical that the correct wage types are mapped to the relevant EVCL13
values for Child Support Garnishee (CG) and Child Support Deductions (CS). Note that amounts that are
requested by the employee themselves or their lawyers are not in scope of Child Support amounts to be
reported via STP2. Those are known as “voluntary” child support amounts and must not be mapped to
EVCL13 values.
- Child Support Deductions – in response to a S45 Notice issued by the Child Support Registrar and
subject to Protected Earnings Amount (PEA). EVCL13-CS and PRCL-64. Highest priority deduction,
with retroactivity to enable the deduction of shortfall amounts (in table DDNTK Deductions Not Taken)
when retroactive payments are paid for the shortfall period (For-Period) to comply with the notice.
o PEA is published by Services Australia on 1 January each year
o Shortfall amount is where the full amount of the deduction cannot be withheld as it would not leave
the employee with a net pay amount ³ PEA, so deducts as much as it can and carries the shortfall
amount to the DDNTK table to recover when any additional For-Period payments are made
o Payments must be received at Child Support by the 7th of the month following the deduction
- Child Support Garnishee – in response to a S72A Notice issued by the Child Support Registrar and is
not subject to the PEA. EVCL13-CG. Highest priority deduction without retroactivity. Is typically paid a
week following the pay from which it was withheld, but may be paid monthly to align all child support
payments.
• Missed Reports – it is critical that pay events are successfully sent on or before payment date to support
the Services Australia and Child Support use of the data to administer their programs. If a report is not
sent on or before payday, in addition to the ATO FTL penalties, you will not have met your legal
obligations under the Child Support (Registration and Collection) Act 1988 for Child Support Deductions
and must contact Child Support on 131 272 to discuss the missed report circumstances, send the
overdue STP2 pay event or complete the manual form and provide it directly to Child Support.
• Prior FY Updates – child support amounts do not and cannot change for prior FY updates
38 | 56
• Period Total Amounts – child support amounts for the period are included in the parent period totals
• Corrections Framework – if you identify that a child support YTD amount that has been reported is
incorrect then there are options about what you need to do to correct the information:
- If you created the child support deduction or garnishee amount against the wrong employee (no Child
Support S45/S72A notice), then correct the record as per normal, as this is covered by the Fair Work
Act 2009, not by the Child Support (Registration and Collection) Act 1988.
- If you have incorrectly understated the reported amount, then correct the record as per normal
- If you have incorrectly overstated the reported amount, then you must contact Child Support to
discuss the timing of the correction.
• Change of Key Identifiers – child support amounts must be managed effectively when transferring YTD
amounts to different key identifiers, as the impact is not to the ATO Income Statements, but to the critical
Child Support obligations.
If you are contacted by Child Support staff to inquire about matters that are not customer-
specific but rather about how the product is designed to work, please refer them to Matt
Voce at [email protected]. Child Support are new to STP2 and YTD reporting!
3.3.3.5.4 Prior FY Update

One of the prerequisites to sending a prior financial year update is that a submit must have been
successfully sent for that prior year. This is what is referred to in the requirements as an “interactive error”
but cannot be enforced in SAP due to the sheer volume and performance impact of interrogating large
volumes of data for every pay event. As such, if this is attempted, the message response will be one of
rejection.
Prior FY updates use the same process for both STP and STP2, through modifications to the T5QSO table
to support both phases. This will streamline the process. The two most significant reasons for prior FY
updates are:
• RFBA – when employees advise that the data provided to payroll is incorrect and payroll must liaise with
the finance area to receive corrected data, if required.
• Overpayments – when an overpayment is discovered this FY that relates to a prior FY, data is corrected
in SAP that triggers a recovery of all monies in this FY. The amounts relating to the prior FY must be
added back to the current FY and deducted from the relevant historical FY. SAP provides WT /LGT that
can be monitored for negative inflow to detect prior FY overpayments. Loans offset the recovery of the
gross – one for Gross (prior FY amount owed is Gross) and one for Net (current FY amount owed is Net
as the PAYGW is recovered automatically in the current FY).
For prior FY update specific data requirements, refer to Figure 5 - "Gap Year" requirements for Prior FY
Updates.
3.3.3.5.5 Negative YTD Amounts
Reporting income via Group Certificates, Payment Summaries and STP have always had some basic
validation rules, such as income must be zero or positive amounts. Whilst this is still in force for STP2, due to
the disaggregation of gross, some of the discrete Payment Types may be negative YTD amounts for specific
circumstances:
• Prior FY – if a discrete Payment Type is paid in one financial year and is corrected in payroll in a
subsequent financial year that has an EVCL13 value for a different Payment Type, it may leave the
original Payment Type in negative YTD, with the corresponding correction as a positive YTD.
• Prior Payer – for related entities on the same payroll, if a payment is corrected by a subsequent payer
that leaves the new payer with a payee with one payment type as negative YTD amounts and another
with the corresponding positive amount
These may be for limited durations only, as the negative YTD amount may become zero or positive in
subsequent periods or may remain as negative YTD amount if no other payments are made to offset the
negative YTD amount. This is limited to those separately itemized amounts that used to be included in
Gross, such as for:
• Gross
39 | 56
• Paid Leave Payment Amount
• Payee Allowance Amount
• Overtime Amount
• Bonuses and Commissions Amount
• Directors’ Fees Amount
• Lump sum Payment Amount (Type W Return to Work only)
• Salary Sacrifice Amounts (only temporarily, as a separate refund of salary sacrifice process applies)
This might typically occur, for example, if an absence type mapped to Paid Leave-W (workers’
compensation) was paid and then in the subsequent FY or payer, is corrected to be Paid Leave-O (other).
The new FY/payer will show a negative YTD amount for Paid Leave-W.
This must not and cannot be used as a reason not to address genuine overpayments. ATO will derive
aggregated gross (sum of the above payments less salary sacrifice) for use in the Income Statement (detail
is shown, but summary amount is provided on the overview screen) and prefilled IITR amounts.
3.3.3.6 Display, Finalise and Declare

There is a new program and transaction to display test (if saved in STP2 tables) and live submissions, auto
finalize/finalise/unfinalize and declare pay events:
• Program – RPCSTPDD
• Transaction - PC00_M13_STP2_DD - Single Touch Payroll - Phase 2 - > Reconcile, Finalize and
Declare Data
Figure 38 - RPCSTPDD (PC00_M13_STP2_DD Display, Finalize and Declare)
40 | 56
This program/transaction is used for multiple purposes:
• Display – to view data that has been saved in the STP2 tables (T5Q_STP2_ER/EE/PAY/LOG) where
submissions have been selected by:
- Submission Id – individually or for multiple selections
- Personnel Number – one or multiple selections
- ABN and/or Branch Number – individually or for multiple selections
- Date Range – from the date of the last update, or date range
- Declaration Status – declared records only, undeclared records only or all records
- Finalization Status – finalized records only, unfinalized records only or all records
- STP Data Selection – status of the submission: simulation data (test file) or live data, but not both.
Note: test files cannot be finalized or declared, only live files permitted
• Finalize – advise the ATO that the tax records of specific employees are complete and their Income
Statement can be made Tax Ready (ATO will change status after EOFY only) to enable them to complete
their Individual Income Tax Return. This functionality supports:
- Finalize – for specific employees (payee layout only) to enable customers to manage their EOFY
processes progressively (some employees) or all at once (all employees). This is currently only
permitted in the foreground, but the option to perform this in background is being explored.
- Unfinalize – used for several purposes, such as to correct accidentally finalized employees; to reflect
that an employee is no longer finalized where they once were; to alert the ATO and employees that an
issue has been detected and will be corrected but the data cannot yet be corrected. This will prevent
employees from mistakenly using incorrect finalized data to be prefilled into their tax return.
- Auto finalize – will check the last record in the same FY as the system date of the check (click auto
finalize button) and, if the records are TRUE, will copy that status to the default value of the record
(FALSE) to ensure continuity of the ATO Income Statement status. If the status is not different, a
message will be displayed to inform the user that no values were copied.
• Declare – this transaction has authorization objects that restrict access only to those users who are
authorized to declare the pay event “true and correct” subject to penalty. This transaction has the
following impacts:
- Liability – the userid of the declarer will be included in the pay event fields and sent to the ATO,
identifying that the declarer has accepted the declaration statement to accept liability that the pay
event is “true and correct”, subject to penalty
- Final – no data can be changed, including finalizing, unfinalizing, auto finalizing as the data is “locked”
and final, confirming the declaration step as the final step in ensuring the accuracy of the data to be
sent to the ATO
- Payload – the declaration triggers the transformation of the data into the XML payload format and
creates the submission as an object in the B2A queue, awaiting the next process to send the file to the
ATO
This transaction can be used to support many business purposes in addition to finalizing and declaring the
pay event, such as:
• Problem-Solving – to assist the pay administrators to address issues identified by employees from what
they can see in their ATO Income Statement. It allows the user to select the employee and sort their
declared submissions in descending order to check the data included in the submission.
• Completeness Check – either for specific employees or multiple employees to confirm that all
employees have been finalized or that every employee that had a submission in the FY has been
finalized.
• Analysis – to assist users to understand the reported data over time.
Navigation in the Display/Declare transaction differs from that of the Generation in that the records must be
selected to move to other layouts, using the record selector checkboxes to the left (per row of data) or at the
top (for all records) of the displayed data.
41 | 56
Figure 39 - Display Payer Layout
Declaration statements are required by the ATO to be in the foreground with specific wording to satisfy the
legal obligations. It is critical that the data to be declared has been validated and reconciled and the declarer
is satisfied that the data they are to declare is “true and correct”.
Users may select a single submission id to declare or multiple submissions to declare together. This is only
possible for submissions of the same “type”, as follows:
Figure 40 - Legal Declaration Statements
Pay Event Successfully Submission Id Declaration Statements Saves Declarers Creates XML
Validated and representing Details in Pay payload in B2A,
Reconciled against employer and may Employer Event fields ready to be sent
people/payroll data identify other
parties in parent Intermediary
SPECIFIC LEGAL DECLARATION STATEMENTS Registered Agent

4 types: a set if a single submission is selected for declaration and a set Sending Service Provider
if more than one submission at a time is selected for declaration.
You can only select multiple submissions of the same type, as the Multi-Employers
ATO-stipulated wording of the legal declaration is specific to the type. Multi-Intermediaries
Data in the payer header/T5QGP is used to denote which type of
declaration statement is required to meet legal obligations: Multi-Registered Agents
If T5QGP for the ABN/Br flagged an intermediary as an SSP, then SSP Multi-SSPs
If Registered Agent Number present in parent, then Registered Agent
If Intermediary present in parent, then Intermediary, else Employer
3.3.3.7 Send to the ATO

There have been no changes to the Business to Authority (B2A) Manager for STP2. The same process is
undertaken as for the initial phase of STP. As this is an international function, there are country-specific
layouts. For STP, this should be set to Australia via the B2A menu by selecting [Go To > Change Country
Group] and select [Australia] (13).
Refer to section Error! Reference source not found. Error! Reference source not found. for details about
the layout and selections in B2A.
3.3.3.7.1 Status of B2A Document
When the pay event is declared, the data is transformed into the XML payload format and creates a
document using a unique reference number.
42 | 56
Figure 41 - B2A unique object Id
Refer to section Error! Reference source not found. Error! Reference source not found..
The newly declared document will be created with the status of New and sub-status of New. Selecting the
[Display] button will display the XML payload. Other status and sub-statuses will display the detail of the
message relevant to the message and stage in the process, as follows:
Table 7 - B2A STP Status and Sub-Status possibilities
Status Sub-Status Description Display

New New Ready to be sent to the ATO XML payload
In Process Sent to ATO Pay event has been “pushed” Full description of message
into the SBR channel to ATO
and a technical receipt has been
returned to confirm
In Process No response, Retry There is a delay in getting the Full description of message
message response, try again
Error Process Comm. error; Send Data transmission issue (SAP Full description of message
Again again Cloud Integration or ATO
systems), file not sent to the
ATO, try to send it again
Error, Process Comm. error; There is a delay in retrieving the Full description of message
Again Request again message response, try again
OK Accepted by ATO The submission has been fully Full description of message
accepted by the ATO
OK Partially rejected The parent and at least one Full details of which records were
child record has been accepted rejected and why
by the ATO, but at least one
child record is rejected
OK Corrected manually Record would have been Full description of message
rejected but has been manually
corrected
Incorrect Rejected by ATO Message rejected due to parent Full details of which records were
record failure or all child records rejected and why
failed
Incorrect Fatal Error Product error Full description of message
There may be additional message details provided to customers that would indicate polling issues.
43 | 56
Figure 42 - History of B2A object showing steps in process
1. When pay event is declared, XML 2. When pay event is initially sent to
is created and compressed, appearing the ATO, the SubStatus is changed
in queue with SubStatus of “New” from ”New” to “Sent to ATO”
3. When message response is pulled from ATO, if

response is available and successful, SubStatus
changes from “Sent to ATO” to “Accepted by ATO”.
No further action is permissible
3.3.3.7.2 Troubleshooting or Error Handling

The volume of all possible messages is so extensive, it is not possible to detail them all. Customers are
encouraged to create an Error-Handling list that details the types of messages received, what they mean and
what corrective action is required to address the root-cause issue. This will be an invaluable tool in managing
message responses and ensuring that you have confirmed that you have met your legal obligations.
Although not in detail, the ATO Online Services for Business permits users with an approved myGovID and
business permissions (ATO Access Manager: Payroll Event) to view an overview of the pay events.
Figure 43 - Sample OSFB STP Overview
This will include submit and update actions and will include Accepted by ATO/Partially rejected files.
Connection errors occur from time to time. These are key websites to monitor ATO systems:
• SBR2 System Status - https://sbr2-status.mybluemix.net/
• Current SBR system status for planned outages - https://www.sbr.gov.au/current-sbr-system-status
• ATO system maintenance - https://www.ato.gov.au/General/online-services/system-maintenance/
3.3.3.7.3 Management of B2A Documents
Within the context of ATO’s business record-keeping requirements, your completed STP transactions in B2A
are your record to confirm how you have met your legal obligations for STP.
There may be circumstances where you may need to delete a file. This is possible by:
• In B2A, use the menu to [Go To à Further Administration] that will display the “HR-B2A: Reorganisation
B2A-Manager program (H99_B2AREORG” screen
• In the selection screen for the Functional area [QATO] and document class [STP]/[STP2], test a deletion
by selecting the B2A identifier file/s and select the [Delete] button.
44 | 56
• To delete files permanently (update mode), remove the [simulation] flag and then reselect the [Delete]
button.
To view the XML payload, select the relevant submission id with the history status/sub-status of New/New.
Select [Display]. The XML will be displayed:
Figure 44 - Display XML
The XML can be downloaded for ease of interrogation from this display. From the top menu, select [XML}
and then [Download].
45 | 56
3.4 Business Processes
The following sections provide high-level overviews of some key business process. Customers should
develop their detailed business processes to align with their internal policies.
This is not an exhaustive list of processes impacted by STP2.
3.4.1 Pay Production, Post-Pay Production, Corrections

These processes are interdependent and are shown here in the context of STP processes, that remains
unchanged for STP2:
Figure 45 - STP Pay Production Process including Post-Pay and Corrections
Corrections
SAP Pay Production Process Master
Data Overrides Configuration
Including Corrections and Post-Pay Production
Outputs of Payroll Pay Production

S T T
Correct Errors
Prerequisite Start Pay Time Pay Financial Banking – Superannuation Vendor Payslips STP Pay Validation Reconciliation
Master Data Production Evaluation Calculation Posting Test file (T) Remittances Event Test
Validation Simulation (S) report (T)
Proceed
Post-Pay Production
L PUSH
STP Pay B2A Message Monitor End

Exit pay
Disburse Auto-finalise Declaration
period Event Live Response Outcome
other payroll then finalise PULL
report (L)
outputs or unfinalise B2A
3.4.2 Corrections Framework

The root cause of corrections may be extensive, but the timing and method of correction are common:
Figure 46 - Correcting Reported Data
Post-Pay Production
Fix relates to
current FY?
Yes No
Detect need
to correct Fixed in
data this/next pay When?
in the FY?
Pay Production Corrections
Yes No
Master Data Overrides Configuration
Pay Event - Pay Event -

Submit Update How?
46 | 56
3.4.3 End Of Financial Year
Given the process per pay, the EOFY process focuses on balancing with FY obligations external to payroll,
such as salary sacrifice management, RESC, RFBA, Financial Reconciliations for PAYGW etc:
Figure 47 - Business Process: End of Financial Year
3.4.4 Communication with Employees

Unlike for the initial phase of STP, your employees may be customers of Services Australia and be
presented with the disaggregation of gross payment types that are not intuitive or easy to relate back to the
wage types on their payslips. What they think is overtime may be mapped to gross, what they this is gross
may be mapped to allowance types. It is important that customers address the transparency of their data to
government back to the employees themselves to avoid confusion or employees reporting data
“discrepancies” to the ATO, triggering calls to understand your data.
How customers choose to address this may include enhanced payslips, referencing the EVCL13 values, or
separate reports to employees.
Figure 48 - Consider what your Employees Need to see about their Pay Details reported to Government
Employer Pay
Slip
Services Australia’s
Portal – per Instalment
Period
Employee
Confusion
ATO’s Income Statement
47 | 56
3.4.5 Transfer of YTD Amounts
There may be circumstances where the BMS Id of employees is changing, such as for:
• Upgrade SAP solution, re-implementation
• Acquisition of new business and its payroll
• Multiple payroll solutions at the same time, movement of employees between systems
• Machinery of government for government departments, agencies
• Outsourcing or moving to in-house payroll systems
There may be circumstances where the Payroll Id (PERNR) of employees is changing, such as for:
• Migrating employees from other payroll solution with different or non-unique existing personnel numbers
that must be accommodated in your existing payroll solution
• An existing worker on the system but not in payroll becoming an employee, requiring a payroll-relevant
personnel number
3.4.5.1 Zero Out Method

The option to zero out existing balances can only occur when you still have access and control over the
previous key identifiers. This process must occur BEFORE the YTD amounts are transferred:
Figure 49 - Zero Out Method for Transfer of YTD Amounts
Key Identifiers: Transfer of YTD Amounts – Zero Out
And/Or And/Or
Instance of Different client or

Payroll/SAP client instance or product
Transfer YTD
Update Test Override Upload Update Live Amounts Pay Calculation Submit
File
Personnel Different
Number Personnel Number
BEFORE TRANSFERS TRANSFER YTD AMOUNTS

• Original Key Identifiers • Create new Key Identifiers
• Last transaction • Create wage types for the amounts zeroed out, using
EVCL13 values for P1, P2, P3, P4 if discrete WTs
• Run a test Update and download output to identify
every financial amount • Run payroll calculation
• Create an override upload file to REVERSE the • Submit will show the new opening balances + pay
financial value of every wage type (cross-reference period amounts as new YTD reporting for new Key
with ACRT/AETP) Identifiers. Parent period totals will show period amts
Factors for consideration when using the zero-out method:

• Whilst the personnel number “change” from the previous key identifier to the new key identifier may occur
within the same payroll for specific business reasons, it is not recommended to change the BMS Id of an
existing system, as this may lead to extraordinary complications in managing the continuity of
employment obligations.
• If the personnel number is to be transferred on the same payroll system, the employee (previous payroll
id) must be terminated with an action/reason that is mapped to the Cessation Type of T (transfer) to alert
the government recipients of the data that an administrative process is occurring and there is no end to
the employment relationship. When the new payroll id is sent, the taxpayer identity will be identified to link
back to the previous payroll id. The hiring process should reflect appropriate date specifications for the
new PERNR, the extensive master data maintenance, leave accruals, averages for LSL etc. would need
to be addressed as part of this “reset” of the employment records.
48 | 56
• ATO Income Statements are removed when all financial amounts are removed and will be published
when the new submit is sent to reflect the new key identifiers with the progressive YTD amounts.
3.4.5.2 Replacement Method

If you are transferring YTD amounts for systems and/or employees for which you no longer have access or
control, but the previous key identifiers are known, then this new method will allow you to advise the ATO
that they should “mask” the key identifiers and treat the YTD amounts for the new key identifiers as a
continuation of their STP data.
This is new for STP2 and was created to address the typical business scenario, generally for small business
software, where the transfer of YTD amounts has occurred after the new key identifiers have been created
and/or reported in STP.
It is critically important that, in this process, the update to advise, as a once-off exercise, the replacement of
key identifiers occurs as soon as the first submit has been successfully sent to the ATO. Until then, there are
duplicate Income Statements.
Figure 50 – Replacement Method for Transfer of YTD Amounts
Key Identifiers: Transfer of YTD Amounts – Replacement
And/Or And/Or
Instance of Different client or

Payroll/SAP client instance or product
Transfer YTD
Amounts Pay Calculation Submit Previous Key Update Live
Identifiers
Personnel Different
Number Personnel Number
TRANSFER YTD AMOUNTS IMMEDIATE UPDATE (as soon as submit

received)
• New Key Identifiers
• Choose the “Replacement” option in Update
• Create wage types that represent the closing balances, using EVCL13 values
for P1, P2, P3, P4 if discrete WTs • Enter the previous BMS Id and/or specify
the previous Payroll Id file (New PERNR,
• Run payroll calculation Previous PERNR)
• Submit will show the new opening balances + pay period amounts as new • Send update to ATO that will correct the
YTD reporting for new Key Identifiers. Parent period totals will show period duplicate Income Statements
amts
Factors for consideration when using the replacement method:

• It is not an appropriate method to use if the employees are on the same system. That is, the previous
payroll id and the new payroll id will exist on the same system. This is due to the fact that, even if the
previous payroll id is terminated with an action/reason that is mapped to Cessation Type T (transfer), the
previous payroll id will be included in finalization pay events, resetting the whole purpose of replacement
key identifiers.
• It is particularly relevant and useful when transferring or migrating employees from one external system
onto your instance or client in your SAP payroll solution
49 | 56
4 IMPLEMENTATION APPROACH
The implementation approach for STP2 is going to vary between SAP customers and their particular
circumstances, however, there are options:
• Support Packs – apply the changes as part of the normal support pack application
• Project – apply the changes as a stand-alone project
Both approaches are fully supported by SAP, however, the project approach may allow more focused
testing, specific to STP2, as these changes are significant.
4.3 Support Pack Approach

This approach is to apply these changes as part of the extended Support Pack application process. It is
recommended that the process be completed using the following steps:
1. Apply Support Packs and identify any payroll variations.
2. Apply STP2 Changes and identify any payroll variations
3. Perform targeted scenario testing
This approach will allow you to clearly identify, if there are differences, what the source of the difference is.
Most customers have well defined approaches when it comes to applying Support Packs. The list below is
simply a recommended approach to follow:
1. Perform a copy of Production data to Test environment.
2. Run Baseline Payroll run
3. Extract Payroll results for later comparison
4. Apply Support Packs
5. Re-run Payroll and compare the results to Step 3
7. Apply STP2 Changes
8. Re-run Payroll and compare the results to Step 6
9. Perform UAT / Scenario testing
10. Sign off Test Results
11. Migrate to Production
4.4 Stand-alone Project

This approach is to implement the new solution as a separate project and to apply the changes and perform
targeted testing of the new solution. This would include the following steps:
1. Perform a copy of Production data to Test environment.
2. Run Baseline Payroll run
4. Apply STP2 Changes
5. Run Payroll and compare the results to Step 3
6. Perform Targeted Scenario testing
7. Sign off Test Results
8. Migrate to Production
50 | 56
Figure 51 - Transitioning to STP2
Transitioning to Single Touch Payroll Phase 2

Prepare
Rules Solution Collaborate Plan
Realise
Errors
Start
License Apply Configure Customisations Test Correct
Transition
Deploy
End Live with

Communicate Checklist Agree Go Live Support Transition Single Touch Deadline
Payroll SAP deferral:
Phase 2 31.12.2022
4.5 Initial Transition to STP2

SAP recommends the following process for Production transition into STP2:
Figure 52 - Production Steps to Transition to STP2
Production Steps
Transition to STP Phase 2 If no Child Support amounts
Prerequisites to transition
U L
IT0188 Separately EVCL13 Configuration Mid-Year Child Payroll Pay Event Declaration Send – Push
Data for Identified Go Live 2 Support Calculation LIVE
Receive - Pull
STP2 Wage Types Update
• Prerequisites:
◦ IT0188 employee master data changes to reflect tax data, Income Types, Country/Region Codes
◦ Wage Types that reflect the disaggregation of gross approach to separately identify the
components of pay (particularly for Allowances; pre-sacrifice amounts) ATO Received
Message
• Deploy the configuration changes Responses
• Perform MYGL2 if your first pay reported via STP2 is not 01.07
• If you have employees with Child Support amounts, send an update ASAP after MYGL2
• Proceed with business processes, focusing heavily on validations and reconciliations to
confirm accuracy and compliance
51 | 56
5 TESTING APPROACH
STP2 introduces extensive changes to the payroll and other business processes associated with paying
employees. It is critical that the solution is thoroughly tested before being deployed to your Production
environment:
Figure 53 - STP2 Testing Approach
Recommended Test Strategy

STP Testing Approach
Objective of Testing: Solution Migrate New Employee
§ Technical architecture Deployment Solution Data
confidence
§ Business transaction Dev Test Prod
and process success
§ Confidence in solution
Customers will unit test

Customers will deploy Test business
subsequent to fix processes and
transactions
SAP will provide support in
the solution deployment Success
Explanation from
Discrepancy SAP
Validate and
reconcile
Fix from SAP outputs using
current tools
Discrepancy Negative Discrepancy Positive
5.3 ATO External Vendor Testing Environment (EVTE) Requirements

SAP customers have been afforded special privileges by the ATO that are not enjoyed by customers of other
payroll products. Their test environment (EVTE) is designed to permit DSPs to test their solutions as they
build and modify them. This is not limited to STP but applies to all of ATO’s digital services.
Access to EVTE allows customers to connect using their non-Production SAP Cloud Integration to connect to
the ATO to test the end-to-end process. However, to continue to enjoy this ATO privilege, there are
conditions of use that MUST BE ADOPTED :
• Identity Security – employee data such as names and addresses must be scrambled or anonymized
• Payload Size – as this environment is strictly for DSPs developing commercial products, SAP customers
must restrict their submissions to a maximum of 100 child records. Breach of this condition may adversely
impact DSPs development of their commercial products, the core purpose of EVTE, and may result is
slowing down the system for all users, triggering a call from the ATO.
- Please do not abuse this condition!
- If you need to test performance, please contact Matt Voce ([email protected]) for him to arrange
the additional privilege with ATO on your behalf. Provide details of timing, size, identity security and
purpose. ATO staff will be on standby to assist with volume impacts. It may need to be scheduled.
• TFN – although the entire EVTE and ATO systems are secured, the access to real TFNs is not granted to
all ATO staff, only those authorized to handle live TFNs. As such, you must only use TFNs as follows:
- EVTE TFN: 485215078
- TFN Exemption Codes: 000000000, 111111111, 333333333, 444444444
• ABNs – ATO’s EVTE is a “stand-alone” environment that is not connected to the extensive government
databases such as Business Registers, TFN Identity database, Relationship Authorization Manager,
Access Manager, TPB Registered Agents and the many other government internal-only data stores. Only
the following EVTE-specific ABNs can be used in EVTE:
- 14088411787: this is the M2M credential owner and “head office” equivalent
52 | 56
- Others: 16000023656, 17088268884, 19087046080, 62483468038, 11000002568, 11000703613,
32087112105, 49425379391
- Branches: all branches from 000 to 999 for all EVTE ABNs are permitted
• RAN – Registered agent number: 17801003
Figure 54 - ATO EVTE Key Data
Non-Production <-> EVTE: ABN and RAN Values
16000023656
17088268884
19087046080
62483468038
11000002568
11000703613
32087112105
49425379391
Business Related Entities * Any/all branches Registered Agent
ABN-Br: 14088411787-001 RAN: 17801003
These related entities are employers,
M2M Credential Owner but will require an intermediary: the *can be used with all ABN/Br
M2M Credential Owner
KeyStore in non-Prod SAP
Cloud Integration
This requires configuration differences between Production and Non-Production environments:

• T5QGP – employer or intermediary must be 14088411787
• T50BK – M2M must be 14088411787
Customers can either manage this through careful transport management or through use of the Badi.
5.4 Scenario Testing

Before planning out the customer-specific testing needed to confirm the STP2 solution for customer-specific
Production environments, it must be highlighted that SAP has been successfully whitelisted after completing
extensive tests written and reviewed by the ATO. This approach has never been adopted before and allowed
the ATO to test an extensive array of validations, rules and requirements.
The full requirements for DSPs are not available to employers. The BIG (business implementation guide) and
MST (message structure tables) are publicly available on the SBR website. The extensive array of DSP-only
position papers and guidance notes are restricted to registered DSPs only. The ATO Online Services for
DSPs has further extensive guidance and rules for DSPs to develop their products. None are available to
employers, as they are not required.
The extensive validation rules and field requirements have been developed, tested and passed by the ATO.
There is no need to test against them. However, if customers want to understand or confirm these, many of
them are available in the MST. Those rules are the DSP responsibility.
Testing may include, but is not limited to, the following transactions:
• Payment Types - focusing on pre-sacrifice amounts and salary sacrifice amounts
• Bonuses and Commissions – ensuring that the business process will result in the pre-sacrifice
amounts, salary sacrifice to super and RESC
53 | 56
• Terminations – ensuring that all actions/reasons, including termination organizer and personnel actions,
have been mapped to a valid Cessation Type. Terminations in the period, in arrears, in advance, via off-
cycle (on-demand off-cycles are out of scope of STP/STP2)
• ABN/Branches – changes to new ABN/Branches within the period, after pay period end date
• Income Types/Country Codes – representing the full array of employee circumstances you have now,
sometimes have, may have in the future
• Tax Scales – any downward variations, new tax scales, interactions with variations such as STSL and
Medicare Levy variations (surcharge, exemption, reductions)
• Downward Variations – ensuring that the circumstances result in the appropriate Tax Treatment Codes
• Employment Basis – ensuring your Personnel Structures or other aspects that define the employee as
full-time, part-time and casual have been tested
• Death Beneficiaries – ensuring the configuration requirements have been met, the specific master data
requirements are available and the business processes support this specific scenario/s
• Prior FY Updates – particularly with any Income Types that require Country/Region Codes: both in the
“gap years” and prior to 01.07.2020. Include those with Lump Sum E, WHM, Income Types that are
introduced for STP2 but were included in SAW.
• Transfer of YTD Amounts – to the extent that this occurs in your organization, the particular
circumstances may be able to be “mocked-up” to test it, or test what you can for the functionality
available. Particularly focus on the impact to parent period totals.
• Child Support – whilst this is not a complicated change, the transition in and the process to co-ordinate
where your manual process ceases and your STP2 one begins must be tested
• Income Type Changes – for employees that change Income Types that would be realistically
experienced in your Production Payroll
• Global Mobility – these processes typically involve financial staff, ensure that the new governance of
these employees is tested, for example: FEI, IAA
• Amendments – how this process will occur, particularly for Lump Sum E processes and timings
• Negative YTD Amounts – if you have multiple ABN/Branches on the same payroll, reversing one
Payment Type (EVCL13 value) retrospectively to replace it with a different Payment Type should be
tested so you understand how it will look and how you accommodate it in your validations and
reconciliations
• Allowance Items – the most extensive and, in the opinion of many, most complex aspect to the STP2
changes, as those allowance items that have concessional tax treatment have many conditions that are
to be met, or different wage types are required to address the extensive requirements for PAYGW, super
guarantee and STP2 pay event fields.
• Internal Reporting – the extensive array of validations and reconciliations of the pay event against the
source of truth: pay results, master data and configuration. These reports may include, but are not limited
to the following checks:
- Configuration – T5QGP entries, T512W wage type configuration, T530/T5Q30 termination
action/reasons to cessation types
- Error Handling – how the process is addressed for pay event log warning messages, error messages
and correcting data (including the timing of correction)
- Data Integrity – master data integrity, å RT = CRT = ACRT, overrides (T5QSO) and prior FY
overpayments (monitoring negative inflows of /LGT)
- Completeness Check – ensuring all employees with payments subject to withholding have been
included in the submit and finalized at EOFY for both regular and off cycle pays.
- Compliance – with Fair Work obligations, PAYGW, super guarantee and STP2
- Reconciliation – the components of payroll/override have been accurately reflected in the pay event
and key items reconcile with the financial accounts
• Business Processes – the modified business processes to support the STP2 requirements have been
tested and users understand the details and timing of the steps they are to perform when the solution is
deployed into Production
54 | 56
5.5 Issue Reporting
When or if any issues are encountered that require SAP support, please Report a Case on SAP for Me and
raise the customer incident using the Application Area of PY-AU for Non-CE customers, with OSS prefix as
“STP2:xxxxxxx”.
This is important to focus support and priority for customers transitioning to STP2.
Figure 55 - SAP for Me: Report a Case
5.6 Supporting Documents

Where there are SAP Notes with attached documents to support partners and customers to transition to
STP2, these supporting documents should be shared with the payroll business users to ensure the full
requirements to assist the business to meet their STP2 obligations are provided.
This may include (names may change upon release):
• Implementation Guide – this document, as it not only details the configuration requirements, but
explains functionality and business processes
• Pay Event Field Mapping – this workbook identifies all of the STP2 fields and explains the source of
data, configuration and logic used to source the data included in the pay event. It includes validation rules
and interdependencies
• SAP STP2 Data Structure – this 3-page diagram illustrates the data structure of the PAYEVNT.2020
STP2 pay event.
• EVCL13 Mapping to Pay Events – a workbook showing the changes to EVCL13 and the mapping to the
Pay Event fields for STP2, identifying impacts between phases of STP
• Various – there may be other guides, such as for SAP Cloud Integration, B2A Manager and other
supporting documents.
55 | 56
www.sap.com/contactsap
© 2021 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.
The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.

SAP STP2 Implementation Guide V1.2 - Part2

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

SAP STP2 Implementation Guide V1.2 - Part2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP STP2 Implementation Guide V1.2 - Part2

Uploaded by

Copyright:

Available Formats

2

Single Touch Payroll Phase 2

Non-Concurrent Employer Solution (Non-CE)

Refer to related topic Hyperlink to the section number and heading

The purpose of this document is to provide:

• Details of the configuration required to support the operation of the solution

• Recommended business processes, where relevant

3.3.1 Changes introduced by STP2

3.3.2 Data Requirements

3.3.2.1 Taxation Master Data

Figure 1 - New fields and validations for IT0188 Tax Australia

Char-1 and Char-2 (may be Char-3

• Tier 1 (1%) = ***1XX

Tax Offset Amount

Table 1 - Permissibility of Tax Scales to Income Types

Tax Scale Income Types Permissible

Table 2 - Ongoing maintenance of tax infotypes (0188, 0817, 0227)

Arrears Pay Arrears

This also applies to IT0227,

Submit actions will read tax data as at payment date.

Figure 4 - SAP STP2 Tax Treatment Framework

1 = RN T1 = ANXXXX C1 = CTXXXX IS = SI W = HRXXXX SW = WPXXXX 3 = FF 4A = NAXXXX 8/9 = DVXXXX*

0^ = RT TP = APXXXX SI = SS WU = HUXXXX Logic when ETP-Death

1H/1S# = RNS 3H/3S# = FFS * Also influenced by IT0817

Table 3 - Supported Tax Treatment Codes

Where the colours indicate (text shade relates to cell shade):

Figure 5 - "Gap Year" requirements for Prior FY Updates

STP Transition FY 1 July 2020 STP2 Transition FY

SAW/CHP/IAA/SWP = SAW SAW/CHP/IAA/SWP = SAW Income Type

SAW only SAW only ETPs (per Income Stream Collection)

Cannot be reported Cannot be reported < 01.07.2022 Child Support Deduction

Cannot be reported Cannot be reported < 01.07.2022 Child Support Garnishee

Figure 6 - IT0817 Income Tax Withholding Variation-AU

3.3.2.2 Transfer of YTD Amounts

Figure 7 - Transfer of YTD Amounts

Taxpayer Income Statements

ABN/Branch ABN/Branch Instance of PY PERNR

Figure 8 - Death Beneficiary: Pay Event Payee Layout

Figure 9 - Death Beneficiary: Pay Event Income Stream Collection Layout

3.3.3 Tables, Structures, Programs and Utilities

3.3.3.1 Payroll Cluster

Figure 11 – Cluster Table: TAXP

3.3.3.1.2 SABN ABN Table

Figure 13 - SABN approach to assigning payer

Split Pay Period

3.3.3.1.3 ACRT STP Cumulated Results Table

Figure 14 - Payroll Cluster: ACRT

Current Pay Period PP01 PP02 PP03 PP04 PP05

Current Payer 14088411787-001 16000023656-001 17088268884-001 19087046080-001 62483468038-001

14088411787-001 16000023656-001 17088268884-001 19087046080-001

14088411787-001 16000023656-001 17088268884-001

When the pay results for period 05 are

3.3.3.1.4 AETP – STP Employment Termination Payments

Figure 16 - Payroll Cluster: AETP Table

3.3.3.2 STP Overrides (RPCSTOQ0)

If STP year is:

If Income Type = FEI or WHM and

If prior FY update of a pay event that