Black IPS header

A-NZ PEPPOL INDUSTRY PRACTICE STATEMENT

Guidance and Recommendations for Access Point Migration and Exit

Version: 1.0

Publication Date: 9 December 2022

📄 Copy available for download here

Contact the local Peppol Authority for questions or feedback:

PURPOSE

This document has been developed by the Access Point Migration and Exit focus group (the group) which was formed as part of the A-NZ Peppol All Stakeholders Working Group (ASWG). It aims to support a smooth and positive experience for end users switching Peppol providers.

The document provides guidelines and recommendations for A-NZ Peppol Service Providers, including Access points (AP), Service Metadata Publishers (SMPs), and Business Management Software (BMS), e.g. accounting software, ERP or FMIS solution providers.

This document also summarises key questions raised and discussed at the ASWG and the focus group, aiming to promote visibility and support end users to make informed decisions.

NOTE: This is a living document that may be updated as the A-NZ and/or global Peppol market matures, as new challenges arise, or as Peppol standards evolve.

CONTEXT

At the ASWG meeting in November 2021, it was agreed that better processes and guidance is required to support smooth transitions and minimise interruption to business operations.

The following scenarios have been identified where end users need to switch to a different Peppol Service Provider, e.g.:

  1. An end user makes a decision to switch Peppol providers.
  2. A BMS solution makes a commercial decision to change a partner Peppol provider (and as a result end users of the BMS will be using a different Peppol provider).
  3. A Peppol provider makes a commercial decision to exit the market.
  4. A Peppol provider is forced to pause or cease operation due to non-compliance.

The group discussed various scenarios, which can be found here.

1. Terminology

Common terms used by the group and in this document are included below.

Term Description
Service Provider This is used as an encompassing term for Peppol Service providers who support the functions of both Access Points (APs) providers and Service Metadata Publishers (now referred as Address Capability Look-up, ACL providers) as many A-NZ APs provide their own SMP services.
This term can also refer to the party with whom the end user has the service contract with, i.e. BMS or Peppol Service Provider. This acknowledges that some Small and Medium Enterprises may only have a contract with their BMS, and may not be aware of who provides AP and SMP services.
Address Capability Look-up (ACL) providers This is the new term used in Peppol to refer to the SMP providers.
To avoid confusion, this document continues to use the term SMP and SMP providers.
Existing Service Provider The Service Provider with whom the end user currently has a contract with i.e. BMS or Peppol Service Provider.
Gaining Service Provider The Service Provider who the end user identifies as their new Service Provider i.e. BMS or Peppol Service Provider.
Access Point (AP) Peppol Service Providers that provide document or message transport and translation services in the Peppol network, commonly referred to as corner 2 and corner 3.
In Australia, many Access Points also provide SMP services.
Business Management Software (BMS) This term is used within the document to describe an end user’s software/system (such as accounting software, ERP and FMIS) through which an end user business may access Peppol eInvoicing and eProcurement services.
The BMS system:
> may have close integration with a single Peppol Access Point, or may provide interfaces that can be used by several different Peppol Access Points
> may be implemented ‘on premise’ for end users, or may be a cloud solution
Peppol Look-up services The two key components of Peppol’s Look-up services are SML and SMP:
SML is the single central addressing registration and look up facility provided by OpenPeppol.
It identifies which SMP to use for discovering the delivery details of an end user. An end user can only have a single entry in the SML, i.e. can only direct to a single SMP to record their receiving capabilities per document type.
SMPs (now referred as Address Capability Look-up, ACL) publish and maintain the receiving capabilities of end users (e.g. digital delivery addresses, business processes and document types supported), which is similar to an address book or business registry.
An SMP provider is responsible for ensuring end users are discoverable by publishing them in the SML.
Although an SMP may be affiliated with a single Access Point, they can record different Access Points for an end user’s various receiving capabilities.
More information for SMPs and SML can be found here.
Deregistration In the context of AP migration, the term ‘deregistration’ means the process of removing the listing of an end user from SML, i.e. the end user ceases to be ‘discoverable’.
Switch / Migration The process by which an end user’s receiving capabilities are transferred from one Peppol Service Provider to another. In the A-NZ market, if an end user changes BMS providers, it is likely that they will need to migrate between Peppol Service Providers.

PRINCIPLES

The focus group developed the following principles for Service Providers, including both Peppol Service Providers and BMS providers.

Note: The group agreed that questions related to data storage and retention (e.g., process/timeframe for Service Provider to delete business data) is specific to commercial agreements and therefore is not in scope for the focus group. End users should ensure they discuss this topic with their Service Provider.

1. All end users must have the ability to deregister from Peppol

The option to initiate deregistration must be enabled by the party with whom the end user has the service contract with.

This can be enabled by including the deregistration process and/or supporting information in the contract, or the option is made available via the product’s user interface (UI).

The end user can request to deregister from their:

  • BMS, or
  • Existing Peppol Service Provider

It is acknowledged that Small and Medium Enterprises (SMEs) may not know who their Peppol Service Provider is.

2. The existing Service Provider must verify that a deregistration request is valid

Before proceeding with the deregistration process, the existing Service Provider must ensure that the end user is authenticated and authorised to make this request. The existing Service Provider should complete adequate checks to be confident that the request is valid.

This aligns with the Peppol Authority Specific Requirements (PASR) for Australia and New Zealand. Refer to the A-NZ Peppol Guidance Note 10 - End-user identification guidelines for detailed guidance.

3. The gaining Service Provider cannot force the existing Service Provider to release a Peppol ID

The end user should initiate this process by requesting to deregister from the Service Provider with whom they have an active service contract with, i.e. their existing BMS or Peppol SP.

If the end user makes this request and their existing Service Provider is unresponsive or refuses to take action, they can seek assistance from the gaining Service Provider. See principle 9 for more information.

4. The existing Service Provider should, in simple business terms, highlight the Peppol features and/or functions the end user will lose by leaving the current SP

The focus group agreed that it is best practice that existing Service Providers provide enough information to support the end users to make informed decisions when considering leaving the current provider.

The existing Service Provider can determine how they convey this information to their end users. The focus group recommends messaging includes the following points:

  • Which document type(s) will no longer be supported,

  • Which capabilities will be lost per document type: i.e., send, receive, or both,

  • A timeframe for the end user to consider and confirm whether they would like to proceed with deregistration,

  • If the end user confirms deregistration, information is provided on how and when it will occur.

This principle caters for circumstances where the end user may accidentally initiate the deregistration process without fully understanding the consequences of what they have requested.

5. The technical deregistration process should be completed in near real time after the request is confirmed

Once the existing SP validates the deregisteration request (by the end user), the technical deregistration process can commence either automatically or manually.

The Peppol Service Metadata Locator (SML) specification outlines a migration pattern for the technical switch of business metadata from one SMP to another SMP (Section 2.2 Flows Relating to Service Metadata Publishers) with nil / little disruption to document exchange. However, the group acknowledged that this capability is currently not widely used/available.

In most cases, the technical deregistration (for a single or small number of end users) should be completed as close to real time as possible. In practice, deregistration may involve a few hours’ service outage as there may be some timing considerations such as:

  • communications between different system components (e.g. BMS to Peppol Service Provider), or

  • systems that have built-in schedules e.g. updating user status every 24 hours.

The deregistration process and Service Level Agreements (SLAs) should be clearly documented in service contracts with end users.

6. Bulk deregistration will be handled on a case-by-case basis

Bulk deregistration may happen when a BMS changes their partnering Peppol Service Provider, or when a Peppol Service Provider ceases operation.

The group agreed that bulk deregistrations are more commonly managed as projects, where scale and complexities will vary. Therefore the process and timeframe for bulk deregistration should be managed on a case-by-case basis, i.e., as negotiated between the BMS and Peppol Service Provider.

7. When a Service Provider ceases operation, they must inform all their end users

Service Providers must inform all end users about their intent to exit the market as early as practical, so that end users can ensure continuity of business processes and have an opportunity to arrange new Service Providers.

This aligns to Section 22.6 of the Peppol Servcie Provider Agreement:

\[Section 22.6]. The Parties are obliged to inform third parties that are affected by the termination of the Agreement for whatever reason or cause, by the giving of written notice. If notice is given upon termination of the Agreement, the Parties undertake to negotiate on the procedures that pertain to the ending of the cooperation according to the Agreement in order to avoid any unnecessary disturbances in the customer relationships of the Parties

8. End users that no longer have access to services must immediately, or as soon as practical, be deregistered from the SML and/or SMP by the existing Service Provider

An end user may lose access to services from a Service Provider, e.g. termination or suspension of the licence or contract due to nil/late payments .

In this case, the Service Provider should deregister the end user as soon as possible to ensure accuracy of the SML/SMP data, and to allow them to register with a new Service Provider if they desire.

Where an end user’s relationship with a Peppol Service Provider is established via their BMS, the Peppol Service Provider is responsible for ensuring that the BMS communicates, in a timely manner, when an end user leaves, or their access has been removed.

This aligns with the following sections of the Peppol Service Provider Agreement, which stipulates that end user capabilities must be accurate and kept up to date in the SML:

  • [Section 9.5.1] Submit correct and updated metadata regarding its technical capabilities and the services provided to End Users to the relevant provider of Peppol Addressing and Capability look-up services.

  • [Section 9.6] Peppol Service Providers offering Peppol Addressing and Capability look-up oriented Peppol Services shall use all reasonable endeavours to ensure that the metadata provided by its services are correct and updated and gives a correct description of the services accessible.

The above clauses imply that where services are no longer being provided to the end user, this must be accurately reflected in the Peppol Addressing and Capability look-up services. In this scenario the existing Peppol provider is obliged to remove the user’s Peppol ID from the SML, or if the AP uses a third party SMP, the end user’s entry should be removed from the SMP.

9. If a Service Provider is refusing to take action or unresponsive, the end user can contact their gaining Service Provider for assistance

The end user can approach their new Service Provider for help. This may occur when an existing Service Provider is unresponsive or refusing to take action when requested to deregister an end user.

The gaining Service Provider should attempt to contact the existing Service Provider to resolve the issue in the first instance.

Failing a resolution, the gaining Service Provider can escalate the matter to the Peppol Authority who should act as a neutral party and provide fair, impartial assistance. The matter may be escalated to OpenPeppol.

This principle is supported by the Peppol Service Provider Agreement, under Roles and Responsibilities (Section 9).

[Section 9.4.6] Engaging with other Peppol Service Providers to resolve issues related to transfer of Peppol Dataset Types between them.

[Section 9.4.7] Escalating support issues that the Peppol Service Provider cannot resolve to the Peppol Authority.

CONSIDERATIONS FOR END USERS

This section summarises key points and questions that the focus group has discussed, most of which are incorporated in the principles above.

This section aims to support end users to be informed on the processes and considerations with switching Peppol Service Providers.

End users who are choosing a Peppol Service Provider may have considerations such as the following:

  1. Is there a clear process for switching BMS and/or Peppol Service Providers?

  2. Should you consider setting a service level agreement or timeframe for deregistration requests?

  3. If the service contract ends or the Service Provider ceases to operate, (and the access to Peppol services is also lost), ensure your Peppol ID will be released in a timely manner. (Refer to principles 6, 8 and 9).

End users who have implemented Peppol but may switch providers in the future, consider the following to assist the decision making process:

  1. Ensure you understand what and how your existing Peppol capabilities will be affected by switching.

  2. Are you switching the send or receive functionality only, or both?

  3. Are you switching to another Service Provider for all Peppol transactions/document types (e.g. Order, Invoice, Invoice Response), or selected document types only?

    Note: An end user can use different Peppol Service Providers for sending and receiving. The end user can also use different Service Providers to receive different document types.

  4. Ensure a timeframe is agreed between the existing Service Provider and the gaining Service Provider, so the migration is smooth and business interruption is minimised, for example:

    • The existing Service Provider should inform the gaining Service Provider (and/or end user) once the Peppol ID is released and ready to be registered.

    • The new Service Provider should register the end user as soon as practical to minimise disruption to document exchange and other business impacts.

    • The end user may consider communication with relevant trading partners if expecting service outages.

Version history

Version Date Change
Initial draft 21 September 2022 Initial draft based on working group discussion
Final draft 17 October 2022 Draft version ready for ASWG to review.
Incorporated feedback from the focus working group.
1.0 9 December 2022 Document updated for publishing.
This site uses Just the Docs, a documentation theme for Jekyll.