Invoice message
A detailed usage description of the Invoice message
Preface
Within Smart Connected Supplier Network (SCSN) we chose not to specify a domain specific invoice, but to use the European Norm for e-invoicing (EN16931:2017). This European Norm aims to provide one uniform invoice format in Europe. The European Commission has made the use of the European Norm mandatory for all governments and it is expected that the business community (B2B) will follow. Anticipating this, SCSN decided to adopt this European Norm for exchanging invoices.
The norm includes the possibility to draw up additional specifications for countries. These specifications are restrictions on the invoice as specified in the norm. This means that one is also compliant with the norm when using the country specific additional specification. For the Netherlands the ‘gebruiksinstructie voor de basisfactuur conform EN 16931-1’, also known as the NLCIUS, has been developed. This specification clarifies the use of the elements and data for invoices in the Netherlands in order to comply with country-specific legislation. As the organizations participating in SCSN also do international business, we decided not to adopt this specification for the Dutch market, but the European Norm.
In the online SCSN environment we refer to the specification of the invoice according to the European Norm. This instruction manual has been drawn up to support implementations of the European Norm within the SCSN context. It explains:
How to comply with Dutch laws and regulations using the NLCIUS
How to specify different invoice types
How to include payment terms
How to include a revision ID
Comply with Dutch laws and regulations
The NLCIUS specifies how the European Norm can be used to be suitable for the Dutch market. An invoice that complies with the NLCIUS also complies with the norm. The NLCIUS limits the specification of the invoice by making certain optional elements mandatory, by banning optional elements, by discouraging the use of elements, and by restricting the number of repetitions. The NLCIUS also clarifies the European Norm with additional explanations, restricts code lists/business rules and adds non-conflicting business rules. For example, in the Netherlands additional requirements exist from the tax authorities that do not apply in other countries. For SCSN, make sure you can receive, process and send invoices according to the European Norm. In addition, you can use the NLCIUS for invoicing within the Netherlands. To discover the differences between the NLCIUS and the European Norm at a detailed level, the documentation of the NLCIUS can be consulted via https://www.stpe.nl/.
Usage of ‘Invoice type code’
The element Invoice type code specifies the type of invoice. The European Norm distinguishes between:
An initial, regular invoice – code 380
A correction to a previous invoice – code 384
When an invoice is sent for the first time, the 380 code will always be used. If this first invoice needs to be corrected, then the 384 code will be used to send a corrective invoice. There are two scenarios for sending a correction invoice:
The correction invoice (code 384) is used to completely credit the previous invoice and a new invoice (code 380) is sent with the correct information. In this scenario the correction invoice is negative and the new invoice is positive.
The correction invoice (code 384) is directly used to specify the correction on the previous invoice, indicating the difference between both invoices. In this scenario the correction invoice can either be positive or negative.
In both occasions the correction invoice must include a reference to the previous invoice.
Besides the two types of Invoices, also a credit note exists, code 381. In the Credit Note, the invoice totals are positive if the customer receives a refund and negative if the customer has to pay. We recommend to use the regular invoice message (code 380) for both debit and credit invoices and we strongly advise against implementing the credit note.
In the Dutch market and existing standards usually the regular invoice message is applied. This avoids common problems in interpretation of the (positive/negative) sign of quantities and amounts. This means that invoicing, crediting, return and/or correction takes place via one and the same invoice format. Invoices from abroad could be a Credit Note and therefore receiving systems must be able to handle them. In these cases not the regular invoice scheme is used, but the credit note scheme, with code 381 as its invoice type code.
The NLCIUS documentation contains a comprehensive scenario description including examples of the use of the invoice type code. It can be found on https://www.stpe.nl/.
Payment Terms
There is a difference between the invoice and the order messages regarding the element Payment Terms. In the invoice it is only possible to provide a textual description of the payment terms in multiple lines, whereas the order provides the possibility to further specify the payment terms within several sub elements, such as Discount percentage, Discount amount and Settlement period. In the invoice this is not yet possible. An extension for the European Norm has been proposed to include these details, but this extension has not yet been developed. We advise to wait and then add and use it when the extension becomes available.
The use of ID and revision ID
In the European Norm an extra revision number cannot be specified, it only specifies an item number (ID) for an Item. This applies to both parties who can specify an item number, the seller and the buyer. The addition of a revision number is possible in the other SCSN standards, but cannot be included in the invoice because it is against the European Norm.
In order to make it possible for parties to include a revision number of an item in the invoice, we propose to adhere to what is specified in the order (called 'Scheme A'):
A single identifier is used to uniquely identify an item. This identifier can include a revisions number. For example: 'AN0000123456A1'. The part 'AN0000123456' identifies the product and 'A1' identifies the product revision. Both parts together identify the item as a whole. Another example is '12345', where no revision number is applicable at all.”
In this case, the item number and the revision number are included in the ID element by merging them without separator. The other option specified the order (called 'Scheme B') cannot be applied to the invoice. As a result, there is a small difference between the Item element in the order and the invoice.
Last updated