What do Legos, APIs and e-invoicing have in common? Let’s start with APIs and Lego blocks. Great APIs are like Lego blocks. They are easy to use, and they can be combined in novel and innovative ways that extend beyond their intended purpose.
Just like Lego blocks, APIs can be modified, combined and assembled to create new structures. For example, in Figure 1, Uber Eats has an API that small restaurants can use to view dinner order data. This data can then be stored in Salesforce API for end-of-financial-year accounting.
More technically, application programming interfaces (also known as APIs) are reusable, standardised, and customisable. They have universal components that function as building blocks, with instructions that make them easy to use, as well as options to mix different blocks or APIs for different functionalities.
These instructions are based on protocols. Developers use these protocols to retrieve only the needed information instead of developing the entire application from scratch! For example, developers can get Google Maps coordinates without needing to understand how the data is aggregated from satellites and historical images.
Benefits of APIs – The 2Cs
Although APIs have many incredible benefits for businesses, these benefits can be summarised in the 2Cs: customisation and cost savings.
Just like the customisation of Lego blocks, business owners and their development teams can pick out the functionalities that best fit their business requirements. These building blocks can expedite application development for businesses by tapping into new capabilities such as APIs for analysing data, monitoring customer touch points and connecting to new suppliers.
For smaller businesses, APIs can provide cost-saving opportunities. Instead of developing all the functionalities from scratch or purchasing a software package that has numerous unnecessary fancy options, businesses can integrate the capabilities that are within their budget. A business has the option of including or excluding a Google API, for instance, which can lead to major differences in costs.
However, there is no “one size fits all” solution for developing applications to solve business problems. APIs provide a balanced trade-off between customisation and cost efficiencies. Developers have enough flexibility to choose the API functions, but they will not be able to change the API code within the API just like how we can choose the Lego block to use but not change how the Lego was made by the Lego Group.
Professor Fethi Rabhi at the University of New South Wales in the School of Computer Science and Engineering and Dr George Joukhadar, a lecturer at the School of Information Systems and Technology Management in the University of New South Wales, have collaborated to conduct interdisciplinary research on the application of API ecosystems in the e-invoicing industry.
“From the 1st of July, all Australian Government agencies are e-invoicing enabled,” Professor Rabhi said. This means businesses conducting transactions with the Australian government are encouraged to set up e-invoicing facilities.
“This can be achieved by implementing the BIS Billing 3.0 specification. This specification is underpinned by three core pillars: data format, network, and validation,” Professor Rabhi added.
Data format ensures interoperability, allowing information to be read by different systems. For example, the receiver invoice system needs to be able to read the invoice from the sender invoice system. This is achieved through standardised formats. In Australia, the adopted data format is the Universal Business Language (UBL).
Network, also known as the PEPPOL network, is a medium of exchange between the sender system and the receiver system that facilitates the transfer of invoice data. The network hosts all the digital business addresses and, in Australia, this is based on the approved ABN addresses from the Australian Taxation Office (ATO).
Validations are rules enforced by non-profit organisations or governing bodies. In Australia, the governing body is the ATO. These governing bodies certify the vendors providing access to the network. This ensures invoices are passed through the network and comply with regulatory requirements.
With the increasing requirements from the international governments to implement PEPPOL, George explains that “depending on the country’s jurisdiction, not all three pillars need to be implemented. Within the pillars themselves, there may be variations between countries.”
For example, these differences are observed in the data format. Australia uses the UBL format while other countries use the Cross Industry Invoice (CII) format. As such, the invoices in Australia will not be validated and accepted in the other networks.
Applying API ecosystem to e-invoicing
Given the differences in requirements, the Lego analogy of APIs becomes critical to providing businesses with an opportunity to build their e-invoicing systems with different blocks of functionality. This has created an e-invoicing API ecosystem of three key players: customers, API providers, and solution providers.
Customers are businesses that would like to purchase business solutions, allowing them to adopt e-invoicing according to country regulations. API providers are developers who understand the requirements of the regulations to create specific functions. Finally, solution providers are intermediary companies that connect the API providers to customers by customising packaged solutions.
Business Process Modelling
George highlights that “a key outcome of our research is examining how a potential e-invoicing API ecosystem can be accelerated by the use of business process modelling (BPM).”
BPMs are technologies and principles that help businesses understand their processes. This way, multiple APIs that provide different needed microservices can be connected to one another to drive innovation.
For instance (figure 3), when a small restaurant extracts dinner order data from Uber Eats’ API, the information is sent to Salesforce’s CRM API to manage the priorities of the dinner orders and the financial records. When inventory depletes to a certain level, the BPM will trigger the Woolworths supermarket supply chain API to request additional ingredients. Once the order is complete, the status is sent back to the Uber Eats API.
BPM also provides a visual layout of the key functionalities, and businesses can use this information to understand what functionalities require the integration of APIs. An additional benefit of BPM is the potential for automation. Once the set-up of the BPM processes is complete, the APIs can automate the checking, sending, and receiving of e-invoices.
The study by Fethi and George provides an opportunity to delve deeper into an e-invoice API ecosystem. For Australians, this research is a timely piece since it uses API ecosystems to address complex requirements such as the adoption of the PEPPOL network. For the developer community, the article raises the question of whether the API ecosystem can be applied in other industries.
Just like Lego’s ultimate purpose is to “inspire and develop the builders of tomorrow,” the API ecosystem is here to build out tomorrow’s future.