STP2 - BMS Ids and Payroll Ids

Context is King ??

I've written articles before about the complexity of the management of the BMS Id/Payroll Id in Single Touch Payroll. One digital reporting solution (STP), for the whole of Australian employers/payers means that everyone has to meet the same benchmark, even if it's required only to accommodate only one segment of the market. That's the reporting reality.

There are many valid scenarios of why one employee/payee/taxpayer may be paid from more than one payroll system for the same payer in the financial year. Sometimes it's simultaneous, sometimes it's sequential. Some payers may never experience this over the lifetime of their operations, some may experience it many times in a financial year. Some businesses acquire and divest other entities as part of standard operations, so have to manage employee transitions between payrolls as a matter of course. This is just how business works, so STP needed to accommodate the business reality. Hence: BMS Id.

When employees are transitioned between payroll systems, technical differences may require a change of Payroll Id, others maintain continuity. Sometimes, within the same payroll system, payees have different Payroll Ids over their employment lifecycle. Some payroll systems cannot maintain continuity of Payroll Ids upon rehire, others require specific number ranges for different parts of the business, so when employees move within the business, so do their Payroll Ids. Some payers maintain simultaneous payroll systems that are set up for specific industrial conditions, so workers may exist in more than one instance of payroll at the same time, sometimes using the same Payroll Id to prevent worker confusion about their internal reference number. Whatever. Payroll policies the payer adopts are just the business reality.

Record Keeping Obligations

The Fair Work Act and Regulations oblige employers to retain 7 years of employee records. If you change payroll systems, the issue of transferring historical data arises. Will the payer have ownership, control or access to the legacy system? Access is the basic requirement. What historical data informs the period of continuous service as per state-specific Industrial Relations Acts that you will need in your new system? What historical data informs the average rates required to determine, for example, the value of LSL taken in your new system? Both time and pay requires historical data to meet employment obligations. Payers also get to determine if they transfer current financial year YTD amounts across to the new system, but employment obligations are far more extensive than just current YTD amounts. If the payer retains ownership, control and access to their legacy systems, some historical data may remain in the legacy system, but key data must still be transitioned to the new system to meet time, pay and super guarantee obligations.

So, there are a number of options for payers about transferring the YTD amounts of their payees, both current financial year and any historical years for which amendments may be required. It's got nothing to do with business size, it's about employment obligations.

Partnership of Process

Before the introduction of STP, whatever option the payer took about transferring YTD amounts, it was the payer's choice and payers published the annual payment summaries for their workers. However, STP split the responsibility for the end-to-end process and ATO picked up the final publishing step: ATO Income Statements instead of Payer Payment Summaries. This meant that transferring YTD amounts requires the payer to notify the ATO so the Income Statements maintain their accuracy and the payer doesn't double their PAYGW liability.

In the initial transition to STP, some DSPs didn't build in the functionality required in their products to inform the ATO about the transfer of YTD amounts. That was chaos for those payers whose DSPs didn't deliver: ring the ATO, provide the details of the YTD transfers and have ATO officers manually fix your payees' records for you. It couldn't have been much fun for the ATO either: OUCH! This time, in STP2, it is mandatory for DSPs to deliver at least one of the two options to inform the ATO about the transfer of YTD amounts:

1. Zero Out - the same method as for the original STP. That is: an Update action to reduce "closing balances" to nil in the legacy payroll system; transfer YTD amounts as "opening balances" in the new payroll system; and report (Submit or Update) the new YTD amounts. ATO Income Statements retain accuracy.
2. Replacement Key Identifiers - "key identifiers" is the term referring to the "primary key" fields for which the income is payer-reported and controlled: ABN/Branch (or WPN), BMS Id and Payroll Id. Instead of the 3 steps required in the first method (that requires access and control of both the legacy and new systems), this method uses only the 2nd and 3rd steps, but a slightly modified 3rd step: where only an Update action can reference the previous BMS Id/Payroll Id as a "once-only" notification to the ATO to retain Income Statement accuracy.

So, no more chaos for changes to the key identifiers with STP2. This is what I refer to as "Track and Trace" of YTD amounts!

Complexity Squared

The methods and choices that some payers make in how they choose to "transfer" YTD amounts and historical employee data may also have massive impacts on their reporting obligations if not done correctly. Because the concept of key identifiers is new to so many payers, any examples of YTD-transfers have been "introductory"-simple to aid understanding. However, the reality of complex data copy options has meant that payers may have to consider:

1. Historical Data Maintenance - if the history of data that was previously submitted by the entity needs to be amended, how will that be enabled and performed? Do you still have access to the data? Do you still have authorisation to lodge for the payer? Payers can't always prevent the need to correct finalised Income Statements. For example: prior financial year overpayments.
2. Related Entities - if one entity on a payroll of several entities is transferred, such as for a divestment to a new owner, do any of the transferred payees have payments from one of the remaining payers in their history? How would amendments to that data be enabled and performed? Who has control of that non-divested payer data for the payee now?
3. Employment Status - were only active payees transferred? What about recently terminated payees who may need to be included in a subsequent pay event? How is access to that data and process enabled and performed? For example, if you have to pay an annual bonus or correct an underpayment. What about historically terminated employees whose finalised Income Statements must be amended? How is access to that data and process enabled and performed? And please, let's not kid ourselves, mistakes happen, it's just an issue of the size (volume) of the correction (and size matters).
4. Authorisation - this is the weak link in the chain with respect to corrections and amendments: do you still have ATO Access Manager authorisation to report on behalf of that entity? Does that entity still exist? There's no effective date control of payers in Government Business Registers. If the payer is divesting to another entity, during the transition period, who controls the authorisation and who is granted access and for how long? Food for thought, as it will undo all the rest of your careful planning and, once closed, you have a big problem on your hands and the payees won't be happy, Jan!

In Conclusion

STP2 has streamlined the transfer of YTD amounts, but the payer administration and planning behind the reality is still as complex as ever, reflecting the depth, breadth and length of employment obligations. After all, there's no "one size fits all" approach to payroll in Australia!