Payroll and Single Touch Payroll schedule

#01Readiness at a glance

This schedule applies only where an Institution uses Academyship's Payroll module. Paying people involves four separate activities: calculating pay and keeping records, paying wages into bank accounts, paying superannuation, and reporting to the Australian Taxation Office (ATO) through Single Touch Payroll (STP). Completing one of these in Academyship does not complete, or prove, any of the others.

#02Status of this schedule and how it applies

This is a module schedule to the Terms of Service. It applies to an Institution only when the Payroll module is identified, by name and by this schedule's version, in an Order Form or in a module activation completed by an Institution representative with authority to bind the Institution. It applies only to the Payroll module's subject matter.

For that subject matter, this schedule prevails over the Terms if they are inconsistent. A signed Order Form or government schedule prevails only where it expressly overrides an identified provision. The Data Processing Addendum (DPA) continues to govern the processing of personal information, including payroll and tax file number information. The Acceptable Use Policy continues to apply.

A later version of this schedule does not apply automatically. It applies only through the change process in section 31 of the Terms, which provides notice for material changes and does not operate retrospectively. Academyship keeps a record of the version an Institution accepted.

Employees, contractors and other Workers are not parties to this schedule. The Staff Privacy Guide explains in plain language how their information is handled. That guide is informational and is not a contract.

Academyship does not give tax, legal, employment, superannuation or financial advice. The module does not replace the Employer's own payroll expertise or a registered tax or BAS agent. This does not reduce Academyship's obligations to supply the module with due care and skill under section 25 of the Terms, to make it work as documented, and to fix its own errors (section 6).

#03Definitions

Capitalised terms not defined here have the meanings given in the Terms and the DPA.

• Employer: the Institution (the Customer under the Terms) when it uses the Payroll module to pay its Workers.
• Worker: an employee, or any other person the Employer pays through the module, including former Workers.
• Pay Run: a payroll calculation for a pay period, a group of Workers and a payment date, together with its outputs.
• Payroll Rules: the rates, pay schedules, pay codes, salary components, allowances, deductions, leave rules, overtime and penalty rules, and tax and superannuation settings that determine a calculation. This includes any statutory rates or tables Academyship supplies as part of the module.
• Payment File: a file the module prepares for the Employer's bank or payment process, such as an ABA file for salary or superannuation payments.
• STP Report: a Single Touch Payroll report of payroll information to the ATO. This includes a pay event, an update event or a finalisation, where the module supports it.
• STP Provider: the sending service Academyship engages to transmit STP Reports from the platform to the ATO and return the responses (section 10).
• Payroll Data: Customer Data processed by the module. This includes Worker identity, employment, time, leave, pay, tax, superannuation, bank and reimbursement information, as well as Pay Runs, Payment Files, STP Reports and related audit records.
• TFN: tax file number. A TFN is a different identifier from a student's Unique Student Identifier (USI) and from a superannuation fund's Unique Superannuation Identifier (also abbreviated USI).

#04What the module does and does not do

The module supports the Employer's payroll process. Depending on the Institution's plan and configuration, it can:

• hold each Worker's pay settings, including employment basis, pay frequency, rate, classification, and bank, tax and superannuation details;
• bring approved timesheets, attendance, leave, overtime and reimbursements into the right pay period;
• calculate earnings, allowances, deductions, PAYG withholding, study and training support loan amounts, superannuation and net pay from the Payroll Rules;
• produce pay slips, payroll reports (such as the payroll register, PAYG and superannuation summaries, leave liability and year-to-date reports), Payment Files and exports;
• when an authorised user marks a Pay Run as Paid, start payment of the Pay Run's net pay amounts through the payment arrangement the Employer has set up in the platform (section 7); and
• map pay components to STP reporting categories. STP lodgement through the platform is not currently available (section 10).

The module does not:

• decide a Worker's employment status, classification, award or agreement coverage, or entitlements;
• interpret an award, enterprise agreement, contract or policy;
• fund payments, because the Employer provides the money for each payment;
• send contributions to superannuation funds, because the Employer pays those (section 9);
• lodge anything with the ATO except as section 10 describes; or
• make any declaration the law requires of an Employer.

#05The Employer's responsibilities

The Employer remains legally responsible for paying its Workers correctly and on time, and for its tax, superannuation, workplace and record-keeping obligations. Using the module does not transfer those obligations to Academyship. In particular, the Employer is responsible for:

• status and classification: deciding whether each person is an employee or a contractor, their employment type (for example, full-time, part-time or casual) and their classification;
• industrial instruments: identifying the awards, enterprise agreements, contracts and policies that apply. This includes configuring Payroll Rules that reflect them, including minimum rates, penalty rates, overtime, allowances and loadings;
• hours: recording and approving accurate ordinary hours, overtime, shifts and attendance before they enter a Pay Run;
• rates and changes: keeping rates current from their correct effective date, including changes from wage reviews and agreements;
• deductions: making only lawful deductions, with any authorisation the law requires;
• leave: configuring leave types, accruals, loadings and payouts correctly, and approving leave;
• superannuation: eligibility, rates, salary sacrifice arrangements, fund choice and fund details, and paying contributions on time (section 9);
• tax: obtaining TFN and withholding declarations, applying the correct withholding settings and any variations, and reporting and paying PAYG withholding to the ATO;
• source data: the accuracy and lawfulness of everything entered or imported, including Worker details and bank accounts;
• review and approval: reviewing each Pay Run, including its exceptions and warnings, before approval, and giving approval permissions only to people with authority;
• payment: funding each payment, checking amounts before a Pay Run is marked as Paid, allowing only authorised people to mark a Pay Run as Paid after approval, checking any Payment File against the approved Pay Run before using it, and confirming that each payment has arrived (section 7);
• reporting: authorising and declaring STP Reports, meeting ATO due dates and correcting errors, whether it reports through another service or, once STP lodgement is available, through Academyship;
• reconciliation: reconciling Pay Runs against bank, superannuation, accounting and ATO records (section 7);
• corrections: correcting underpayments and overpayments lawfully and promptly, including any back pay, recovery or corrected reporting;
• notices: giving Workers the collection notices and information the law requires, including about TFNs (section 11);
• access: assigning payroll permissions, removing access for people who leave or change roles, and protecting Payment Files and exports after download; and
• records: keeping the records and pay slips the law requires for as long as it requires, including after the Institution's subscription ends (section 12).

#06Academyship's responsibilities

Academyship will:

• provide the module with due care and skill, in accordance with the Terms, this schedule and the module's documentation;
• calculate in accordance with the configured Payroll Rules and the documented calculation method, and document how the module applies them, including how time records are assigned to a pay period;
• take reasonable care to update any statutory rates or tables it supplies as part of the module (for example, PAYG withholding schedules or the superannuation guarantee rate) for changes that take effect. Academyship will tell Employers when it has made such an update;
• keep a history of Pay Runs, state changes, approvals and the Payroll Rules a finalised Pay Run used (section 7);
• protect Payroll Data under the DPA, including the measures in Annex II, and protect TFNs as described in section 11;
• investigate reported faults and correct confirmed defects in the module;
• tell affected Employers about a confirmed defect that may have produced incorrect Pay Run results, help them identify the affected Pay Runs, and provide reasonable assistance with correcting the affected records;
• tell affected Employers, in the product or by email, about known outages of the module or of the STP Provider that are likely to affect a Pay Run or an STP submission; and
• never make a declaration on an Employer's behalf, or submit an STP Report, without an instruction from a person the Employer has authorised.

Liability for a defect is governed by the Terms, including sections 25 and 27. Nothing in this schedule excludes, restricts or modifies rights that cannot lawfully be excluded, restricted or modified.

#07Pay runs: states, approval and corrections

Each Pay Run moves through defined states. The module shows the current state in words, not by colour alone. Only users with the relevant permission can move a Pay Run to its next state.

Corrections to a finalised or paid Pay Run are explained under "Back pay, reversals and corrections" below.

Marking a Pay Run as Paid

Marking a Pay Run as Paid moves money. It starts payment of the Pay Run's net pay amounts through the payment arrangement the Employer has set up in the platform. It is not only a record that payment has been made in some other way.

• Authority. Only a person the Employer has authorised should mark a Pay Run as Paid, and only after the Pay Run has been approved. The Employer decides who holds that permission.
• Funding and checks. The Employer is responsible for funding the payments and for checking the amounts, Workers and bank details before marking a Pay Run as Paid. This includes checking that the same amounts have not already been paid another way, for example by uploading a Payment File to its bank.
• Payment outcome. A payment can still fail or be delayed by banks or payment providers. A Paid status is not proof that the money has arrived in a Worker's account. The Employer must check that each payment has arrived and follow up any payment that has not.

Separate permissions

Payroll permissions are granted as separate scopes. These include processing Pay Runs, configuring Payroll Rules and Worker pay records, preparing reports and Payment Files, viewing masked TFNs, viewing full TFNs, editing TFNs, and exporting sensitive payroll data. The Employer decides who holds each scope. Academyship recommends that the person who sets a rate or a bank account is not the only person who approves the Pay Run that uses it or marks it as Paid. Academyship also recommends that Payment File preparation is kept separate from configuration. If the Employer gives one person several scopes, the module cannot provide that separation.

Pay periods, payment dates and time zones

Each Pay Run has a pay period and a payment date. Which time records fall inside a period depends on the dates recorded and the workspace's time settings. The Employer must check pay calendars, period boundaries, payment dates and public-holiday settings for each state or territory where its Workers work. This is especially important where shifts cross midnight or a period boundary, or where Workers are in different time zones.

Back pay, reversals and corrections

The Employer decides whether back pay, an adjustment or a reversal is needed, and how to calculate it under the applicable instrument. Corrections to a finalised or paid Pay Run are made through the platform's correction and adjustment functions, or in a later Pay Run, as the Employer's authorised users decide. The original record is kept. A correction may also need a corrected pay slip, a further payment, a superannuation adjustment and a correction to the Employer's STP reporting (section 10). Recovering an overpayment from a Worker is a matter between the Employer and the Worker, subject to workplace law.

Versioned rules and calculation history

Rates and thresholds are held against effective dates, so a later change does not silently alter a finalised Pay Run. The Employer must check that the effective date it enters for each change matches the applicable rule, for example the first full pay period on or after a wage increase. Academyship will keep enough history to show which Payroll Rules and statutory tables a finalised Pay Run used.

Approval evidence

The module records who generated, reviewed, approved, locked and marked Paid a Pay Run, and when. A rejection during review requires a reason. These records support the Employer's governance. They are not an audit opinion and do not prove that the figures are correct.

Independent reconciliation

The Employer must reconcile each Pay Run independently of the module. This includes comparing payments started from the platform and Payment File totals with bank records, superannuation contributions with fund or clearing-house confirmations, PAYG withholding with ATO records, STP year-to-date amounts with payroll records, and payroll totals with the Employer's accounts. The module's reports help, but they are not a substitute. The Employer should promptly report to Academyship any discrepancy that the module may have caused.

#08Payment files, reports and exports

Payment Files and payroll exports are sensitive records. They contain Worker names, bank account details and amounts. An export containing full TFNs can be produced only by a user with the separate sensitive-export permission (section 11).

Validation checks a Payment File's structure, and checks its totals against the approved Pay Run. It does not confirm that the Employer's bank will accept the file, that an account belongs to the Worker named, or that a payment will settle by a particular time.

The Employer must:

• generate Payment Files only from an approved and finalised Pay Run, and check them before upload;
• not change a Payment File after download. If it does, it is responsible for the changed file;
• verify any change to a Worker's bank details through a channel independent of the request before paying to the new account. Requests to redirect pay are a common fraud method;
• store and transfer Payment Files and exports securely, never send them by ordinary email, and delete local copies when they are no longer needed; and
• keep only the copies it needs as records, under its own retention rules.

#09Superannuation

The module calculates superannuation contributions from the Payroll Rules, including rates held against effective dates. It holds fund details for each contribution type, such as the fund's ABN, its Unique Superannuation Identifier and the Worker's member number. It also prepares contribution reports, fund data templates and superannuation payment files.

The Employer decides eligibility, rates, salary sacrifice arrangements and fund choice, including any stapled fund. The Employer must pay contributions by the due dates that apply to it, through a channel that meets the superannuation data and payment standards (SuperStream).

A superannuation payment file is a bank payment file. On its own, it does not deliver the contribution data a fund needs, and it does not show that a fund has received or allocated a contribution. Academyship is not a superannuation clearing house and does not receive or hold contributions. The rules on when contributions must be paid can change. The Employer must apply the rules in force, and Academyship will update any rates it supplies in accordance with section 6.

#10Single Touch Payroll

Current status

Provider and roles

Academyship has engaged Single Touch Pty Ltd as its STP Provider for STP lodgement through the platform once that feature is available. Before Single Touch receives any Customer Data, Academyship will add it to the Subprocessor Register and give Customers the notice that section 18 of the DPA requires.

The Employer is the payer and is responsible for each STP Report. A registered tax or BAS agent may act for it. Once STP lodgement is available, Academyship's software will prepare each report and pass it to the STP Provider when an authorised person instructs it to, and the STP Provider will transmit the report to the ATO and return the ATO's responses. Academyship is not the Employer's tax or BAS agent and does not lodge on its own authority. Before its first submission through the platform, the Employer must complete any authorisation the ATO requires for the reporting arrangement. Academyship will explain the steps during set-up.

Sandbox and test submissions

Any sandbox or test submission uses a test environment and does not reach the ATO's production systems. A successful test does not mean that STP lodgement through the platform is available, or that a real report will be accepted. Academyship will not use real Worker information for sandbox testing without the Employer's instruction.

What is reported

An STP Report contains the information the ATO's STP requirements call for. That information depends on each Worker's circumstances. For example:

• about the Employer: ABN and branch, name, contact details and payroll identifiers;
• about each Worker: name, date of birth, address, TFN (or the code the ATO requires where none was quoted), employment basis, tax treatment, income type, payroll identifier, and start and finish dates;
• amounts: year-to-date gross amounts by reporting category (such as salary and wages, allowances, overtime, bonuses, paid leave, salary sacrifice and lump sums), PAYG withholding, superannuation liabilities and certain deductions; and
• the declaration: the declaration made for the report, and details of the person who made it.

Recipients, locations and retention

An STP Report lodged through the platform goes to the STP Provider and then to the ATO. Single Touch stores the data in Australia. The Subprocessor Register entry and the notice described under "Provider and roles" will identify Single Touch's service, the purpose, the categories of data and the processing locations. The ATO handles reported information under the laws that apply to it. Workers can see much of their reported information in ATO online services through myGov.

Authority and declarations

Before each submission through the platform, the Employer, or its registered agent, must authorise a person to review the report and make the declaration the ATO requires. Academyship will record who made the declaration and when, and only users the Employer has given permission to submit STP Reports will be able to submit. Academyship does not make declarations for the Employer.

Submission states

Once STP lodgement is available, the module will show the status of each submission. Academyship will describe the exact status labels when it tells Employers that STP lodgement is available. Whatever the labels, these distinctions apply.

A browser message or a Submitted status is not proof of acceptance. Check for acceptance in the module, or in the ATO's own records.

Corrections, update events and finalisation

The ATO's rules decide how a reporting error is corrected. Depending on the error, that may be the next pay event, an update event or a full file replacement. The Employer must also make a finalisation declaration for each Worker by the ATO's due date. Once STP lodgement is available, Academyship will tell Employers which of update events, full file replacement and finalisation the module supports. Where the module supports them, it will show them in the submission history. Where it does not, the Employer must use another method the ATO accepts.

Due dates and contingencies

The ATO sets STP due dates, and the Employer is responsible for meeting them, including where it uses Academyship. Academyship does not guarantee that a report will be transmitted, received or accepted by a particular time. Outages at the STP Provider, the ATO, a network or Academyship, as well as validation errors, can delay reporting. The Employer should submit early enough to correct a rejection before the due date. If it cannot report on time, it should keep a record of why, check the ATO's guidance on outages and any concession that applies, contact the ATO or its registered agent where needed, and report as soon as it can. Academyship will tell affected Employers about known outages under section 6 and give reasonable assistance.

Getting help with STP errors

Contact support@academyship.com.au with the Institution, the Pay Run, the submission reference and state, any ATO or provider error codes and messages, and when the problem happened. Do not send TFNs, full bank account details, Payment Files or payroll exports by email. If Academyship needs more detail, it will tell you how to provide it without sending those details by email. Some errors come from the Employer's ATO registration details (for example, ABN or branch registration) or from a Worker's details. The Employer must resolve those with the ATO, and Academyship can help interpret the response.

#11Tax file numbers

Purpose. The Employer collects TFNs only for the tax and superannuation purposes the law permits, such as PAYG withholding, STP reporting and giving a TFN to a superannuation fund where required. The module uses TFNs only for those purposes.

Lawful handling. The Employer must be entitled to collect each TFN, must give the notices the law requires, and must not ask for a TFN for any other purpose. Academyship handles TFN information on the Employer's behalf, under the DPA and in accordance with the tax file number rule made under the Privacy Act 1988 (Cth), as it applies to Academyship. A TFN is a Regulated Identifier. It is not ordinary profile information.

Quoting a TFN is not compulsory. A Worker is not legally required to quote a TFN. If a Worker does not quote one, the Employer generally must withhold tax at a higher rate. That does not apply where an exemption applies or the Worker has told the Employer that they have applied for a TFN. The Employer should explain this without pressuring the Worker.

Controls. Academyship will maintain these controls for TFNs in the module:

• TFNs are masked by default, so users with ordinary payroll access see only a masked value;
• viewing a full TFN is a separate permission, which the Employer should give only to people who need it. Each full view is recorded in an audit trail with the user and the time;
• editing a TFN is a separate permission;
• exporting data containing full TFNs requires a separate sensitive-export permission, and each such export is recorded;
• a TFN is never used as an account identifier, username, sign-in credential or record key;
• a Worker's real TFN is sent to the STP Provider only as part of an STP Report that a person the Employer has authorised has declared and instructed Academyship to submit (section 10); and
• on request, Academyship will give the Employer the audit trail of full TFN views and TFN exports in its workspace.

The Employer must not put TFNs in pay slip templates, notifications, SMS, free-text notes, file names, AI prompts or support requests.

Destruction. TFN information must be securely destroyed or de-identified once the law no longer requires it to be kept and it is no longer needed for a permitted purpose. The Employer decides when that point is reached and instructs deletion. Academyship deletes on instruction in accordance with section 20 of the DPA and its backup lifecycle.

#12Records, pay slips and confidential leave

The Employer's record-keeping obligations

Under workplace law, employers generally must keep time and wages records for seven years. They must also give pay slips within one working day of pay day. These are the Employer's obligations.

The seven-year period is not Academyship's hosting period. Academyship's hosting and export obligations come from section 23 of the Terms and section 20 of the DPA. Payroll Data is available during the subscription, and for authorised export for at least 60 days after termination, unless an Order Form states a different period. The seven-year rule does not mean that Academyship keeps Payroll Data for seven years after the subscription ends. Nor does it mean that all employee information must be kept for exactly seven years: some records must be kept longer, and TFN information must be destroyed once it is no longer required. The Employer must export and keep the records it needs. Any longer hosted retention or archive service must be agreed in an Order Form. The Data Retention, Export and Deletion page explains how retention, export and deletion work for payroll records and across the platform.

Legal holds

The Employer can ask Academyship to preserve specified Payroll Data for a legal hold, such as a dispute, audit or investigation. Academyship will apply legal holds in accordance with the DPA.

Worker access and correction

Workers may have rights under workplace law to inspect or copy their time and wages records, and rights under privacy law. The Employer handles requests about its payroll records and decisions, and Academyship assists through its export and support functions. Workers can contact Academyship directly about Academyship's own handling of their information (section 13).

Pay slips

The module produces pay slips from the Employer's chosen templates. The Employer must check that each template it uses contains the information the law requires and nothing it should not contain.

Family and domestic violence leave

The Employer must not show paid family and domestic violence leave on pay slips in a way that identifies it. The applicable rules and Fair Work Ombudsman guidance explain how such payments may be shown instead. The Employer must also treat information about this leave confidentially, as far as reasonably practicable. The Employer is responsible for configuring leave types, pay codes, pay slip labels and pay slip templates so that pay slips do not reveal this leave, and for checking the result before it pays this leave. The same applies to notifications, reports seen by other staff, and exports. The Employer must also restrict who can see leave reasons and evidence.

Final exports and orderly exit

Before ending use of the module or the subscription, the Employer should complete outstanding Pay Runs and corrections. Where it reports through Academyship, it should also complete STP finalisation. It should export the records it needs, including Pay Run history, pay slips, year-to-date and leave balances, STP submission history and responses, and relevant audit records. It should also give any new payroll provider the opening balances that provider needs. Academyship will provide its export functions, and reasonable transition assistance in accordance with section 23 of the Terms. Custom work is available at agreed charges.

#13Privacy and the employee records exemption

The Privacy Act 1988 (Cth) includes an exemption for some acts of an employer that relate directly to a current or former employment relationship and to an employee record the employer holds. The exemption does not cover contractors or job applicants, and it does not cover everything an employer does.

Academyship does not inherit the Employer's exemption. When Academyship handles Payroll Data for an Employer, it does so as a contracted service provider. It is subject to the DPA, the privacy obligations that apply to Academyship, and the TFN rules described in section 11. Workers can raise concerns about Academyship's handling directly at privacy@academyship.com.au. Academyship will not refuse to deal with a concern about its own handling by pointing to the Employer's exemption. It may refer questions about the Employer's own decisions to the Employer.

The Employer should give Workers its own privacy and collection notices. It may also point them to the Staff Privacy Guide. The Privacy Policy and the DPA contain the complete position.

#14Calculations, automated rules and AI

Pay calculations are rule-based. They apply the Payroll Rules to the inputs in a Pay Run, and they are not generated by AI. Because the results can significantly affect Workers, they must be reviewed and approved by people (section 7). The Employer is responsible for decisions about pay. A Worker who queries a calculation should ask the Employer, which can see the inputs and Payroll Rules used. Academyship will give the Employer the information it reasonably needs to explain how the module applied those rules. This includes information for any automated-decision transparency obligation that applies to the Employer.

If the Employer allows AI Features to use Payroll Data, AI outputs are drafts for a person to check. They are not tax, payroll or legal advice, and AI does not change a pay record without a person's confirmation. Academyship's approved AI provider for Customer Data is Amazon Bedrock, which Academyship configures in the AWS Asia Pacific (Sydney) Region. Academyship's software also contains support for other model providers, including a fallback path that can operate where configured. No other AI provider is approved to process Customer Data unless it is listed in the Subprocessor Register and any notice required by the DPA has been given. See the Responsible AI Statement.

#15Support, incidents and payroll deadlines

Support for the module is provided as described on the Support and Service Information page. Response targets apply only where they are set out in the applicable plan or Order Form. When reporting a problem that could affect a payment or reporting date, say so and give the date. Academyship prioritises issues by severity, but does not guarantee that an issue will be resolved before a payment or reporting date.

Where investigating an issue requires access to Payroll Data, support access is authorised, limited to the minimum necessary and logged. Academyship personnel will not view full TFNs or open Payment Files unless that is necessary to investigate a reported issue and is authorised and logged.

Personal Data Breaches affecting Payroll Data are handled under section 17 of the DPA, including notice to the affected Institution within 72 hours of Academyship becoming aware that Customer Data has been affected. That contractual notice is separate from each party's obligations under the Notifiable Data Breaches scheme. The Institution's role in coordinating communications is not a veto over a notice the law requires.

The Employer should keep a contingency plan for paying Workers and reporting if the module is unavailable near a payment date. For example, it can keep recent Pay Run exports and know how to make payments through its bank directly.

#16Fees, changes and ending the module

Fees. Payroll usage charges apply only as stated in the Institution's Order Form or Academyship's published pricing. This schedule does not set any fee. Academyship does not take any amount out of payroll payments. Its Fees are charged as the Terms and the Order Form provide. If Academyship charges for STP submissions, it will state the charge, including any charge for a resubmission, before the charge applies.

Changes. The version of this schedule identified in the Order Form or module activation continues to apply until a new version applies under section 31 of the Terms. A material adverse change does not apply retrospectively.

Ending the module. The Institution can stop using the module as its Order Form provides. Exports and exit work as described in section 12. After the export period, Payroll Data is deleted in accordance with section 20 of the DPA, subject to legal holds and legal retention requirements. Academyship does not keep Payroll Data for the Employer's own legal retention period unless that has been agreed in an Order Form.

#17Related documents and version history

For questions about this schedule, contact legal@academyship.com.au. For help with the module, contact support@academyship.com.au. For privacy questions, contact privacy@academyship.com.au. For complaints, see the Complaints page.

Terms of Service Data Processing Addendum Privacy Policy Staff Privacy Guide Data Retention, Export and Deletion Complaints Support Subprocessor Register