Page tree

Documentation



Code Lists

The European standard on electronic invoicing (EN16931) defines a set of essential information elements (named "business terms" or BT) that an electronic invoice must or may contain to enable cross-border interoperability. These business terms can be of different data types, such as text, date, identifier or code. Code-type business terms shall only contain values which are chosen from specific code lists that are identified in the EN.

Contents of this page:

Electronic Address Scheme code list (EAS)

Background

EN 16931 was designed to remain neutral as to the method of transmitting electronic invoices. Because of this, and because different methods and networks of transmission use different addressing schemes, the EN allows the invoice to declare both the electronic address identifier itself and the identifier scheme that it is based on. The identifier scheme is declared by using a code and the allowed code must come from a specific electronic address scheme code list.

In the course of defining the EN, the maintenance of this code list was assigned to the European Commission’s Connecting Europe Facility (CEF).

Definition

Business terms BT-34 and BT-49 allow an invoice to include information about buyers' and sellers’ electronic addresses: the address to which the invoice is being sent, and the address to which responses to the invoice should be sent.

Each invoice that uses these “electronic address” business terms must therefore contain the unique electronic address that identifies each seller/buyer. To ensure the uniqueness of these identifiers, which may be based on different identifier schemes, it is necessary to know what that scheme is. The identifiers schemes must come from a specific code list, but any identifier scheme may be added to that list.

To support this functionality, CEF issues and manages the Electronic Address Scheme code list (EAS).

How to use the EAS code list

The EAS code list is used in the European eInvoicing standard to give information about the identifier scheme on which a given electronic address is based. The eInvoicing standard provides business terms for stating the electronic address of the buyer and the seller (BT-34-1, BT-49-1). The electronic address is a string that can be used in a given messaging solution to identify the end point to where the message shall be sent (buyer) and the end point from where it is sent (seller). The electronic address can be of various types, including and not limited to party identifiers, email addresses, web service addresses (URL), file transfer (ftp) and so forth. The structure of each electronic address follows a particular scheme and the eInvoicing standard allows for identifying what that scheme is, by using an attribute.


Example 1: if an electronic address is given by using a GLN identifier that has been assigned to the party then the scheme attribute can be used to provide that information by using the relevant EAS code. The EAS code for the GLN identifier scheme is 0088. This means that the electronic address will be the GLN number with the scheme id attribute as 0088. The use of an identifier as an electronic address depends on the transmission solution that is being used.

Electronic address value: 5790000435944

Scheme identifier value: 0088 (via the EAS code list referring to a “GLN number”)


Example 2: An electronic address is SMTP email such as receiver@company.eu. The structure of a typical email address is based on a specific scheme, named SMPT, which can be identified by using the code EM. When an electronic address is given as an email with the scheme attribute as EM, it can be used with a typical email transmission system. The EAS code list is open for any identification scheme that is used for transmitting electronic invoices and users of any such scheme can ask for an entry into the list.

Electronic address value: receiver@company.eu

Scheme identifier value: EM (via the EAS code list referring to a “Electronic mail”)

The EAS code list

Current code list version: 2.0

Publication date: March 15. 2019

The code list is issued in versions. Any addition or removal of a code constitutes a new major version. A minor version only includes editorial changes to code metadata. A new version will be published every 3 months until the second deadline of the EN on April 18, 2020. Afterwards that interval will switch to every 6 months.

Register or request changes

In order to be used for electronic addresses within EN-compliant eInvoices, each different identifier scheme itself must be listed in the EAS code list.

  • To be listed in the EAS code list, the governor of that identifier scheme must first register the scheme in the ICD code list. You can contact the CEF Service Desk if you need assistance (we can send you examples of application forms and advise you on how to fill them in).
  • After registration, please inform the CEF Service Desk that you want your new ICD code to be also added to the EAS code list.

Electronic Address Schemes that are requested into the code list will only be made for confirmed existing messaging solutions and performed through a representative of the operators of those solutions (i.e. it is not required that this is the governing organisation of the scheme).

CEF Code list Advisory group

Depending on the request, CEF may consult an advisory group of experts representing associations that in turn represent the interests of different transnational groups’ stakeholders. The advisory group may contain representatives from the following organisations.

The role of the CEF Code list Advisory group is to provide CEF with input on the evaluation of RfCs. On need-to basis, CEF may issue a request for consultation by emailing the members of the group and asking them for an opinion on how to handle a RfC or on setting evaluation criteria. The advice is not binding, and the final decision remains with CEF.

Further information and assistance

Maintenance and support services for the EAS code list are available to our stakeholders through the CEF Service Desk, where the submitter can ask questions and submit new codes to be added to the new version of the list.

Information about key concepts in electronic transmission may also be found in the document EMSFEI report on Interoperability and transmission (PDF).

VATEX code list

Definition

The European standard on electronic invoicing (EN16931) defines the business term "VAT exemption reason code" (BT-121). This optional code allows sellers to state in a coded way the VAT exemption reason in order to support automation of VAT processing and reporting. This code complements the textual description of VAT exemption reasons, which is itself mandatory in the case of exemptions.

DG GROW and its advisory body from Member States, the Multi-Stakeholder Forum on eInvoicing (EMSFEI), recognised that the VATEX code list must provide for exemption reasons allowed by the VAT Directive 112/2006 as well as exemption reasons allowed in Member State legislation.

How to use the VATEX code list

The VATEX codes are of two main types: 

  • codes that identify specific articles in the European VAT Directive 2006/112
  • or codes that identify exemption reasons based on Member State legislation.

The issuer of the invoice is responsible for correctly determining whether an item can be exempted from VAT. The exemption reason must be based on the relevant legislation. The appropriate VATEX code can then be used to identify the appropriate VATEX code to identify what that reason is. The VATEX code list cannot be used by itself as basis for a tax decision.

The VATEX code list

Current code list version: 1.0

Publication date: March 15. 2019

The removal of a code constitutes a new major version. A minor version only includes editorial changes to code metadata. A new version will be published every 3 months until the second deadline of the EN on April 18, 2020. Afterwards that interval will switch to every 6 months.

Register or request changes

Changes to the VATEX code list may be requested by submitting a Request for Change (RfC) through the CEF Service Desk.

Further information and assistance

Maintenance and support services for the VATEX code list are available to our stakeholders through the CEF Service Desk, where the submitter can ask questions and submit new codes to be added to the new version of the list.

Full listing of the code lists as used in EN16931 

The European eInvoicing standard EN 16931 specifies what code list shall be used for each of the code elements in the standard. How the code lists are used differs. In some cases, the code lists are used in full and in some cases, a subset of the code list is used. It also varies whether the set of codes allowed in the eInvoicing standard is fixed by the standard or if that may change as the code lists are updated by their relevant governing authorities. When the allowed codes are not fixed, the rule is that the most recent version of the code list is allowed.

Since different governing authorities maintain their code lists on different schedules and because any change in allowed codes needs to be supported in the implementation of the standard in ERP system and in validation artefacts, CEF has taken on the responsibility to periodically review what updates have been made to the code lists and publish in one place what codes are to be allowed and supported in the eInvoicing standard from that point in time.

The following spreadsheet contains the list of the code that are allowed in the eInvoicing standard from the date of the spreadsheets publication. The spreadsheet is not intended to be a full publication of the code lists, only a listing of the allowed codes along with the name of the code for easier reference. The official publication of each code lists typically contains more details about the code lists themselves and individual codes in them and shall be used directly and in conjunction with the specification of the eInvoicing standard when deciding what code is appropriate in a given business case. Further information about the code lists can be found in Annex A to the EN 16931-1 of the eInvoicing standard.

Publication date: March 15. 2019