This module provides an overview of the options available to software developers for mapping applications to the SBR Taxonomy.
- Approaches to XBRL implementation
- Option 1: Government Report level
- Option 2: Built in - at trial balance level
- Option 3: Built in - deeply embedded in ledger systems
- Implementing XBRL support into your application
- Phased implementation
Approaches to XBRL implementation
There are three main approaches available to software developers to implement XBRL in an application supporting SBR:
- High level
Government report level - Embedded
XBRL at trial balance - Embedded
XBRL Global Ledger
High level - Government report level
The first method is to implement the XBRL at the government reporting level.
This method allows software developers to quickly implement XBRL for SBR by tagging existing reports with the SBR taxonomy to produce valid instance reports. Under this approach, if a software developer wanted to further extend their SBR offering, they would need to develop additional reports within their application in order to be able to tag them.
This approach allows very little user interaction with the preparation of the instance documents.
Embedded - XBRL at trial balance
The second method is to embed the SBR Taxonomy in the application to allow users to map trial balance or other summary level information maintained by the supporting system/s directly to the taxonomy to generate reports.
This method allows users to extend their use of XBRL and SBR beyond those reports already developed within the application.
We will discuss embedding the SBR taxonomy at the trial balance level later in this module.
Embedded - XBRL and XBRL Global Ledger
The third method is to embed the XBRL deep within the application by implementing XBRL Global Ledger taxonomy at the transaction level.
XBRL Global Ledger is not a focus of this training. For more information on XBRL Global Ledger, please refer to www.xbrl.org/GLTaxonomy
We will discuss embedding the SBR taxonomy deeper within applications later in this module.
Implementing XBRL support into your application
Once you have decided the appropriate level to embed support for SBR, there are two methods to incorporating XBRL support into your application.
The first method is to outsource the preparation of the XBRL instance document.
There are a number of online providers who are able to prepare instance documents based on information and taxonomies provided to them. There are however significant limitations to this model, and it will not be covered in this module.
The second method is to embed XBRL support (at the appropriate level for your application) directly into the software.
Further information regarding developing XBRL support into your application, including the Software Developers Toolkit can be found at www.sbr.gov.au.
This module with deal with explaining the appropriate levels at which to embed XBRL into your application.
The following table summarises where it is appropriate to use the suggested implementation methods and illustrates their ability to be leveraged for other purposes.
| Implementation level | ||||
|---|---|---|---|---|
| XBRL Global Ledger | XBRL for Internal Reporting * | XBRL for External Reporting | ||
| 1 | Government Report Level Plain coverage of pre-generated reports |
No | No | Yes |
| 2 | Built in At trial balance level |
No | Yes | Yes |
| 3 | Built in Deeply embedded in ledgers/systems |
Yes | Yes | Yes |
* XBRL for internal reporting refers to the ability to leverage XBRL for internal use, for example in preparing consolidated reports across a group of entities.
Option 1: Government Report Level
In order to embed SBR at the government report level, the software developer would map the taxonomy to the reported fields after the final report is compiled and generated. The developer would need to tag each report in isolation. There is very little interaction between the user and the XBRL functionality within the application.
The ability to lodge via SBR would simply be another function presented to the user after they had generated the report, similar to printing a report in today's applications. Users cannot change how the information is presented in the report since they are relying on the existing functionality of the application to produce the report.
Advantages to this approach
- Low cost
This approach is relatively low cost in comparison to other options to implement - Short implementation time
A software developer can implement this approach in a relatively short time frame because it leverages the existing reporting functionality with the software.
Disadvantages to this approach
- Higher maintenance when taxonomy is changed
Software developers will need to manage the process of updating reports as reporting requirements change over time. Developers will need to undertake a relatively high level of maintenance when reports are updated and the taxonomy is changed. They will need to undertake this mapping process and deploy to users continually to allow them to continue to lodge via SBR. - Limited opportunities for process improvement
One of the significant advantages of XBRL in SBR is that it provides opportunities for businesses to undertake significant process improvement and use a range of commercially available applications for data analysis. However, these opportunities are limited in the government report level approach, where the reports are solely developed for compliance purposes. - Limited to existing reports
If a software developer wants to extend their application of SBR to additional reports supported by the SBR Program, the developer will need to tag and implement the additional reports for the end user to be able to lodge directly via SBR. This provides limited ability for the user to extend its use beyond the reporting supported by the software package.
Option 2: Built in - at trial balance level
Option two, where developers build SBR taxonomy support at the trial balance level, allows the end user to map their trial balance and other summarised information directly to the taxonomy to generate their reports.
This provides the balance between implementation costs and benefits by allowing users to extend their use of SBR (and XBRL) beyond those reports already developed within the application.
Mapping an item at the trial balance level allows a particular reporting taxonomy to leverage a particular concept across multiple reports. This item would only need to be mapped once to appear in each reporting taxonomy that leverages that element. This method would also allow users to use customised and other international taxonomies to meet reporting needs beyond SBR and allow XBRL to deliver broader benefit to clients.
The SBR Taxonomy contains many reporting taxonomies covering all of the compliance lodgements in scope. With option 2, the user can select the reporting taxonomy to which they want to map. Each reporting taxonomy contains only the elements that are required for that particular lodgement. By selecting the required reporting taxonomy for mapping, the user does not need to map all data elements or consider reports that are not relevant to that entity.
Advantages to this approach
- Other reporting opportunities for leveraging the tagging
The key advantage of providing functionality to map the taxonomy at trial balance level is that users can leverage XBRL beyond SBR. There are many case studies around the world where XBRL has been applied beyond compliance reporting. For example, it has provided significant efficiencies in preparing consolidated management accounts for groups of related entities. To provide these additional opportunities, software must be able to be mapped to customised or company specific taxonomies. - Improved audit trail between the accounts and reported information
It will provide an improved audit trail between the accounts reporting information. Thus, it will be easier for users to understand how balances in SBR reports have been compiled based on their underlying chart of accounts. - Transparent access to transactions (through the reporting application)
Through the reporting application, this approach can provide access to transactions through drill-down functionalities supported by many applications today.
Disadvantages to this approach
- Higher cost than government report level approach
This approach implies a higher implementation cost to software developers than the government reporting level approach, as it requires user mapping functionality. This will require software developers to create additional interfaces. Software developers will also need to implement the capability to work with non-financial information, which may or may not be stored in the general ledger. - Possible requirement for adjustments
This approach will require the ability to allow adjustments, where information on the trial balance may need to have adjustments processed against it for reporting to government.
Other development opportunities
- Audit trail reports
There is an opportunity to develop audit trail reports to show a clear mapping of the trial balance to specific disclosure requirements. This will simplify the review and audit process for many clients. - Reconciliation reports
Many clients report to different stakeholders and agencies from the same source of data. There is also an opportunity to create reconciliation reports that show how source information is mapped for different compliance and reporting needs.
Option 3: Built in - deeply embedded in ledger systems
Embedding SBR in the general ledger system involves the ability to tag individual transactions.
XBRL Global Ledger supports this functionality, but represents significant cost to the software developer.
XBRL GL, the familiar name for XBRL International's Global Ledger Taxonomy Framework, is a series of modular taxonomies developed by XBRL International and a framework for its extension for representing the information found in a typical Enterprise resource planning (ERP) system using XML and the XBRL Specification.
More information on the XBRL Global Ledger can be found at www.xbrl.org/GLTaxonomy.
An advantage of the deeply embedded approach is that a transaction tagged at its source is more likely to be correct (e.g. not coded to the wrong account).
When implementing XBRL Global Ledger, it is important to consider how the mapping of each transaction could be automated. Relying on data entry staff to make mapping decisions may increase manual intervention in the reporting process and staff undertaking data entry may not be suitably qualified to make all required mapping decisions. This may complicate the process to the extent it cannot be automated.
Embedding XBRL at the transaction layer enables exchange of information between software applications that are all using the same interface, which in turn lowers costs, improves quality, and timeliness. Embedding at the general ledger level allows the creation of additional audit trails and easier auditing of systems. It also simplifies generation of internal reporting and analysis.
There are however disadvantages of the XBRL Global Ledger approach. Within existing applications it could be significantly more costly to implement, as it would require a change to the general architecture of the application. It also requires mapping which, although it can be automated to a large degree, may require decisions to be made at a data entry level by staff who are not always appropriately qualified to do so.
In addition to being able to map client information to a taxonomy, software developers will also need to consider the other components that are required to generate a valid instance document.
The "Overview of SBR Web Services" module contains more information on generating instance documents.
One can map data to the XBRL GL Taxonomy (optimised for capturing business transaction information). XBRL GL captures two types of information for each transaction. The XBRL data effectively maps the transaction amount to a reporting taxonomy.
Advantages to this approach
- Seamless exchange of information between software applications
The effort to integrate applications is significantly reduced where they are both leveraging deeply embedded XRBL as the need to develop customised interfaces is removed. - Automation of manual processes
This will lower costs and improve the quality and timeliness of reporting. - Provides and additional audit trail
Enhances auditing, internal reporting, analysis and process improvement opportunities for clients. - Enhanced transparency
Provides enhanced transparency, access and control of information contained across a wide range of disparate internal data stores. - Enhanced drill down capabilities
Where XBRL facilitates mapping between reports and source information, there is an improved ability to produce clear audit trails. - Enhanced testable controls
This will lower costs and improve the quality and timeliness of reporting. - Improvements in data quality and access
There is better access to more relevant information, enabling better decision making. - Enhanced process agility
Where embedded XBRL standardises interfaces and reporting, processes can change and evolve with decreased requirement to redevelop systems and reports.
Disadvantages to this approach
- More costly than other implementation options
For many developers, embedding SBR at the ledger level will require significant effort and redesign of their system to leverage all the benefits of XBRL. - Mapping must happen for each transaction rather than once at the account/report level
Mapping at the account or report level leverages the internal "mapping" of transactions already embedded in Ledger applications for reporting purposes. Tagging at a transaction level would apply a specific tag to each transaction (which may be set by default based on business rules to reduce intervention). Whilst providing more flexibility, it would require business rules to be established or intervention when capturing transactions to assign tags.
Phased implementation
Software developers could take a phased approach to implementation.
Phase one would be to leverage high-volume reports (such as payment summaries and BAS forms) and implement SBR at the government report level. In many cases, these reports already exist and are proven, and would simply require additional development to allow XBRL instance documents to be lodged directly via SBR. Software developers can leverage the Software Developers Kit to further reduce costs.
Software developers could trial SBR in a lower risk environment. They could seek client feedback on the implementation and gather further intelligence regarding client demand for additional XBRL-based functionality.
Once successfully implemented across high-volume reports, software developers could further embed XBRL, first at the trial balance level and second at the transaction level, to leverage SBR functionality across a wider range of reports and for a wider variety of purposes.