OZEDI has published an independent website, einvoicing.com which features a catalogue of hundreds of software packages and solutions.

This is a very incisive question. One of the advantages of the einvoicing.com marketplace we have built is that it includes the third-party tools and the products to which they are linked.

We can quote as an example the situation with the OZEDI partner promis.co. Let’s assume that you are using promis.co for e-Invoicing and MYOB for accounting and decide to switch to Xero for accounting. You would continue to use promis.co for e-Invoicing with no change. Your subscription with promis.co would continue with no financial penalty and all you have to do in promis.co is to change the software package from MYOB to Xero.

The Peppol framework includes these documents and we frequently hear this question. During the last 5 years of moving to standardised e-Invoicing Australia has looked at the experience in other countries. It seems that anywhere where the implementation was done for a full procurement system, involving all these documents at once – it was something of a failure. The change management associated with such a radical introduction was too difficult, so Australia is introducing invoices first and the others will follow in 2021. We think the demand will drive this to be implemented during the first half of 2021.

This is an absolutely valid statement and we accept that there is a huge investment in all these differing standards. By the same token everyone (with the exception of those with a vested commercial interest in these standards) knows that it is incredibly inefficient and is the reason why EDI has never become universally implemented anywhere.

I would like to draw a comparison to SuperStream, the standard used to send superannuation contributions data from employers to funds. This involves 700,000+ employers sending data to about 200,000 funds. Prior to the introduction of SuperStream in 2013 the ATO estimated that there were about 10,000 different formats and methods of sending this data. SuperStream has been fully implemented for some years and now there are only 2 basic file formats and a single network. The SuperStream network was established using the ebMS 3.0 AS4 messaging technology which Peppol has now also adopted.

SuperStream has created much better security around very high value data and also massive costs savings for both employers and funds. As an example, we have one client in Queensland who employs about 420 staff and pays 80 funds every month. That used to take 3 days of work; after SuperStream – it is done in 10 minutes.

In the same way that SuperStream evolved over a period of years, we expect that the older standards and particularly OCR scanning, will be eventually supplanted by Peppol. It is important to understand that the introduction of Peppol should not fundamentally change any existing businesses processes embedded in software applications.

OZEDI has spent years partnering with software providers, large and small, old and new. We have a set of rich APIs which work with most languages and can also provide sample code libraries for Java and C#.

While most of the software providers OZEDI partners with are producing the Peppol invoice format we can also provide a data transformation service. You will find that most Peppol Service Providers will provide similar functionality.

This is quite correct; in fact, OZEDI estimates that there are probably about 5,000 pieces of software which process invoices in one way or another. The 25+ A-NZ accredited Peppol Software Providers will engage with software providers as suits their particular market position. OZEDI’s history with SuperStream, Single Touch Payroll and e-Invoicing is that our services, pricing and APIs suit any aspect of the marketplace so we have clients using SAP and Oracle and also have a tightly coupled integration with Xero, MYOB and Intuit. We have integrations with many small software providers in the mid-range referred to.

There are a large number of third parties which have already built integrations with these large vendors. OZEDI is partnered with some of them and is developing further partnerships on almost a weekly basis.

The Peppol network revolves around a central index called the SML (Service Metadata Locator) which is an index of Peppol identifiers. An identifier can be, amongst other things, an Australian ABN, a New Zealand NZBN, a GSN from GS1 or a DUNS from Dun and Bradstreet. The sender’s software will look up the SML and if it finds an entry it will send a Peppol invoice into the network. If it does not find an entry it will probably just email the invoice as normal practice. That is one scenario.

Another may be that the sender’s software sends all the invoices to its Access Point, leaving the Access Point to sort out the delivery. Both the sender’s and receiver’s Access Points have an access to the invoice data, so could produce a PDF from the data. OZEDI does this and we know some other Access Points do as well.

There are various ways of addressing this issue and the ATO is currently preparing a White Paper to outline the details.

There are two parts to that question – one to do with receiving invoices from suppliers and the other in sending invoices to customers.

Receiving invoices.

There is a huge amount of value in existing systems and, as was mentioned during the webinar, the real value is in receiving the data and what you do with it. Most of the current EDI systems receive data from various sources – OCR Scanning, data feeds from VANs or data feeds direct from suppliers’ ERP systems. As more and more senders become enabled for Peppol, the requirement for the first two will diminish significantly which will reduce the processing costs of getting the data into the ERP or AP automation software. The Peppol model does not attempt to dictate what processes and technology are in place at the final recipient – what it will do is enhance those solutions with a data feed which is more secure, standardised and contains richer content. As far as existing business processes go our policy is the old adage – “if it’s not broke, don’t fix it”.

What OZEDI provides for e-Invoicing is a set of APIs which can be easily integrated into almost any software to allow it to communicate with the Peppol network.

There is not necessarily a simple answer to this question as there are a number of scenarios which apply:

• An ERP system which has its own AP automation routines built into it – e.g. Pronto is building this type of solution in conjunction with OZEDI as a Peppol Access Point.
• A separate fully featured AP automation system which integrates with multiple ERP systems. An example of that is FileBound which has completed integration with OZEDI and is ready to go into production.
• OZEDI is working with a generalised integration partner – Promis.co has integrated Xero, MYOB, Intuit and MS Dynamics, Reckon Accounts Desktop, etc. And this partner is in production using OZEDI as its Access Point.
• OZEDI is working with a more specialised partner – MuleSoft is an example which has very deep integration with a number of ERP systems.

Sending invoices

This is the part which does not get as much attention because the larger benefit is in receiving invoices. We believe that large enterprises can provide a huge benefit to its customers by implementing the sending of Peppol invoices.

As for example, OZEDI has an account with a retailer and has our ERP software ready to receive Peppol e-Invoices. When we buy something, we would really like a POS software to send a Peppol invoice to us, so we can import it into our accounting system with no data entry. At the moment invoices are entered manually with no line item detail, so if someone at our side wants to look at something specific we have to locate the PDF or log on to the retailer web site. But if we get a Peppol invoice all the line descriptions would be in our accounting system automatically.

Businesses already have the two key pieces of information, being the sending and receiving ABN, so changes should be minimal.

If you would like to discuss further please don’t hesitate to call OZEDI. We always glad to help and to share our API documentation for your evaluation.

There are three expected outcomes for bookkeepers. Obviously, they will become more efficient as they won’t have to enter all the data. That should mean they will have more time to check the invoice value is what it should be and that it has been correctly allocated in the accounts. A richer data set in the accounts should mean they will be able to provide better analysis and reporting to their clients.

This is a good point. It would be comparatively very expensive to set up a connection to an Access Point for one end user client unless it is a very large business with an IT department. Based on our experience – once a few clients start asking for e-Invoicing then the software developer will start looking at it. It also depends on the Peppol Service Provider and their policy.

OZEDI does not charge for integration services and has an onboarding team which provides an assistance to software developers free of charge.

There is no consistent way to digitally identify an individual as a consumer. One of the Peppol rules and the ATO security framework is “Know your customer” which means that a Peppol Service Provider must be able to confidently test the identity and validity of an entity which has signed up with them to use the network. In today’s world that is difficult with a consumer.

A Peppol Access Point can send to and receive from any other Access Point in the world. However, as part of the internationalisation of Peppol outside Europe, there are currently 3 derivatives of the base standard – European, Singaporean and A-NZ. At the moment, the interoperability depends on the sending and receiving capabilities of the end users in each country. In theory, you should be able to send an A-NZ invoice to any entity in the world but only if they are registered on the central register to receive A-NZ formats. Conversely, a business in Europe could send an EU invoice to Australia but only if the receiver was registered to receive EU invoices.

As the focus in the first instance of e-Invoicing is to have Australian and New Zealand businesses interacting with each other this is not seen to be an impediment. This will be resolved in 2021 with the introduction of the PINT – the Peppol International Invoice. This new standard has been developed by the Peppol PINT Working Group which was formed in February 2019. OZEDI has been a member of the PINT WG since inception.

Upgrading to the PINT from the current A-NZ specification will bring a minimal change for end users and software providers.

The sender and/or receiver do not have to be registered for GST but must have a registered Peppol ID which will be an ABN or an NZBN. The NZBN is NOT the same as the GST registration number in New Zealand. To send an invoice to a customer in New Zealand via the Peppol Network you will need to have on file their NZBN.

There a various way of addressing this issue and the ATO is currently preparing a White Paper to outline the details.

OZEDI sees the NPP as being a really important part of the Australian Peppol infrastructure. The ATO is also working closely with the NPPA to meld this into the framework. The NPPA has just released the details of a new set of advanced facilities to be introduced during 2021 and OZEDI is meeting the NPPA in mid-December to discuss these.

David did not answer this particularly well for a couple of reasons. The first is that most EDI providers do not provide any pricing on their web sites – you need to contact them to get a price.

Secondly, David did not want to talk about OZEDI pricing specifically because this was intended to be an information session on e-Invoicing and not a promotion for OZEDI. And having said that, we have always been transparent on pricing and it is all on our web site.

However, please note that we generally only sell to software developers’ who then on-sell our services bundled with their own and pricing for those services is out of our control.

The ATO will have no visibility of the data in a Peppol invoice except for the invoices it sends and receives as the ATO own commercial dealings. It will not be checking any data in the payload.

The answer to this question is an unequivocal – yes. It is mandatory for the sending Access Point to check the validity and structure of the data file before sending it into the network. Access Points all have to sign a service agreement with Peppol which binds them to minimum standards for security and data protection. Under those protocols and the additional security overlay required by the ATO the invoicing data is protected at various stages:

• To be accredited in Australia and New Zealand Access Points must be compliant with ISO 27001 which provides a wide range of security requirements including staff security.
• Data must be encrypted on the wire – that is in any transfer between senders, Access Points and receivers.
• Data must be encrypted at rest – that is when it is being stored at any Access Point

The ATO will have no visibility or access to any of these transactions. The ATO is responsible for the governance of the network and the A-NZ transactions in conjunction with MBIE which is the equivalent body in New Zealand. It is bound by a contract it has signed with OpenPEPPOL which quite clearly spells out the responsibilities and limitations of the Country Authorities.

With a possible 2 million entities in Australia and New Zealand as participants in the network it would be a major exercise to gather reporting from them whenever they were paid late by one of the nominated large businesses. Possibly for the government it would be easier to collect data from a few hundred businesses rather than 2 million.

Once remittance advices start flowing through the Peppol system it will be possible to gather some really valuable data, because the remittance advice will contain both the payment date and the original date(s) of the invoices being paid. That data could obviously be anonymised by each Access Point and summarised and if it was fed into a reporting system would give the country as a whole a good picture how we are travelling with payment times.

The ATO is a conservative agency. With the security industry generally is that nothing can be guaranteed 100%. What the ATO has done is put an extra layer of security on top of the Peppol security standards. And any service provider wanting to be accredited for operations in Australia and New Zealand has to comply with this extra security layer.

This is a Peppol requirement – all data has to be encrypted in transit between points on the internet and that limits the capability of unauthorised alteration of the data. The ATO in its role of the Peppol Country Authority has the capability of extending the Peppol security model and has done this by requiring Service Providers to meet additional security protocols before being accredited by ATO in Australia and MBIE in New Zealand.

It is for both sending and receiving invoices. There is a larger benefit in receiving invoices because of the reduced effort in processing a supplier invoice and because an e-Invoice can provide much richer data. The sender will also receive benefits in terms of potentially receiving faster payments and also receiving a response message form the receiving party that they have received your invoice.

We believe that it is important to view e-Invoicing as a benefit to all of your trading partners and to the economy as a whole. Every invoice is actually two discreet transactions – one for the sender and the other for the receiver. The network will not function at maximum efficiency without a large percentage of senders and receivers enabled.