CEN/TR 16931-6:2017

European foreword
0 Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Testing
5 Generating invoice instances
6 Validation of invoice instances
7 Transmission
8 Presentation and visualization of instances
9 Payment
10 Automatic processing
11 Conclusions
Annex A (informative) - WG6 Comment resolution on Semantic model
Annex B (informative) - List of visualization systems
Annex C (informative) - What is GITB?
Bibliography

0.1IntroductionDirective 2014/55/EU states the following: "The standard shall be tested as to its practical application for an end user. The Commission shall retain overall responsibility for the testing and shall ensure that, during the performance of the test, special account be taken of the respect for the criteria of practicality, user-friendliness and possible implementation costs in accordance with the second subparagraph of paragraph 1. 0.2In scopeThis CEN Technical Report describes the methodology used for testing at a semantic level and at the syntax level, as well as describing the semantic testing, the syntax testing and testing of the validation artefacts that represent EN 16931-1 and the test results. The testing of the validation artefacts will ensure they can be used to automatically check conformance with EN 16931-1.0.3Out of scopeDuring meetings with the European Commission they agreed to supplement the testing activities as the need arises. This included the provision of a hosted GITB (Global eBusiness Interoperability Test Beds) environment for syntax testing and to run separate studies such as assessment of implementation costs. The results of these studies will be published separately by CEF.It was agreed at earlier meetings that piloting was out of scope i.e. perform live transactions, because resources were unavailable to undertake this in the time allowed. Instead we could simulate scenarios by leveraging on the experience of our experts.Working Group 3 (hereafter WG3) in CEN/TC 434 has produced the syntax bindings and validation artefacts, and the task of quality assurance of these deliverables has been the responsibility of WG3.VAT issues are complex and require juridical or legal expertise. VAT is also sometimes very sectoral or even country specific. Certain sections, in the VAT Directive, apply to all trades, others deal with special cases. The model should facilitate, but cannot be seen as an enforcement model. Therefore, VAT compliance would have to be checked on a case by case basis, and is deemed out of scope. The Commission had taken this up and given the draft to their VAT experts. The result was that no issues were discovered.Article 226(B) of the VAT Directive [2] describes the simplified invoice. There are significantly fewer requirements for this invoice. It can only be used when the value is below a specific total amount. The requirement is to provide a model for low value purchases such as train tickets, receipts etc. The key difference is that it doesn’t require the Buyer to be identified. Due to limited resources the simplified invoice requirements were not checked and so are being considered as an extension to be developed at a future stage.The changing between form and format was discussed. It was generally agreed, based on the VAT Directive, that an eInvoice cannot change form i.e. transformed to paper, however it can change format i.e. syntax. This is common in EDI systems and for legal reasons the original needs to be clarified. This means if it is in paper form it shall be archived in paper form and if it is electronic it shall stay in electronic form. An electronic invoice may change format, provided this is documented in an audit trail. However, in Norway and France the legislation states that the format received from the Supplier is the original and no other. Also, general practice in Germany requires that the invoice received from the Supplier be archived and considered as the original. There may be other exceptions in some Member States. This was also considered to be out of scope for this document and would be dealt with by the Member State involved.It was agreed at an initial Plenary session that we should test all four syntaxes as the decision to select syntaxes had not yet been made. However ultimately the group concluded, based on our research, that the ISO 20022 Financial Invoice was not in sufficient use to justify being included.