DIGITAL eInvoicing offers a test infrastructure that allows solution & service providers and public entities to check the compliance of their eInvoicing solution against the standard in a specific syntax: UBL 2.1 or UN/CEFACT CII.

DIGITAL eInvoicing provides a ready to use testing platform, and supports the users of the DIGITAL eInvoicing Conformance Testing service during the entire testing process.

For more information, check here: eInvoicing Conformance Testing

Yes, you can use the conformance testing service described on the DIGITAL Digital site on eInvoicing Conformance Testing

If you want, the DIGITAL eInvoicing support can forward you the example invoices by mail or use invoice examples from other sites:

• CEN/TC434 is using the Github service for maintenance and publication of validation rules and some other resources. On the first page you will also find links to the OASIS UBL and UN/CEFACT Cross industry invoice standards: https://github.com/CenPC434/validation Under the folders UBL/examples and CII/instances you will find sample files.
• Also the syntax binding specifications have sample xml as annexes.
• Another resource which can be used is sample files developed by the Swedish standardisation organisation Single Face To Industry. Even if some documentation is in Swedish, the sample files could still be of interest. http://sfti.se/download/18.384f86211668d140b354a504/1540376570234/Arkiv_BIS_Billing_30_Exempelsamling_2018-10-17.zip

The standard does not prescribe rules for file extensions. The most common file extension is however *.xml. There is no naming convention for filenames which can be used to identify the type of format.

The European Parliament and Council voted on the 16th of April 2014 Directive 2014/55/EU on electronic invoicing in public procurement. This Directive called for the definition of a common European standard on eInvoicing at semantic level, and additional standardisation deliverables which currently enhance interoperability at the syntax level.

Check here for more information: European legislation on eInvoicing

The European standard on eInvoicing (EN 16931) is developed and published by the European Committee for Standardization (CEN), by request from the European Commission. The copyrights of the European standard are owned by CEN and copies of the standard are sold through its member organisations.

Information on sales points to purchase a copy of the European standard can be found on the CEN website. (N.B: the link points to sales points for part 1 of the European standard but other parts can be purchased through the same sale points).

The deadline for contracting authorities and entities to comply with Directive 2014/55/EU and to receive and process electronic invoices according to the EN was 18 April 2019.

This deadline can be extended for sub-central contracting authorities and entities until 18 April 2020. Check also here for key eInvoicing dates and events: eInvoicing Regulatory timeline

There are no formal guidelines on how the information should be provided for the BT-133 code. It could be a simple identifier that the buyer can use for identifying the correct accounting dimensions, or the actual accounting dimension string itself. There is no recommendations on how such a string should be formatted.

BT-89 is the code for 'Mandate reference identifier'. It is intended for facilitating SEPA direct debit. Typically the seller indicates the mandate reference to the buyer so that the buyer is aware from where the payment is drawn. The elements specifically supports SEPA direct debit but can possibly also be used for domestic direct debit system.

There are no formal guidelines on how the information should be provided for the BT-133 code. It could be a simple identifier that the buyer can use for identifying the correct accounting dimensions, or the actual accounting dimension string itself. There is no recommendations on how such a string should be formatted.

The use of the tax exemption reason code is not mandatory so there may not be a reason to create a "catch all" code. Instead the code element can be left empty and the exemption described in the VAT exemption reasons text element. When codes are available they can be added to a later version of the code list.

Electronic invoicing is the exchange of an electronic invoice document between a supplier and a buyer. An electronic invoice (eInvoice) is an invoice that has been issued, transmitted and received in a structured data format which allows for its automatic and electronic processing, as defined in Directive 2014/55/EU.

The DIGITAL eInvoicing building block aims at promoting the uptake and accelerating the use of eInvoicing in respect of the European standard, amongst both public and private entities established in the EU, as well as in participating EEA countries.

The DIGITAL eInvoicing building block serves to support public administrations in complying with EU eInvoicing legislation, and helps service & solution providers adapt their services accordingly. The eInvoicing building block therefore foresees Business to Government (B2G). However, eInvoicing can also be used to enable Government to Government communication (G2G).

Business to Business (B2B) and Government to Citizen (G2C) or Business to Consumer (B2C) are not addressed in the context of the eInvoicing building block.

Mass adoption of electronic invoicing within the EU leads to significant economic benefits and an increase in European business competitiveness. Supported by European legislation, acceptance of eInvoices by governments makes it easier to do business with the public sector.

More information and details on benefits are available here: What are the benefits of eInvoicing

The eInvoicing building block has developed several channels for eInvoicing users to get help:

• eInvoicing user community where all eInvoicing stakeholders can discuss eInvoicing in the EU public and private sectors.
• eInvoicing Service Desk
• eInvoicing Conformance testing
• Registry of supporting artefacts

The directive explicitly says that public entities must be able to receive and process electronic invoices structured in any (to be understood as both) of the syntaxes defined by CEN/TC434. The syntaxes are OASIS Universal Business Language and UN/CEFACT Cross Industry Invoice. The directive also defines an electronic invoice as an invoice that has been issued, transmitted and received in a structured electronic format which allows for its automatic and electronic processing.

So even if this directive doesn’t forbid public entities from using PDF-invoices through email, they should as a minimum support structured electronic invoicing in line with the European Standard.

The Directive 2014/55/EU gives the possibility to the suppliers to send their invoices in one way to all public customers as long as they comply with the European Standard. There are many services available which can provide this functionality also for small public entities with low volumes of invoices.

The NetworkID is a mandatory element in UBL but the syntax mapping specification doesn’t give much guidance on how to handle a situation where a value for this element isn’t available when creating the instance. As far as we have gathered from our contacts with editors of the specification, a way forward is to add the value “Not applicable” or “NA” in lack of other information.

Here are some extracts from the EU-directive which maybe can give food for thought:

From the preamble:

The benefits of electronic invoicing are maximised when the generation, sending, transmission, reception and processing of an invoice can be fully automated. For this reason, only machine-readable invoices which can be processed automatically and digitally by the recipient should be considered to be compliant with the European standard on electronic invoicing.

From the defintions: ‘electronic invoice’ means an invoice that has been issued, transmitted and received in a structured electronic format which allows for its automatic and electronic processing; I can also give a few different examples of electronic processing of an invoice:

• The received invoice has an order reference and the receiving system automatically verifies that the invoice is correct based on an electronic order. If the invoice corresponds to the order and what has been delivered, then it automatically gets approved
• The received invoice has a reference to the person who did the purchase. The receiving system automatically forwards the invoice to that person who are to assess if the invoice is correct.
• The received invoice is presented to a person in an administrative role who manually forwards it to the person/department for where the purchase originated.

It can’t be said if printing a received invoice and to process the paper-copy can be considered to be in line with the directive but I don’t think it is the long term intention.