<<< back
|
eInvoice; V 1.0 <<< back |
The eInvoice recommendation is based on the framework of EANCOM® 2002, the EDI standard from GS1 within the EAN.UCC system. The aim of the recommendation in hand is to offer documentation describing the exchange of invoicing data between business partners in Europe.
The basis of this elaboration is the international standard EANCOM® 2002. The message type INVOIC 010 is used to transmit relevant data. Please be aware, however, that this documentation does not replace the complete specifications in the original chapters, or other relevant instructions within the EANCOM® 2002 documentation. Instead, it deals with the description of segments, data elements and codes to be used for a specific task.
So far, eight country profiles are included in this recommendation:
For each country, an individual country profile of the relevant information content i.e. business terms has been created. The total of all of the business terms used in these individual profiles compromise the set of business terms used in the European profile. For each business term, the relevant status in each of the countries is indicated. For the European profile, no status is indicated as the status within the countries varies.
This guideline provides various options for navigation. For each participating country, an individual country profile is provided. When selecting a country profile, only the information used in this specific country is displayed. The European profile provides a summary of the Business Terms used in all countries. Generally, all information is provided in English. Additionally, German language can be selected within the European and German country profiles as well as in the introduction.
Further information regarding the use of EANCOM®/EDIFACT can be obtained from Appendix 1 (chapter 5) of Part 1 of the EANCOM®-manual.
The eInvoice message implementation guideline is divided into four sections:
Section 1, "Alphabetic list of Business Terms"
In this section the Business Terms which are used in the selected profile are listed in alphabetic order. Within this Business Term list is a harmonised definition of each Business Term and, if applicable, additional comments and/or dependency notes are provided.
Within the table, the Status of each Business Term in each country is provided. This status information is linked to the relevant segment in the Segments Layout. The following abbreviations are used for status indication:
R = Required
O = Optional
D = Depending
If a Business Term is not used in an individual country, the relevant field is empty. Status "X" is used only in the European profile in order to enable a link to the relevant segment in the European profile, as a common status cannot be defined.
By clicking on the required country flags, the Business Term list of the selected country is displayed. Within the selected country profiles, national comments and the relevant segments and data elements are additionally included.
Section 2, "Message Structure Chart"
The message structure chart is a list of all segments used, in the same sequence as they are defined in the EANCOM® message. In general, for each piece of information, a single segment is provided. Exceptions may arise when the occurrence of a segment is limited and can contain alternative information (e.g., segment BGM). By clicking on the country flags, the country profiles can be selected.
Section 3, "Branching Diagram"
The branching diagram is a hierarchical graphic depiction of all segments used, in the same sequence as they are defined in the EANCOM® message. However, every segment is shown only once. By clicking on the country flags, the country profiles can be selected.
Section 4, "Segments Layout"
The segments layout provides an illustration that has been chosen to match the Business Terms with the elements from the EANCOM® syntax.
In the right-hand column "description" the Business Term, the definition and the comments /dependency notes are provided. The Business Term is linked to the Business Term List. The "Legend" is linked to this chapter of the introduction. Further information on applying EANCOM®/EDIFACT messages, e.g. status indicators, conventions, field length etc. can be obtained from Appendix 1 (chapter 5) of Part 1 of the EANCOM®-manual.
By clicking on the country flags, the country profiles can be selected, if the relevant segment is part of the chosen country profile. Within the European profile the status of all countries is provided in the segment documentation - within a country profile, only the relevant status in the selected country is provided.
An additional column, to provide the country data element status, has been added to the layouts. An entry indicates that the country status differs from the EANCOM® status. If the country status is weaker than the EANCOM® status, the data element (or, if only one term exists, the entire segment) can be omitted.
In general, code names are represented in red; these must be understood as being restricted. If codes are given as examples, they are represented in blue (e.g., measurement units). In this case, all codes contained in the relevant code list can be used. By clicking on the codes or the data element/code list number, the codes which are used in this guideline are displayed.
Message structure
The INVOIC message is divided into three sections:
1. Heading section
Specification of parties, dates, references, payment terms etc.
2. Detail section
Specification of GTIN to identify goods and/or services, their quantity, price etc.
3. Summary section
The summary section contains total amounts of the document incl. tax specification.
More information on the use of sublines in the detail section is provided in chapter 3.8.
Within the working group, some general recommendations regarding the invoice process and the application of EANCOM® have been elaborated. These recommendations are made within the framework of EANCOM® 2002, in particular Part 1, which gives additional advice on the use of EANCOM® messages.
The recommended information flow for invoicing is based on best practice and should be applied as follows:
1 - General recommendation for invoice information flow
|
The working group recommends this case: one invoice refers to one despatch advice that refers to one order.
2 - Recommendation for partial delivery
In this case, the delivery of the complete goods is made using several means of transportation to one location - e.g. the delivery is made using more than one vehicle since the capacity of a single vehicle is not sufficient for the goods.
|
In this case, "n" invoices refer to "n" despatch advices that refer to one order.
3 - Exceptional situation for partial delivery
|
The delivery is split up on several means of transport to one location (not unloading at the same time). This case is exceptional.
Information flow for invoicing including credit note:
1 - General recommendation
|
The working group recommend this case: one invoice refers to one despatch advice that refers to one order. The credit note refers to one invoice
2 - Recommendation for partial delivery
|
There are as many invoices as despatch advices. The value "x" is less than or equal to "n". The whole delivery is split up on several means of transport to one location (not unloading at the same time). The capacity of one means of transport is not sufficient for the goods.
National comments
In the UK and Sweden to the total volume of goods supplied in a specific period "volume rebates/discounts" may apply where periodic rebates may be made, based on the total volume of goods supplied in a specific period. In this scenario, a single credit note may be used to adjust the amounts paid against a number of previously-submitted invoices.
In Sweden, the use of EDI requires an agreement where the trading parties have defined the standards and other rules that are to govern their exchange of invoices. In the preparation process information describing the parties, delivery addresses, products and prices and applicable VAT have been agreed and exchanged between the systems of the trading partners. Party information and products/price lists provide both code and equivalent descriptive text, whereas frequent transactions like call-offs/order, order response, despatch advice and invoice only contain codes. Payment agreements and conditions of delivery is also stipulated by contract in advance and is not exchanged in the frequent transactions.
The invoice type is coded and transmitted in data element 1001 of the BGM segment. In the current recommendation the following types of invoice messages (INVOIC) are allowed:
The commercial invoice is the regular invoice document/message, issued by the supplier/seller to the customer/buyer, that is used to request payment for goods or services, supplied under conditions agreed between seller and buyer.
The credit note for goods and services is used in order to provide credit information related to goods and services to the relevant party.
The debit note for goods and services is used in order to provide debit information related to goods and services to the relevant party.
The credit note related to financial adjustments is used in order to provide credit information related to financial adjustments to the relevant party, e.g., bonuses.
The debit note related to financial adjustments is used in order to provide debit information related to financial adjustments to the relevant party.
The corrected invoice is a commercial invoice that includes revised information differing from an earlier submission of the same invoice.
Self-billing is a business process where the invoicee (buyer) creates the invoice in the name of, and on behalf of, the supplier/seller. Used, for example, for goods removed from a consignment warehouse, at the buyer's location.
The self-billed credit note is a (electronic) document which indicates that the customer is claiming credit in a self-billing environment.
The proforma invoice is a (electronic) document serving as a preliminary invoice, containing - on the whole - the same information as the final invoice, but not actually claiming payment. Normally sent to the same destination (e.g. buyer or buyer´s head office) as the invoice, with the content of the delivery note (including or exclusive prices, but WITHOUT VAT amounts).
Data which do not vary between transactions such as terms of delivery, shipping, and payment agreements, prices, clear text for GLN and GTIN should be part of the underlying business contract and accessible by the respective party's business application, for use as appropriate. Each trade item must be numbered (and barcoded) with its Global Trade Item Number, GTIN. In some cases, however, additional information such as article text may be provided, if the master data is not available - e.g. where a central payment service provider is involved. In France, even if the data do not vary, each trade item must be numbered and the article text must be provided for legal reasons. The same rules apply for the description of the parties in clear text and with the GLN.
Numeric data element values, such as prices and amounts, should be regarded as positive. Although a deduction is conceptually negative, it should be represented by a positive value, (e.g. in a credit note all values are positive, the application software uses the message type (coded in DE 1001 of the BGM segment) to convert all values into negative). In addition, some data elements and code combinations will lead to implied negative values, (e.g. data element 5463 with code value 'A, Allowance' in an ALC segment in an invoice).
If a value is to be represented as negative in transmission, it should be immediately preceded by a minus sign (e.g., -112). The minus sign shall not be counted as a character when computing the maximum field length of a data element.
In many countries amounts are indicated in Euro and rounding of amounts is not necessary. If rounding of amounts applies, the rounding off of amounts follows mathematical rules.
Examples:
0.344 = 0.34
0.346 = 0.35
0.345 = 0.35
However, some business partners may wish to apply truncation, rather than rounding, to the decimal part - e.g. 0.596 = 0.59 truncated (0.60 rounded). It is recommended that only one method is used, rounding should be the preferred option as truncation is not applicable in all countries.
Payment terms can be indicated in the header section of the invoice within segment group 8 (PAT-PCD-MOA). The following types can be distinguished:
Penalties
The invoice can also mention the penalty amount which is due if the payment is made after the payment net due date/payment due period mentioned on the invoice. Penalty rates are the application results of the general conditions of sale.
The description of these penalty conditions, and their percentage or amount should be indicated, if possible, in the PAT segment group. If not, the description, the amount or the associated percentage should be transmitted in the heading section, segment FTX DE 4451 code value "PMD".
It is recommended that payment agreements and conditions of delivery is stipulated by contract in advance and not exchanged in frequent transaction like orders or invoices.
When indicating allowances and charges in the invoice these are already included in the prices and amounts, if net calculation is applied. In this case it is not necessary to state allowances and charges. If they are transmitted, it is for information purposes only, in order to follow the calculation. If gross calculation is applied, the prices and amounts do not include allowances and charges.
The type of allowances and charges is bilaterally agreed between the business partners. They can be indicated as bilaterally agreed text in segment ALC DE 1230 and/or coded in DE 7161.
Additional comments for application of charges and allowances in Sweden:
Allowances: In Swedish retail sector and public sector a common/general agreement is established on how allowances should be dealt with. Allowance shall always be included in the contract price. Only net prices(allowance included) are communicated in price lists and invoices. Regarding discounts there is only three sorts; volume discount, invoice discount and periodically volume discount.
Volume discount is expressed in a step based price list: a lowest quantity (volume) together with a maximum quantity states for which the price is valid in that step of the price list. Information about volume discount can only be fetched by a price list. The invoice discount is regarding the actual invoiced delivery and calculated from the value of the delivered goods according to agreement. Periodically volume discount is calculated periodically according to agreement and is paid out by using a credit note.
Charges: Charges, if any, is always included in the net price of the item. If transport charge is agreed in a delivery agreement it is communicated in the invoice (header level) as a net price and the VAT amount separate.
How to apply allowances and charges
The specification of multiple levels of allowance and charge information is possible in the EANCOM® commercial messages, at message and product detail levels. This is achieved through the use of the ALC segment group, which normally will contain additional segment groups in which the actual allowances or charges are specified (e.g., QTY-RNG, MOA-RNG, etc).
Where a message or individual product is subject to multiple levels of allowances or charges, (e.g., 10% on purchases between 1000 and 2000 units, 10000 EURO for handling charges, etc.), it is recommended that each individual allowance or charge is expressed in separate repeats of the ALC group, with the actual allowance or charge details specified in the sub-groups beneath the ALC segment.
In addition, it is of vital importance, where multiple levels of allowances or charges exist, that the sequence in which they are to be processed is indicated, in order to ensure the correct result of the application of the allowances and charges. This is achieved through the use of data element 1227 in the ALC segment.
For example:
| ALC+A+++1+ADS' | Allowance for ordering a full pallet is to be processed first |
| PCD+3:15' | Percentage discount of 15 |
| ALC+A+++2+TD' | Allowance for trade discount is to be processed second |
| MOA+204:4000:EUR' | Allowance amount of 4000 EURO |
Note: Allowances and charges in the heading section of a message are independent from those in the detail section, e.g. ALC at detail level does not override ALC at heading level.
In some business cases, rebate in kind is offered by the supplier. E.g. 100 bottles of skin lotion are invoiced and 10 bottles are delivered free of charge. There are, according to the business process, different ways to indicate free goods in an INVOIC message.
If the same line contains "quantity delivered, QTY+46..." and "free goods quantity, QTY+192…", then "free goods quantity" is contained in "quantity delivered". If one line "free goods quantity" and one line "quantity delivered" is transmitted by use of the same GTIN, the total quantity is calculated by addition of both QTY segments.
The use of more than one QTY segment in one line of the detail section of an INVOIC message needs to be mutually agreed by the business partners, because not all in-house systems are able to deal with more than one quantity information per line.
Identification of products is carried out through the use of the EANCOM® Price/Sales Catalogue (PRICAT) message. Wherever possible, all products or services should be uniquely identified by means of a Global Trade Item Number (GTIN) and transmitted as a line item in the LIN segment. That being said, it is also possible to identify the constituent parts of a product (e.g., hamper containing multiple different products) through the use of sub-lines. Sub-lines should be used only to identify the relationship between a number of products, not the complete product itself.
Every EANCOM® message contains a message reference and a line number which are unique to that message and enable the recall of information in subsequent EANCOM® messages e.g INVOIC and the creation of application databases. Within the EANCOM® messages the creation of complex configurations is achieved through the linking of EANCOM® main line numbers using the sub-line function within the LIN segment. Within EANCOM® it is recommended that the line numbers used in the first occurrence of data element 1082 in the LIN segment be sequential, starting at 1 for each new message.
Sublines in the invoice message are used only used in some countries, as the information on standardised multiple/mixed packages and composite services can be provided in the price list/catalogue. Sublines can also be applied in order to display different VAT rates for one product e.g. in the case of batch of products (book and CD) with different VAT rates.
If this information should, however, transmitted in the INVOIC message, the following structure is recommended in order to provide users with an appropriate way of displaying assortments as well as consumer units in an invoice:
For further details on the use of sublines please refer to the EANCOM® manual.
An invoice serves two functions:
The COUNCIL DIRECTIVE 2001/115/EC, published on December 20, 2001, has its focus on the VAT function of an invoice. Within business practice an invoice is part of business processes and, in addition to the legal requirements, business requirements are added to an invoice. Both requirements are represented in this EANCOM® guideline.
The Directive has defined a common set of legal requirements for an invoice within the European Union. It is necessary to check within the national law/implementation rules on how these requirements need to be fulfilled in each member state. According to the Directive, the following details are required for VAT purposes on invoices:
Rules for transmission of electronic invoices:
Generally the EC Directive 2001/115/EC allows two ways of transmitting electronic invoices:
However the implementation varies in the different member states within the framework of the Directive. Additionally, invoices may be sent by other electronic means subject to acceptance by the Member State(s) concerned.
As a general rule, for the transmission of invoices from one member state to another, it is the national law of the invoice issuer i.e. the supplier/seller, that applies.
The following table shows the implementation in the participating countries:
| Country | Requirements for invoices sent with electronic signature | Requirements for invoices sent via EDI | Requirements for electronic invoices sent by other means |
|---|---|---|---|
| Austria | Advanced electronic signature | EDI according to the EC directive (see above). Additionally a summary document is required on paper (send by mail, standard fax or digitally signed). | Not allowed |
| Denmark | Advanced electronic signature | If an Invoice is sent via a third party VAN, then no extra security measures are required. | If invoices are sent via means other than a third party VAN, then encryption technology is required. |
| France | Advanced electronic signature | EDI according to the EC directive (see above). Additionally a summary document and partner document is required. This summary document is not transmitted. The e-invoicing tool of the sender and also of the receiver automatically generates it. During the administration control, these two lists are compared.Using EDIINT AS2 according to the rules defined by GS1 no additional document is required. | |
| Germany | Qualified electronic signature, based on qualified certificate of a natural person, created by a secure signature-creation device. | EDI according to the EC directive (see above). Additionally a summary document (Sammelabrechnung) is required on paper (send by mail, standard fax or digitally signed). | Not allowed |
| Netherlands | Advanced electronic signature | EDI according to the EC directive (see above). Additionally a summary document is required on paper (het afstemmingsoverzicht). This document has got to have the same characteristics as the paper invoice. | Any other means, as long as this is agreed upon by the tax authority. |
| Sweden | No special requirements | No special requirements | |
| Switzerland | According to EIDI-V (swiss national law, regulates the transfer and archiving of electronic invoices) qualified electronic certificate Class 3 needed. (Link) | No specific requirement made (no specific syntax) in the EIDI-V (swiss national law, regulates the transfer and archiving of electronic invoices). (Link) | Not in scope in Switzerland |
| United Kingdom | No special requirements | No special requirements | Provided that users can demonstrate an acceptable level of control over authenticity and integrity of invoice data - whether this is by electronic signature, control over access to/security over the "end to end" communications infrastructure, or by the application of internal controls/ procedures, is a matter for business to decide. |
Additional information regarding EDI invoices in United Kingdom:
In the UK, the summary document can be (and is) transmitted as part of the invoice interchange itself - under the UN/EDIFACT standard, the UK has developed a message known as the "TAXCON" (TAX CONtrol) which, in a batched invoice interchange, normally appears AFTER the last "UNH - UNT" INVOIC message, but BEFORE the UNZ segment.
Briefly, within the TAXCON, provision is made for the (once-only) declaration of the full names, addresses and VAT registration numbers of the interchange partners, which means that, at individual invoice message level, coded representation (e.g. GLNs) can be used and VAT numbers can be omitted - this is allowed under the provisions of the EC Directive on Invoicing. The TAXCON also makes provision for a count of documents (by document type - e.g. separate document counts for invoices and credit notes, if sent in the same interchange) and summary totals of the taxable amount and VAT, by VAT Rate.
The supplier transmits the TAXCON, as part of the interchange, to his trading partner - the recipient then retotals the individual invoice messages and compares his summary totals with the summary totals, as transmitted by the supplier, to confirm that no data has been either corrupted or lost during the end to end interchange.
In each case (supplier and customer), the TAXCON message is used to generate the summary documents. In the case of the supplier, the summary documents only show the control totals as transmitted; in the case of the customer/recipient, the summary documents show both the control totals as transmitted by the supplier AND the control totals as retotalled by the recipient.
| <<< back | top ^ |
 |
© GS1 Europe 2005 |