10. Appendix

10.1 Design principles for eInvoicing

This document describes the Council endorsed design principles that informed the development of this eInvoicing Interoperability framework (eIFW).

Principle 1: Extensibility Select standards that will not inhibit the future extension of the eIFW to other elements of the procure-to-pay process.
Rationale • The goal of implementing the eIFW is to help bridge ‘islands of trade’ in order to reduce the cost of doing business.
• Savings to the economy will accrue due to increased automation and the reduction of error prone paper based processing of invoices.
• The success of the interoperability framework is measured by the rates of straight through processing and conformance with the standards, as well as the value of savings and improved experience of Australian businesses, particularly the SME market.
Implications • The design of the interoperability framework would need to be balanced between focussing on immediate implementation of process automation in the accounts payable stages and strategically strategic alignment to the end to end procure to pay process lifecycle, post the procurement award stages.
• The standards should be designed to facilitate automation of common processes between buyers and sellers.
Principle 2: Nonproprietary Choose standards that are open, royalty free and vendor agnostic.
Rationale • The standards should be able to be freely adopted, implemented and extended.
• Avoid lock in to a particular proprietary solution and thereby minimise the cost of adoption for parties involved.
• Avoid exclusion of a particular market segment.
Implications • In deciding the use of open standards, existing levels of take-up across all domains and availability of implementations of these standards will be considered to prevent use of poorly supported open standards.
• The framework will need to be attractive to the business community and all of government will adopt the interoperability framework.
Principle 3: Existing standards alignment Align with relevant and established international standards. Adopt Australian standards and practices only where international standards are not applicable. Do not modify any standard, international or Australian, other than as a last resort.
Rationale • There are various parts to a likely framework that have been successfully proven locally and internationally. Reuse of these proven standards will improve the likelihood of adoption and reduce risk.
• There are most likely proven integration approaches between pre-existing standards.
• Irrespective of whether the initial scope includes payments or not some businesses may choose to implement the full procure-to-pay lifecycle which includes payments. Alignment with the new payments platform (NPP) will reduce the burden on the software industry.
Implications • Leveraging the standards that other countries have started to adopt for eProcurement or eInvoicing will mean that amount of effort that went into assessing suitability would also be leveraged – applicability to the Australian context will need to be assessed against the context of global trading environments not being too dissimilar.
• Many software vendors and businesses have already implemented a range of international and local standards and hence there may be some changes to some of the market but not all of the market – there would be reduced effort, risks and costs.
• Interoperability between the selected standards and those currently in use by Australian businesses will need to be considered.
• Standards which are not well established in the user community may be chosen if an alternative approach provides greater value and better ongoing sustainability.
Principle 4: Platform independence Enable businesses to business(B2B) connectivity irrespective of platform or solution to exchange electronic business transactions.
Rationale • Interconnection with disparate electronic systems will bridge the ‘islands of trade’.
• Business should not need to replace existing solutions, but merely create connections with trading partners.
Implications • Many software vendors and businesses have already implemented a range of international and local standards and hence there will be some changes to some of the market but not all of the market – there would be reduced effort, risks and costs. An understanding of commonly accepted standards will be required.
• Interoperability between the selected standards and those currently in use by Australian businesses will need to be considered.
Principle 5: Unobtrusive The chosen standards should not impose a particular design of internal solutions for stakeholders.
Rationale • The standards should not lock stakeholders into a particular proprietary solution and hence should minimise the cost of adoption for parties involved.
• The use of standards and best practices should maximise the ability to leverage off the-shelf solutions for businesses, software developers and Government.
Implications • The standards and any solution aspects will need to facilitate open integration and should not dictate internal implementation methods to stakeholders.
• The ‘how’ or implementation of the standards should be in the hands of the stakeholders, including software developers.
Principle 6: Semantic model The semantic model of the eIFW will inform future revisions of the SBR dictionary, exploiting the ability to share the model and gain efficiencies of standardised data models.
Rationale • Consistent reuse of standardised definitions and meanings provide greater opportunities to optimise business processes and ability to integrate information with further cost reduction.
• The use of standards and best practices will maximise the ability to leverage off the-shelf solutions for businesses, software developers and Government.
Implications • The semantic model will need to be defined/elaborated in a consultative manner – preferably reusing an existing global standard.
• The data definitions will be incorporated into the SBR definitional taxonomy.
• The definitions will require ongoing maintenance.
Principle 7: Return on investment Design the eIFW in a way that optimises costs and benefits to software developers and solution providers.
Rationale • Within the scope of achieving the eInvoicing objectives, the eIFW should keep to the minimum the cost of changes to Software Developers’ products and transition costs to industry and employers.
• Align with natural business terms and common processes where possible.
Implications • Solutions should be commercially viable to ensure the long-term sustainability of the standard and supporting platforms & products.
• Software developers should not be required to implement changes to their software unless there is a clear statement articulating the need for those changes.
• Transition costs for industry should not be created unnecessarily.
• Cost should be reduced where milestones are published to provide certainty and stakeholders are involved in the communication, collaboration and co-design process.