GST Governance, Data Testing and Transaction Testing Guide

Top 100 and Top 1000 GST assurance programs

Contents

1. Executive Summary

1.1 Background

Our justified trust program seeks greater assurance that taxpayers in the large market are reporting the right amount of Goods and Services Tax (GST). This supports and expands on existing compliance approaches, including justified trust reviews for income tax.

We are undertaking GST assurance (justified trust) reviews in the large top 100 and top 1000 markets because large corporate groups make a significant contribution to the Australian economy and play a critical role in the tax system.

The total net GST liabilities across the ATO in 2017-18 was $59.3 billion and combined the top 100 and top 1000 taxpayers paid just under 47% of net GST collected by the Australian Taxation Office (ATO) giving an indication of their large contribution to the tax system.

1.2 Objective of this guide

The purpose of this guide is to explain how the justified trust methodology is applied with regard to reviewing the existence, design and operation of GST controls as part of an effective tax control framework.

Demonstrating how your good tax governance is embedded in positions taken, disclosures in Business Activity Statements (BAS) and tax calculations provides us with evidence we can rely upon, which can reduce the intensity of enquiries.

This guide provides practical guidance on how to conduct a self-review of your tax control framework for GST, by describing the requirements for each level of our staged rating system. In particular, it outlines the core elements and what we look for when we review the following three fundamental GST controls:

• > periodic internal controls testing for GST (board level control 4)
• > data controls in place for GST purposes (management level control 4)
• > documented GST control frameworks (management level control 6).

This guide also provides detailed guidance on how to undertake data and transaction testing, to ensure that your business systems are creating, capturing and correctly reporting GST. Data and transaction testing may also help you identify areas where your tax control framework may not be designed or operating effectively for GST purposes.

This guide can be used to:

• > prepare for a top 100 or top 1000 GST assurance (justified trust) review if you are a large market taxpayer in either of these populations;¹
• > review the design and operation of your GST controls as part of updating your tax control frameworks; and
• > undertake data and transaction testing to ensure your business systems are correctly reporting GST.

If you use this guide to self-review your governance for GST purposes or undertake data and transaction testing, it is advisable to scope this work with reference to this document, in particular sections 4 and 5.

1.3 Benefits of a well-designed GST governance control framework

The benefits to documenting and having a well-designed framework that is operating effectively for GST controls include the following:

• > Provides insights into the strength of GST controls and through ongoing testing may:
• - provide insight as to what your tax operating model looks like (i.e. resourcing, processes and technology); and
• - help to identify potential systems/process gaps to prevent GST control breakdowns in advance.
• > Assists senior management with:
• - clarifying accountabilities for managing tax risks to the board/senior management; and
• - helps the board/senior management to manage tax risk.
• > Provides evidence to support a higher assurance rating in your Tax Assurance Report/ Streamlined Tax Assurance Report. This may in turn:
• - help to reduce the risk of unexpected reviews/audits; and
• - provide a point of reference for statements you make in tax transparency reports.
• > Assist us in reducing the intensity of our enquiries because we can have confidence in your tax disclosures.

Appendix 1 contains two tables listing the common drivers and errors in GST reporting. These tables further highlight the importance of a well-designed GST tax control framework.

1.4 Benefits of well-designed GST business systems

The way in which your business systems create, capture, collate and report GST impacted transactions is fundamental to the correct reporting of your GST obligations.

The ATO considers this one of the most significant focus areas for a GST assurance review because incorrectly reported transactions can often lead to significant GST revenue effects over time. For example, in a high volume - low value environment such as a retail outlet, an undetected GST classification error of just one product could extrapolate to significant GST shortfalls when replicated throughout large volumes of sales across a large number of stores.

In assessing the correct reporting of your GST obligations, the ATO expects that you undertake assurance and verification procedures that align with your business and that are tailored to your own operating environment. The ATO considers data and transaction testing as a critical aspect of this process.

1.5 GST and Justified Trust

In a GST assurance review, we look for assurance that:

• > an appropriate GST control exists, is designed effectively and is applied in practice
• > none of the GST risks we have flagged to the market are present
• > the GST outcomes of atypical, new or large transactions are appropriate
• > we understand and can explain the various streams of economic activity and how they are treated for GST, which may include applying the GST analytical tool.

Therefore, while tax governance and data and transaction testing are important components of our assurance reviews, there is other work conducted as part of applying our justified trust (JT) methodology in a GST assurance review. For further information on the broader JT program, please refer to Appendix 5.²

1.6 Our governance ratings

We look for evidence that a tax control framework exists, such as a board-endorsed tax policy and/or documented procedures for preparing Business Activity Statements (BASs). Once we've established a tax control framework exists, we then look for objective evidence that the framework is designed effectively and is "lived". In this regard, we use the following staged rating system:

• > Stage 1: You provided evidence to demonstrate that a tax control framework exists.
• > Stage 2: You provided evidence to demonstrate that a tax control framework exists and has been designed effectively.
• > Stage 3: You provided evidence to demonstrate that a tax control framework exists, has been designed effectively and is operating effectively in practice.
• > Red flag: You have not provided sufficient evidence to demonstrate a tax control framework exists or we have significant concerns with your tax risk management and governance.

To reach our highest rating for tax governance for GST (stage 3) you must be able to demonstrate that your tax control framework has not only been designed effectively but is also operating as intended. This stage can be evidenced by a periodic tax controls testing program as well as reports describing the outcomes of that testing. When considering eligibility for a stage 3 rating, we look for evidence of an independent review that tests specific tax controls, for example by internal or external auditors that provide an independent level of assurance to the Audit Committee and the Board.

We may assign a "red flag" where you cannot provide evidence to demonstrate a tax control framework exists or if we have significant concerns with your tax risk management and governance. These concerns may include your approach to tax compliance, for example, where there are significant errors your tax control framework is not detecting.

1.7 Our approach

In undertaking our justified trust reviews for GST, we are likely to review the tax control framework for the largest GST reporting entity in a top 1000 group. We may also review the tax control framework of another GST reporting entity in that group where it has entities or business divisions that may present GST risk.

In our top 100 reviews, if there are a number of key GST reporting entities, we are likely to review the tax control framework for each of these entities.

A GST assurance review will focus on the last complete financial year. It will include systems and BAS walkthroughs. Data and transaction testing is also undertaken, focusing on a minimum of three consecutive BAS periods.

There are a number of materials to assist you with understanding the overall process followed in our tax assurance reviews (refer to Appendix 5). For GST governance, you should focus on this guide in preference to the older tax risk management and governance review guide, as it provides more current and additional practical information on how we review GST governance for large businesses in our Top 100 and Top 1000 assurance reviews.

This guide helps you to prepare for a GST assurance review by outlining the ATO's expectations in terms of what better practice tax corporate governance looks like. It can help you to develop or improve your own tax governance and internal control framework, test the strength of the design of your framework against our better practice benchmarks, and understand how to demonstrate the operational effectiveness of your tax controls to the ATO.

This guide also provides separate practical guidance to help you prepare for a systems and BAS walkthrough (Appendix 3).

2. Essential features of a tax control framework

A "tax control framework" typically comprises a suite of policies and procedures prepared by management which have been endorsed by the board of directors. The framework outlines your organisation's tax risk appetite, the acceptable level of tax risk for day-to-day operations and what types of issues and transactions require escalation.

The following eight areas of focus, which we describe as "controls," form the basis of a tax control framework. We focus on these controls because they are most closely aligned with the following justified trust objectives:

When applying the justified trust methodology, three of the above eight areas of focus, being BLC4, MLC4 & MLC6 are fundamental, because the design of these controls directly influences the way in which GST is reported. Section 3 of this guide provides a detailed explanation of these controls, including, the core elements and what we look for when we review these three fundamental controls.

The other five areas of focus are BLC1, BLC3, MLC1, MLC3 and MLC7. These five controls are common controls because the design is equally as critical for both income tax and GST, and there are common features in the way these controls are evidenced. Appendix 2 of this guide provides information on these controls, including, the core elements and what we look for when we review the design effectiveness of these five common controls from a GST perspective.

3. Our approach to reviewing governance

3.1 Overview

We review governance by requesting objective evidence of the design of tax controls which aligns with our ratings system. We review the design of your controls based on documentation you submit to us. We look for evidence in the form of approved policies and procedures demonstrating the existence and design of a tax control framework, for example, work instructions, templates and process maps.

We are unable to rely on slide presentations, draft policies or narrative descriptions of the tax control framework, as they do not represent source documentation.

When applying the justified trust methodology, we review the three fundamental controls (MLC4, MLC6 & BLC4) based on evidence you provide as part of our tax assurance review for GST purposes.

We also review the five common controls; however, if there has already been an income tax assurance review, we will generally seek to rely on source documentation previously submitted in reviewing these controls for GST purposes. We usually will only request additional evidence in relation to common controls if the source documentation submitted as part of a previous income tax assurance review does not extend to GST, or if there have been material changes in your tax control framework since the income tax assurance review.

We refer to this as our "top up" approach to GST governance reviews as part of our integrated approach, which is the same for top 100 and top 1000 taxpayers, however the intensity for top 1000 taxpayers will be different, as compared to top 100 taxpayers.

If you have not previously had an income tax assurance review, we will request evidence for all of the five common controls.

3.2 Standard ratings system

We apply an integrated tax governance staged ratings system, based on objective evidence provided by you to demonstrate existence (stage 1), design (stage 2) and operational effectiveness (stage 3) of your tax control framework. Our standard governance ratings for income tax and GST purposes are defined as follows:

	Stage 3	You provided evidence to demonstrate that a tax control framework exists, has been designed effectively and is operating effectively in practice.
	Stage 2	You provided evidence to demonstrate that a tax control framework exists and has been designed effectively.
	Stage 1	You provided evidence to demonstrate a tax control framework exists.
	Not evidenced or concerns	You have not provided sufficient evidence to demonstrate a tax control framework exists or we have significant concerns with your tax risk management and governance.

The table below articulates what is required for each stage.

4. Practical guidance to self-review your tax control framework

The scope of the review will be driven by whether you are a top 100 or top 1000 taxpayer to acknowledge the fact that taxpayers in the large market have multiple GST reporting entities and GST groups.

Top 100

A self-review of your tax control framework will enable you to self-assess the existence and design of your tax control framework for GST purposes using the ATO criterion and processes outlined in this guide.

In undertaking a self-review it is important that you obtain sufficient coverage over the whole GST economic group. We consider that a BAS relating to the largest GST reporter that provides at least 75% coverage of the GST throughput⁵ of the economic group represents sufficient coverage. Therefore, for the top 100, you should use the following criteria:

• > Greater than 75% coverage
• - Where the economic group is comprised solely of one GST reporting entity, select that entity.
• - Where the sole GST reporter's BAS is comprised of a number of GST divisions, identify the division that provides at least 75% coverage.
• - Where the economic group is comprised of a number of GST reporting entities, identify the reporting entity that provides at least 75% coverage.
• - Where the entity or division that contributes to the economic group provides less than 75% coverage, your scope should include:
• - The largest contributor based on GST throughput, and
• - The next largest contributor until the required 75% coverage is achieved.
• > Entities or business divisions including branches⁶ with unique or complex transactions including input taxed supplies, GST-free supplies and property transactions such as 'built-to-rent' that may present a GST risk.
• > Entities or business divisions including branches that have recently undergone major business system upgrades or introduced new IT systems, changed business operations models, have a high turnover of staff, where business reporting functions have been outsourced or business operations have introduced special purpose vehicles such as joint venture structures.

The ATO understands that undertaking a self-review of your GST controls requires a substantial investment in your time and resources. To ensure your self-review is undertaken as efficiently as possible and achieves the desired outcome, you are invited to discuss your intended scope and methodology with your Senior Relationship Manager before you begin your self-review.

For top 100 taxpayers your Senior Relationship Manager's contact information is listed on the most recent copy of your ATO Risk Differentiation letter.

Top 1000

In undertaking a self-review we encourage you to obtain sufficient coverage over the whole GST economic group. In our justified trust reviews for GST we are likely to review the tax control framework for the largest GST reporting entity in your economic group. We may also review the tax control framework of other GST reporting entities in your group if they have entities or business divisions that may present GST risk or have recently undergone major business system changes.

Evidence

Our approach to reviewing governance as part of our justified trust methodology is evidence based. We look at the policies and procedures you have provided to demonstrate the existence, design and operation of your tax controls framework in place for managing tax risk. The guidance on the following pages clearly articulates the ATO's expectations in terms of the design effectiveness of the three fundamental controls, which are MLC4, MLC6 and BLC4.

Please note that the types of objective evidence listed below under the heading "what we look for" are included as illustrative examples. We recognise the exact documents will differ between taxpayers.

Our guidance for each control is structured as follows:

• > Intent
• > Core elements
• > What we look for (in terms of objective evidence), and
• > Connections (where applicable).

4.1 MLC4 Controls in place for data for GST purposes (Design effectiveness, Stage 2)

4.1.1 Intent

The focus of MLC4 is to establish that controls are in place to ensure GST data integrity. Having a well-designed control framework is central to ensuring all business systems that process and store financial data, are able to accurately calculate, allocate, record and report GST amounts.

It is important to note that the term "business systems," which appears throughout this section of the guidance, is intended to cover the design of all of the business systems, subsystems, platforms etc. used to process business transactions.

The amount of GST reportable to the ATO is captured at the time supplies and acquisitions (referred to as sales and purchases) are entered into the relevant business system. Therefore, it is important that business systems and the GST data controls within those systems are designed effectively to help manage risks associated with potential processing errors (MLC4).

The effectiveness of the design of your business systems for GST will depend on the extent of automation and manual intervention required to capture and process data for GST purposes. Therefore, the design of your business systems should be fit for purpose and tailored to your circumstances to identify and mitigate GST risks.

The objective of reviewing your business systems is to identify and review your controls that support the accurate flow of data, including how they are initiated, authorised, processed, recorded and treated for GST purposes.

The objective evidence we look for is in the form of documented policies and procedures informed by the findings from walkthroughs undertaken on your business systems.

A walkthrough is a process where enquiries, inspection of documents and observations are performed to understand and evaluate the design of your business systems from a GST perspective. The walkthrough provides an opportunity to assess whether your business systems have been designed effectively and will assist in identifying design gaps that may give rise to potential GST errors. Refer to Appendix 3 for guidance on how to perform a business systems walkthrough including accounts receivable and accounts payable processes.

The objective of reviewing the extent of data processing and manual controls is to identify potential control deficiencies or weaknesses and areas of manual intervention that could increase the risk of errors in the data used to process and report your GST obligations.

The complexity of your business systems, including the extent of manual intervention, will determine which business systems you need to include within the scope of your self-review.

4.1.2 Core elements

In undertaking a self-review of your business systems for GST purposes, it is important to consider the following two core elements:

• > Business systems setup
• - IT controls for integrity and security of GST data (see 4.1.3.1 below)
• - GST master tax codes (see 4.1.3.1.2 below), and
• > Data processing - manual controls (see 4.1.3.2 below).

4.1.3 What we look for

4.1.3.1 Business systems setup

4.1.3.1.1 IT controls for integrity and security of data

The objective of reviewing your IT controls is to assess the design effectiveness of controls regarding the integrity and security of the data used for reporting your GST obligations.

Essentially, this element is about the design of your business systems and related application controls that are used for GST reporting. This is inclusive of:

• > Any sub-systems and how they interface with the business systems to process sales and purchases, and
• > Security controls in relation to your business systems access to prevent and detect unauthorised processing entries.

The objective evidence we look for in respect to IT controls is in the form of documented policies and procedures informed by the findings from a business systems walkthrough which is based on the business systems that you use to process and report your GST obligations.

Examples of the type of objective evidence we look for are set out below.

IT systems architecture and user interactions

Documentation in the form of policies and / or procedures which include the following information:

• > An IT systems architecture diagram focused on GST reporting, with an overview of the business systems (and any interfaces) you use to capture and process sales, purchases and related manual adjustments.
• > Details of any:
• - business systems developed in-house
• - outsourcing arrangements for accounting data
• - vendor support arrangements in case of any breakdowns in your business systems.
• 
  For example, commercial off-the-shelf or in-house developed systems. If multiple business systems are present, you will also need to provide your interface methodology and policies.
• > A description of IT controls in place to ensure accuracy and integrity of GST data input and processing, including segregation of duties.
• > Access control matrix, containing details of your access controls (logical, cloud and physical assets) including your current user access policy relevant to your business systems.
• > Details of how your IT team interacts with your tax/finance team regarding system implementation, upgrades or other changes to IT systems that may have an impact on GST reporting.

Recent business systems and user access audits/reviews

• > Results from your most recent business systems and/ or interface review (internal or external), including a copy of the report, proposed remediation for any matters identified during the review including the timelines for remediation.
• > Results from any recent internal/external user access audits, including copies of the reports received, proposed remediation for any matters identified during the audit(s) including the timelines for remediation.

4.1.3.1.2 GST master tax codes

We look for objective evidence to demonstrate the existence and design of your data controls built into your business systems, for example, the implementation and maintenance of:

• > GST tax codes
• > Customer, vendor and product master files.

The objective evidence we look for is in the form of documents such as policies and procedures informed by the findings from a business systems walkthrough. Refer to Appendix 3 for guidance in terms of the performance of a business systems, accounts receivable and accounts payable walkthroughs.

The objective evidence for policies and procedures could be in the form of an extract from business systems setup documentation, accounts receivable and accounts payable manual, BAS preparation manual /or other relevant policies/procedures. In terms of GST tax codes, we look for documented controls based on the examples set out below.

Controls regarding GST tax codes

Documentation in the form of policies and/or procedures which include the following information:

• > List of all GST tax codes which are available for use in business systems used to process sales and purchases for entities (including codes used where no GST applies).
• > Owners of the master list of tax codes for GST purposes. As this is often the tax/finance function, you may find this information in documented policies and/or procedures owned by the tax/finance function (generally documented in the BAS preparation manual).
• > Process for the regular review and signoff of the appropriateness of existing GST tax codes (typically by the tax/finance function).
• > Process for setting up, adding or deleting GST tax codes, including documented procedures regarding authorisation for access to create, change and/or delete GST tax codes and signoff process to seek tax/finance input/review.
• > Process for deciding if, when and how new GST tax codes can be created or old codes reactivated.

Customer, vendor and product GST master file setup

Documentation in the form of policies and/or procedures which include the following information:

• > New vendor/customer master file setup process. This includes IT controls around the assignment of GST tax codes based on details such as the Australian Business Number, the address and the GST registration.
• > Standard product/item master files including the GST classification of those products.

Built in "rules" to automate the assignment of GST tax codes within business systems

• > Information to demonstrate that standard rules are built into your business systems to automatically assign GST tax codes to sales and purchases based on the customer/vendor/product master file data as well as other information specific to each sale and purchase transaction (e.g. sales order, purchase requisition).

Example - Tax conditions tables These tables sit in the background within the business system (e.g. SAP) and comprise a set of "rules" to automatically assign GST tax codes to sales and purchases. The rules are based on specific customer master data, tax codes available in source systems, the actual sales order etc. Typically, this type of automation is in place for sales and purchases. The example below illustrates a sales transaction: SALES Practical example - Tax code automatically assigned to outgoing invoice (sales) Based on Customer master file, sales order, delivery, the condition table automatically assigns the tax code as follows: - Sold to and ship to address = Australia - GST tax code S1 assigned - S1 = taxable 10% GST applies)

4.1.3.2 Data processing - manual controls

The objective of reviewing data processing controls is to assess how GST tax codes are applied to facilitate the correct GST treatment.

This element is about the linking of the GST tax codes with the product/item master file to process routine transactions and reliably determine the correct GST treatment of sales and purchases including both routine and non-routine transactions.

"Routine transactions" in this context are those recurring, high volume standard sales and/or purchases which are low value at a transaction level and occur on a daily basis and where there is a low inherent risk of a GST technical error. Whilst the risk of technical error may be low, the aggregated effect of the error may be material. This can be distinguished from non-routine transactions which are mostly material at a transaction level or give rise to a high inherent risk of a GST technical error. These are typically one-off type transactions and/or transactions that maybe subject to the GST special rules.

The objective evidence we look for is in the form of policies and procedures informed by an accounts payable and accounts receivable walkthrough. Refer to Appendix 3 for guidance on how to perform an accounts receivable and accounts payable walkthrough.

The objective evidence for policies and procedures is typically in the form of standard operational procedures and/or instructions for accounts receivable and accounts payable as well as for procurement and sales order teams to process both routine and non-routine transactions.

We acknowledge that you may use other terminology in your documentation. However, for the purposes of this guidance, we have outlined below examples of the type of information that we would expect to see in your documentation:

• > The end to end flow of information to record sales and purchases.
• - General flow of information from sales order or purchase requisition through to the issue or receipt of invoices and the amount of GST charged or paid (could be by way of flowchart).
• > GST tax coding procedures:
• - instructions to establish and assign GST tax codes including manual processes including the approval process
• - process to identify and address transactions without a GST tax code
• - process to prevent the overriding of GST tax codes and the detection of this occurring (e.g. in what circumstances, why and by whom)
• - whether the business systems are capable of automatically identifying changes made to tax codes.
• > Instructions regarding any other manual processing of sales/purchases for GST purposes to ensure the correct amount of GST payable/receivable is recorded in the business system (e.g. use of spreadsheets and/or complex calculations which could result in errors in the amount of GST included in a sales invoice or errors in the amount of refundable GST recorded on purchases).
• > Valid tax invoice checks for compliance with applicable law and public rulings before processing.
• > Procedures for arrangements that are subject to the GST special rules.

4.1.4 Links to other controls

The rating for MLC4 may be impacted by any systemic errors identified through other aspects of our justified trust review, for example data and transaction testing especially where the reason for the errors are directly linked to missing and/or poorly designed data controls.

BLC4 - The internal tax controls testing contained in the periodic testing plan must include the testing of data controls in place to process sales and purchases including manual adjustments to ensure the GST treatment is correct.

MLC6 - The tax/finance function reviews the amounts reported in the BAS for each BAS period. Where errors are identified in the amounts reported in the BAS labels, it is important to understand the root cause of these issues. This process may uncover fundamental control gaps that are directly attributable to data integrity issues that specifically relate back to MLC4.

4.2 MLC6 Documented GST control frameworks (Design effectiveness, Stage 2)

4.2.1 Intent

This control relates to documented work instructions in place for GST compliance procedures for the monthly preparation, review and approval of Business Activity Statements (BAS).

These processes involve repetitive tasks; therefore, documenting them ensures consistency in tax positions or adjustments and mitigates key person risk.

4.2.2 Core elements

Detailed work instructions form the basis of the evidence of this control. These instructions should describe the controls and processes for each step of the monthly BAS end-to-end process to help to ensure compliance with legislative requirements and to help manage risks regarding GST disclosures.

4.2.3 What we look for

A comprehensive set of instructions, such as a manual covering the following:

4.2.3.1 Procedures for monthly BAS preparation process

Data extraction process (what, how, who, when). We look for:

• > A description of the names of GST reports run in each business system (which should list all supplies and acquisitions, tax codes and GST payable and refundable) and the process to verify the correct flow of transactions from business systems to GST reports.
• > Instructions for those running the GST reports in each business system regarding transformation, compilation and manipulation of source data and the processes to minimise the risk of transposition and duplication errors.
• > Procedures which must be followed to help ensure you have captured all supplies and acquisitions for the tax period for GST. For example, accounts receivable and/or accounts payable batches not processed to the general ledger.
• > Description of how GST reports are set up to ensure the correct attribution of supplies and acquisitions and whether the reporting date is based on "Invoice date", "Posting date" or some other date. The reason is to ensure that transactions flow through to the correct tax period for GST purposes and therefore the transactions disclosed in the BAS are in line with the attribution rules within the GST law.

Data analysis process (to ensure correct amount of GST is remitted and claimed), such as:

• > Running standard data tests and trend analysis tests to check for processing errors (e.g. exceptions based reports), through basic excel / databases or 3rd party software
• > Standard checks to identify high risk or material transactions (e.g. property, financing, Mergers and Acquisitions) and the process to confirm correct GST treatment including whether the GST tax code assigned was correct. Here we would expect to see a standard process for checking against tax invoices and contracts to confirm the correct characterisation of the supply or acquisition. We also look for evidence of the process in place to rectify errors once they are identified in relation to the monthly BAS preparation and review process.
• > Regular manual adjustments made to GST payable and receivable including the reasons.

4.2.3.2 Process for reviewing and signing off the monthly BAS

• > checklists to confirm the review of data analysis results, conclusions, what is approved and signed-off
• > process to review any adjustments made and the reasons
• > BAS working paper review instructions/templates
• > list of authorised personnel to approve and sign off the BAS (process to demonstrate segregation of duties between preparation and sign-off).

NOTE: In addition to the tax function reviewing the numbers which go into the BAS each month, you should also have a documented process for regular reviews by the tax function that examine GST classification, attribution, recording, reporting and supporting document validity (e.g. tax invoices) in accordance with the GST law.

4.3 BLC4 Periodic controls testing program (Design effectiveness, Stage 2)

The ATO does not conduct the testing required to assess the operational effectiveness of tax controls. Instead, we rely on the fact that your testing program has been designed effectively based on the principles outlined below.

In this regard, we recommend that testing of your tax control framework for operating effectiveness be performed by an independent reviewer as part of a periodic testing program which meets the criteria for design effectiveness as part of BLC4.

4.3.1 Intent

As part of its oversight role, the board should obtain assurance that the internal control framework it has endorsed is operating effectively. The design of the testing program helps determine whether the review is robust enough to provide a reasonable level of assurance that tax controls operate effectively. The testing program should include testing of GST controls for operating effectiveness. The design effectiveness of BLC 4 (stage 2) is a pre-requisite for being eligible to reach the highest rating for governance overall across all controls (i.e. Stage 3 overall).

If we have already undertaken a tax assurance review of your income tax affairs, we will consider evidence previously submitted with regard to your periodic tax controls testing program in reviewing it from a GST perspective.

However, we review this control for GST purposes based on the principles set out below.

4.3.2 Core elements

A periodic testing program that covers the following elements:

Scope of controls tested and taxes covered

For the ATO to rely on your testing, the test scope must include the testing of GST controls for data (MLC 4) and your documented GST control framework (MLC 6).

The test scope should be set out in a plan put together by the independent reviewer which has been signed off describing:

• > taxes to be reviewed
• > tax controls to be reviewed
• > control owners, and
• > frequency.

In terms of frequency of testing, this should be periodic, that is, not once-off testing, but rather, ongoing testing, with the frequency determined by an appropriately skilled person, for example an internal auditor. We would expect MLC4 and MLC6 are tested by an independent reviewer for operational effectiveness regularly for GST (ideally annually).

Who is conducting the testing - independent reviewer

The ATO does not conduct the testing. Instead, we rely on your testing program and the actual test results to assess the operating effectiveness.

In order for us to place reliance on your testing program, it needs to be conducted by independent testers. This means someone with a suitable degree of independence and skill. The most common scenario is the internal audit function conducting independent testing; as they have the skills and requisition level of independence, because they are not tax control owners.

Testing of certain GST controls, such as MLC4, by the tax function could qualify as independent testing, if the tax function is not the owner of those controls. For large corporates, this is often the case and the tax function often collaborates with internal audit to test GST controls owned outside the tax function (e.g. finance, IT, procurement, commercial teams etc.).

Testing methodology

We acknowledge that the testing methodology and frequency of testing will vary depending on the type of controls. We require evidence of the testing methodology in sufficient detail including any sampling methods applied in order to assess the adequacy of the work performed and to rely on your testing. We note the various testing methodologies in order of preference as follows: (1) re-performance, (2) examination/inspection, and (3) observation.

4.3.3 What we look for

• > Policies or procedures documenting the tax controls testing program i.e. operational effectiveness testing (within tax policy and/or enterprise wide policy or a combination of these).
• > Supplementary information, such as an extract from your actual test plan for the next 3 to 5 years setting out the above information, plus
• - proposed/actual commencement date for testing within the next 3 years or past 3 years
• - controls tested align with the controls forming our GST areas of focus on a rotation basis
• - evidence that the test plan is finalised and approved
• - agreed dates and deliverables
• - reporting process for test results (i.e. that the test results are tabled with the board or their delegated authority)
• > We acknowledge that the methods of testing and testing plans will vary depending on whether testing is done as part of an external audit, internal audit or another form of independent review. However, you should provide a sufficient level of detailed evidence of their testing plan for us to validate whether the testing can be relied upon.
• > Design of program reflects the various tax control owners, for example:
• - MLC4 - Control owners of business systems design and supplies/purchases processing are typically out in the business (e.g. finance, accounts receivable, accounts payable etc.), so testing of these controls may form part of broader enterprise wide testing programs.
• - MLC6 - The control owner is typically the tax function, so we look for a testing program specific to tax and BAS preparation. The reviewer needs to be someone independent from the tax function.

4.3.4 Sample Testing Program template

We encourage you to work with your internal risk team to identify existing testing programs which may cover certain testing that can be relied upon for GST purposes. For example, data controls for GST under MLC 4 may be covered as part of the existing 'Order to Cash' and 'Order to Payments' business process testing plans.

The sample controls testing plan at Table 1 is an indicative illustration of a plan for periodic tax controls testing for operating effectiveness. It illustrates the key elements to be included in a test plan for the ATO to place reliance on that testing.

Actual plans vary and the testing could also be performed by external auditors or other independent reviewers. We acknowledge that your testing program, the approach and the ongoing commitment to conduct periodic testing for operating effectiveness are driven by your overall enterprise wide risk management program.

Table 1: Sample Tax Controls Testing Plan⁷- illustration to demonstrate the key elements of a test plan.

5. Self-review your GST Correct Reporting through Data and Transaction Testing

5.1 Background

The way in which your business systems create, capture, collate and report GST impacted transactions is fundamental to the correct reporting of your GST obligations.

The ATO considers this one of the most significant focus areas for a GST assurance review because incorrectly reported transactions can often lead to significant GST revenue effects over time. For example, in a high volume - low value environment such as a retail outlet, an undetected GST classification error of just one product could extrapolate to significant GST shortfalls when replicated throughout large volumes of sales across a large number of stores.

In assessing the correct reporting of your GST obligations, the ATO expects that you undertake assurance and verification procedures that align with your business and that are tailored to your own operating environment. The ATO considers data and transaction testing as a critical aspect of this process.

GST Data Testing

Data testing involves running a number of pre-determined tests (see Appendix 4) against a defined data set to identify reporting errors and exceptions for further investigation and or correction.

GST Transaction Testing

Transaction testing involves tracing an identified transaction from its source documentation through to the financial reports to confirm the accuracy of the GST treatment, calculation and reporting of the transaction. Where errors and exceptions are identified, further investigation will be necessary and / or correction may be required.

Application in a justified trust review

As explained above, a justified trust review includes seeking assurance in relation to GST risks flagged to market (Focus Area 2) and atypical, new or large transactions (Focus Area 3). Your testing must also include these transactions and we will seek to understand how you have treated these transactions for GST purposes.

The ATO will review data and transactions for correct reporting. This includes further analysing transactions where we identify errors, anomalies, outliers or other exceptions from the data testing. It will also include separately analysing transactions relevant to any GST risks flagged to market and new or large transactions to confirm that these have been correctly treated and reported for GST purposes.

5.2 Data Testing

5.2.1 Intent

The purpose of data testing is to obtain quantitative insights and assurance over transactional data.

An effective data testing plan is one that is tailored to the specific business so that reasonable conclusions can be drawn in respect to whether your business systems are capable of correctly capturing, recording and reporting your GST obligations.

Applying data analytics over GST data assists in the identification of:

• > potential errors and exceptions that may require further analysis, examination and correction
• > potential process deficiencies
• > over and under payment of output tax (GST on supplies), and
• > over and under claiming ITCs.

5.2.2 Scope and Methodology

We look to the objective evidence that demonstrates the scope and methodology of the data testing with specific reference to the following:

• > the entity (entities) to be reviewed
• > the overall architecture of the source systems
• > how data is captured in source and business systems
• > determining what data fields for example date, invoice number etc. are required to undertake the testing
• > the data sample size
• > the testing methodology, and
• > the tests to be conducted.

5.2.3 The entity to be reviewed

It is common for taxpayers in the large market to have multiple GST reporting entities and GST groups. The scope of the data testing is driven by whether you are a top 100 or top 1000 taxpayer.

Top 100

In undertaking a self-review it is important that you obtain sufficient coverage over the whole GST economic group. We consider that a BAS relating to the largest GST reporter that provides at least 75% coverage of the GST throughput⁸ of the economic group represents sufficient coverage. Therefore, for the top 100, you should use the following criteria:

• > Greater than 75% coverage
• - Where the economic group is comprised solely of one GST reporting entity, select that entity.
• - Where the sole GST reporter's BAS is comprised of a number of GST divisions, identify the division that provides at least 75% coverage.
• - Where the economic group is comprised of a number of GST reporting entities, identify the reporting entity that provides at least 75% coverage.
• - Where the entity or division that contributes to the economic group provides less than 75% coverage, your scope should include:
• - The largest contributor based on GST throughput, and
• - The next largest contributor until the required 75% coverage is achieved.
• > Entities or business divisions including branches⁹ with unique or complex transactions including input taxed supplies, GST-free supplies and property transactions such as 'built-to-rent' that may present a GST risk.
• > Entities or business divisions including branches that have recently undergone major business system upgrades or introduced new IT systems, changed business operations models, have a high turnover of staff, where business reporting functions have been outsourced or business operations have introduced special purpose vehicles such as joint venture structures.

The ATO understands that undertaking a self-review of your GST correct reporting involves a substantial investment in your time and resources. To ensure your self-review is undertaken as efficiently as possible and achieves the desired outcome, you are invited to discuss your intended scope and methodology with your Senior Relationship Manager before you begin your self-review.

Your Senior Relationship Manager's contact information is listed on the most recent copy of your ATO Risk Differentiation letter.

Top 1000

As noted above for top 100 taxpayers, to draw a reasonable conclusion that your business systems are capable of correctly capturing, recording and reporting your GST obligations, it is important that you obtain sufficient coverage over the whole GST economic group. We encourage you obtain sufficient coverage over the whole GST economic group. In our justified trust reviews for GST we are likely to review the governance framework for the largest GST reporting entity in your economic group. We may also review the governance framework of other GST reporting entities in your group if they have entities or business divisions that may present GST risk or have recently undergone major business system changes.

The desired scope of data testing will depend and rely on the individual facts and circumstances.

If you have been notified of a top 1000 GST assurance review, we will discuss the scope of any data testing or self-reviews you have already undertaken at the commencement of the review. We will also work collaboratively with you where we identify any limitations in the scope of the work to close any identified gaps in this regard.

5.2.4 The overall architecture of the source systems

It is important to identify the systems that capture and record data to understand how data flows and GST specific information is captured, recorded and reported as well as the relevance of each system to the key GST touchpoints of a transaction. This provides the catalyst to identify which source system will be tested and determine the tests required. For example, to ensure the correct capture and reporting of sales values, data testing would start with the point of sale (POS) system.

5.2.5 How data is captured in source and business systems

To ensure completeness and accuracy of transactions, an understanding of how transactions flow into source systems and into business systems such as general journal and ledgers allows for testing of billing system totals against GST output accounts.

5.2.6 The data sample size

The ATO considers that it is better practice to test data that relates to the 12 month period that aligns to the most recent income tax return lodged. This will ensure that any improvements to the business system and data controls that you have implemented will be included in the testing scope.

The ATO considers a data set of at least three consecutive months (approximately 25% of all transactions) used as a representative sample of a full 12 month period as appropriate for business operations that involve a stable supply and acquisitions base.

Three consecutive months of data allows for month-end processes to be tested, trend and variance analysis to be performed and timing adjustments identified. It is also possible to test for the most common types of GST reporting errors made by large businesses from this data sample size. A list of common GST reporting errors and drivers for those errors is at Appendix 1.

There are a number of factors that will impact on the final data sample size chosen and the data analytics tests to be undertaken during a review:

• > rapid growth in the business
• > changes in existing business systems, Accounts Receivable (AR), Accounts Payable (AP), and BAS preparation processes and controls
• > changes in key accounting staff and/or GST tax managers
• > restructuring of the group
• > recent merger or demerger
• > the volume of transactions
• > the presence of any transactions involving GST risks flagged by the ATO
• > the presence of any identified significant or new transactions.

Where any of the factors listed above exist, it is likely that further testing and a larger data set may be considered more appropriate to mitigate sampling risk and achieve the intended outcome.

Where you have identified that these factors exist in your business operations, it is recommended that the data sample size includes the periods where any of these factors are present. Where significant changes have occurred in the existing business systems or processes and controls or where changes in key accounting staff have occurred, it is recommended to include months that are pre and post these changes in your data sample size.

Where data testing results indicate a large number of GST errors that can be attributed to specific GST tax governance controls, the sample size should be increased to a level that provides sufficient evidence to support an accurate factual finding. Similarly, where the test results include a number of significant or one-off transactions, the sample size should be increased to ensure sufficient coverage of those transactions.

5.2.7 Determining what data to include in the testing (what fields or tables within the database are required to test specific business processes)

Once the data testing period is established, a data sample size and data fields are selected. The data request should contain sufficient detail to ensure the correctness and completeness of the data to be tested. Often this includes data from source systems such as Point of Sale (PoS). The table below provides the detail required in a typical data request.

5.2.8 Testing Methodology

The ATO is aware that there are a number of commonly used data analytics software tools available to identify errors in the reporting of an entity's GST obligations. This may include proprietary specific purpose software or software tools used by accounting firms or data analytics service providers.

Where this type of software is utilised in performing the data and transaction testing, you need to compare the list of software tests against the list of ATO e-audit tests (see Appendix 4). This is important to ensure that the ATO can assess the results without the need to undertake further testing.

The comparison between data analytics software and the ATO data tests will provide valuable insights into further tests that may assist in your analysis and provide opportunities for further enhancements to your existing tests. This process will assist you in developing a tailored approach specific to your entity and promote a more streamlined and efficient process to ensure a targeted investment of your valuable resources.

5.2.9 Documenting your findings

The data testing you undertake needs to support the conclusion, including through objective evidence, that your business systems are capable of correctly reporting your GST obligations. Where data testing identifies errors and exceptions, process deficiencies and or over and under payment of GST, the steps you have taken to address these issues also forms part of this assurance. Further guidance is provided at 5.2.12.

5.2.10 Connections to GST tax governance controls

The outcomes from your data testing provide an opportunity for you to review underlying GST tax governance controls that may be contributing to the exceptions and errors identified. For example, where an error is identified in respect to the correct GST coding of a supply, the underlying error may be attributable to the review and sign off process that governs the Master File set-up.

5.2.11 Self-Review Process

Step 1: Identify the entity/entities to be reviewed

To draw a reasonable conclusion that your business systems are capable of correctly capturing, recording and reporting your GST obligations, it is important that the scope of the testing has sufficient coverage over your whole GST economic group. This has been discussed above.

Step 2: Identify the testing periods

Typically, the scope and methodology of the data testing will have a direct relationship with the observations and outcomes of the walkthrough of the business systems (see Appendix 3).

Gaps identified in governance controls can provide valuable insights into potential reporting errors and this information is used to identify and select a suitable representative sample of a consecutive three month period that has similar characteristics to the full 12 months being tested.

The period to be tested should reflect a 12-month tax period that aligns with the most recent income tax return lodged by the entity or the consolidated group.

In selecting three consecutive months as the test period as a representative sample of the period of review, consider:

• > trend analysis of the BASs for the relevant 12 month period
• > changes to Information Technology (IT) and source systems
• > structural change, changes to GST group or related entity dealings
• > observations and outcomes from the walkthrough of business systems
• > new and significant transactions.

In selecting the tests to be performed, consider:

• > outcomes and observations from the walkthrough process
• > tests published by the ATO
• > any tests specific to the industry
• > bespoke tests unique to your business.

Step 3: Testing the data

The data testing process begins with understanding the data, designing and deploying the tests and includes capturing and reporting the outcomes in the form of errors, exceptions.

It involves the extraction of data and the use of software to run the tests over the data. The software will produce error and exception reports that require further investigation and validation.

Key elements to consider when planning your data testing include:

• > the availability of software to undertake the data testing
• > the capability and capacity of staff to undertake the testing
• > scoping the testing including the process and the methodology
• > ensuring the data request/data extraction contain the required fields to conduct the testing
• > consideration of secondary systems such as staff expense (e.g. Concur) for batched and totals posted to the general ledger
• > ensuring that the scope and methodology of the data tests and procedures to be performed are documented
• > ensuring the tests include those specific to the industry, bespoke to the business and a description of each test and fields required to run the tests
• > document data transformation steps including data cleansing, reconciliations and uploading to analytics tool
• > identifying potential errors and exceptions, including anomalous transactions
• > capturing and reporting of identified errors, exceptions and recommendations.

Appendix 4 provides a list of the general tests that are undertaken by the ATO E-Audit function. These will assist in developing and enhancing your existing data testing processes. It also includes the approach to be used when determining whether specific tests will be required based on the unique attributes of your business.

Step 4: Documenting your findings

Capturing and reporting your data testing outcomes provides the objective evidence that demonstrates the extent to which your business systems are capable of correctly reporting your GST obligations.

The ATO expects that your report of factual findings provides sufficient detail and references to objective evidence.

Where data testing identifies errors and exceptions, process deficiencies and or over and under payment of GST, the steps you have taken to address these issues needs to be detailed and supported by evidence. Where further testing is conducted to test remediation activities, these should also form part of the report of factual findings.

Consistent with the ATO's record retention requirements, you must keep all records related to establishing, running and selling your business. This includes one-off transactions and those that support the calculations and amounts in your tax returns for five years after they are prepared, obtained or the transaction is completed, whichever occurs last.

Step 5: Disclose over and under payments of GST to the ATO.

In disclosing over and underpayments of GST to the ATO, you may be able to correct an error made in an earlier tax period in a future BAS. Goods and Services Tax: Correcting GST Errors Determination 2013 specifies the circumstances in which you may correct errors in working out your net amount for an earlier tax period.

5.2.12 Recording Testing Outcomes

The recording of the outcome of data testing undertaken must include the following:

• > a title and an addressee (ordinarily the engaging party such as independent external third party advisor)
• > the qualification, authorisation and independence of the person undertaking the testing
• > the testing scope including the methodology, the process for setting the scope, selecting the period of review and defining the testing period
• > details of the software used to run the tests
• > details of each test performed including the methodology applied and the procedures performed, detailing the nature, timing and extent of each procedure
• > a description of factual findings in relation to each procedure performed, that includes:
• - sufficient details of errors and exceptions identified
• - clearly defined criteria of each test and transaction (line-by-line) results be provided for all tests
• - step-by-step details of actions completed to format/manipulate and/or add to the raw data
• - control checks (reconciliations) of raw data used to upload to the data analysis platform that clearly shows the process and confirms the reliability of the tests output
• > details of the procedures which could not be performed, stating the reasons
• > a listing of errors and exceptions that require examination including any remedial action planned/taken
• > details of tests undertaken assuring the remedial action taken
• > a statement of full and true disclosure of all matters.

5.2.13 Efficacy of self-review

The alignment of the scope, method and recording of the data and transaction testing undertaken to the guidelines set out in this section including the independence of the person undertaking the testing vis-à-vis the underlying control owner will determine the extent to which we can rely on the outcomes of your self-review and whether we undertake additional e-audit and transaction testing (including the scope and sample size).

5.3 Transaction Testing

5.3.1 Intent

Transaction testing provides an opportunity to test routine and specific transactions so as to understand and explain errors and exceptions identified during data testing. Based on the results of the data testing, sample transactions are selected and traced from source documents through the financial reports to confirm the correct GST treatment, recording and reporting of a particular transaction.

5.3.2 What we look for

We seek to understand the errors and exceptions identified during data testing to gain insights into the root cause of these discrepancies.

Where sampling is used, we seek to understand the reasons used to identify the sample transactions identified for further testing and the testing methodology adopted to ensure it appropriately addresses the identified errors or exceptions.

We seek objective evidence including the source documentation relied on to validate the GST treatment of the transaction. The source documentation may include:

• > tax invoices, RCTIs, adjustment notes
• > contracts, agreements and deeds
• > journal entries
• > apportionment methodology
• > GST treatment approvals
• > GST calculation worksheets
• > Financial acquisitions threshold (FAT) calculation worksheet
• > bills of lading.

We rely on your testing outcome report to understand the methods you used to validate the errors and exceptions and any remedial or corrective action that you have implemented to prevent similar errors from occurring in the future.

We expect that the report, including the full data set, is retained to comply with the ATO's record retention requirements and is able to provide it to the ATO upon request.

5.3.3 Connections to GST tax governance controls

Transaction testing outcomes provide an opportunity for you to review underlying GST tax governance controls that may be contributing to the exceptions and errors identified. For example, where an incorrect amount of GST has been calculated in respect to a transaction, the error may be attributable to an incorrect interpretation or application of the legislation which could relate to the way significant or new transactions are identified and escalated for consideration by a Risk Management Committee.

5.3.4 Self-Review Process

Step 1: Review the errors and exceptions emanating from data testing.

Step 2: Select a sample of transactions from the errors and exceptions for examination and analysis to validate the data test outcomes.

In deciding on the sample size factors to consider include:

• > the number of errors and exceptions for each test
• > reasonableness to draw conclusions about the population from which the sample is drawn.

Step 3: Documenting the sampling methodology and the factors considered in determining the sample size.

To ensure that the sample size and sample methodology is fit for purpose, you should refer to professional standards on sampling.

Step 4: For the selected transactions, make appropriate enquiry, examination and analysis of the supporting documentation such as tax invoices, RCTIs, adjustment notes, journal entries, contracts, bills of lading and other documentation is sighted to understand and validate the correct GST treatment.

As part of this process, it is important to:

• > obtain the source document related to the transaction (i.e.) invoice, contract
• > identify how the transaction has been treated for GST purposes noting the technical working papers, approval documentation and any escalation processes that have occurred
• > determine whether any ATO published guidance is applicable to the transaction noting the expected GST treatment and compare this to the actual GST treatment
• > determine whether the correct GST treatment has been applied making specific reference to the relevant legislation, ATO guidance and any independent advice received
• > review all working papers related to the GST treatment and calculation for each transaction for correctness
• > trace each transaction from source documents to journal entry to general ledger
• > in certain circumstances it may require a detailed analysis to consider the appropriateness and validity of allocation of costs/amounts to cost centres.

Step 5: For errors confirmed, note the corrective and remedial action required and or taken to prevent these errors occurring in the future and note if any escalations were made to senior management with respect to errors identified.

Step 6: Capture and report findings including quantum of the error.

Step 7: Disclose over and under payments of GST to the ATO.

In disclosing over and underpayments of GST to the ATO, you may be able to correct an error made in an earlier tax period in a future BAS. Goods and Services Tax: Correcting GST Errors Determination 2013 specifies the circumstances in which you may correct errors in working out your net amount for an earlier tax period.

5.3.5 Recording Testing Outcomes

The report of transactional testing should include:

• > details of the errors and exceptions resulting from the data testing
• > an outline of the approach undertaken, errors and exceptions tested, validation outcomes and verification process including future action or remediation points
• > where sampling is used, the details of the methodology and sample sizes and document why they are appropriate and best suit the errors or exceptions
• > for each category of error or exception, the detail of the methodology and procedure applied including the nature of the enquiry, examination and analysis of the supporting documentation such as tax invoices, RCTIs, adjustment notes, general ledger postings, journal entries, contracts, bills of lading and other documentation to validate the GST treatment of the transaction
• > for each category of error or exception confirmed, note the corrective and remedial action required and or taken to prevent similar errors occurring in the future
• > A copy of the exception reports produced by the software used to undertake the transaction testing
• > a statement that the procedures performed were those outlined in the ATO's guide
• > the report, including the full data set and work papers, is retained to comply with record retention requirements
• > a statement of full and true disclosure of all matters.

Appendix 1 - Common drivers and errors in GST reporting

Drivers

The following table lists the common drivers for errors in GST reporting:

Common errors

The following table lists common errors in relation to GST reporting:

Appendix 2 - Common controls for GST and Income Tax

As mentioned at section 2 of this Guide, in addition to the three fundamental controls, there are five common controls across income tax and GST which form part of our JT areas of focus for governance. These controls are BLC1, BLC3, MLC1, MLC3 and MLC7. They are common controls because the design elements are equally as critical for both income tax and GST and there are common features in the way these controls are evidenced.

If you have already had an income tax assurance review, we will be largely relying on the evidence provided as part of that review where the results are equally applicable across both income tax and GST. We will only request additional evidence in relation to common controls if the source documentation submitted as part of a previous income tax assurance review does not extend to GST, or if there have been material changes in your tax control framework since the income tax assurance review. This approach is the same for top 100 and top 1000 taxpayers, however the intensity for top 1000 taxpayers will be different.

If you have not previously had an income tax assurance review, we will request evidence for all of the five common controls below.

The purpose of this appendix is to provide guidance on what we look for to demonstrate the design effectiveness of these five common controls.

BLC 1 - Formalised tax control framework

Intent

Sets out the parameters of how tax risks are to be managed in line with enterprise wide risk management strategy.

Core elements

1. A tax strategy document that sets out how tax risks are to be managed (including GST and Income Tax).
2. Board endorsement, or endorsement by a delegated authority where applicable.

What we look for

Tax strategy document

• > An enterprise-wide document that refers to tax or a stand-alone policy for tax that sets out the strategy for managing tax risk (can be high level or detailed), where "tax risk" covers GST.
• > For multi-national enterprises, we look for the same document as above, but it could be either a global document or a separate document that applies to Australia.
• > Check whether all entities within the GST group and income tax consolidated group (TCG) or multiple entry consolidated (MEC) group are within the scope of the document.

Board endorsement

• > Extract from board minutes must show endorsement (noting by email is not sufficient).
• > Can be evidenced within the strategy document itself (e.g. on the front page or version control table at the end of the document).
• > Where the board has delegated its authority to endorse the policy on its behalf, evidence of this delegation and approval.

Links to other controls

The strategy to manage tax risk sits across all board level and managerial level controls.

BLC 3 - The board is appropriately informed

Intent

The board has the leading role in overseeing risk management structures and policies. To do this the board must be informed of the tax risks (including GST and Income Tax) in the organisation.

Core elements

1. Who informs the board.
2. What matters the board is informed on.
3. How the board is informed.
4. When the board is informed.

What we look for

Policy, procedure or manual (or stated in a board reporting template) that addresses the above core elements:

1. Identifies who is responsible to report to the board (e.g. CFO, Head of Tax) and if there are any differences for GST compared to other taxes (e.g. via Chief Operations Manager, Chief Technology Officer) and how GST matters are escalated from the indirect tax manager (or equivalent) to ensure GST risks are covered by the Head of Tax / others in reporting of all tax risks to the Board .

2. Sets out what tax matters (including GST and Income Tax) are reported to the board; the minimum requirements are:

• > Effective tax rate, whether income tax and/or GST paid/refunds claimed aligns with business results, reasons for misalignment (i.e. permanent and temporary differences, changes to the business model resulting in changes to GST group structure, apportionment methodologies for attribution of costs to input-taxed acquisitions/supplies) - refer to MLC 7.
• > Potential and actual tax risks or implications of significant transactions (which should be clearly defined based on risk rating, materiality thresholds, etc.) and how tax risks are trending. For GST, better practice reporting processes include GST specific technical risks, as well as related commercial/systems based risks which flow on from positions taken (e.g. variations to standard contract terms, requirement for major systems changes). For GST, we would expect materiality thresholds are defined to reflect GST payable on supplies and GST claimable on acquisitions (i.e. not just the net GST payable).
• > Transactions that may need board approval due to the tax risks involved (e.g. positions taken outside published ATO safe harbours for income tax and GST) and requirement to seek external advice- this might be set out as part of documentation evidencing MLC 3.

3. Specifies how the board is informed (e.g. board reporting template, memo).

4. Clearly articulates the frequency of reporting (e.g. quarterly, 6 monthly, annually).

Links to other controls

MLC 3 - Authorisation levels for significant transactions.

MLC 7 - Reporting on effective tax rates and whether tax paid aligns with business results.

MLC 1 - Roles and responsibilities are clearly understood

Intent

Clear accountability between departments or individuals reduces the risk of conflict in responsibilities that could lead to inefficiencies, such as duplication of work, delayed work or mismanagement of key tax risks.

Core elements

Documented responsibilities:

1. For key roles: board, sub-committee (audit or risk committee), management and business units.
2. In relation to:
1. Review and preparation of BAS, income tax return and tax disclosure for financial statements.
2. GST and income tax advice, including escalation of significant transactions to tax team and reporting to senior management (where required).
3. Reviewing and maintaining the tax control framework.

What we look for

• > Responsibilities: commonly set out in a matrix such as a RACI (Responsible, Accountable, Consulted and Informed), or across multiple documents.
• > Controls should be clear on whom it applies to and what is required of them.
• > Policy or procedures should clearly set out:
• - Who prepares, reviews and signs off BAS, income tax return and tax effect calculations (the preparer should not also be the reviewer) - refer to MLC 6 and MLC 7.
• - The reporting chain for tax matters (including GST and Income Tax) - who reports risks to the tax team, who escalates to management and/or the board for approval, who reviews or follows up identified risks (including how frequently this is done) - refer to BLC 3 and MLC 3.
• - process for indirect tax manager (or equivalent) to partner with accounting/finance/operations and systems staff to consider the GST consequences of transactions and materiality thresholds

Links to other controls

All board and managerial level controls.

MLC 3 - Significant transactions are identified

Intent

Management of GST and income tax risks relating to significant transactions is critical as it may have a large impact on tax positions. This control focuses on the end-to-end process from identification through to risk mitigation strategies.

Core elements

1. Significant transactions must be clearly defined by reference to materiality thresholds (monetary and non-monetary, e.g. reputational risk) and types of transactions.
2. Escalation process to the tax team covering all business areas (for GST this should include A/R, A/P, finance/accounting, procurement, commercial legal).
3. How the tax team categorises and rates the risks (including GST and Income Tax) and how these risks are recorded (e.g. by way of a tax risk register).
4. Thresholds to obtain external advice or seek approval from senior management or the board and whether there are commercial/legal processes which require GST sign-off and by whom.

What we look for

Policy, procedures or operations manual that sets out:

• > What matters require escalation to the tax team (should be sufficiently clear, easily understood and not discretionary).
• > Process for indirect tax manager (or equivalent) to partner with accounting, operations and systems teams to consider the GST consequences of significant transactions
• > How business units notify the tax team (e.g. mailbox, contact person, referral template with instructions).
• > The method of assessing and classifying GST and Income Tax risks (such as heat maps, risk matrix), and how often these ratings are evaluated.
• > What matters require approval from senior management and/or the board.

Links to other controls

BLC 3 - The board is appropriately informed of how tax risks are trending in relation to significant transactions.

MLC 6 - Tax implications of significant transactions are correctly reflected in the BAS and income tax return.

MLC 7 - Procedures to explain significant differences

Intent

Process to explain differences between accounting disclosures, financial statements, the BAS and income tax return. This involves repetitive tasks, therefore documenting the process ensures consistency, reducing fluctuations (such as large unders/overs) year-on-year, and mitigates key person risk.

Core elements

Process or procedures for:

1. Calculating income tax expense, deferred tax assets and deferred tax liabilities for the financial statements.
2. Reconciling the tax note to the financial statements and the completed income tax return.
3. Management to explain income tax paid compared to business outcomes and variances between tax expense for financial statements and tax payable for completed income tax return.
4. Management to explain BAS reporting of GST payable on sales (1A) and GST receivable on purchases (1B) compared to business outcomes and variances in comparison to financial statements (e.g. through GST analytical tool).
5. Management to explain variations between monthly net GST payable/receivable as reported on the BAS and monthly GST clearing account balances for management accounting purposes.

What we look for

• > Procedures may be found in a single manual or can be in separate accounting notes or policy papers (this depends on whether teams other than tax are responsible for recording accounting treatment, such as the Accounting or Project team).
• > Tax effect calculations prepared in accordance with the tax accounting standard.
• > Consider the accounting standard on tax adjustments and any connected standard covering the accounting treatment.
• > Template used to compare and explain variances between GST reporting on the BAS and business outcomes as reported in financial statements (e.g. through GST analytical tool).

Links to other controls

BLC 3 - informing the board on effective tax rates and alignment to business outcomes.

MLC 1 - responsibility to prepare and review calculations and report to the board.

MLC 6 - BAS and income tax return preparation process.

Appendix 3 - Systems and BAS Walkthrough

Walkthroughs

The systems and BAS walkthroughs involve gaining an understanding of:

• > The systems that are used within your organisation that have an impact on ATO reporting, including sub systems and reports.
• > The key accounts receivable, accounts payable and BAS preparation processes explaining how these are representative of your business, including any significant and new transactions.
• > The identification of relevant personnel involved in the end-to-end process for each function.
• > The level of consultation that has occurred with relevant personnel involved in the end-to-end process for each function with the primary objective of observing the actual processing and control procedures in real time.
• > The flow of GST specific information from data initiation, customer and vendor setup, product setup, GST tax code allocation, invoice processing and the various approval and authorisation points.

Whilst a walkthrough overlays and informs particular aspects of our review of your tax governance framework, the review of the design of your tax governance controls is based on source documents.

Accounts Receivable (AR) and Accounts Payable (AP)

The objective is to understand and evaluate the systems used that support the AR and AP functions including meeting with relevant personnel that have the specialist knowledge and can explain key processes.

Key Personnel

For AR it will be those staff involved in the end-to-end sales process from customer set up to raising and issuing of sales invoices. For AP it will be those staff involved in the end-to-end AP process from vendor set up, procurement and processing of invoices.

Discussion points will include:

• > how long they have been in their current role
• > whether their role overlaps with other duties
• > the information they rely on to do discharge their role
• > the training or induction they receive when they started their current role
• > how changes to procedures and processes are communicated to them
• > their familiarity with the escalation process for when something goes wrong or when a particular sales transaction, issue or matter requires escalation.

AR - Product setup and classification

We select different product types and step through the end-to-end process.

For the product(s) selected we are seeking to observe:

• > Whether the documented process caters for different product types and the existence of checklists.
• > The process for allocation of GST tax codes:
• - whether the tax function and or IT involved in this process
• - the information captured and the source of this information
• - segregation of the setup and authorisation functions
• - the controls in place (including any potential deficiencies) to ensure the accuracy of the information captured during this process.
• > Each step in the process (which may include screenshots) evidencing the flow of the information through the system that supports the Product Master File.

AR - Tax codes

Review of the list of available GST tax codes in the business system for sales.

For each tax code:

• > description of the code
• > when it is used
• > whether the code is the same across all systems
• > the process for assigning tax codes to products and whether the tax function is involved in this process
• > whether the tax code can be overridden
• > who is authorised to change the code
• > whether the changes to tax codes are tracked
• > each step in the process (which may include screenshots) evidencing the application of the GST codes in the system that supports the process.

AR - Customer setup

Review the process for customer set up:

• > system(s) and business processes that support the function
• > whether the process is documented
• > the number of staff involved in the process
• > the information captured (ABN, customer location including any overseas ship to address etc.)
• > whether any GST codes are assigned
• > segregation of the setup and authorisation functions
• > controls in place to ensure the accuracy of the information captured
• > each step in the process (which may include screenshots) evidencing the flow of the information through the system that supports the Master Customer File.

AR - Sales and invoicing

Review of the product list (including the GST tax codes) in the business system for sales.

For each sales segment, selecting a sample transaction, including any significant or non-routine transactions and stepping through the process.

For each transaction selected:

• > the systems and business processes that support the function
• > the existence of a documented process
• > access to the systems
• > how a sale is initiated
• > whether purchase orders are matched to your sales/supplies
• > whether the system permits a sales transaction to be processed without a tax code
• > whether the tax codes are hard coded in the system
• > if classification of supplies can be manually over-ridden during transaction processing, if so, who can override the tax codes e.g. sales personnel or an authorised personnel
• > the ability to track the changes to the product classification
• > the invoicing process, whether it is fully automated and invoice numbering is sequential, or some manual process involved especially for non-routine transactions
• > how unusual/one-off significant transactions are flagged and processed, and escalation points/authorisations
• > the extent of authorisation, if any
• > for exports and GST-free transactions, existence of any special rules or alerts such as overseas ship to address
• > if a documented process exists for returned goods, and note the existence of any authorisation process and the documentation generated i.e. adjustment and credit notes and the associated general ledger postings
• > the treatment of discounts and rebates and documentation generated
• > training provided to staff performing this function
• > whether staff duties, roles and responsibilities are clearly defined
• > documented process that includes a checklist for staff and approvers
• > note the extent of user input and the systems functionality that permits the user to change/alter GST information while processing the relevant transaction
• > each step in the process including screenshots evidencing the flow of sales and invoicing (including general ledger postings) through the system that supports the process.

AP - Master vendor setup and maintenance

Review of the process for Vendor set up:

• > system(s) and business processes that support the function
• > whether the process is documented
• > the number of staff involved in the process
• > the information captured (ABN, GST status of the vendor)
• > segregation of the setup and authorisation functions
• > controls in place to ensure the accuracy of the information captured
• > each step in the process including screenshots evidencing the flow of information through the system that supports the Master Vendor File.

AP - Tax codes

Review a list of all the tax codes used in the business system relevant for acquisitions.

For each tax code:

• > description of the code
• > when it is used
• > whether it is the same across all systems
• > the process for assigning tax codes to products
• - whether the tax code can be overridden
• - who is authorised to change the code
• - whether the changes to tax codes are tracked.

AP - Procurement and invoice receipting, and payment review of the list of acquisitions (including GST tax codes) in the business system, and selecting some sample transactions

For each sample transaction stepping through the process:

• > the system(s) and business processes that support the AP function
• > the existence of a documented process
• > the number of staff that perform this function and whether the function is centralised
• > whether access to the systems to relevant system(s) maintained and monitored
• > how an acquisition is initiated and whether a purchase order is required
• > whether there is a documented process to consider the GST ramifications of contracts reviewed and authorised by the tax team
• > whether acquisitions for major assets, such as land acquisitions are reviewed/authorised to ensure correct GST treatment
• > whether receipting includes mandatory 3 way matching of purchase orders with goods, the invoice and the GST amount
• > where the system automatically defaults to an ITC amount on acquisitions of 10%, what process is followed to deal with invoices where the GST is less than or more than 10%
• > whether the system permits acquisitions to be processed without a purchase order and or tax code
• > whether the tax codes are hard coded in the system, and defaults to taxable (potential for over claim of ITCs)
• > if the tax codes can be manually over-ridden during processing of invoices, and who can override the tax codes e.g. AP personnel or an authorised personnel
• > how unusual/one-off significant acquisitions are flagged and processed, and the process to escalate these
• > whether duplicate invoices are prevented from being processed
• > whether Vendor ABN and GST status is checked during processing of invoices
• > whether guidance exists for what constitutes a valid tax invoice, i.e. for invoices over $1000, the recipients details are required
• > the authorisation process, if any
• > if a documented process exists for returning of goods, and noting the existence of any authorisation processes and the documentation generated i.e. adjustment and credit notes and the associated general ledger postings
• > the treatment of discounts, rebates and commissions received and the process for raising and issuing of recipient created tax invoices
• > the processing of staff reimbursement expenses, including any subsystem that supports the process, including the interface to the main system
• > training provided to staff performing this function
• > whether staff duties, roles and responsibilities are clearly defined
• > documented processes that includes a checklist for staff and approvers
• > documented process for allocating/posting of particular expenses to relevant cost centres/ general ledger accounts
• > documented process for input taxed supplies and monitoring of the financial acquisitions threshold exists
• > processes to identify intra-GST group transactions and claiming of ITCs
• > the amount of user input and the systems functionality that permits the user to change/alter GST information while processing the relevant transaction
• > each step in the process (which may include screenshots) evidencing the flow of the information (including general ledger postings) through the system that supports the procurement, invoice receipting and payments.

Walkthrough Outcomes and Conclusions

The walkthrough of your AR and AP systems should confirm that your processes and controls ensure that:

Month-end Process

Observation as to:

• > when the accounts are closed for month-end and whether the AR and AP accounts closed on the same day
• > the systems processes that support the month-end process
• > how the commencement of the month-end is communicated to AR and AP staff
• > who is responsible for the month-end process and what tasks are undertaken that impact GST.

For each task with a GST impact:

• > why it is undertaken and what is the GST impact
• > why there is a need for the month-end journal entry
• > the approval process
• > consideration of any automated process to eliminate the need for the relevant month-end journal entry.

BAS preparation

The objective is to understand the BAS preparation process.

Key Personnel

Meet with the relevant personnel responsible for preparing, reviewing and signing-off the BAS to understand the BAS preparation.

Walkthrough Process

Step 1: Select a sample BAS period

We may select a sample BAS period and request the relevant personnel to step through how the BAS is compiled; from extracting the reports, completing the various BAS labels, the analysis undertaken, the review and sign-off, lodgment and ultimately to retention of the BAS working papers.

Step 2: Relevant systems and business processes

Systems and business processes that support the BAS:

• > the systems and applications where data is sourced and processed and the reports that are run from the systems
• > whether all systems are integrated, or are there any legacy/unintegrated systems requiring manual intervention to collect BAS/excise return preparation data
• > what are the Access controls to identified key systems
• > whether the BAS preparation process is documented
• > the system diagram showing the flow of transactions from source systems to the BAS
• > the extent to which the BAS preparation is automated and the number of manual steps to integrate reports from different systems or parts of the organisation
• > the process for ensuring that the extracted data is complete and reconciled to the general ledger/source systems
• > whether all GST groups and group members use the same business system for GST reporting
• > access controls to BAS worksheet and working papers, ensuring access is restricted to authorised personnel
• > whether an excel worksheet is used to prepare the BAS
• > the use of assurance software to facilitate the preparation of your BAS and whether the software has been customised
• > whether the BAS process forms part of the periodic review program and if so, when it was last reviewed.

Step 3: The BAS Preparation Process

Step through the BAS preparation process:

• > the number of personnel trained and authorised to prepare the BAS
• > the steps in the preparation process
• > the reports generated to prepare the BAS and the source of these reports
• > the tests and checks performed including variance, trend analysis and identification of outliers and significant transactions.
• > the transaction testing undertaken including sampling of transactions to ensure the accuracy of the BAS
• > the reconciliation and review of GST general ledger accounts (and relevant excise liability accounts) and the approval process for journals/postings
• > any manual adjustments and supporting evidence to support the adjustments
• > the existence of a preparer checklist.

Step 4: BAS Review and Sign-off Process

Step through the BAS review and sign-off process:

• > the number of personnel trained and authorised to review and sign-off the BAS
• > whether the reviewer performs a complete review of the BAS to ensure accuracy, including the uses of exception reports, analysing significant transactions, matching of source documentation for verification purposes and trend or reasonableness analysis to confirm the BAS numbers are consistent with business expectations
• > the existence of a documented checklist for the approver
• > whether the review/sign-off process is segregated from the preparation process
• > whether the BAS process forms part of the periodic review program, if so, when was it last reviewed.

Step 5: Retention of BAS working papers

Step through the BAS retention of working papers process:

• > the formal document retention policy
• > how long the BAS working papers are required to be retained
• > where the digital and paper copies of BASs are stored
• > whether access to BAS working papers is restricted to authorised staff.

Appendix 4 - General and specific data tests

General tests

Specific testing

A bespoke approach will need to be used to determine what specific tests will be required based on the unique attributes of your business, including industry specific risks and risks identified in ATO public or private rulings and guidance documents. It is expected that you:

> Have an in depth understanding of the tax risks associated with your business and that you are aware of tax technical risks that apply. You should also be informed of ATO positions in ATO rulings and published guidelines, especially in relation to significant or unique transactions.

> In addition to tax risks, it is recognised that you have a systems design which relates to your individual business and industry. Complex or unique systems, structures that include multiple systems and interfaces should be understood, well documented and have a clear synergy. The whole systems environment should be taken into consideration focusing on points where a decision is made as to the GST treatment of the transaction.

The following examples illustrate this:

1. A motor vehicle dealer has multiple technical elements which are unique and include:
• > Factory incentives, holdbacks, bailment arrangements, trade-ins (second-hand acquisitions reflected in notional GST account) and Luxury Car Tax which would generally apply to the whole car industry and specifically to each dealership.
• > Motor vehicle dealers also use specific Dealer Management Software (DMS) which has attributes common to all motor vehicle dealers but may also have unique factors. There may also be other systems and interfaces which are used to determine GST treatment.
2. A food retailer may have multiple systems which are interfaced to their business system for a large number of retail outlets. The linked tax treatment may be driven by product codes from multiple system sources. These products may be updated from the ATO GST food guide and a private ruling for GST classification purposes may have been sought.
3. A financial supply provider will have unique accounting rules to claim ITCs based on their Extent of Creditable Purpose (ECP). ECP rates may be applied through the business system based on business rules or applied in a separate database or separate system. The application of these ECP rates to the claiming of ITCs should be tested to confirm the ECP rates have been applied correctly within the applicable system.

The types of factors in the examples need to be considered when designing your approach and scope for the tests that will be required. In addition, it would be expected that you have a robust testing methodology to ensure the flow of tax reported is clear, concise and easily identified, and followed from points where decisions are made as to the GST treatment right through to the BAS.

In undertaking your data and transaction testing it would be expected that a level of sampling takes place in regards to specific risks that relate to your industry or have been flagged to market by the ATO.

For example, if you export goods the ATO would expect that a reasonable sample of those export transactions are examined to confirm that the 60 day rule has been complied with. This would include confirming that either of the two factors below has occurred and the goods have been exported within 60 days:

> the supplier receives any payment for the goods, and

> the supplier issues an invoice for the goods.

In other cases it may be necessary to test using a statistical sampling technique, such as stratified random sampling, due to the volume of transactions. This would then involve, for example, vouching from journal or transactional data to a valid tax invoice.

In the financial supplies example above, it would be necessary to design a specific data analytics test, based on your business system, to confirm the ECP rates have been applied correctly within the applicable system.

Appendix 5 - Additional information

This following links will take you to further guidance and resources regarding justified trust, and the top 100 and top 1000 programs including:

* For GST governance, you should focus on this guide in preference to the older tax risk management and governance review guide, as it provides more current and additional practical information on how we review GST governance for large businesses in our Top 100 and Top 1000 assurance reviews.

Contact us

For a copy of the GAT Guide and method statement we use to complete our GAT calculations or to learn more about the Top 100 or Top 1000 GST assurance program, email us at Top100@ato.gov.au or Top1000Program@ato.gov.au

We welcome feedback as we continue to integrate our approaches for justified trust across income tax and GST.

¹    The top 100 population is determined through the annual moderation process which is outlined on our website (and a link is included at Appendix 5). The top 1000 population is also defined the same for income tax and GST being any foreign owned or Australian headed economic group with turnover greater than $250M.

²    Refer to our large business Justified Trust webpage - see Appendix 5 for details.

³    Refer to Practical guidance to reviewing tax governance published on 19 June 2018.

⁴    Refer Appendix 2 for an explanation of what we look for regarding the design effectiveness of BLC1.

⁵    GST throughput refers to the total $ amount of GST transactions that the taxpayer manages. It is the sum of GST on sales (1A), GST on purchases (1B), and deferred GST on imports (7A). This calculation provides a more accurate understanding of the amount of the GST - both liabilities reported and credits claimed. This includes the GST reporting obligations of the GST joint venture operator (but not in the capacity of joint venture participant).

⁶    A branch of a GST registered entity can be separately registered as a GST branch. Separate BAS is lodged in respect of the branch. However, a branch of a registered entity cannot be registered as a GST if the registered entity branch is a member of a GST group.

⁷    Refer to 'Reviewing tax governance for large public and multinational businesses' published on 19 June 2018 for further guidance.

⁸    GST throughput refers to the total $ amount of GST transactions that the taxpayer manages. It is the sum of GST on sales (1A), GST on purchases (1B), and deferred GST on imports (7A). This calculation provides a more accurate understanding of the amount of the GST - both liabilities reported and credits claimed. This includes the GST reporting obligations of the GST joint venture operator (but not in the capacity of joint venture participant).

⁹    A branch of a GST registered entity can be separately registered as a GST branch. Separate BAS is lodged in respect of the branch. However, a branch of a registered entity cannot be registered as a GST if the registered entity branch is a member of a GST group.

Copyright notice

© Australian Taxation Office for the Commonwealth of Australia

You are free to copy, adapt, modify, transmit and distribute material on this website as you wish (but not in any way that suggests the ATO or the Commonwealth endorses you or any of your services or products).