Joint Position Paper: requirement to receive electronic invoices in the ‘listed syntaxes’ under Directive 2014/55/EU

  • 1

Joint Position Paper: requirement to receive electronic invoices in the ‘listed syntaxes’ under Directive 2014/55/EU

  1. Introduction

The European E-invoicing Service Providers Association (EESPA) and OpenPEPPOL present this joint paper on the subject of the European Norm (EN) for the semantic data model for a core electronic invoice, and in particular the List of Syntaxes to be used. There is a current consultation within the relevant CEN Technical Committee, CEN TC 434, on the List of Syntaxes and the discussion is likely to continue for some time thereafter. This position paper makes a contribution to that debate.

EESPA and OpenPEPPOL are very concerned by the provision in the Directive 2014/55/EU (the Directive) that all public sector contracting authorities (over 300,000 in Europe have been mentioned) will need to be able to receive electronic invoices expressed in any of a list of up to four syntaxes (technical languages) to be recommended by CEN TC 434 during the preparation of the standard for a European core invoice (see Appendix A below). It is strongly recommended that members of CEN TC 434, national standards organisations, the European Commission and other stakeholders take note of the points made in this paper, which is written with the success of the standard in mind and from a hands-on practical perspective.

Both EESPA and OpenPEPPOL communities have considerable experience in the management of syntax and in particular of accurate and timely format conversion. What is not at issue is their ability to deliver these processes, as this lies at the heart of what service and solution providers and their users do today in e-invoicing. Service and solution providers will be able to manage the process on behalf of contracting authorities; but the environment will be complex and some may argue creates too many ‘moving parts’ to guarantee success. A clear challenge is the sheer scale and burden of imposing such a complex requirement on all public authorities, many of which will be embracing e-invoicing for the first time as the Directive is implemented.

In short, the choreography for all these processes is significant. The EN, with multiple syntaxes, format conversions and extensions, will be far from a single ‘operating’ solution at the invoice exchange level, and if all this jeopardises adoption of the standard, it would be a pity.

This position paper proposes two Plans, A and B, for the resolution of this problem:

Plan A. Restricted List of Syntaxes:  in the first scenario, it is recommended that CEN TC 434 seeks to recommend a restricted list of no more than two syntaxes that would be mandatory for any single contracting authority. This decision would reflect a recognition of the impracticality and complexity of managing a longer List of Syntaxes on the part of contracting authorities. Contracting authorities would face a reduced burden of cost and complexity than in managing the reception of e-invoices in up to four syntaxes. Sellers, which work in one of the non-selected syntaxes or another one entirely, would need to bear the cost of format conversion into one of the two selected syntaxes. In this way, the cost of format conversion would be shared between the buyer and seller communities. In all circumstances, it is essential that CEN TC 434 should provide the syntax bindings for all four syntaxes under consideration to support the format conversion efforts.

Plan B.  Optional use of the individual listed syntaxes: under this second plan, guidance would be provided to Member States making it clear that individual contracting entities are able to specify to invoice senders one or more of the listed syntaxes in which they are prepared to receive and process electronic invoices. This is different from Plan A in the sense that CEN TC434 could nominate a List of Syntaxes containing all four of the likely syntaxes under consideration, but contracting authorities are free to nominate one, two or more for the receipt of invoices depending on their own criteria. Sellers would need to undertake format conversion as required. This would clearly conflict with the obligation for contracting authorities to receive e-invoices in any of the Listed Syntaxes and would require a derogation, implementing regulation, or technical clarification about the obligation set out in the Directive. It should be borne in mind that in the minds of some, the wording of the Directive is already capable of interpretation and some Member States may already be likely to transpose the Directive in a way that introduces an element of optionality for contracting entities. Under this Plan B, the burden of carrying out the scenario would lie with the Commission and the EU legislative process in conjunction with the Member States, rather than with CEN TC 434.

  1. The impact of multiple syntax management

During discussions within the EESPA and OpenPEPPOL communities the following concerns about multiple syntax management are raised:

  1. Potential fragmentation: whilst creating apparent choice at the syntax level, the eco-system might become perversely fragmented as different communities develop channels, variations, extensions and syntax preferences that impede interoperability and create ‘islands’. This takes into account the characteristics of the EN as a whole, in which the syntax obligations are but one source of complexity. A more clearly defined standard would reduce the likelihood of fragmentation.
  2. Complexity and systems readiness: Contracting authorities will need to embrace the management of substantial complexity involved with multiple syntaxes, even though they will be well supported by service providers. Public sector ERP (Enterprise Resource Planning) and related systems are very variable in terms of sophistication and automation, thus potentially limiting benefits from e-invoicing adoption until these systems are updated. The challenge of updating these systems to handle automated invoice processes is enough of a challenge and the addition of too many syntaxes could prove to be a distraction from the objective of driving out the real savings from e-invoicing adoption. For service and solution providers, the format conversion effort will be significant and may divert resources from other more critical tasks to stimulate e-invoicing adoption across the economy.
  3. Need for retro-fitting: For public contacting authorities that have already embraced or are committed to embrace e-invoicing based on one or two syntaxes, there will be a substantial cost to adapt their solutions to multiple syntaxes. For example, for current users of an infrastructure such as PEPPOL, which is engaged in a major effort to win business and enhance its current functionality, this will be a major change.
  4. Cost: the obligation to support multiple syntaxes will incur a greater cost burden on contacting authorities, than would be the case with a reduced number. Solutions to support this will be procured in a competitive market and based on the plethora of such solutions, which are now available and convenient to use. The more such solutions are required the greater the cost for contracting authorities. Placing a slightly greater cost burden on sellers to the public sector is not only equitable but reflects current reality in e-invoicing.
  5. Sharing the burden: At the heart of the issue, is the question of where to place the burden of multiple syntax management, either on the side of invoice receiver, or on the side of the invoice sender. In the case of the invoice sender being able to freely choose the syntax by itself, or on its behalf by its service provider, the invoice receiver has the whole burden of format conversion and will usually need to procure and manage the interface with services and solutions to support this process. However, for invoice senders, it is often the case that they do not create the invoice in their own systems, but provide data to a cloud platform or service provider, which will create the actual structured invoice. In other words, they often have no involvement with standards management. By sharing the burden, there could be a reduction in complexity for both buyers and sellers. Given the high number of trading partners that each buyer and supplier will have, the likelihood is that most, if not all, will have to support the full range of required syntaxes.  Therefore, the cost burden will scale directly in proportion to the number of syntaxes that are required to be supported.
  6. Comparisons: In a similar digital initiative, the Single Euro Payments Area, a single syntax was chosen and implemented (ISO20022 XML). The initiative has been successfully implemented based on this single syntax. In other e-business initiatives such as PEPPOL and in many Member States a limited syntax approach has been taken, all with use of XML-based syntaxes as a common denominator. Such approaches have been proved to work very well.
  7. Future-proofing and version management: the adoption of e-invoicing on such a major scale requires solutions that are maintainable and lend themselves to development in the years to come. New requirements will emerge. These could be related to e.g. tax collection or reporting, fraud, terrorism and things unimaginable today. It must be possible to introduce these changes to the overall system as easily as possible. As already stated, we know from experience that even in the context of a single syntax system a mere version upgrade is a far from trivial exercise. In the context of multiple parallel syntaxes driving through changes will become challenging, cumbersome and error-prone.
  8. Critical mass: since use of the new standard is not mandated and contracting authorities are quite free to retain other forms of invoicing, the volumes likely to be received in all the Listed Syntaxes may be low and therefore achieve low economies of scale for the format conversion facilities, which will be required from the outset. The scale of up-front investment will be large and unlikely to be optimised. With mandates issued once the standard is accepted, things could improve, but this could be a lengthy process.
  9. Additional challenges: Whilst testing will take place, in which EESPA and OpenPEPPOL members are fully prepared to participate, these are likely to be simplified scenarios. In the real world environment all sorts of other challenges of a technology and management nature will be thrown up.
  10. Extensions: The end- to-end eco-system will have to cope with Extensions, which form a requested element in the use of the new core invoice standard. Extensions add another major dimension of complexity. The syntax bindings for Extensions is planned to be provided by the relevant sponsor of the Extension, and then registered in a central data-base. Quality issues in these syntax bindings could affect the core syntax representations. The number of invoice data maps could increase exponentially, although no quantification of likely numbers of extensions has so far been undertaken.
  11. Hybrid invoices: The eco-system will also have to deal with various forms of ‘hybrid’ invoice, where the structured invoice is embedded in a PDF or vice versa, or the two artefacts are carried in a common container. This adds further complexity to the environment.
  12. Full range of messages: The trading parties may be exchanging a range of supply chain messages beyond the invoice. It is likely that these messages will also need to be converted into multiple syntaxes adding a further dimension of complexity. Any recommendations on use of syntaxes made in TC434 should take into consideration the work done on providing support for standards based end-to-end e-procurement in CEN/TC 440 Electronic public procurement.
  13. EDIFACT: Whilst having wide support in the commercial world, EDIFACT is not supported throughout the EU public sector and will have to be embraced as a different data standard and format from scratch in addition to the XML syntaxes making up the other three listed syntaxes, the latter being of a different technical character. EESPA and OpenPEPPOL have many members who are deeply engaged with the EDIFACT standard, but nevertheless an obligation to impose this on all contracting entities requires careful reflection.
  14. Original syntax: there are often legal requirements to receive and archive the original structured message in its original form in addition to the format transformed into the buyer’s expected one. The multiple syntax requirement adds complexity to the processing and archiving process.
  15. Bilateral model: a model where the invoice sender sends an invoice directly to the system of the receiver is unlikely to work, unless the contracting authority invests in the necessary format conversion technology itself, as opposed to using a service platform. This will effectively weaken one key model for e-invoicing adoption.
  16. Why no choice on syntax when there will be for other issues: in e-invoicing it is perfectly normal market practice that buyers specify acceptable requirements for e-invoice exchanges, and the invoice receiver and invoice sender agree such requirements as part of  contractual For example, it should be noted that CEN TC434 is  planning the inclusion of a Core Usage Specification in the European Norm (EN), precisely to allow invoice receivers to publish their  expectations on the use of information elements at the detailed level.  Given this flexibility, there is a plausible reason to apply the same flexibility to syntaxes.

 

EESPA is broadly neutral on the selection of the list of syntaxes, although in providing feedback to CEN TC434 in a recent call for contributions it recommended the use of a single syntax, UBL. OpenPEPPOL has made it clear that its community would prefer to use the existing configuration with UBL as the most widely used option (99.9% of e-invoices transmitted), but also supports UN/CEFACT CII on an optional basis.

 

  1. Specific questions raised in the CEN TC 434 consultation due to close on 24 July 2016

EESPA and OpenPEPPOL have the following responses:

Question 1: Are the notions of ‘free to use’ or ‘freely usable’ relevant to the cost of processing e-invoices in the Listed Syntaxes?
Response 1: Only marginally; the real processing costs lie elsewhere.

Question 2: Should CEN TC 434 recommend a restricted list or a wider list of multiple syntaxes?
Response 2: this position paper recommends a Restricted List with a maximum of two mandatory syntaxes and others optional, or a derogation under the Directive to permit contracting entities to support ‘one or more syntaxes’.

Question 3: Is current usage a factor to be taken into consideration?
Response 3: yes, but the spread of usage is more important than mere scale.

Question 4: should ‘state of the art’ refer to ‘modern’ and the currently accepted technology direction, or ‘present usage’?
Response 4: the former. The prevalence of XML should be accepted.

Question 5: Is current use at national level an important factor?
Response 5: yes, of course. Especially within the public sector, as it is the public sector invoice receivers that will be directly affected if mandated to receive and process invoices in multiple additional syntaxes.

 

  1. Section on testing scenarios and format conversion use-cases based on multiple syntax management

As indicated above, the EESPA and OpenPEPPOL members are likely to be prepared to support whatever syntax mapping and format conversion is demanded by the market, subject to a selection process and contractual terms being agreed between a service or solution provider and a contracting entity.

These scenarios demonstrate a wide range of use cases that will need to be tested. On the assumption that all four syntaxes are listed and contacting authorities are prepared to receive all of the four listed syntaxes, the following business scenarios need to be considered in the end-to-end invoice flow:

  1. The invoice is issued by the sender in a syntax, which the receiver is happy to receive. Result: no format conversion required.
  2. The invoice is issued by the sender to the receiver in one syntax, but the receiver would like to receive one or any of the other 3 listed syntaxes. Result: a format conversion is required on the side of the receiver.
  3. The invoice is issued by sender to the receiver in one syntax, but the receiver would like to receive another syntax, not being one of those listed but one compatible with its ERP system. Result: a format conversion is required on the side of the receiver.
  4. The invoice is issued by the sender in one syntax and sent to its service provider for validation and sending to the receiver or its service provider, but the receiver would like to receive one or any of the other 3 listed syntaxes. Result a format conversion is required and undertaken either by the sender’s service provider or on the side of the receiver by its service provider or the receiver itself (if one syntax is identified by the receiver).
  5. The invoice is issued by the sender in one syntax and sent to its service provider for validation and sending to the receiver or its service provider, but the receiver would like to receive another syntax, not being one of those listed but one that is compatible with its ERP system. Result: a format conversion is required and undertaken either by the sender’s service provider or more likely on the side of the receiver, by the receiver itself or its service provider.
  6. Invoice data is provided by the sender to its service provider, which prepares the invoice and sends it in a syntax that the receiver would like to receive. Result: no format conversion required.
  7. Invoice data is provided by the sender to its service provider, which prepares the invoice and sends it in one syntax to the receiver or its service provider, but the receiver would like to receive one or any of the other 3 listed syntaxes. Result: a format conversion is required on the side of the receiver, by the receiver itself or its service provider, unless the sending service provider has been requested in advance to send a required syntax and performs the format conversion.
  8. Invoice data is provided by the sender to its service provider, which prepares the invoice and sends it in one syntax, but the receiver would like to receive another syntax, not being one of those listed but one that is compatible with its ERP system. Result: a format conversion is required and will usually be undertaken on the side of the receiver, by the receiver itself or by its service provider.

For all these scenarios the ability to also map data to and from ERP systems in all four listed syntaxes is required.

In the event that contracting authorities are permitted to limit syntaxes received to one or more syntaxes then the number of business scenarios listed above will be adjusted accordingly.

Other requirements will need to be supported and factored into the testing scenario as discussed above in section 1. e.g.: extensions, hybrid invoices, use of PDFs, and archiving requirements.

To support the above mentioned business scenarios, the following base mapping tests will be required:

SP=Service Provider.

SP1 creates a map to convert the test data compliant with syntax 1 (conforming to the defined binding)

SP2 creates a map to convert the test data compliant with syntax 2 (confirming to the defined binding)

SP3 creates a map to convert the test data compliant with syntax 3 (confirming to the defined binding)

SP4 creates a map to convert the test data compliant with syntax 4 (confirming to the defined binding)

SP5 creates a map to convert syntax 1 back into the test invoice and validates the received data

SP6 creates a map to convert syntax 2 back into the test invoice and validates the received data

SP7 creates a map to convert syntax 3 back into the test invoice and validates the received data

SP8 creates a map to convert syntax 4 back into the test invoice and validates the received data

Other test scenarios will be required.

 

EESPA and OpenPEPPOL members are happy to engage with the CEN TC 434 Work-stream on Testing and with the teams supporting the test beds and processes on the side of the Commission teams. EESPA and OpenPEPPOL would appreciate receiving an indicative timescale and work load requirement in order to plan and resource these activities.

 Conclusions and recommendations

  • It is recommended that CEN TC 434 and its affiliated National Standards Organisations give consideration to recommending a Plan A proposal in which contracting entities would only be required to support a maximum of two syntaxes on the receiving side. This should be based on a holistic impact analysis of multiple syntaxes and extensions and on consideration of the real effort required for format conversion.
  • It is recommended that in the event of CEN TC 434 recommending a wider List of Syntaxes that the Commission takes forward an initiative to implement a Plan B, under which Member States are granted a derogation to allow contracting entities to specify to invoice senders one or more of the listed syntaxes in which they are prepared to receive and process electronic invoices.
  • EESPA and OpenPEPPOL are happy to engage in the test scenario planning and test implementation and other efforts to make implementation of the new EN a success.

 

APPENDIX A: Obligations under Article 7 of Directive 2014/55/EU in relation to syntax 

Article 7 of the Directive on Receipt and Processing of electronic invoices states:

‘Member States shall ensure that contracting authorities and contracting entities receive and process electronic invoices which comply with the European standard on electronic invoicing whose reference has been published pursuant to Article 3(2)[1] and with any of the syntaxes on the list published pursuant to Article 3(2).’

There should also be a mention of the preceding item 34 in the ‘preamble’ to the Directive itself:

‘Upon the expiry of the transposition deadlines laid down in this Directive, contracting authorities and contracting entities should be obliged to receive and process electronic invoices which comply with the European standard on electronic invoicing and with any of the syntaxes on the list published by the Commission in the Official Journal of the European Union. Contracting authorities and contracting entities should therefore not refuse electronic invoices which meet the above conditions solely on the grounds of non-compliance with requirements (for example national or sector-specific requirements, or additional technical requirements of any kind) other than those specifically provided for in this Directive.

And of the preceding item 35 in the ‘preamble’:

Where the sender chooses to submit the invoice using the European standard on electronic invoicing, the recipient’s obligation to receive and process should only apply if the invoice is in one of the syntaxes included on the list of syntaxes published by the Commission in the Official Journal of the European Union. This should be without prejudice to the sender using the services of a third party to translate between its own syntax and one of those on the list.

These obligations are also repeated in the Standardization Request.

Points arising

  1. Could the current provisions be read ambiguously?
  2. Could a derogation be issued to create more flexibility and optionality in these legislative requirements?

[1] Article 3(2): Where the European standard on electronic invoicing, drawn up in accordance with the request referred to in paragraph 1, satisfies the requirements contained therein and where a test phase in accordance with the fifth subparagraph of paragraph 1 has been completed, the Commission shall publish the reference to the standard in the Official Journal of the European Union, together with the list of a limited number of syntaxes drawn up in accordance with the request referred to in paragraph 1. That publication shall be completed by 27 May 2017.

 

APPENDIX B: News Release

European E-invoicing Service Providers Association and OpenPEPPOL to cooperate in supporting the rapid adoption of e-invoicing

 


1 Comment

EESPA + OpenPEPPOL Position Paper: reduce the amount of syntaxes – E-invoicing Platform

July 11, 2016at 10:56 am

[…] the Joint Position Paper here. Download a PDF version […]