2

PUBLIC

Single Touch Payroll Phase 2

Implementation Guidelines

Non-Concurrent Employer Solution (Non-CE)

Version: 1.2

Status: FINAL
TABLE OF CONTENTS
1 INTRODUCTION ............................................................................................................................... 5
1.1 Single Touch Payroll Phase 2 Requirements ............................................................................... 5
1.2 Deferrals ........................................................................................................................................... 5
1.3 Scope of Solution ............................................................................................................................ 5
1.3.1 Out of Scope .................................................................................................................................... 5
1.4 SAP Software Requirements .......................................................................................................... 7
1.4.1 SAP Cloud Integration Requirements ........................................................................................... 7
2 STANDARD BUSINESS REPORTING (SBR) .................................................................................. 8
2.1 Digital Messaging ............................................................................................................................ 8
2.2 ebMS3/AS4 Adapter ......................................................................................................................... 9
2.3 SAP Cloud Integration ..................................................................................................................... 9
2.4 Pay Event Service ............................................................................................................................ 9
2.5 Message Responses ....................................................................................................................... 9
2.6 Government Security Protocols ................................................................................................... 11
2.7 Interdependency between Government Security and the SAP STP2 Solution ....................... 13
3 THE STP2 SOLUTION .................................................................................................................... 15
3.1 Solution Overview ......................................................................................................................... 15
3.1.1 Message Exchange ........................................................................................................................ 15
3.1.2 Business to Authorities (B2A) ...................................................................................................... 16
3.1.3 Transitioning to STP2 .................................................................................................................... 17
3.1.4 Business Process .......................................................................................................................... 18
3.1.5 STP2 Data Tables ........................................................................................................................... 18
3.2 Solution Configuration .................................................................................................................. 19
3.2.1 STP2 Transition Date (T5Q_CONSTANTS) .................................................................................. 19
3.2.2 ebMS3/AS4 Integration with Payroll (T50BK) ............................................................................. 20
3.2.3 Employer Set Up (T5QGP) ............................................................................................................ 21
3.2.4 Employment Termination Payments (T5QPC) ............................................................................ 22
3.2.5 Termination Action/Reasons (T5Q30) ......................................................................................... 24
3.2.6 Wage Type Evaluation Classes (T512W) ..................................................................................... 25
3.2.7 Income Types ................................................................................................................................. 31
3.2.8 Numbering Sequences .................................................................................................................. 32
3.2.8.1 B2A Object IDs (HRB2A) ................................................................................................................. 32
3.2.8.2 Pay Event Submission IDs (HR_AU_SUBI) .................................................................................... 33
3.2.8.3 STP Override Sequence Numbers (HR_AU_OVID) ....................................................................... 34
3.2.9 Constraints for Live Pay Events (Feature 13STP) ...................................................................... 34
3.2.10 Message Response Polling Intervals (STP_POLLING) .............................................................. 35
3.2.11 Authorisations (P_KW_REPT) ...................................................................................................... 35
3.2.12 Employee Contact Details (Features 13PF5/4, 13PF2/3, 13ADD) .............................................. 36
3.2.13 Employment Basis Code (Feature 13DEG) ................................................................................. 37
3.2.14 Customer-Specific Business Add-Ins (BAdi).............................................................................. 37
TABLES
Table 1 - Minimum HRSP Levels ...................................................................................................................... 7
Table 2 - Evaluation Class 13 values for STP2 ............................................................................................... 25
Table 3 - Colour legend for EVCL13 ............................................................................................................... 27
Table 4 - STP Programs and Transaction Changes ....................................................................................... 36

2 | 37
FIGURES
Figure 1 - SAP Cloud Integration: STP iflows.................................................................................................... 7
Figure 2 - Structure of the ebMS user message ............................................................................................... 8
Figure 3 – Structure of the ebMS message response ..................................................................................... 10
Figure 4 - M2M Credential Renewal Process .................................................................................................. 11
Figure 5 - Convert M2M Credential XML to JKS Format Process................................................................... 12
Figure 6 - M2M Credential Permissions Process ............................................................................................ 12
Figure 7 - Revoke the M2M Credential Process ............................................................................................. 13
Figure 8 - SBR Channel Validation Process.................................................................................................... 13
Figure 9 - Interdependency between Government Security and SAP ............................................................ 14
Figure 10 - Single Touch Payroll End-to-End Solution Overview .................................................................... 15
Figure 11 - Message Responses in B2A ......................................................................................................... 16
Figure 12 - Purpose of the MYGL Utility .......................................................................................................... 17
Figure 13 - Single Touch Payroll Business Process ....................................................................................... 18
Figure 14 - STP2 Data Tables ......................................................................................................................... 19
Figure 15 - T5Q_CONSTANTS ....................................................................................................................... 20
Figure 16 - T5Q_CONSTANTS: Where Used ................................................................................................. 20
Figure 17 - T50BK Integration between ERP and SAP Cloud Integration ...................................................... 21
Figure 18 - T5QGP Employer Setup ............................................................................................................... 22
Figure 19 - ETP Configuration for Pay Event .................................................................................................. 23
Figure 20 - ETP Codes per EVCL13 and Pay Event Field .............................................................................. 23
Figure 21 - T5Q30 Cessation Types per Termination Action/Reason ............................................................ 25
Figure 22 - EVCL13 Changes for Allowances, CDEP ..................................................................................... 28
Figure 23 - EVCL13 Changes for Gross and JPDA ........................................................................................ 29
Figure 24 - EVCL13 Changes for FEI and Child Support ................................................................................ 29
Figure 25 - EVCL13 New values for Transferring YTD Amounts .................................................................... 30
Figure 26 - EVCL13 use by the Pay Event ...................................................................................................... 30
Figure 27 - Income Types Whitelisted for use in SAP ..................................................................................... 31
Figure 28 - T5Q_INC_TYP: Whitelisted Income Types ................................................................................... 32
Figure 29 - Object IDs required for B2A submissions ..................................................................................... 32
Figure 30 - Establishing B2A Object Number Sequences: HRB2A ................................................................ 33
Figure 31 - Number range required to form unique Submission Ids ............................................................... 33
Figure 32 - Submission Id number range: HR_AU_SUBI ............................................................................... 33
Figure 33 - STP Override Sequence Numbers ............................................................................................... 34
Figure 34 - STP Override Sequence Numbers: HR_AU_OVID ...................................................................... 34
Figure 35 - Feature 13STP to enforce system controls ................................................................................... 35
Figure 36 - Polling Intervals: STP_POLLING .................................................................................................. 35

3 | 37
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 | 37
1 INTRODUCTION
Single Touch Payroll (STP) was enacted in 2016 as an Australian Taxation Office (ATO) initiative to
streamline reporting for pay as you go withholding (PAYGW) and superannuation guarantee amounts. SAP
released the STP solution in May 2018. That initial introduction to digital reporting services took the existing
annual Payment Summary reporting data and tailored it to align with the pay production process to report it
each pay.
In the 2019/2020 Federal Budget, the Australian Government announced the expansion of STP reporting,
referenced as STP Phase 2 (STP2). This phase has changed the data structure to future-proof the pay event
and enable it to be more responsive to changes in government policy. This phase was designed to
accommodate the requirements of Services Australia to assist in the management of welfare payments and
for Child Support to obtain the real-time details of amounts withheld in response to a notice issued under S45
and/or S72A of the Child Support (Registration and Collection) Act 1988.
The data has expanded to include further details about the employment and components of the employees
pay. Rather than report the total taxable gross amount to the ATO, required as input to their Individual
Income Tax Returns at the end of financial year (EOFY), Services Australia requires the separately
identifiable components of pay for their income assessment purposes for social security administration at
each welfare instalment period (fortnightly, monthly etc.).
SAP released the STP2 solution in June 2022. Unlike the initial phase of STP, this phase requires significant
preparation by customers to ensure they have the data required for the expanded reporting in STP2 and the
business processes to support ‘true and correct” data each pay.

1.1 Single Touch Payroll Phase 2 Requirements

The ATO manages and administers the Single Touch Payroll pay event services for whole-of-government
and provides employer guidance on their website, including references to the enacted legislation. The
detailed ATO STP2 requirements are the pre-requisite knowledge required to accurately establish and
process payroll to deliver “true and correct” pay events. It is also critical that configurers are across these
requirements to adequately support the solution.
Customers are encouraged to seek training on these extensive requirements from appropriately qualified
payroll associations or trainers. The transparency of the components for PAYGW and super guarantee
amounts in STP2 means that robust governance over taxation and super obligations is warranted.

Do not rely on general information you source through search engines. Consult with your
tax agent or compliance manager for specific advice for your business.

1.2 Deferrals
The mandatory date for STP2 was 1 January 2022 and SAP obtained an ATO deferral to 31 December
2022. Customers who are unable to start their STP2 transition by or on the first payday from that date will
need to apply to the ATO for an employer-specific deferral via Online Services for Business.

1.3 Scope of Solution

This solution is confined to the non-concurrent employment (Non-CE) solution for Australian Private Sector
and Public Sector solutions:
• ECP Cloud V6.08
• ECC On-Premise V6.0, V6.04, V6.08
The ATO provided digital service providers (DSPs such as SAP) with extensive documented guidance, most
of which are controlled documents, secured for registered DSPs only. In addition to mandatory requirements,
there were some options provided to DSPs to enable product-specific choices and options. SAP made
choices not to deliver some of these options, specified in the following section.

1.3.1 Out of Scope

The following optional functionality is not supported in the SAP STP2 solution:

5 | 37
• Full file replacement – this functionality is intended to replace a successful submit action with another
submit action. However, the rules are so complex that very few DSPs have chosen to include this
functionality in their products. Of those who do, the ATO had to introduce limits to prevent more than one
full file replacement from being sent each 24-hour period. This is not included in the SAP STP2
functionality. If there is an issue with a successful submit action, take corrective action and perform an
update action or wait until the next submit action in the same financial year.
• Deferred off-cycle payments – this functionality is intended to allow users to delay sending a submit
action until the next regular pay cycle, where the parent period totals will sweep all off-cycles in the
financial year since the last regular pay cycle to include all period amounts, not just the current regular
pay period amounts. However, the complexity of payroll organization and arrangements for SAP
customers means that this functionality is not an option in the SAP STP2 functionality. A pay event submit
must be sent to the ATO at each regular and off-cycle pay: on or before payday.
• On-demand off-cycle payments – this functionality in SAP enables the creation of a bank file to pay an
employee that is included in a regular pay cycle where the pay period has been released but has not yet
been exited. This “on-demand” payment process cannot be accommodated in STP due to the complex
requirements of the pay event parent totals and the extensive logic and rules to comply with the ATO STP
requirements. The use of on-demand off-cycles is not supported by SAP for STP or STP2
• Generation of a GUID – the BMS Id represents each SAP client (instance of payroll) and should have at
least the same longevity as the actual SAP payroll solution. It must be a 32-char GUID and it is not
automatically generated by SAP, rather, customers must generate this themselves for the T50BK B2A
Integration table for constant BMSID.
• Income Types – of the 9 active and 1 historical income types included in the STP2 solution, those
Business and Personal Services income types are not available (or permissible) in SAP:
− VOL: Voluntary Agreement for contractors with PAYGW
− LAB: Labour Hire firm contractors
− OSP: as per regulation 27 of the Taxation Administration Regulations 2017
• Employment Conditions – in association with the income types listed above, these employment basis
codes are not available (or permissible) in SAP:
− V: Voluntary Agreement
− L: Labour Hire
− N: Non-employee
• Tax Treatment Code – derived from the tax data on IT0188 Taxation Australia and IT0817 Income Tax
Withholding Variation-AU, some tax scales are not supported in SAP:
− RDXXXX: NAT 1024 Tax table for daily and casual workers as this method applies only for casuals
who work three shifts in a week as this does not align with the method of tax assessment based upon
payments, not number of “shifts”
− ADXXXX: NAT 1023 Tax table for actors, variety artists and other entertainers, only for the discrete
subset of workers covered under this schedule who have three performances per week as this does
not align with the method of tax assessment based upon payments, not number of “performances”.
Other workers covered under this tax table are accommodated in SAP
• Ordinary Time Earnings – this super entitlement type may be reported and/or the super liability type.
SAP reports only the super liability, as with most DSPs, OTE is a more complex value to discretely and
accurately report, given the many variables that apply
• Batch of Bulk Messaging – SAP only uses the ATO message packaging option of Bulk Messaging,
where each message is comprised of one parent containing one or many child records. SAP does not
offer the Batch of Bulk Messaging option that bundles many parents within the one message
• AdHoc payments – the standard SAP functionality via IT0011 External Bank Transfers that generates a
bank file from specific wage types entered rather than from the pay cluster is a valid function to effect
payment but cannot be included in a discrete STP pay event, as there is no discrete ad-hoc pay result to
report. SAP will include the payment in the next regular pay, however, if the next regular pay is in a
subsequent financial year, manual overrides may be required to include the payments in a current
financial year pay event and exclude them from the next regular pay event, where relevant. The ad-hoc
payment process may be used for both advance payments to employees or to substitute for an off-cycle
when the control record for the payroll area is not in a supported status (such as Released, Corrections).

6 | 37
 Seek assistance from your tax agent or Tax Compliance Manager for guidance on if/when an override for
ad-hoc payments may be required for your specific circumstances.

1.4 SAP Software Requirements

The minimum HRSP (Human Resources Support Pack) level for the STP2 solution is:

Table 1 - Minimum HRSP Levels

Product Release HRSP Level

SAP-HR 608 A7
SAP-HR 604 H9
SAP-HR 600 L3

1.4.1 SAP Cloud Integration Requirements

To securely connect your SAP payroll to the ATO, customers must have a licence for SAP Cloud Integration:
• Minimum government security standards are set to protect the security of employee and taxpayer data
• STP-specific pricing models have been developed for market readiness (standard discount included)
• Multiple tenants are required to support the Production and Non-Production environments
• Secured, isolated tenants for Non-Production environments connect to the ATO’s External Vendor Test
Environment (EVTE) and Production environments connect to the ATO’s Production environment
• If your instance of SAP Cloud Integration is off-shore, due to your business structures, additional security
obligations from ATO apply
• Refer to your SAP Account Executive (AE) for assistance
SAP delivers the STP package and iflows in the SAP Cloud Integration Environment:
• Package Name – Single Touch Payroll (STP) Reporting – Australia
• Iflows Name – Data submission for STP reporting; and Receiving Response for STP Submission
• ebMS3/AS4 Adapter – only available for use in SAP Cloud Integration

Figure 1 - SAP Cloud Integration: STP iflows

7 | 37
2 STANDARD BUSINESS REPORTING (SBR)
SBR is a whole-of-government secure channel to communicate and exchange digital messages between
business and government. SBR uses a common dictionary of standard terms (taxonomy) and reports
(services) are designed that specify the relevant SBR taxonomy to be reported directly from business
software. DSPs develop these services to deliver the relevant fields from their products in the SBR format.
Each service has specific rules and validations that are performed in the SBR channel that must pass
through successfully to be received by the government recipient. The Australian Business Register (ABR)
program is responsible for SBR.
The ATO manages the STP2 service and DSPs must successfully complete Extended Conformance Testing
(tests against ATO requirements, results assessed by the ATO) in order to be whitelisted (approved for
commercial release) for each technology product.

2.1 Digital Messaging

The digital message of the STP2 pay event is comprised of two-part envelopes (ebMS):
• A set of layered extensions to the SOAP protocol, providing security and reliability features, enabling e-
commerce transactions.
• ATO is using the ebMS3 standard with the addition of the AS4 profile payload (XML)
• Allows for a standard base to communicate and exchange business information between parties
• This is the chosen format for SBR and provides consistent reporting for agencies using the associated
taxonomy
Details of SBR requirements can be found on the SBR website.

Figure 2 - Structure of the ebMS user message

Underlying Protocol Evnelope (HTTP, SMTP..)

SOAP with Attachments MIME Envelope
MIME Part ebMS user message is just a SOAP message that has an additional eb:message
SOAP Envelope header element that contains details about the enclosed business message
SOAP Header
Eb: Message Message structure is defined in the SBR ebMS3 WIG, ATO Common MIG and
Eb: UserMessage per service MIGs
Eb: MessageInfo Message identification, timestamp and other links
Eb: PartyInfo Identification of communicating business partners
Eb: CollaborationInfo Collaboration parameters, agreements, service info
Eb: MessageProperties Other message properties with business relevance
Eb: PayloadInfo Manifest for payload elements

Security Header
SAML Token SBR messages include a SAML token and M2M credential in the SAP Security
M2M Credential (X.509 Certificate) Header

Signatures

SOAP Body
<Empty> SOAP body will be empty for ATO services

MIME Part(s) The actual business message is attached as a MIME part

Payload(s)
Business Message(s) There could be 0 or more additional MIME Parts that contain business
messages as payloads. Business message is in XML format for STP

8 | 37
2.2 ebMS3/AS4 Adapter
The ebMS3 messaging for STP requires the SAP Cloud Integration to perform the further compression of the
XML payload, form the message wrapper and to secure the message using the customers own Machine-to-
Machine (M2M) credential.
The message header identifies the reporting parties (employer ABN/Branches as defined in SAP T5QGP)
and intermediaries (for SAP customers, this is usually the head office of the related parties) that represents
the ABN owner of the M2M credential. These details are required for authentication and authorisation
purposes.
SAP does offer limited support for those customers who choose not to use the SAP end-to-end whitelisted
solution and choose, instead, to partner with an external third-party (SSP: Sending Service Provider) to
handle the XML payload from SAP. In these circumstances, the message wrapper and security protocols are
handled external to SAP.
SAP uses the ebMS3/AS4 Light Client conformance policy that requires manual pushing of the message to
the ATO and manual retrieval of message responses from the ATO.

2.3 SAP Cloud Integration

SAP Cloud Integration connects SAP cloud and on-premise applications with other SAP and non-SAP cloud
and on-premise applications. This service has the capabilities to process messages in real-time scenarios
spanning different companies, organizations or departments within one organization.
There are extensive resources and uses for SAP Cloud Integration and this is the only integration option
that delivers connectivity with Australian Governments due to the high security standards and messaging
protocols. The full details of the security protocols can be found in the Feature Scope Description
[ HYPERLINK FOR PDF DIRECT DOWNLOAD ] document.
Typically, the tenants for Australian payroll will be operated from the SAP Australian Data Centres, however,
if global business structures require the use of off-shore SAP Data Centres, then special security processes
are required by customers as part of the ATO Operational Security Framework requirements. Liaise with
your SAP Account Executive in these circumstances.

2.4 Pay Event Service

The ATO Single Touch Payroll Pay Event service (PAYEVNT.0004 2020) is sent using ebMS3/AS4 Bulk
Message types. This means that each message contains a single payer header (parent, employer)
containing one or many payee record/s (child, employee).
The pay event service supports two actions:
• Submit action – the legal obligation to report payments subject to withholding on or before payday,
subject to penalty. Penalties may be applied by the ATO for missed reports (FTL – Failure to Lodge), with
increasing amounts for each period of 28 days overdue
• Update action – to transition in to STP, correct a successful previous submit action, to finalize the
existing records of employees and to amend prior financial year finalized employee records
The payee record has undergone significant restructuring from the initial phase of STP. The timing, process
and scope of the payments to be reported have not changed in STP2 from the initial phase of STP. Regular
pay cycles and off-cycle payment business processes must include steps for sending a submit action.
Note that on-demand off-cycles and ad-hoc (IT0011 External Bank Transfers) payments are not supported in
the SAP STP/STP2 solutions.
There are extensive field validations and rules for the fields in the pay event that have been enforced by SAP
to prevent customers from having their messages rejected in the SBR channel, forcing error-handling
processes to be performed.

2.5 Message Responses

When the message successfully makes it through the SBR channel and key validations are performed
against government databases, the ATO message response is formed and available to be pulled back into
SAP via SAP Cloud Integration.

9 | 37
The technical structure of the message response is as follows:

Figure 3 – Structure of the ebMS message response

Underlying Protocol Evnelope (HTTP, SMTP..)

SOAP with Attachments MIME Envelope
MIME Part ebMS user message is just a SOAP message that has an additional eb:signal
SOAP Envelope header.
SOAP Header
Eb: Message Message structure is defined in the SBR ebMS3 WIG, ATO Common MIG and
Eb: SignalMessage per service MIGs
Eb: MessageInfo

Eb: PullRequest
or
Eb.Receipt
or
Eb: Error

Security Header
SAML Token

M2M Credential (X.509 Certificate)

Signatures

SOAP Body
Fault Block (When Error) SOAP body is empty for Signal Messages, except when it s an Error. In which
case a Fault Block will be present.

When polling the ATO systems (pulling back into SAP) for the message response, possible responses are as
follows:
• Accepted by ATO – the message has passed validations for parent and all child records and the process
is now complete, lodgement obligation met
• Partially Rejected – the message has passed validations for parent and at least one child record,
although there are child records that failed field validations and further action is required to investigate the
root cause, fix the problem and generate an update for those rejected child records or to include those
employees whose records were rejected in the next submit in same financial year as the rejected file.
This is highly unlikely to occur in SAP as all field validations are enforced. Lodgement obligation to report
“on or before payday” has been met and the rejected employee (child) records are now part of the
corrections framework (customers have until the next regular cycle in the same financial year to correct
these rejected records).
• Rejected by ATO – the message has failed validations at the parent level or all of the child records, it is
as if you never sent the file, as no lodgement obligation has been met. This may occur for data that SAP
cannot validate, as it is externally controlled, such as for an ABN/Branch that is no longer active or valid
or for customisations performed by the customer instead of the standard SAP whitelisted solution. Further
action is required to investigate the root cause, fix the problem and generate another submit (if the file
rejected was a submit) or an update (if the file rejected was a submit). You cannot satisfy your legal
obligation by sending an update to replace a submit, as a submit is required to meet the obligation to
report payments subject to withholding “on or before payday”. In some circumstances, the file may have
been rejected due to interactive-errors that cannot be enforced in SAP, such as for sending a prior FY
update for data (employee/payment date) that was not reported via a submit action for payment dates in
that financial year. This scenario is not permissible and attempts to do so will result in rejected files
Messages with these sub-statuses cannot be executed further. Attempts will result in a log display advising
that further action cannot be taken.

10 | 37
2.6 Government Security Protocols
Taxpayer data containing identity details and TFN (tax file number) is highly secured via encryption and must
be further secured using SAML (Security Assertion Markup Language). SAML is an XML-based open
standard for transferring identity data between two parties:
• Identity Provider – performs authentication and passes the user’s identity and authorization level to the
service provider
• Service Provider – trusts the identity provider and authorizes the specific user to access the requested
resource
The whole-of-government SAML is the Machine-to-Machine (M2M) credential that is created in Relationship
Authorisation Manager and permissions between related entities that is managed via ATO Access Manager.
All guidance on the use of renewal of M2M credentials can be found on the government websites
hyperlinked above.
The SAP STP solution requires customers to load their M2M credential into the SAP Cloud Integration
keystore. A valid M2M credential is required to send and secure the pay event to the ATO. The M2M
credential is issued in XML format and this must be converted to JKS format for SAP Cloud Integration. This
is done via Java Eclipse.
Refer to details in SAP Notes 2705107, 3154267, and 3109579.
The following diagrams are taken from the SAP M2M Credential Management presentation in the SAP STP
Jam Group Contents directory.

Figure 4 - M2M Credential Renewal Process

11 | 37
Figure 5 - Convert M2M Credential XML to JKS Format Process

Figure 6 - M2M Credential Permissions Process

12 | 37
Figure 7 - Revoke the M2M Credential Process

The M2M credential outlined above is required for the Production tenant, as this connects with the ATO
Production environment. The non-production environments have an ATO-issued M2M credential, updated
periodically by ATO and made available to SAP customers via SAP Notes.

2.7 Interdependency between Government Security and the SAP STP2 Solution
The process, once the message enters the SBR channel, is as follows:

Figure 8 - SBR Channel Validation Process

SAP CLOUD INTEGRATION PUBLISH TIMETABLE

• Sending Party defined by M2M credential • From Send to Publish is maximum 72 hours
• Must be employer or intermediary

SBR Channel ATO Systems

MESSAGE STRUCTURE PUBLISH
Error: SBR.GEN message
• Employee data published to Income
• SAP Cloud Integration must be set up in accordance with Statements (latest Run Date/Time Stamp)
the SAP guidelines. Cannot proceed any further,
• Employer data published to Online
configuration must be fixed if errored at this stage
Services for Business
AUTHORISATION PERMISSIONS ANALYTICS
Error: CMN.ATO.AUTH message
• Internal assessment to ensure
• The related entities configured in T5QGP do not reflect compliance and detect anomalies for
the business permissions granted in ATO Access investigation
Manager. Revise permissions. Matched: Taxpayer identity known
ABN BUSINESS REGISTER TAXPAYER IDENTITY DATABASE
Error: Rejected by ATO message due to Parent failure
• Full tax payer identity details that are
• The validity of the ABN and Branch, PAYGW used to uniquely identify an individual
registration and relationships between the entities must
be valid to pass the Parent record and proceed with • Cannot publish unless identity known
Child record validations TAXPAYER IDENTITY
CHILD RECORD VALIDITY
• Cross-referencing the payee identity
• The validity of the every field in the child records details with Tax File Numbers to
against the technical requirements to ensure data identify which tax payer records will
meets the validation and business rules for STP be updated
Error: Rejected by ATO message due to all Child failures Unmatched: Monitor until identity known
Warning: Partial Rejection due to some Child failures Incorrect TFNs: Letter sent to employer
Accepted by ATO: Parent and all child records passed

13 | 37
The Sending Party is a field captured in the ebMS3 message header that is derived from the comparison
between the M2M credential owner (T50BK-AUSKY) and the employer (T5QGP-ABNUM), the intermediary
(T5QGP-INABN) or registered agent (T5QGP-EMNUM). Permissions must exist in the ATO Access Manager
between the employer and intermediaries or registered agents. The permissions exist to check to see if the
sending party has been authorised by the reporting party (employer) to send data on their behalf.
Unlike other payroll products that use ebMS3/AS4 adapters owned by third parties, the SAP STP solution is
for employers or their intermediaries to send their own data from their own adapters with their own M2M
credentials.

Figure 9 - Interdependency between Government Security and SAP

ATO Access Manager SBR Channel → ATO

Related Entity
T5QGP: Intermediary ABN
Business
Permissions Registered Agent
myGovID T5QGP: Intermediary ABN/RAN Access SBR Channel authorisation checks
Administrator Manager Validation against Access Manager
Either the Employer ABN or Intermediary ABN must be the M2M credential owner, or file rejected as unauthorised

SAP ERP SAP Cloud Integration

T5QSO
PA0188
PA0227 ABN of Device
PA0002/21
PA0006 STP Pay M2M Credential Owner
PA0105 Master Data Direct from CI KeyStore
Event Declaration B2A M2M Credential Owner ABN:
PA0001 T50BK
SABN Ready
ACRT Validate else else
AETP to Send
Reconcile
PC261A M2M
Registered Intermediary Employer
Payroll Data Field validations, PUSH Credential Agent ABN ABN ABN
authorisation checks
Message to ATO
T5QGP on report generation Derived from Payload
T512W PULL
T5QPC Reporting Party: Party Role/Type
T5Q30 Response from ATO
T50BK else else

Configuration If not true and correct, then fix

Message
Header Registered Business Business
T5QGP Employer (mandatory) Agent Intermediary ABN
(ebMS3) RAN ABN
Payer ABN/Br or WPN
Related Entity (conditional) M2M credential owner if ≠ Employer Payload including declarations
Intermediary ABN and key details from T5QGP
Registered Agent (conditional)
Pay Event
Intermediary ABN and RAN (XML)

14 | 37
3 THE STP2 SOLUTION
The following sections detail the configuration, functionality and business processes required for Single
Touch Payroll Phase 2 in the SAP solution.
What hasn’t changed between the initial STP solution and the new STP2 solution in SAP:
• Process to send the declared pay event to the ATO and to retrieve message responses
• Timing of the process to report on or before payday for all regular and off-cycle payments subject to
withholding
• Payments subject to withholding in scope of STP
At a high level, what has changed with STP2:
• Payments must be separately identified into discrete labels rather than reporting an aggregated gross
amount, required for use by Services Australia in administering social security benefits
• Child Support deductions and garnishees may be voluntarily reported in the pay event, relieving the
employer of their obligation to separately report to the Child Support Registrar
• Additional fields are reported that further define the employment relationship of the employee and may
relieve or reduce the need to provide Services Australia with Employment Separation Certificates
• Granular level of data provides the Australian Taxation Office with more insight into your governance over
tax and superannuation obligations

3.1 Solution Overview

This section provides an overview of the end-to-end process to send pay event data to the ATO on or before
payday. STP is designed to meet your ATO reporting obligations by aligning it with the natural business
processes of payroll. For each regular or off-cycle payroll, you must send a validated and reconciled pay
event that is declared by an authorised user in your organisation to be ‘true and correct” subject to penalty.
The userid of the declarer is included in the pay event, along with the best contact person for the
Government to contact in your organisation to discuss details in the pay event.
Your obligation is met when you confirm that your “approved form” has been successfully lodged with the
ATO. This process enforces accountability for the accuracy of payments subject to withholding and
superannuation guarantee liabilities.

3.1.1 Message Exchange

Figure 10 - Single Touch Payroll End-to-End Solution Overview

SAP ERP SAP Cloud Integration SBR → ATO

Creates Transforms
Data Store
Submission Id to XML PUSH PUSH
request request Channel Validations
STP Pay PUSH ebMS3/AS4
Master Data SOAP
Event Declaration B2A responses
PUSH PUSH
response Integration flow response
for PUSH
PULL PULL
Payroll Data
Status: request request
New/New PULL ebMS3/AS4
SOAP
responses
PULL PULL ATO Back End Systems
Data Store
response Integration flow response
Data Store Data Store

Configuration for PULL

End User Experience Technical Connectivity

15 | 37
The pay event data is an output of payroll and, upon declaration that the validated and reconciled data is
“true and correct”, is transformed into an XML payload in the B2A queue to be sent to the ATO. After
sufficient time for the data to be validated in the SBR channel and every child record is processes, a
message response will be available in ATO systems that must be pulled back into SAP and reviewed to
determine if the legal obligation has been met or if further action is required to meet it.

3.1.2 Business to Authorities (B2A)

The B2A manager is a transaction commonly used by countries for managing files that need to be sent to
authorities (governments, kingdoms etc). B2A is used to initiate communication with the ATO for STP. The
formation of the initial message, sending the message and retrieving the message response from the ATO is
all performed in B2A.
The messages displayed in B2A are shaded using the traffic light colours associated with the success or
failure of each sub status

Figure 11 - Message Responses in B2A

The history of each object can be displayed including the contents of the message. The message may
display different items, depending on the sub status:
• New – the XML payload can be viewed or downloaded
• All others – the detailed message explaining the response/sub status of the message. For example, if a
message is partially rejected, it will display the details of the errors.
Default view enables the user to select the following options:
• Area – QATO is specific to the digital services for the Australian Taxation Office
• Document Class – STP is specific to the initial phase of STP and STP2 is introduced for phase 2. This is
required to group similar document types for ease of business process and user experience
Further options are permissible to control the document types viewed:
• Only Display Open Processes – this is checked by default to only display those documents that may be
executed or have yet to be successfully completed. Documents that have been successfully completed
will no longer be displayed. These may be displayed by unchecking this option
• Log – this is checked by default to display the transaction log that provides immediate feedback on the
status of the message. To ensure legislative obligations have been met, this should remain checked, else
the user will be presented with a message at the bottom of the screen to advise the completion of the
step only
• Simulation – this is not checked by default for QATO/STP* as simulating the sending or pulling of
messages is not relevant for Single Touch Payroll services
The B2A Manager has detailed documentation explaining the functionality and features. This can be
accessed by selecting the information icon next to the SAP command field.

Refer to section Error! Reference source not found. Error! Reference source not found.

16 | 37
3.1.3 Transitioning to STP2
Other than SAP-selected pilot customers, who take on the burden of testing the solution in advance of the
remaining SAP customers to identify gaps and are supported to transition at the start of the financial year,
remaining customers will transition in the middle of the financial year, unless they have employer deferrals
with the ATO to transition in subsequent financial years.
SAP has a Mid-Year Go Live (MYGL) utility that must be run for those customers transitioning other than at
the start of the FY, as the prerequisite to running the STP2 report. It will read the critical master data, payroll
data and configuration and modify specific payroll cluster tables for all payroll clusters in the FY of transition.
It writes the Income Type and Country/Region Code to TAXP, ACRT and AETP. This utility may be used
multiple times, as it will also apply this same methodology to correct any corrupt data that may be
inadvertently created in production payroll if configuration or other data is incorrect.
For example, if T5QGP is incorrectly configured and has resulted in invalid ABN/Branches in the payroll
cluster, fixing the configuration and running the utility will replace the invalid ABN/Branches in the payroll
cluster with the correct ones.
Additionally, if there is occasion to need to retroactively assign a different income type and country code in
IT0188, standard functionality will only apply the income type/country code to the current (In-Period) result,
requiring manual overrides to effect the retroactive changes. Alternatively, the MYGL utility may be run to
assign the correct income type/country code without the need to create manual overrides.
The MYGL utility must read an extensive range of data and create a relatively significant volume of changes,
so may be managed accordingly.
The MYGL utility is also used to perform EOFY lump sum E (LSE) adjustments by reading the PASUM table
in the payroll cluster and creating an override upload file to reduce the specific income type/country code
wage types from the payment types in STP2 and create the LSE amounts per financial year.

Figure 12 - Purpose of the MYGL Utility

TAXP Report
AETP
Write
ACRT

SABN
Start Pay
MYGL
Pay Event Production
2020

Read
RT
CRT
Report

1 July 30 June
Pay Event
2018

Master Config
Data T5QGP
IT0001
IT0188 Transition

17 | 37
3.1.4 Business Process
The pay event is included in the following business processes: Pay Production; Post-Pay Production; End of
Financial Year and Amendments (corrections to finalized pay events).

Figure 13 - Single Touch Payroll Business Process

Master
Data Overrides Configuration

Outputs of Payroll

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

L PUSH

Exit pay
STP Pay B2A Message Monitor End
Disburse Auto-finalise Declaration
period Event Live Response Outcome
other payroll then finalise PULL
report (L)
outputs or unfinalise B2A

The Pay Production process is the primary process for STP however, other processes may be impacted to
ensure master data is valid and available for inclusion in the pay event.
Whilst there are extensive detailed business processes that are pre-requisites for this process and many
after this process, it is important to understand that the pay event submit action must be sent:
• On or before payday, may be in advance, late submit actions (pay event) may attract penalties
• For every regular pay period and off-cycle payment, noting that on-demand off-cycles are not supported
for inclusion in the SAP STP2 pay events

3.1.5 STP2 Data Tables

The pay event may be run in both test and live mode. Feature 13STP provides the system control to prevent
users from creating live pay events until after the regular pay period has been exited. This control is similar to
that for the financial postings, to prevent accidental sending of files before the payroll is completed.
When the pay event is run live, the data is saved to specific STP tables. With STP2, new tables have been
created and a new option that will allow the user to choose if their test pay events also save data in the STP2
tables. The data is saved with a status that defines it as test and will not enable declaration or sending of test
files.
Additionally, with STP2, a new table is created to store the logs of the warnings and error messages from all
layouts. This full transparency supports extensive reporting options for internal validation and reconciliation
reporting and error-handling. Additionally, all layout logs in one table allows for quick overview of all layout
logs together.
The payee layout contains those financial amounts that are not included in the income stream collection
tuple of the pay event data structure. They have a one-to-one relationship with the payee and are defined in
the ATO requirements as Other Components. Both the income stream collection layout and the Allowances –
Other/LSE/ETP layouts represent the income stream collection tuple of the pay event and may have a one-
to-many relationship with the payee. That is, a payee may have more than one income stream collection if
there are different income types and/or country codes for the payee.
The income stream collection layout displays columns for the fields per income type/country code, where an
employee may have more than one row if they have more than one income type/country code.

18 | 37
The allowances – other/LSE/ETP layout contains those items in the income stream collection (data structure)
that have tuples that are displayed as one or many rows. It has been discretely displayed to ease the user
experience.

Figure 14 - STP2 Data Tables

All logs from all layouts can be viewed in Display, Finalise, Declare (transaction: PC00_M13_STP2_DD)

Income Allowances-
Payer Payee Stream Other/LSE/ Error Logs
Collection ETP

Other Components

T5Q_STP2_ER T5Q_STP2_EE T5Q_STP2_PAY T5Q_STP2_LOG

T5QSO

3.2 Solution Configuration

Whilst STP2 has introduced relatively minimal configurations, this section will review all configuration
required for Single Touch Payroll. Detailed insight into the logic used by SAP to generate the Pay Event can
be found in other SAP supporting workbooks.

3.2.1 STP2 Transition Date (T5Q_CONSTANTS)

There are many complexities to the ATO requirements for STP2, particularly with respect to dealing with
“mandatory” fields that are new and have not been previously captured and stored by employers. There is
also the complex issue of when each customer may choose to transition to STP2 and their need to perform
prior FY updates.
This complexity has been addressed by SAP in configuration and logic, so that customers do not need to
manually address these complexities. Furthermore, SAP’s solution for STP2 means that, once transitioned to
STP2, the customer can no longer use the solution for the previous phase of STP.
This mutually exclusive use of the pay event services is due to the re-use and modification of the evaluation
class 13 values that have been aligned to the disaggregated approach to gross income. It is not backwards
compatible with the PAYEVNT.2018 service (STP phase 1), as that range of fields and validations are
significantly different from this phase of STP.
Once configurations are changed, the STP programs become invalid:
• Pay Event Generation – PC00_M13_STP_GEN (Program: RPCSTPQ0)
• Pay Event Display, Finalize and Declare – PC00_M13_STP_VIEW (Program: HAU_DISPLAY_STP)
• Mid-Year Go Live Utility - PC00_M13_CLST_MYGL (Program: RPCMYGQ0)
New STP2 programs replace those deprecated programs. Other existing programs have been modified to
span use for both phases, such as:
• Override Direct Entry - PC00_M13_STP_OVR
• Override File Upload - PC00_M13_STP_OVR_UPL
• Send to ATO - PC00_M13_STP_SEND or PB2A (Program: H99_B2AMANAGER)
A view has been created for the STP2 transition table to enable it to be maintained via transaction SM30
(view: T5Q_CONSTANTS):

19 | 37
Figure 15 - T5Q_CONSTANTS

The STP2 transition table (T5Q_CONSTANTS) is used in many functions and programs:

Figure 16 - T5Q_CONSTANTS: Where Used

T5Q_CONSTANTS

WORKING HOLIDAY MAKERS

TRANSITION DATE
• Determines use of WHM Flag (pre-STP2) in
• Must reflect payday of the first pay to transition ACRT/AETP and T5QSO overrides

INCOME TYPE-COUNTRY/REGION CODES

MID-YEAR GO LIVE
• Determines the inclusion of the Income Type and
• Checks that the financial year is greater than or
Country/Region Codes in ACRT/AETP
equal to the STP2 transition year
OVERRIDES
GENERATION of PAY EVENT
• Determines the fields required for the override entry:
• Checks that the financial year of the system date WHM Flag (pre-STP2 transition), Income Type,
is the STP2 transition year Country/Region Code, LSE FY (STP2 only)

VALIDATION RULES TAX CHANGES

• Determines application of field validation rules on
• Some ATO validation rules stipulate different field
values based upon the Pay/Update Date of the IT0188 Taxation Australia
pay event in relation to the STP2 transition date • If default date of 31.12.9999 then applied from
01.07.2022 else customer-specific date is used for
records that do not span that date

Once modified from the SAP-delivered value of 31.12.9999 to reflect the customer-specific transition date, it
must not be modified once in the production environment. More information about each of the impacts is
provided in the relevant sections in this document.

3.2.2 ebMS3/AS4 Integration with Payroll (T50BK)

Key data is required for STP2, similar to the initial phase of STP, to provide integration between ERP payroll
and the ebMS3/AS4 adapter (SAP Cloud Integration). As such, the same constants that were defined for
STP are required for STP2 in T50BK. These values are pre-delivered by SAP and must be copied from
Client 000.
However, there are 2 critical constants that must be maintained by customers:
• BMSID – the same Business Management System Identifier must be used as the existing STP BMSID.
BMS Id is critical in STP to define the specific instance of payroll from which the pay event is sent. It acts
as a serial number and is a virtual third dimension to the ABN/Branch of the payer. YTD amounts
reported are assigned to the ABN/Branch/BMS Id/Payroll Id and this is the grouping the ATO uses to
publish Income Statements. Changing BMS Ids have significant implications for both the employer and
employee. Ensure your GUID for STP2 as for STP. The start date for the BMSID should be the same
start date as the STP BMSID constant.
• M2M – this is the same government security credential as the AUSKY for STP, updated to reflect the
introduction of myGovID and the machine-to-machine (M2M) credentials. This reflects the owner of the
credential that has been loaded into the ebMS3/AS4 adapter (SAP Cloud Integration) keystore. It is used
when the pay event is generated to perform a critical validation. Either the employer or the intermediary
must have the ABN of the M2M credential owner, else the message will fail in the channel. This SAP
validation will prevent significant re-work by customers.

20 | 37
All other constants in this table reflect the technical details stipulated by the ATO for the PAYEVNT.0004
2020 service. They must not be modified.

Figure 17 - T50BK Integration between ERP and SAP Cloud Integration

Start of FY you went

live with STP1
Start of FY you are
ATO technical start transitioning to STP2
date of the service E.g.: 01.07.2022*

* Dates in screenshot reflect an internal SAP test system configured for testing purposes only, not a valid customer STP2 transition date

3.2.3 Employer Set Up (T5QGP)

The configuration of the employer uses the same table that has been used for Group Certificates, Payments
Summaries and Single Touch Payroll. There has been no modification to the use of T5QGP for STP2,
however, there are key points to understand about its use:
• Uniformity of ABN/Brach details – the table uses Personnel Area and Personnel Subarea as its keys.
ABN and Branch details are defined for each combination of these key fields, creating a one-to-many
relationship for the ABN/Branch employer. When the pay event program searches for data from T5QGP,
it uses the first random record to populate data in the pay event. If there are multiple uses of the ABN/Br
but the data is inconsistent, it is likely that incorrect data will be reported that may fail validations.
• Contact Details – the business and intermediary contacts logic has been changed for STP2 so that it
now reads the T5QGP effective date of the Run Date/Time Stamp for the contact details. This overcomes
the issue of prior FY updates that read historic contacts who may no longer work for the business.
The intermediary details are critically important in T5QGP for the pay event validation and mandatory field
rules. It is also used to populate payer details in the submission that are used to define which declaration
statement is presented to the declarer to meet the legal obligations defined by the ATO. It must also
represent the business permissions that have been maintained in ATO Access Manager.

Refer to 2.7 Interdependency between Government Security and the SAP STP2 Solution

21 | 37
Figure 18 - T5QGP Employer Setup

Either Employer or
Intermediary ABN
must be the M2M
credential owner If no Intermediary
ABN exists,
declaration statement
will be Employer

If Intermediary ABN
exists, declaration
statement will be
Intermediary

If SSP checked, SSP If Registered Agent

name appears, Number exists,
declaration statement declaration statement
will be Sending will be Registered
Service Provider Agent

3.2.4 Employment Termination Payments (T5QPC)

Employment Termination Payments (ETPs) represent payments made upon termination in consequence of
employment but does not include payments that are separately itemised as:
• Lump Sum D – tax-free component of a severance payment for a genuine redundancy
• Lump Sum A – annual leave , leave loading and long service leave paid out for all termination reasons
that accrued from 16 August 1978.
• Lump Sum B – long service leave that accrued before 16 August 1978
• Paid Leave U – unused annual leave, leave loading and long service leave accrued after 17 August 1993
when paid out for termination reasons other than for genuine redundancy, invalidity or approved early
retirement schemes
All other types of leave and termination payments are ETPs. There are two categories of ETPs:
1. Life Benefits – termination payments to employees
2. Death Benefits – termination payments paid to the death beneficiaries of deceased employees
ETPs are the most complex payroll transaction and the legal obligations for Fair Work, state industrial
relations departments (long service leave), state/territory revenue offices and worker safety (payroll tax and
work cover), Services Australia (employment separation certificates), Child Support (deductions and
garnishees) and the ATO (PAYGW, superannuation guarantee, STP2) significantly complicate this process.
There are a range of configuration dependencies for ETPs:
• Termination Actions and Reasons – refer to 3.2.5 Termination Action/Reasons (T5Q30)
• ETP Codes – T5QPC is required to allocate all of the ETP EVCL13 values to an ETP code. Note that tax-
free components paid to death beneficiaries are not reportable.
• Death Beneficiaries – Feature 13ETP decision tree defines a 12-char value where chars 5-12 refer to
death beneficiaries, particularly chars11-12 that define the IT0006 subtype for Trustees. When a payment
is made that is configured in T5QPC as one of the 4 death beneficiary types, it looks for data in:

22 | 37
 − IT0021 Family Members/Dependants – subtype AU01 Beneficiary’s Details
− IT0006 Addresses – subtype QB Beneficiary’s Address and subtype Q1 Trustee’s Address (as per
feature 13ETP)
− IT0227 TFN – field for Beneficiary’s TFN

Figure 19 - ETP Configuration for Pay Event

Wage Type Evaluation Class 13 T5QPC Feature 13ETP

If WT paid that has relevant EVCL13 mapped to ETP Code Char11-12 Trustee
EVCL13 value Address Subtype

AETP

T5Q30
Pay Event
Cessation Type

IT0021
IT0006 Addresses IT0227 TFN
Family/Dependants
Subtype AU01 Subtype QB/Q1 Field TBFFN

Figure 20 - ETP Codes per EVCL13 and Pay Event Field

ETP
Code Payment Type Reason Type Split Tax Free Component (EVCL13) Taxable Component (EVCL13) ETP PAYGW (EVCL13 + WT)
R Life Benefit Redundancy et al No C4 ETP - Life Benefit - Tax Free LE ETP - Life Benefit - Taxable TE Tax - ETP - Life Benefit –
Component - Redundancy Component - Redundancy Redundancy (WT /477)
O Life Benefit Other No C2 ETP - Life Benefit - Tax Free EL ETP - Life Benefit - Taxable TL Tax - ETP - Life Benefit –
Component - Other Component - Other Other (WT /471)
S Life Benefit Redundancy et al Yes C6 ETP - Life Benefit - Tax Free SE ETP - Life Benefit - Taxable TS Tax - ETP - Life Benefit -
Component - Redundancy - Split Component - Redundancy - Split Redundancy – Split (WT /478)
P Life Benefit Other Yes C5 ETP - Life Benefit - Tax Free S1 ETP - Life Benefit - Taxable S4 Tax - ETP - Life Benefit - Other
Component - Other - Split Component - Other - Split – Split (WT /474)
D Death Benefit Dependant No -- Not reportable -- DE ETP - Death Benefit - Taxable T1 Tax - ETP - Death Benefit –
Component - Dependant Dependant (WT /479)
N Death Benefit Non-dependant No -- Not reportable -- ED ETP - Death Benefit - Taxable TD Tax - ETP - Death Benefit -
Component - Non-Dependant Non-Dependant (WT /473)
B Death Benefit Non-dependant Yes -- Not reportable -- S3 ETP - Death Benefit - Taxable S6 Tax - ETP - Death Benefit -
Component - Non-Dependant - Non-Dependant – Split (WT /476)
Split
T Death Benefit Trustee No -- Not reportable -- DT ETP - Death Benefit - Taxable -- Not applicable --
Component - Trustee

If the wage types have been correctly configured, they will not only be stored in ACRT, but will be stored
separately in AETP where the wage types are grouped by ABN, Branch, Income Type and Country Code,
Payment Date and ETP code. If the ETP you have paid does not appear in AETP, the configuration is
incorrect.
ETPs are slightly different from other payment types reported, in that they are not “YTD amounts” as they
must be reported as positive amounts per payment date for each ETP code. If you correct an ETP
overpayment, AETP entries will reflect negative amounts for the ETP code/payment date. You must
manually override the negative entries (in T5QSO) that are created for the overpayment correction payment
date to offset them against the termination payment that was overpaid.
Note that monies that were owed to employees when the deceased, such as salary and wages, unused
leave, bonuses etc are NOT ETPS nor are they reportable or taxable.

23 | 37
3.2.5 Termination Action/Reasons (T5Q30)
The existing purpose and use of T5Q30 has been extended for STP2 due to the new field for Cessation
Type. This table has been used previously for Group Certificates, Payment Summaries and Single Touch
Payroll to define which actions and reasons represent the ATO definition for genuine redundancy, invalidity
and approved early retirement termination reasons for Lump Sum A purposes. The ATO requires that Lump
Sum A amounts must be reported against the category of termination, although taxed the same. The reason
this is still required is to accommodate more than one occurrence of termination over one or many
employment periods. For STP2, instead of only those action/reasons, now every termination action/reason
must be mapped to the relevant Cessation Type.
Dual purposes of T5Q30 are as follows:
• Lump Sum A – all Lump Sum A (LSA) wage types should be configured with EVCL13-GA Gross Lump
Sum Payments – A. For those termination actions/reasons that meet the definition of ATO’s “redundancy
et al”, these must be mapped to relevant Category Reasons. When the payroll schema runs, if there is a
LSA payment, it reads the action/reason in the cluster (WPBP) and cross-references it with the Category
Reasons for: 01 – Redundancy; 02 – Invalidity; 06 – Approved early retirement. If it is one of those
specific action/reasons, then WT /LSA is generated in the pay results. As this wage type is mapped to
EVCL13-GR, then the lump sum A payments will be reported as Lump Sum A – Type R
• Cessation Type – introduced for STP2 to reduce the burden on employers of having to create
Employment Separation Certificates (SU001) on request. This way, for every employee who terminates,
reporting the cessation type will streamline Services Australia’s processes to support your employees if
they are also customers of Services Australia. All actions and reasons for termination must be mapped
and will be reported when there is a cessation date present. Whilst the definitions are generally obvious,
there are two cessation types that must be called out to ensure every customer has a discrete termination
reason that can exclusively be aligned to the following:
− Contract Cessation – if the employee was engaged for a fixed duration, or the casual employee is no
longer required, this reason must be separately identified, as it is distinct from a voluntary cessation
and has social security implications
− Transfer – if the employee is being transferred between the employers’ payrolls as an administrative
process or transferred between in-house and outsourced payroll providers or across related entities,
across government departments/agencies then this reason must be separately identified to inform the
government that it is a technical termination, but the employment relationship has not ceased.
This mapping exercise (T5Q30) is not effective-dated and will apply to historical terminations as for current
terminations. If there has been an historical change in termination action/reasons and an employee with
those reasons is included in the pay event (including prior FY updates), then the mapping is required. There
should be at least one discrete termination action/reason for each of the Cessation Type codes.
Services Australia has not disclosed how they will determine the period covered by any unused leave or
termination payments that is not reported via STP2. These Cessation Types do not align with the types on
the Employment Separation Certificate, as those types are for more qualitative HR purposes than the payroll-
specific leave and taxation reasons that, at least, need to be captured in payroll to meet legislative
obligations.
The Cessation Type field is conditional in the pay event on there being a Cessation Date reported. SAP
sources that data from IT0000 Actions where employment status = 3 Withdrawn from historical dates to the
Pay Period End Date + 1. Future-dated terminations will not be reported, other than where the first day of
withdrawn status is the first day of the next pay period. There are ATO validation rules specific to these fields
to prevent invalid data from being sent.
This field in the pay event provides significant data, not only to the ATO, Services Australia and Child
Support, but also for the Australian Bureau of Statistics for their Labour statistics that inform economic policy
and analysis. It is vital that rigor is applied to the mapping of this key data.
The seven Cessation Types are illustrated in the diagram below and include:
• V – Voluntary cessation
• R – Redundancy
• I – Ill-health
• C – Contract cessation

24 | 37
• F – Dismissal
• T – Transfer
• D - Deceased

Figure 21 - T5Q30 Cessation Types per Termination Action/Reason

Ensure you understand the purpose, specifically, for Cessation Type Codes C and T.
Ensure you have discrete Termination Action/Reasons for those purposes.

Category for ATO Mapping to ATO

“Redundancy et al” STP2 Cessation Type

3.2.6 Wage Type Evaluation Classes (T512W)

Evaluation Class 13 has been revised for STP2 and, once the configuration change to wage types has been
transported into the relevant environment, PAYEVNT.2018 (initial phase of STP) can no longer be
generated. Evaluation Class (EVCL) 13 values are as follows:

Table 2 - Evaluation Class 13 values for STP2

EVCL13 Evaluation Class 13 value and description

AK AK - Task Allowances
AQ AQ - Qualifications/Certificates
AT AT - Tool Allowances
BC BC - Bonus and commissions
C2 C2 - ETP - Life Benefit - Tax Free Component - Other
C4 C4 - ETP - Life Benefit - Tax Free Component - Redundancy, etc.
C5 C5 - ETP - Life Benefit - Tax Free Component - Other - Split
C6 C6 - ETP - Life Benefit - Tax Free Component - Redundancy, etc. - Split

25 | 37
EVCL13 Evaluation Class 13 value and description
CA CA - Allowance - Car (pre-STP2)
CD CD - Gross Payments - CDEP (pre-STP2)
CG CG - Deduction - Child Support Garnishee
CK CK - Cents per Kilometre
CS CS - Deduction - Child Support
DE DE - ETP - Death Benefit - Taxable Component - Dependant
DF DF - Directors' Fees
DT DT - ETP - Death Benefit - Taxable Component - Trustee
ED ED - ETP - Death Benefit - Taxable Component - Non-Dependant
EL EL - ETP - Life Benefit - Taxable Component - Other
FB FB - RFBA Reportable Fringe Benefits Amount - Taxable
FE FE - Exempt Foreign Income
FT FT - RFBA Reportable Fringe Benefits Amount - Exempt
G1 G1 - Gross Payments
GA GA - Gross Lump Sum Payments - A
GB GB - Gross Lump Sum Payments - B
GD GD - Gross Lump Sum Payments - D
GE GE - Gross Lump Sum Payments - E
GF GF - Gross Payments - Foreign Employment (pre-STP2)
GR GR - Gross Lump Sum A Type R else T
GW GW - Gross Lump Sum Payments - W
JG JG - Gross Payments - JPDA Foreign Employment (pre-STP2)
JT JT - Foreign Tax Paid - Foreign Employment JPDA (pre-STP2)
JW JW - Tax - Gross JPDA Foreign Employment (pre-STP2)
LA LA - Allowance - Laundry
LE LE - ETP - Life Benefit - Taxable Component - Redundancy, etc.
MA MA - Allowance - Overtime Meals
OC OC - V1 Private Vehicle
OF OF - T1 Transport/Fares
OG OG - G1 General
OH OH - H1 Home Office
ON ON - ND Non-Deductible
OT OT - Allowance - Other (govt policy WTs only)
OU OU - U1 Uniform
OV OV - Overtime
P1 P1 - Parent Gross Adjustment
P2 P2 - Parent PAYGW Adjustment
P3 P3 - Parent CS Garnishee Adjustment
P4 P4 - Parent CS Deduction Adjustment

26 | 37
 EVCL13 Evaluation Class 13 value and description
PA PA - Paid Leave - Ancillary/Defence
PC PC - Paid Leave - Cash out of leave in service
PO PO - Paid Leave - Other
PP PP - Paid Leave - Parental
PU PU - Paid Leave - Unused leave on termination
PW PW - Paid Leave - Workers' Compensation
S1 S1 - ETP - Life Benefit - Taxable Component - Other - Split
S3 S3 - ETP - Death Benefit - Taxable Component - Non-Dependant - Split
S4 S4 - Tax - ETP - Life Benefit - Other - Split
S6 S6 - Tax - ETP - Death Benefit - Non-Dependant - Split
SA SA - RESC Reportable Employer Superannuation Contribution
SE SE - ETP - Life Benefit - Taxable Component - Redundancy, etc. - Split
SL SL - Superannuation Liability Amount
SO SO - Salary Sacrifice Other
SS SS - Salary Sacrifice Superannuation
T1 T1 - Tax - ETP - Death Benefit - Dependant
TA TA - Allowance - Travel
TD TD - Tax - ETP - Death Benefit - Non-Dependant
TE TE - Tax - ETP - Life Benefit - Redundancy, etc.
TF TF - Foreign Tax Paid - Foreign Employment
TL TL - Tax - ETP - Life Benefit - Other
TR TR - Allowance - Transport
TS TS - Tax - ETP - Life Benefit - Redundancy, etc. - Split
TT TT - Tax - Gross Payments
UD UD - Deduction - Union Fees
WF WF - Tax on Gross FEI (pre-STP2)
WG WG - Deduction - Workplace Giving

Table 3 - Colour legend for EVCL13

Green New EVCL13 values introduced for STP2

Grey Deprecated from STP2 onwards, but historically valid (for prior FY updates)

Gold Remain in use, but some wage types to be split to other EVCL13 values

Blue Historically valid (prior FY updates) but all wage types must be split to other EVCL13 values

Drk Grn New and PAYEVNTEMP8 Other Allowance Type Description will be populated with the
EVCL13 description. E.g.: V1 Private Vehicle

OT Historically valid (prior FY updates) and any new government policy wage types required in the
future. PAYEVNTEMP8 Other Allowance Type Description will be populated with the 25-char
wage type text description (for govt policy WTs only). Non-govt policy wage types must be split
to other EVCL13 values for STP2.

27 | 37
Customers should seek qualified tax agent or Tax and Compliance Managers assistance in determining the
appropriate EVCL13 value for each wage type. To do so, it is imperative that the industrial instrument
circumstances and conditions of payment that informed the creation of each wage type is assessed against
the ATO’s requirements for income classification, as industrial instruments alone are insufficient requirement
to configure a wage type.
Additionally, STP2 has disaggregated gross from the total figure that has been historically reported to the
ATO. This is due to Services Australia’s assessment of income for social security and welfare purposes that
differs from that of the ATO.
It also relies on the Fair Work obligations to separately identify the components of pay. Marrying the
industrial, tax, superannuation guarantee and other legislative and administrative requirements for each
wage type is a significant effort with a high-risk factor for non-compliance and underpayment. This is a heavy
focus of both state/territory and federal governments and the separately identified components of STP2 will
provide transparency of your governance over these employment obligations.
The SAP EVCL13 values are used to map to specific pay event fields. Many EVCL13 values remain as they
were for the initial phase of STP, however, the following changes have been introduced for STP2:

Figure 22 - EVCL13 Changes for Allowances, CDEP

AT Tool Allowances
CK Cents per kilometre
AQ Qualifications/Certificates
Other Allowances  OC V1 Private Vehicle
OC V1 Private Vehicle
ON ND Non-Deductible
OF T1 Transport/Fares CA Allowance –
OT Allowance Car (pre-STP2)
– Other (govt OG G1 General deprecated
policy WT OH H1 Home Office
only)
ON ND Non-Deductible CD Gross Payments – CDEP
(pre-STP2)
OU U1 Uniform Leave historical WTs, as programme deprecated
OT Allowance deprecated in 2015
– Other (govt
policy WT only
Remaining Wage Types Wage Types with EVCL13-OT will use the wage type
For JobKeeper and JobMaker wage types for prior text description to populate the “Other Allowance Type
FY updates and to keep consistency of splitting
WTs for EVCL13 changes. Will be used in future
Description” field in the Pay Event, differing from new
for any new government policy wage types. “other allowances” that will use the EVCL13 name

28 | 37
Figure 23 - EVCL13 Changes for Gross and JPDA

PA Paid Leave – Ancillary/Defence

PC Paid Leave – Cash out of leave in service
PO Paid Leave - Other JG Gross Payments –
JPDA Foreign
PP Paid Leave - Parental
Employment (pre-STP2)
G1 Gross PU Paid Leave – Unused leave on termination deprecated Leave historical WTs, as programme
deprecated 30/08/2018
Payments PW Paid Leave – Workers’ Compensation
JT Foreign Tax Paid –
AK Task Allowances Foreign Employment
G1 Gross JPDA (pre-STP2)
BC Bonus and commissions
deprecated Leave historical WTs, as programme
Payments deprecated 30/08/2018
Remaining Wage DF Directors’ Fees
Types JW Tax – Gross JPDA
GW Gross Lump Sum Payments - W Foreign Employment (pre-
OV Overtime STP2)
deprecated Leave historical WTs, as programme
deprecated 30/08/2018
SO Salary Sacrifice Other
SS Salary Sacrifice Superannuation

Child Support reporting of the deductions (S45 Notice) and garnishees (S72A Notice) has commenced with
STP2. It is optional but introduced to streamline the manual monthly summary of child support deductions
and is a significant administrative saving for SAP customers.
It is important to revisit the configuration of Child Support Deductions (S45 Notice) to ensure you have
configured the wage type with Processing Class (PRCL) 64 that triggers the Protected Earnings Amount
(PEA) threshold, updated annually. Additionally, the Child Support Deduction wage type should be
configured with the highest priority deduction setting and retroactivity should be set to meet the shortfall
conditions defined by the Child Support Registrar. For example, if the employee doesn’t earn enough to
deduct the full amount due to the PEA, any arrears amounts for that shortfall period (For-Period) should
deduct the remaining (shortfall) amounts. Earliest effective date of EVCL13 for Child Support (CG/CS) is
01.07.2022.

Figure 24 - EVCL13 Changes for FEI and Child Support

EVCL13-CG cannot be < 01.07.2022

WTs split as per G1 Gross
Historically valid and required for WTs prior to STP2 ONLY wage type/s representing a S72A Child
transition, but must be remapped to the range of Support Notice issued by the Child Support
deprecated disaggregated EVCL13 values as for G1 Gross CG Deduction – Registrar under the Child Support (Registration
and Administration) Act 1988
Payments
GF Gross Child Support
Payments – Garnishee
* New *
Foreign DO NOT MAP any wage types to these
Employment EVCL13 values for voluntary Child Support
contributions created in response to a
request from the employee. Those
contributions are NOT REPORTABLE

TT Tax – Gross Payments

Historically valid and required for WTs prior to STP2 ONLY wage type/s representing a S45 Child
transition, but must be remapped to TT Tax – Gross Support Notice issued by the Child Support
deprecated Payments for STP2 CS Deduction – Registrar under the Child Support (Registration
and Administration) Act 1988. WT should be
WF Tax on Child Support configured with PRCL64 to apply the PEA.
Gross FEI (pre- * New *
EVCL13-CS cannot be < 01.07.2022
STP2)

Child Support is not permitted to be included in reporting prior to 01.07.2022, so should not be configured
with EVCL13 with an effective date prior to 01.07.2022.

29 | 37
Figure 25 - EVCL13 New values for Transferring YTD Amounts

EVCL13 effective date must be  01.07.2022 – Can only be used for STP2

P1 Parent Gross P2 Parent P3 Parent CS P4 Parent CS

Adjustment PAYGW Garnishee Deduction
* New * Adjustment Adjustment Adjustment
* New *
* New * * New *

WTs that are exclusively used to bring in closing balances from prior key identifiers (Payroll Id or BMS Id) need to
be excluded from the calculation of the Parent Period Total Amounts (PPTA). PPTA is calculated as current IN-
PERIOD amounts less the prior IN-PERIOD amounts in the same financial year. If you bring in new opening
balances, this will be included in the PPTA and overstate the amounts. Map the exclusive WTs for YTD amount
transfers to the new EVCL13 values. This will ensure PPTA are “true and correct”.
Alternatively, if you use the same WTs for opening balances that you use for payroll results, then create new
notational WTs mapped to these new EVCL13 values and create overrides that represent the YTD transfer
amounts to offset the overstated PPTA. This will ensure PPTA are “true and correct”.

An important aspect of the configuration of wage types is the effective date of the change. This will be
influenced by the timing, number of payroll areas, payment dates, status of reporting STP for completed
payrolls. This is due to the use of EVCL13 for the pay event:

Figure 26 - EVCL13 use by the Pay Event

WT 2500 Annual Leave FP

01.07.2018 → 30.09.2022 01.10.2022 → 31.12.9999 Effective Date of Configuration

EVCL13 = G1 Gross EVCL13 = PO Paid Leave Other

Transport to PRD: 27.09.2022 1 2 First payday after STP2 transition Actual System Date

Consider earliest payday of STP2

payroll areas, consider any 1 28.09.2022 GEN for first PP after transition to STP2
with payday of 05.10.2022:
updates, including prior FY
• Submit – reads EVCL13 as PO Paid Leave Other
Pay Event
• Update – reads EVCL13 as G1 Gross

Submit Update 2 02.10.2022 GEN for first PP after transition to STP2

with payday of 05.10.2022:
Reads EVCL13 as Reads EVCL13 as
at Pay/Update Date at GEN Date (Run • Submit – reads EVCL13 as PO Paid Leave Other
Date/Time Stamp) • Update – reads EVCL13 as PO Paid Leave Other

SAP customers must assess the timing of the transition to STP2 with their specific payroll areas and paydays
to determine the appropriate timing. Additionally, and most significantly, the timing of the transports of the
wage type changes to production. That is, if the configuration change of wage types is transported into
production before the business operationally transitions to STP2, the effective date of the change is
imperative to support the continued validity of reporting STP pay events in readiness for the business change
to STP2 pay events.
It may be simple or very complex, depending on your payroll organisation and timing of where in the cycle
the transports are deployed into the production environment.

30 | 37
3.2.7 Income Types
New income types and arrangements for reporting income have been introduced with STP2. Rather than the
income-specific fields and therefore EVCL13 values approach previously, the data structure of the pay event
has changed to future-proof against government policy changes. Additionally, it has been aligned to support
the ATO’s Individual Income Tax Return future roadmap. STP2 introduces an Income Stream Collection
approach to reporting commonly defined payment types.
This means that instead of having three separate Gross amounts (for SAP customers: INB, WHM, FEI) with
separate EVCL13 values (JPDA was deprecated from 31 August 2019), each defined differently, requiring
different treatment for the same wage types, the pay event has moved to a common definition, such as for
Gross, across all income types. This is a cleaner approach to wage type management.
Not all payment types are permissible for every income type. All payments, therefore, are reported per
Income Type and Country Code, where applicable. There are new Income Types used to claim a reporting
concession for specific circumstances (Inbound Assignees to Australia and Closely Held Payees for small
business only) and to separately identify key policy initiatives (Seasonal Worker Programme).
There is also a significant volume of validation rules that ATO have issued for how income must be handled
in various circumstances. These are extensive and complex but have been addressed by the SAP STP2
solution.
These Income Types have been pre-delivered by SAP and are the only income types permitted for the
whitelisted SAP STP2 solution. If customers want to extend these income types to those not included in the
SAP solution, each customer/SAP partner must register with the ATO as an In-House developer, obtain
certification and their own product id and perform the extensive whitelisting process of Extended
Conformance Testing (ECT). This is not a simple process, and the rules are complex and extensive.
Contractors are not supported in the SAP payroll solution.

Figure 27 - Income Types Whitelisted for use in SAP

Working in Australia Special Permission to Work in Australia

SAW Salary and Wages CHP Closely Held Payees IAA Inbound Assignees to WHM Working Holiday SWP Seasonal Worker
Small business ONLY Australia Makers Programme

Australians Working Overseas Out of Scope of SAP’s Whitelisted STP2 Solution

Deprecated 31 August 2019

VOL Voluntary LAB Labour Hire OSP Other Specified

FEI Foreign Employment JPD Joint Petroleum
Income Development Area Agreements Payments
Business and Personal Services income for CONTRACTORS

There are extensive ATO rules and interdependencies with other field values and validations with STP2, it is
not a simple matter to create income types for customisations away from the standard SAP supported
solution. Reporting scope is covered by detailed documented requirements from the ATO that are controlled
documents, secured for registered DSPs only.
As DSPs had to pass ECT to be whitelisted for STP2, the ATO is aware that these are the only income types
whitelisted for the standard SAP solution. Any attempt to extend income types outside of the In-House
developer process will be immediately detected by the ATO and the customer will be contacted for invalid
use of the product.
The excluded income types are not mandatorily in scope of STP2.
Additionally, to recognise legitimate non-reportable income, SAP has created an income type for EXC
Exclude (from STP2 reporting). All income types and country codes will be maintained against the employee
via IT0188 Taxation Australia.

31 | 37
Refer to Error! Reference source not found. Error! Reference source not found.

Only one Income Type can be automatically assigned for the pay cycle and manual overrides are required to
split the pay period income.

Figure 28 - T5Q_INC_TYP: Whitelisted Income Types

3.2.8 Numbering Sequences

There are number ranges to be configured to support STP. Although not changed for STP2, it is important to
understand the configuration requirements and update them if required.

3.2.8.1 B2A Object IDs (HRB2A)

For the initial implementation of STP that uses B2A Manager, the Object Ids must be configured to enable
the successful output of an object in B2A:

Figure 29 - Object IDs required for B2A submissions

Establish the STP B2A Object ID number sequence

via transaction SNRO > HRB2A > Interval 01

Use transaction SNRO > Object Name: HRB2A > select [Display] > select [Interval Editing] (F7) > select
[Change Intervals]. Create interval [01] from number [00000000000000000001] to number
[99999999999999999999] and number range status {current number in use – initially 01 then automatically
updated to reflect current number}.

32 | 37
Figure 30 - Establishing B2A Object Number Sequences: HRB2A

3.2.8.2 Pay Event Submission IDs (HR_AU_SUBI)

For each financial year of STP, a number range must be established for the generation of unique submission
Ids for each pay event. This number range is critical to the formation of the pay events:

Figure 31 - Number range required to form unique Submission Ids

Establish the STP Pay Event submission ID number sequence via transaction SNRO > HR_AU_SUBI > Number Range 01 for each financial year

Use transaction SNRO > Object Name: HR_AU_SUBI > select [Display] > select [Interval Editing] (F7) >
select [Change Intervals]. Create number range number [01] for each financial year (including future years)
from number [000001] to number [999999] and number range status {current number in use – initially 00
then automatically updated to reflect current number}.

Figure 32 - Submission Id number range: HR_AU_SUBI

33 | 37
3.2.8.3 STP Override Sequence Numbers (HR_AU_OVID)
Each entry to override the STP data in T5QSO is created with a unique sequence number:

Figure 33 - STP Override Sequence Numbers

Use transaction SNRO > Object Name: HR_AU_OVID > select [Display] > select [Interval Editing] (F7) >
select [Change Intervals]. Create number range number [01] for each financial year (including future years)
from number [0000000001] to number [9999999999] and number range status {current number in use –
initially 00 then automatically updated to reflect current number}.

Figure 34 - STP Override Sequence Numbers: HR_AU_OVID

Some customers have chosen to maintain unique numbers regardless of the financial year by limiting the To
Number to approximate the anticipated number of overrides and starting the next financial year From
Number to continue from the Number Range Status. That is an acceptable approach, however, limits must
be in excess of requirement to prevent override issues.

3.2.9 Constraints for Live Pay Events (Feature 13STP)

There are many steps to the Pay Production process that may be performed by different users. To ensure
and enforce system controls, similar to those in place for financial postings, a feature may be set to require
the payroll control record to be exited before a live document is generated. Whilst this feature was in place
for the initial phase of STP, test files did not create any data in the STP tables to support reporting to validate
and reconcile the outputs, so many customers turned the feature off and created live files to get the stored
data.
This “workaround” is no longer required, as the STP2 solution gives users the option when generating the
pay event to save the test file data to the STP2 tables. This includes error logs. As such, this feature may be
restored to enable its intended use: prevent live files before the pay is completed and to prevent accidental
misuse.
Given the business complexity of STP2, it is appropriate to ensure there are as many system controls as
possible to prevent accidental errors.

34 | 37
Figure 35 - Feature 13STP to enforce system controls

STP data is stored with a status to indicate if it is live or a test. Test files cannot be declared or sent.

3.2.10 Message Response Polling Intervals (STP_POLLING)

The ATO stipulates polling (pulling of message response) intervals from external systems to their systems,
depending on the number of records in the pay event. Breach of these polling policies has adverse impacts
on the performance of ATOs systems and may result in a phone call from the ATO about a breach of their
rules.
The polling intervals are defined in the SAP-delivered table that must not be modified by customers:

Figure 36 - Polling Intervals: STP_POLLING

3.2.11 Authorisations (P_KW_REPT)

The STP2 generation program (RPCST2Q0) requires a new authorisation object P_KW_REPT to be
assigned to the user role that will generate the pay event. The profile is not pre-delivered by SAP and must
be created by customers. Transaction PFCG can be used to create and assign authorisation profiles to
users.
Create authorisation profile ZPAXX using authorisation object P_KW_REPT with access to reports
RPCST2Q0_* and assign it to authorised users. Ensure that the authorised users with profile ZPAXX can
access all layouts:
• RPCST2Q0_ER – Payer layout
• RPCST2Q0_EE – Payee layout
• RPCST2Q0_IS – Income Stream Collection layout
• RPCST2Q0_OC – Allowances Other/LSE/ETP layout
The authorisation object related to B2A Manager is P_B2A.

35 | 37
This differs from the reports for the initial phase of STP (RPCSTPQ0) and the layouts:
• RPSTPQ0_ER – Payer layout
• RPSTPQ0_EE – Payee layout
• RPSTPQ0_ETP – ETP layout
• RPSTPQ0_DED – Deductions layout
• RPSTPQ0_ALL – Allowances layout
Transaction and program impacts of STP2 are as follows:

Table 4 - STP Programs and Transaction Changes

Program Transaction Status

RPCMYGQ0 PC00_M13_CLST_MYGL - Migration Utility for STP STP only, replaced for STP2
Phase 1 Go-live
RPCSTPQ0 PC00_M13_STP_GEN - Generate Reporting Data STP only, replaced for STP2
HAU_DISPLAY_STP PC00_M13_STP_VIEW - Reconcile, Finalize and Declare STP only, replaced for STP2
Data
H99_B2AMANAGER PC00_M13_STP_SEND - Communicate Data with ATO Unchanged, document class
and Track Responses defines STP or STP2
RPCSTOQ0 PC00_M13_STP_OVR - Maintain Override Entries Modified to support both STP
Manually and STP2 to streamline the user
experience for prior FY updates
RPUSTOQ0 PC00_M13_STP_OVR_UPL - Maintain Override Entries Modified to support both STP
through File and STP2 to streamline the user
experience for prior FY updates
RPCMYGQ2 PC00_M13_CLST_MYGL2 - Migration Utility for STP New for STP2, including the
Phase 2 Go-live enhanced Lump Sum E
requirements
RPCST2Q0 PC00_M13_STP2_GEN - Single Touch Payroll - Phase 2 New for STP2, supersedes the
-> Generate Reporting Data STP program that becomes
obsolete upon transition to STP2
RPCSTPDD PC00_M13_STP2_DD - Single Touch Payroll - Phase 2 - New for STP2, old program must
> Reconcile, Finalize and Declare Data be used to view STP pay events
SAP has delivered an enhancement spot in the STP Display Report (RPCSTPDD) to give customers an
option to secure the various transactions for specific users: auto-finalize, finalize, un-finalize, declare.
Customers may choose to manage declarations for all submissions in their payroll or may choose to have
different declarers for different ABN/Branches. The standard SAP process can be followed to secure these
transactions.

3.2.12 Employee Contact Details (Features 13PF5/4, 13PF2/3, 13ADD)

The ATO must match the employee data sent in the pay event with their internal taxpayer identity database
to inform to which taxpayer to publish the Income Statement in ATO Online. Sometimes, the data provided
by the business does not exactly match the taxpayer identity details, particularly for those with TFN
exemption codes, so data other than the employee name, address, date of birth and TFN is required.
To establish a myGov account, used to authenticate taxpayers to access government services, the personal
email address and mobile phone number are required, if it is captured in the payroll. For those employers
who record this detail, it must be provided.
SAP uses these features for other functionalities, but is used in STP to specify where that employee detail is
recorded for taxpayer identification purposes:
• 13PF5 – home email address is specified as an infotype/subtype. For example: 0105MAIL

36 | 37
 − If this is not populated, SAP will then use feature 13PF4 work email address. However, it is highly
unlikely that taxpayers set up their personal account with the government using their work email
address.
• 13PF2 – mobile phone number is specified as an infotype/subtype. For example: O105CELL
− If this is not populated, SAP will use feature 13PF3 work telephone number. However, it is highly
unlikely that taxpayers set up their account with the government using their work mobile number.
• 13ADD – specifies which IT0006 Addresses subtype will be used for STP. It has been used for group
certificates, payment summaries and STP previously. ATO require the residential address of the
employee, not mailing addresses. Historically, when physical documents were issued to employees,
many were concerned about the security of those documents so used a mailing address. With the
introduction of secure digital messaging, that is not a concern and residential addresses will assist the
ATO to identify the taxpayer.

3.2.13 Employment Basis Code (Feature 13DEG)

The existing feature used in the standard SAP report to report TFN Declaration details to the ATO
(RPCPBSQ0 Employment Declaration Details to the Australian Taxation Office) has been used to report the
same data, now included in the pay event each pay. The feature is used to map employment basis from
EG/ESG (employee groups and subgroups) to the values on the ATO TFND form: F (full-time), P (part-time),
C (casual). SAP logic will address the employment basis for death beneficiaries (D death beneficiary).
The date types on IT0041 to capture payee date of declaration and payer date of declaration (features
13DSN, 13DEN) should still be captured, but are not required to be reported to the ATO.

3.2.14 Customer-Specific Business Add-Ins (BAdi)

SAP has created two BAdis that may be used to override either specific fields or the entire dataset:
• HR_AU_CUST_REC_STP – overwrites specific records (employee data) in the STP pay event. Methods
are:
− OVERRIDE_EE_DATA_PREPROCESS
− OVERRIDE_EE_DATA_POSTPROCESS
• HR_AU_CUST_REP_STP – overwrites the entire dataset generated in the STP pay event (for all
employees present in the file), Method:
− OVERRIDE_REPORT_DATA
These are optional, if customisations or integrated solutions require it.
SAP customers have advised their use of these BAdis for STP in the following ways:
• ABN/Branch – given the different requirements between production and non-production environments for
ebMS3/AS4 connection to the ATO, customers use this enhancement to replace real ABNs with the
EVTE-only ABNs by checking the client/environment (if prod is copied to non-prod with prod flagged)
• M2M Credential Owner – as per the above replacement, T50BK check against constant M2M requires
the EVTE-specific credential owner
• Employment Basis Code – if feature 13DEG will not resolve the employment basis using the Personnel
Structures, non-standard approaches can be resolved using this method
• Commencement Date – for historically migrated data for specific groups of employees where the
standard SAP source of commencement date does not reflect the actual start of the employment
relationship, a specific date type in IT0041 Date Specifications is used
• Contractor ABN – to replace payee TFN with contractor ABN, however, this option for STP2 now has
security and whitelisting impacts, as the SAP STP2 solution has not been whitelisted for contractors

ATO requirements for STP2 are extensive, complex and secured for registered DSPs only. It
is recommended that customers check with SAP before modifying beyond simple field
values, as this may breach extensive validation rules in place at field-level.

37 | 37