GUIDANCE: Contributions for defined benefits
guidance / external / 11 April 2017 / UNCLASSIFIEDformat / Audience / Date / Classification
/ File Ref: / G0xx
Contributions for defined benefits
Purpose
The purpose of this document is to provide additional guidance on the use of the SuperStream data standard for facilitating the reporting and payment of member registrations and contributions for defined benefit (DB) schemes.
Scope
The scope of this guidance note covers an agreed, harmonised set of data concepts to facilitate member registration and contributions for defined benefit schemes. Lump sum payments determined by the fund, and paid by the employer on notification from the fund, are processed outside of the standard and are not within scope of this guidance note.
Background
The Superannuation Data and Payment Standard 2012 (the 'standard') handles the data elements required by defined benefit schemes via two mechanisms:
- Inclusion of commonly used terms which can readily be standardised and also have utility in accumulation schemes wherever possible, and
- Inclusion of generic tuples (name-and-value pairs) for terms specific to defined benefits and for which there was no agreed harmonisation between different defined benefit schemes.
These tuples allow declaration of a data concept by a fund with a defined benefit scheme and then reporting of a value against that data concept by the employer. The data concepts are not currently defined in the standard taxonomy as they are specific to each defined benefit scheme. Each fund that has a defined benefit scheme is required under the standard to publish individual schema extensions that specify its data requirements.
Approach
As a result of a co-design process across key industry stakeholders in early 2014, commitment was obtained to harmonise as many data concepts as possible in the defined benefits sector and relate these to the tuple requirements of the contributions messaging standard.
This work would then be carried forward as a recommended guidance note to assist users with implementation of the standard and, based on the actual experience of that implementation, become a candidate change for inclusion in the standard at a later date.
A high degree of potential harmonisation in usage of terms was identified by stakeholders and agreed as the basis for a guidance note to be issued to industry.It was recognised by the parties involved that some of the most highly complex defined benefit schemes may continue to need local schema extensions to cater for concepts specific to that scheme, but that these were likely to be outliers in the overall sector.
Sincethe initial release of the guidance on contributions for defined benefitsin July 2013, further issues had been raised in relation to the large number of additional elements that were commonly being requested by DB funds in payroll extract processes and also inconsistent interpretations of existing element definitions.
Further consultation with industry started early in 2016 to address these shortcomings and as a result of the work of the consultation group it has been possible to define an extended list of harmonised fields for (DB) schemes.
This document supersedes the original guidance (G019) on this topic and defines an enhanced set of harmonised elements for DB funds.
Recommended guidance
The section immediately following this defines the rules and usage conventions for naming and populating generic tuples for defined benefits.
Attachment 1 provides an alphabetic list of the existing and additional data elements defined by this guidance.
Attachment 2 sets out the agreed definitions and usage of data concepts recommended for use in the defined benefit context.
USE OF GENERIC TUPLES FOR DEFINED BENEFITS
As specifiedin the Standard, the Member Registration request (MRR) and Contributions Transaction Request (CTR) taxonomies include ‘OtherDetails’ and ‘OtherAmounts’ tuples to allow declaration of a data concepts that are not defined in the taxonomy.
This guidance sets out the recommended conventions for use of these tuples for member registration and contributions messages. As per the schema, the generic tuples are always optional and have zero-to-many cardinality.
Where a data concept required by a defined benefits scheme has not been specified in this document, a fund that requires that data concept should define that concept for use in the relevant generic tuple, publish a fund-specific schema extension, and make this available to users.
Optionality of tuples and child elements
Whilst the ‘OtherDetails’ and ‘OtherAmounts’ tuples are always optional, the schema requires that, where a generic tuple is used in a business document, the optionality rules for child elements must be followed. This means that if a generic tuple is used, certain child elements will become mandatory within the bounds of that tuple.
The MRR and CTROtherDetails tuples and OtherAmounts tuple are defined as follows:
1. MemberRegistrationOtherDetails
a)SuperannuationFundDetails.MemberRegistrationOtherDetails.Text
b)SuperannuationFundDetails.MemberRegistrationOtherDetails.Description
c)SuperannuationFundDetails.MemberRegistrationOtherDetails.Start.Date
d)SuperannuationFundDetails.MemberRegistrationOtherDetails.End.Date
2. SuperannuationContributionOtherDetails
a)SuperannuationContribution.OtherDetails.Text
b)SuperannuationContribution.OtherDetails.Description
3. SuperannuationContributionOtherAmounts
a)SuperannuationContribution.Other.Amount
b)SuperannuationContribution.Other.Description
UNiqueness of tuples within each context
Any particular value contained in the Description element in a (member level) context must be unique, that is must only be used once with each context.
For example, any value within SuperannuationContribution.OtherDetails.Description and also any value within SuperannuationContribution.Other.Description must be unique within each context.
Intepreting data types
The generic tuples have data types defined in the underlying schema. These data types do not reflect the full range of data types that would be required if the fields were to be reported in their own right; they are either ‘stringItemType’ or ‘monetaryItemType’.
Accordingly, Attachment 2 describes a ‘notional’ data type for each item. The notional type is expressed as a defined xbrl data type. In order to process these fields correctly, the data must be interpreted in accordance with the notional data type (rather than the inherent data type).
In addition, the recommended use of the generic tuples should include, within the ‘description’ child element of each tuple, an explicit statement of the notional data type for the reported value (in either the ‘Text’ or ‘Amount’ child element as applies).
The method for structuring the ‘Description’ is as follows:
- data concept name
- ‘#’ (hash) symbol (used as a delimiter)
- notional xbrl data type.
In addition, guidance is given that certain elements SHOULD be reported (primarily the effective start date for data passed in the member registration message). For these elements the schema dictates that they are optional, however to support the outcome of reporting correct data these elements will be needed by the defined benefits fund. Not providing these elements will result in exceptions and reverse workflows for both the employer and fund
Negative amounts
The Standard, by default, does not cover negative amounts under common fields. However the Standard provides the flexibility by including the ‘OtherDetails’ and ‘OtherAmounts’ tuples.
Where a fund opts to allow negatives amounts, the fund is responsible for specifying the rules governing how and where negative amounts can be added, and the implications for associated payments. The fund is also responsible for working with their stakeholders to implement this choice
RECONCILIATION OF PAYMENTS
The following defined benefits data concepts defined here and reported within the Contributions Transaction Request (CTR) message are expected to have an associated payment amount and should therefore be considered in the payment reconciliation process:
- Defined Benefit Member Pre Tax Contribution
- Defined Benefit Member Post Tax Contribution
- Defined Benefit Employer Contribution
- Admin Fee for other categories (new)
- Group IP Premium (new)
- Insurance Levy (new)
No other defined benefits data concepts described in this guidance note are expected to have an associated payment.
To assist the reconciliation process, this guidance note applies the following principles to the use of generic tuples within the contributions transaction request message:
- all amounts that have an associated payment must be reported via the ‘Superannuation Contribution Other Amounts’ tuple and must reconcile with the money received, and
- any amounts that do not have an associated payment must be reported via the ‘Superannuation Contribution Other Details’ tuple and do not reconcile with money received.
superannuable allowances
The recent co-design process identified that there is significant difference in industry practice with respect to superannuable allowances for defined benefits. The agreed industry approach removes this variability.
Where superannuable allowances are reported in accordance with this guidance note they should be aggregated and reported in a single field (that is, Superannuable Allowances Paid, or Notional Superannuable Allowances as relevant).
This means that when a fund registers an employer, allowances that are included for superannuation purposes will need to be identified so that they can be aggregated for reporting in accordance with this guidance note.
The fund will be responsible for agreeing and identifying the relevant allowances. The employer will be responsible for reporting the relevant allowances using their payroll system
1
GUIDANCE: Contributions for defined benefits
OtherDetails Tuple Example
This tuple is used to accommodate elements that do not have an associated payment.
Some elements may have a notional datatype of ‘monetaryItemType’ but do not have associated payments, for example Service Fraction. These elements must be reported using an ‘OtherDetails’ tuple.
An example of how to populate the element ‘Service Fraction’ in a tuple is shown below.
Business term / Tuple description / Format / Notional Datatype / Business Definition / NotesService Fraction / ‘Service Fraction#decimalItemType’ / decimalItemType / The ratio of contracted hours to full-time hours during the contribution period.
Recommended maximum five decimal places
Element Name / Usage
MemberRegistrationOtherDetails Tuple / Optional
SuperannuationFundDetails.MemberRegistrationOtherDetails.Text / Include the value for Service Fraction.
For example, the value is “0.25”
SuperannuationFundDetails.MemberRegistrationOtherDetails.Description / The value for this field is constructed as follows:
- Element name
- Hash symbol (“#”)
- Notional XBRL data type (as specified in previous sections)
SuperannuationFundDetails.MemberRegistrationOtherDetailsStart.Date / Optional per schema but SHOULD be provided.
SuperannuationFundDetails.MemberRegistrationOtherDetailsEnd.Date / Optional
OtherAmounts Tuple Example
All elements that have an associated payment must be reported usingan ‘OtherAmounts’ tuple, and must be consideredin payment reconciliation.
An example of how to populate the element ‘Defined Benefit Member Pre Tax Contribution’ in a tuple is shown below.
Business term / Tuple description / Format / Notional Datatype / Business Definition / NotesDefined Benefit Member Pre Tax Contribution / ‘Defined Benefit Member Pre Tax Contribution#monetaryItemType’ / monetaryItemType / Member defined benefit contribution that the member has elected to pay via salary sacrifice subject to employer approval.
Financial amount: It must have an associated payment amount and be included in the payment reconciliation process.
Element Name / Usage
SuperannuationContributionOtherAmounts / Optional
SuperannuationContribution.Other.Amount / Report the value of the Defined Benefit Member Pre Tax contributions.
For example, the value is “580.50”
SuperannuationContribution.Other.Description / The value for this field is constructed as follows:
- Element name
- Hash symbol (“#”)
- Notional XBRL data type (as specified in previous sections)
1
GUIDANCE: Contributions for defined benefits
Attachment 1 – Defined benefits element list
Contributions
Element name / Financial amount?1 / Actual Hours Paid
2 / Actual Periodic Salary or Wages Earned
3 / Contracted Hours
4 / Defined Benefit Employer Contribution / Y
5 / Defined Benefit Member Post Tax Contribution / Y
6 / Defined Benefit Member Pre Tax Contribution / Y
7 / Defined Benefit Notional Employer Contribution
8 / Defined Benefit Notional Member Post Tax Contribution
9 / Defined Benefit Notional Member Pre Tax Contribution
10 / Employee Location Identifier
11 / Full Time Hours
12 / Notional Superannuable Allowances
13 / Ordinary Time Earnings
14 / Service Fraction
15 / Service Fraction Effective Date
16 / Superannuable Allowances Paid
Member registration
Element name17 / Annual Salary for Benefits Effective Date
18 / Annual Salary for Insurance Effective Date
19 / Defined Benefit Annual Salary 1
20 / Defined Benefit Annual Salary 1 End Date
21 / Defined Benefit Annual Salary 1 Start Date
22 / Defined Benefit Annual Salary 2
23 / Defined Benefit Annual Salary 2 End Date
24 / Defined Benefit Annual Salary 2 Start Date
25 / Defined Benefit Annual Salary 3
26 / Defined Benefit Annual Salary 3 End Date
27 / Defined Benefit Annual Salary 3 Start Date
28 / Defined Benefit Annual Salary 4
29 / Defined Benefit Annual Salary 4 End Date
30 / Defined Benefit Annual Salary 4 Start Date
31 / Defined Benefit Annual Salary 5
32 / Defined Benefit Annual Salary 5 End Date
33 / Defined Benefit Annual Salary 5 Start Date
34 / Defined Benefit Employer Rate
35 / Defined Benefit Employer Rate End Date
36 / Defined Benefit Employer Rate Start Date
37 / Defined Benefit Member Rate
38 / Defined Benefit Member Rate End Date
39 / Defined Benefit Member Rate Start Date
40 / Employee Benefit Category Effective Date
41 / Employee Location Identifier
42 / Employee Location Identifier End Date
43 / Employee Location Identifier Start Date
44 / Employee Status Effective Date
45 / Leave Without Pay Code
46 / Leave Without Pay Code End Date
47 / Leave Without Pay Code Start Date
48 / Service Fraction
49 / Service Fraction End Date
50 / Service Fraction Start Date
Additional common elements
Element name1 / Full Time Hours
2 / Member Group
3 / Part Time Hours
4 / Part Time Hours Effective Date
Additional member registration elements
Element name5 / Choice Flag
6 / Contract length greater than 12 months
7 / Effective Date or Choice
8 / Member Pay Group
9 / Member Registration Pay Period End Date
10 / Member Registration pay Period Start Date
11 / Superannuation Fund Details Occupation Code for Insurance Description
Additional contribution elements
Element name / Financial amount?12 / ADIC Payment Amount
13 / Admin Fee for other categories / Y
14 / Base Remuneration
15 / Contribution Due Days
16 / Defined Benefit Member Post Reserve Units Amount
17 / Defined Benefit Member Pre Reserve Units Amount
18 / Group IP Premium / Y
19 / Insurance Levy / Y
20 / Notional GSS Remuneration
21 / Number of weeks purchased
22 / Packaged Remuneration
1
GUIDANCE: Contributions for defined benefits
Attachment 2– Defined benefits element definitions
Contributions
Business term / Tuple description / Format / Notional Datatype / Business Definition / NotesActual Hours Paid / ‘Actual Hours Paid#decimalItemType’ / decimalItemType / Number of paid hours in the period.
Actual Periodic Salary or Wages Earned / ‘Actual Periodic Salary or Wages Earned#monetaryItemType’ / monetaryItemType / Actual gross salary or wages received in contribution period.
Fortnightly Casual Salary Payment - The amount the member actually earned in the fortnight, excluding payments for overtime, compensation or reimbursement of expenses. The contributions to be paid by the member and the employer are based on this amount.
Contracted Hours / ‘Contracted Hours#decimalItemType’ / decimalItemType / Number of hours the employee is contracted to work during the contribution period.
Defined Benefit Employer Contribution / ‘Defined Benefit Employer Contribution#monetaryItemType’ / monetaryItemType / An amount paid by the employer to fund defined benefits.
Financial amount: It must have an associated payment amount and be included in the payment reconciliation process.
Defined Benefit Member Post Tax Contribution / ‘Defined Benefit Member Post Tax Contribution#monetaryItemType’ / monetaryItemType / Member defined benefit contribution that the member has elected to pay from after tax salary.
Financial amount: It must have an associated payment amount and be included in the payment reconciliation process.
Defined Benefit Member Pre Tax Contribution / ‘Defined Benefit Member Pre Tax Contribution#monetaryItemType’ / monetaryItemType / Member defined benefit contribution that the member has elected to pay via salary sacrifice subject to employer approval.
Financial amount: It must have an associated payment amount and be included in the payment reconciliation process.
Defined Benefit Notional Employer Contribution / ‘Defined Benefit Notional Employer Contribution#monetaryItemType’ / monetaryItemType / A notional employer defined benefit contribution calculated by the employer based on advice provided by the fund.
Defined Benefit Notional Member Post Tax Contribution / ‘Defined Benefit Notional Member Post Tax Contribution#monetaryItemType’ / monetaryItemType / A notional member defined benefit post-tax contribution calculated by the employer based on advice provided by the fund.
Defined Benefit Notional Member Pre Tax Contribution / ‘Defined Benefit Notional Member Pre Tax Contribution#monetaryItemType’ / monetaryItemType / A notional member defined benefit pre-tax contribution calculated by the employer based on advice provided by the fund.
Employee Location Identifier / ‘Employee Location Identifier#stringItemType’ / stringItemType / Identifies sub-component of employer organisational structure in which the employee sits.
Full Time Hours / ‘Full Time Hours#decimalItemType’ / decimalItemType / The number of hours of the position a full-time employee would work during the contribution period.
Notional Superannuable Allowances / ‘Notional Superannuable Allowances#monetaryItemType’ / monetaryItemType / Sum of all superannuable allowances notionally received during the contribution period.
Ordinary Time Earnings / ‘Ordinary Time Earnings#monetaryItemType’ / monetaryItemType / Amount paid to the member in the contribution period as defined by legislative definition of ordinary time earnings.
Fortnightly Ordinary Time Earnings - The member’s fortnightly ordinary time earnings for the given pay day calculated in accordance with the Superannuation Guarantee (Administration) Act 1992 and any determinations or rulings issued by the Australian Taxation Office (ATO).
Service Fraction / ‘Service Fraction#decimalItemType’ / decimalItemType
Recommended maximum five decimal places. / The ratio of contracted hours to full-time hours during the contribution period.
Service Fraction Effective Date / ‘Service Fraction Effective Date#dateItemType’ / dateItemType / Date from which the service fraction applies
Superannuable Allowances Paid / ‘Superannuable Allowances Paid#monetaryItemType’ / monetaryItemType / Sum of all superannuable allowances received during the contribution period
Member Registration