EHF Implementation guide Invoice and Credit note - Nets

EHF Implementation guideInvoice and Credit noteVersion: 2.0Date: July 5, 2013

EHF Implementation guideVersion:Invoice and Credit note 2.0TABLE OF CONTENTS1 INTRODUCTION .......................................................................................................... 41.1 BACKGROUND AND OBJECTIVE ......................................................................................................................... 41.2 TARGET AUDIENCE ........................................................................................................................................ 41.3 DOCUMENT STRUCTURE ................................................................................................................................ 51.4 MANDATORY USE ......................................................................................................................................... 52 DOCUMENT HISTORY .................................................................................................. 62.1 CONSEQUENCES OF IMPLEMENTING THIS VERSION ............................................................................................... 92.1.1 Registration in ELMA ....................................................................................................................... 92.1.2 Issuers supporting both version 1.6 and version 2.0 ....................................................................... 92.1.3 Receivers supporting both version 1.6 and version 2.0 ................................................................... 93 EHF – ELEKTRONISK HANDELSFORMAT (ELECTRONIC COMMERCE FORMAT) ..............103.1 ABOUT EHF .............................................................................................................................................. 103.2 INFORMATION CONSISTENCY ........................................................................................................................ 103.3 MESSAGE TRANSPORT ................................................................................................................................. 103.4 PROFILES AND MESSAGES ............................................................................................................................. 113.5 USE OF COLLABORATION AGREEMENTS ........................................................................................................... 123.6 VERSIONING .............................................................................................................................................. 123.6.1 Main version .................................................................................................................................. 123.6.2 Sub version .................................................................................................................................... 123.6.3 Revision ......................................................................................................................................... 134 DEFINITIONS ..............................................................................................................145 PRINCIPLES AND PREREQUISITES ...............................................................................155.1 INVOICE MESSAGES IN GENERAL .................................................................................................................... 155.2 FUNCTIONALITY AND ROLES .......................................................................................................................... 155.3 PROFILES AND MESSAGES ............................................................................................................................. 155.3.1 ProfileID ......................................................................................................................................... 155.4 USE OF UBL 2.1 ........................................................................................................................................ 165.5 THE INVOICING PROCESS .............................................................................................................................. 165.5.1 exception handling, validation by the issuer ................................................................................. 175.5.2 exception handling, validation by the receiver .............................................................................. 185.6 USE OF NEGATIVE INVOICE ........................................................................................................................... 185.7 FINANCIAL ADVANCE VS ON ACCOUNT INVOICING.............................................................................................. 186 DESCRIPTION OF SELECTED PARTS OF EHF INVOICE MESSAGES ..................................196.1 ROLES AND ACTOR ...................................................................................................................................... 196.2 ALLOWANCES AND CHARGES, GENERAL RULES .................................................................................................. 216.2.1 Invoice ........................................................................................................................................... 216.2.2 Credit note ..................................................................................................................................... 246.3 ROUNDING ................................................................................................................................................ 246.3.1 Elements that must be rounded .................................................................................................... 246.3.2 Rounding of the payable amount .................................................................................................. 256.3.3 Examples of rounding .................................................................................................................... 256.4 USE OF SUPPLIER AND CUSTOMER CONTACTS.................................................................................................... 29Invoice and Credit note July 5, 2013 Page 2 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06.5 VALUE ADDED TAX (NORWEGIAN MVA) ........................................................................................................... 296.5.1 Currency other than NOK .............................................................................................................. 306.6 SPECIAL TAXES/CHARGES ............................................................................................................................. 306.7 ORDER / ORDER NUMBER / ORDER REFERENCE ................................................................................................. 306.8 CONTRACT NUMBER .................................................................................................................................... 316.9 ACCOUNTING INFORMATION ........................................................................................................................ 316.10 ATTACHMENTS ........................................................................................................................................... 326.10.1 Copy of the invoice/creditnote as an attachment ......................................................................... 336.11 OTHER USE OF ADDITIONAL DOCUMENT REFERENCE .......................................................................................... 336.12 INVOICING OF CONSUMERS (B2C) ................................................................................................................. 346.13 PLACE OF DELIVERY ..................................................................................................................................... 346.14 USE OF PARTY TAX SCHEME FOR ACCOUNTING SUPPLIER PARTY ............................................................................ 356.15 BANK ACCOUNT ......................................................................................................................................... 356.16 ENDPOINTID / LEGAL REGISTRATIONID .......................................................................................................... 366.17 TAX REPRESENTATIVE .................................................................................................................................. 366.18 OPTIONAL ELEMENTS .................................................................................................................................. 377 COMPLETE INFORMATION CONTENTS........................................................................387.1 EHF INVOICE INFORMATION CONTENTS ........................................................................................................... 397.2 EHF CREDIT NOTE INFORMATION CONTENTS ..................................................................................................... 568 VALIDATION ..............................................................................................................718.1 VALIDATION PRINCIPLES ............................................................................................................................... 718.2 DYNAMIC VALIDATION ................................................................................................................................. 728.3 VALIDATION RULES PER PROFILEID AND CUSTOMIZATIONID ............................................................................... 738.3.1 ProfileID bii04, invoice only ........................................................................................................... 738.3.2 ProfileID biixx, credit note only ...................................................................................................... 738.3.3 ProfileID bii05, Invoice and Credit note ......................................................................................... 738.3.4 ProfileID biixy, Invoice, credit note and reminder ......................................................................... 748.4 VALIDATION RULES ..................................................................................................................................... 758.4.1 Invoice ........................................................................................................................................... 758.4.2 Credit note ..................................................................................................................................... 828.5 VALIDATION SERVICE ................................................................................................................................... 899 APPENDICES ..............................................................................................................909.1 APPENDIX 1 - STRUCTURES ........................................................................................................................ 909.2 APPENDIX 2 – MESSSAGE TABLE ................................................................................................................. 909.3 APPENDIX 3 – CODE LISTS ......................................................................................................................... 909.4 APPENDIX 4 - UBL 2.1 SCHEMA ................................................................................................................ 909.5 APPENDIX 5 - SCHEMATRON FILES .............................................................................................................. 909.6 APPENDIX 6 – EXAMPLE FILES .................................................................................................................... 90Invoice and Credit note July 5, 2013 Page 3 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.01 INTRODUCTIONThis document describes the data formats used when trading partners exchange invoice informationelectronically (Norwegian: Elektronisk Handelsformat; EHF). It is prepared as part of the initiativetaken by the Norwegian “Agency for Public Management and eGovernment” (Difi) within thestandardization of electronic trade processes.The EHF formats are based on CEN BII 1 with a syntax binding to Universal Business Language (UBL) 2 .Invoice, Credit note, Catalogue and Order are based on UBL 2.1.UBL is an open standard with no license fees and the same goes for EHF.EHF is maintained by Difi.1.1 BACKGROUND AND OBJECTIVEThe government white paper labeled “St.Meld. nr. 36 (2008-2009) Det gode innkjøp” (The goodprocurement), states among other things:«It’s the Government’s opinion that increased use of electronic solutions is important to improve andincrease the efficiency of public procurement. The use of electronic solutions may reduce time spent onpublic procurement, increase the competition and arrange for purchases to be more transparent and easierto re-examine. By spending less time and money on procurement, resources will be available for bothmodernizing the public sector and more welfare.The goal for introducing electronic solutions is to contribute to a better, simpler and more secureprocurement. »The «Ministry of Government Administration, Reform and Church Affairs» (FAD) considers use ofopen standards as a vital means to build a well-functioning public administration, with good internalcollaboration and a high level of service for both inhabitants and businesses.Definition of open standards:An open standard is characterized by its reputation and will be maintained by a non-commercial organisation,and the continuing development is based on decision processes open to every interested party. The standard ispublished and the documentation is available, either free of charge or for a small, insignificant fee. Anyonemust be allowed to copy, distribute and use the standard free of charge or for a small, insignificant fee. Theintellectual rights related to the standard (e.g. patents) are irrevocably available, without any royalties. There isno reservation regarding re-use of the standard. 3The purpose of this document is to describe a common format for invoice messages in the Norwegian market,and to facilitate an efficient implementation and increased use of electronic collaboration regarding theinvoicing process based on this format1.2 TARGET AUDIENCEThe target audience for this implementation guide is both accounting and IT professionals inorganisations aiming at performing the invoicing process completely or partially electronic. That1 http://www.cen.eu/cwa/bii/specs/2 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl3 http://no.wikipedia.org/wiki/%C3%85pen_standardInvoice and Credit note July 5, 2013 Page 4 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0means issuing an invoice, a credit note and a reminder. This document may also benefit systemsuppliers, ERP suppliers and message brokers. Accounting professionals are advised to read chapters 1 through 5. IT professionals may concentrate on chapters 6 through 9.1.3 DOCUMENT STRUCTUREThis document consists of the following chapters and contents:Chapter 1 gives a short introduction describing the background and objective of thisimplementation guide.Chapter 2 gives the change history of the document.Chapter 3 describes the EHF formats (Invoice and Credit note) in general.Chapter 4 links to definitions relevant to EHF formats.Chapter 5 links to general principles and conditions for the formats.Chapter 6 describes in detail central information elements.Chapter 7 gives the complete information contents of the invoice and the credit noteformats.Chapter 8 deals with validation.Chapter 9 embraces these appendices:o Appendix 1: Message structureo Appendix 2: Message matrixo Appendix 3: Code listso Appendix 4: Link to UBL 2.0 schema for invoice and credit noteo Appendix 5: Link to Schematron files used in validationo Appendix 6: XML example filesAppendices 1, 2, 3 and 6 are separate documents. Appendices 4 and 5 serve aslinks to information on the internet.1.4 MANDATORY USEThis version is valid from July 1, 2013. It will be mandatory from July 1, 2014, andvalidation of previous versions will not be supported after September 1, 2014.This means that: EHF 2.0 will be mandatory for all invoice receivers from july 1, 2014. EHF 2.0 will be mandatory for all invoice issuers from september 1, 2014.Invoice and Credit note July 5, 2013 Page 5 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.02 DOCUMENT HISTORYVersion Comments AuthorDatedd.mm.ccyyExtensions, invoice and creditnote:Invoice in other currency than NOK (VAT inNOK)Sellers tax representativeContract typeType AllowanceChargeContact name for seller and buyerPeriod, manufacturer and country of origin forthe item on line levelExtensions, creditnote:2.0Registration name for party legal entity, sellerand buyerDelivery on document and line levelPayment means on document levelAllowanceCharge on line levelBase quantity for price on line levelReference to invoice/invoice line on line level(BillingReference)Deletions, invoice and creditnote:Address identifier, PO box, Building numberand Department in the Address element ,regarding seller, buyer and deliveryCountrysubentity in the legal addressDepartment, seller and buyerPayment channel in the payment measnselementContact person, seller and buyerMVA spesifikasjon for rabatter/gebyrer på linjeog prisOlav A. Kristiansen, DifiCamilla Bø, HafslundMorten Gjestad, NetsDan Andre Nylænder,Unit4 AgressoJan Terje Kaaby, NARFMorten Krøgenes,BankenesStandariseringskontorPer MartinJøraholmen, DFØJostein Frømyr, EdisysErik Gustavsen, Edisys30.05.2013Deletions, creditnote:Referance to credtinote on document level(BillingReference)Changes, invoice and creditnote:Invoicetype, mandatoryLegal registration name, seller and buyer,Invoice and Credit note July 5, 2013 Page 6 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0mandatoryVAT percentage on line level, optionalPayment terms may occur several timesIncorrect VAT category leads to rejection of thedocument in the validatorContent in EndpointID changedContent in UBLVersionID changed from 2.0 to2.1Content in CustomizationID changed. Version number in Profile ID changed from 1.0to 2.0Functional extension:Invoicing of consumers (B2C)Several adjustments and clarifications about:Accounting costDeliveryAttachmentsOptional elementsEndpointIDBank account numberUse of UBL version 2.1 XML schema.1.6 English version Gunnar Stensby, Edisys 16.01.20131.6Rev. 11.6Adding a colon in CustomizationID.Allow more than one occurrence of AllowanceChargeunder Price.Accounting string on InvoiceLine is changed fromrecommended to optional.Urge to not use optional Note elements.Text adjustments.Several adjustments and clarifications about: Endpoint ID Organisation number VAT-number Allowances Charges Amount Rounding rules description Profiles and messagesIn addition introducing technical and functionalmodifications for Allowing negative invoice Delivery Address on invoice line Support for Norwegian profiles Mandatory elements made optional(StreetAddress for supplier and customer)Olav A. Kristiansen, DifiJostein Frømyr, EdisysErik Gustavsen, EdisysOlav A. Kristiansen, DifiJostein Frømyr, EdisysErik Gustavsen, Edisys14.01.201302.01.2013Invoice and Credit note July 5, 2013 Page 7 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.03 EHF – ELEKTRONISK HANDELSFORMAT (ELECTRONIC COMMERCE FORMAT)3.1 ABOUT EHFEHF is an anagram of the Norwegian expression «Elektronisk handelsformat» (Electronic CommerceFormat).EHF is based on the work performed by CEN BII 4 . This is further adjusted to comply with theNorwegian accounting regulations and current practices for the different business processes in theNorwegian market. Difi pursues the goal to cover the full trading process using EHF documents, bothbefore and after the signing of a contract.Documents, from the tender catalogue to the credit note will be gathered under the EHF umbrella.During 2013 Difi will prepare for the use of EHF formats in what is known as the post award process,i.e. the part of the business process that starts when a supplier and a customer have signed acontract.By using the EHF documents the collaboration between the supplier and the customer will bepredictable. Elements from the tender Catalogue will be re-used in the Order, and elements fromthe Order will be re-used in the Invoice. This leads to a holistic use of all the documents under theEHF umbrella.Difi has chosen to use CEN BII 5 as a base for the EHF formats and the Universal Business Language(UBL) 6 as a foundation for the implemented syntax. Both EHF and UBL are open standards and assuch not liable to any licensing fees or royalties.EHF is managed and maintained by Difi.3.2 INFORMATION CONSISTENCYThe different EHF formats mentioned above contain a number of common information elements(supplier, customer, item etc.). It is important to preserve consistency in those common informationelements, and that means that elements with identical content are declared in the same way and asfar as possible given the same element tag name.EHF invoicing formats will for instance re-use elements from the Catalogue and Order to ensureconsistency between the messages and to make sure that the information from the businesstransactions are reflected in the invoicing documents. This makes it possible to implement anefficient and automated control of the invoice and the originating transactions.3.3 MESSAGE TRANSPORTOpen PEPPOL Transport Infrastructure will provide an efficient use and transport of the EHF formats.4 http://www.cen.eu/cwa/bii/specs/5 http://www.cen.eu/cwa/bii/specs/6 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ublInvoice and Credit note July 5, 2013 Page 10 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0The objective is to make it easy for parties in different countries to do cross-border trade. Experienceshows that it is easy to implement electronic messaging in Norway, because most of the serviceproviders use standard processes.It must be noted that every document scheduled for this infrastructure must be validated with noerrors by Difi’s own validation service. This is likely to be done by the document issuer or by theservice provider on behalf of the document issuer.According to circular P-10/2012 7 FAD recommends all central government agencies to use thistransport infrastructure.3.4 PROFILES AND MESSAGESIn line with the underlying methodology for the EHF formats (cf. www.cenbii.eu) the electronicmessages included in a specific format will be exchanged between the parties as a part of anelectronic collaboration process – a profile.CEN BII has defined a profile as “A specification of how one or more Business Processes are executedby specifying the business rules governing its business collaborations and the information content(data model) of the electronic business transactions exchanged.”To the largest extent the EHF is using profiles prepared by BII (ref www.cenbii.eu) or PEPPOL (cf.www.peppol.eu). Examples of relevant profiles are:Interaction process Messages BII/PEPPOLProfileIDInvoice only Invoice bii04EHFProfileIDCredit note only Credit note biixxInvoice and credit noteInvoiceCredit notebii05Invoice, credit noteand reminderInvoiceCredit noteReminderbiixyOrder and invoiceOrderOrder responseInvoiceCredit notebii067 http://www.regjeringen.no/nb/dep/fad/dok/rundskriv/2012/digitaliseringsrundskrivet.html?id=706462Invoice and Credit note July 5, 2013 Page 11 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0The messages being exchanged within a profile are customized to comply with the requirementsgiven for that particular business document. A CustomizationID is used to identify the business rulesthat apply to the document in question, i.e. the whole set of business rules the document issuerfounded the document on.The example CustomizationID below indicates that the contents of the current message is based onbusiness rules determined by BII (urn:www.cenbii.eu:transaction:biitrns010:ver2.0), extended,customized and clarified by PEPPOL (urn:www.peppol.eu:bis:peppol5a:ver2.0) and further extended,customized and clarified in this implementation guide regarding the Norwegian businesses(urn:www.difi.no:ehf:faktura:ver2.0).urn:www.cenbii.eu:transaction:biitrns10:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.03.5 USE OF COLLABORATION AGREEMENTSThe combination of the ELMA registration and the implementation guides referred to in that contexteliminates the need for any formal collaboration agreement between the sender and the receiver.The ELMA registration verifies that an actor has declared the ability and the commitment to receivebusiness documents composed according to the specific implementation guide, and any party is freeto send the business document to this actor.Exchanging Catalogue and Order requires no registration in ELMA, and actors are advised to includethe use of electronic messages in the purchase contract or to supply an collaboration agreement 8 asan attachment, in order to link the electronic collaboration with the mercantile regulations and thusachieve a regularly revision of the electronic process.3.6 VERSIONINGDifi claims the right to exchange the current format with a new one as and when needed. If so, Difiwill inform the public via the web site and their registered users via e-mail.Difi manages the formats in this way:3.6.1 MAIN VERSIONA new main version will be announced at least 5 months prior to release. When a main version isreleased, there will be at least a 12 months implementation period before the new version is mademandatory.Difi intends to relate every main version to the regulations concerning IT standards in the publicsector.3.6.2 SUB VERSION8 DIFI’s mal for Samhandlingsavtale (Interaction agreement template)Invoice and Credit note July 5, 2013 Page 12 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0A new sub version will be announced at least 3 months prior to release and is made mandatory 5months after release.All sub versions must be backwards compatible. 2 months after the new sub version has becomemandatory, the support (validation service and implementation guide) is ceased for precedingversions.3.6.3 REVISIONA revision is in principle a result of bug fixing the latest sub version, and will be announced at releasetime and should be implemented without further delay.Invoice and Credit note July 5, 2013 Page 13 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.04 DEFINITIONSThe table below gives the definitions of key concepts of the invoicing process.TermSupplierSellerCustomerBuyerInvoiceElectronic invoiceInvoice issuerInvoice receiverPayment receiverCredit noteElectronic CreditnoteDefinitionPerson or company supplying goods or services on own or someoneelse’s behalf.Person or organisation with the necessary authority to sign acontract and transfer the ownership of a product or service.Person or organisation acquiring the ownership of a product or aservice against agreed price and payment terms.Person or organisation acquiring the ownership of a product or aservice for an agreed price and payment terms.A commercial document confirming a sale between a seller and abuyer. The invoice is issued by the seller and the buyer has to paythe claim.An invoice transferred electronically from the issuer to the receiver.The invoice is imported into and processed by the receiver'scomputerized accounting system.Person or organisation that issues an invoice.Person or organisation that receives an invoice.Person or organisation that receives the payment.A commercial document cancelling all or part of an invoice alreadyissued. The Credit note must have a distinct reference to theoriginating invoice.A credit note transferred electronically from the issuer to thereceiver. The credit note is imported into and processed by thereceiver's computerized accounting system.Invoice and Credit note July 5, 2013 Page 14 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.05 PRINCIPLES AND PREREQUISITESThis chapter describes the principles and assumptions that underlie the use of EHF invoicing process.This is basically similar to the CEN BII 05 Billing profile.5.1 INVOICE MESSAGES IN GENERALThe electronic messages described in this implementation guide are Invoice and Credit note. Themessages make it possible for the supplier to issue an invoice, send it to the customer and receivethe agreed payment.5.2 FUNCTIONALITY AND ROLESThe diagram below shows the roles involved in the invoicing process. In EHF the customerand invoice recipient is the same entity as is the supplier and the invoice issuer.Figure 1: Functionality and roles5.3 PROFILES AND MESSAGESThe definition of a profile is given in chapter 3.5.The profiles relevant to the EHF invoicing process are shown in the table below:Interaction process Messages BII/PEPPOLProfileIDInvoice only Invoice bii04EHFProfileIDCredit note only Credit note biixxInvoice and Credit noteInvoiceCredit notebii05Invoice, Credit noteand ReminderInvoiceCredit noteReminderbiixy5.3.1 PROFILEIDThe ProfileID identifies the process the business document is part of. EHF uses the identificationInvoice and Credit note July 5, 2013 Page 15 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0system according to BII, with the addition of two Norwegian profiles (biixx and biixy):Profile contentsInvoice onlyCredit note onlyInvoice and Credit noteInvoice , Credit note and ReminderProfileIDurn:www.cenbii.eu:profile:bii04:ver2.0urn:www.cenbii.eu:profile:biixx:ver2.0urn:www.cenbii.eu:profile:bii05:ver2.0urn:www.cenbii.eu:profile:biixy:ver2.05.4 USE OF UBL 2.1This version of EHF Invoice and Creditnote is based on UBL XML schema version 2.1. Previousversions of the EHF Invoice and Creditnote used UBL version 2.0.5.5 THE INVOICING PROCESSThe invoicing process includes issuing and sending the Invoice and the Credit note from the Supplierto the Customer and the reception and handling of the same at the customer’s site.The invoicing process is shown in this work flow:1. A Supplier issues and sends an EHF Invoice to a Customer. The invoice refers to one or moreorders and a specification of delivered goods and services.An invoice may also refer to a contract or a frame agreement. The invoice may specifyarticles (goods and services) with article number or article description.2. The Customer receives the invoice and processes it in the invoice control system leading toone of the following results:a. The Customer fully approves the invoice, posts it in the accounting system andpasses it on to be paid.b. The Customer completely rejects the invoice, contacts the Supplier and requests aCredit note.c. The Customer disputes parts of the invoice, contacts the Supplier and requests aCredit note and a new Invoice.The diagram below shows the invoicing process with the use of EHF invoice messages. This process isbased on the profile 5 in CENBII (BII05 - Billing), which assumes that both the invoice and the creditnote are exchanged electronically. The profile also includes the message type «Corrective invoice»,but this is not used in Norway. If the customer disputes the invoice, the supplier must issue a creditnote and a new invoice.Invoice and Credit note July 5, 2013 Page 16 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Collaboration Inv oicing processCustomer SupplierGenerate invoice orcreditnoteInvoiceSend invoiceEHF invoiceCreditnoteEHF creditnoteReceive and processinvoice/creditnoteSend creditnoteNoOK ?YesContact the supplierFigure 2 The invoicing process5.5.1 EXCEPTION HANDLING, VALIDATION BY THE ISSUERAn EHF Invoice or EHF Credit note should be validated by the issuer before submitted to thetransport infrastructure. The validation process is described in chapter 8. Validation may beperformed at several stages and by several services:1. In the ERP-system. Validation is included in the process that creates the invoice/credit notedocument. If validation fails the document will not be created. The information thedocument is based on must be modified and the creation process rerun.2. In the access point. The service provider offers to validate documents on behalf of the client.If the validation fails the document is returned to the client and not forwarded into theinfrastructure. The issuer has in that case 2 options:A. If the document is not posted in the issuing accounting system, it may be modified andresubmitted.B. If the document is posted in the issuing accounting system, it cannot be modified.Instead a credit note must be posted (internally) and not submitted. After modifying thedata for the invoice a new invoice may be issued.Invoice and Credit note July 5, 2013 Page 17 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.05.5.2 EXCEPTION HANDLING, VALIDATION BY THE RECEIVERSome receivers want to validate incoming documents even though the documents should have beenvalidated before they were submitted to the transport infrastructure. The following scenarios mayarise:1. The document fails to validate:a. Due to the use of different versions of the EHF formats (cf. chap. 2.1.2), the receivermust process the document manually.b. Other reasons. The received document is discarded (not processed).The receiversends a «Message Level Response» to the supplier and requests a new, correctdocument.2. The document validates correctly, but the receiver disputes all or parts of the contents. Thereceiver informs the sender manually about the situation. The sender issues a credit noteand may issue a new invoice.5.6 USE OF NEGATIVE INVOICENegative invoice is an invoice where the total invoiced amount is less than zero. This version of EHFInvoice accepts that, but Difi’s validation service will give a warning message. Earlier it gave an errormessage.A negative invoice must not be confused with a credit note. A negative invoice invoices the sale ofnew goods or services. A credit note resets or repays all or part of a previously received invoice.5.7 FINANCIAL ADVANCE VS ON ACCOUNT INVOICINGFinancial advance is not previously invoiced, (ref. «Skattedirektoratets uttalelse av 23.05.07Finansielle forskudd eller forskuddsfakturering og GBS 13 Forskuddsfakturering.», in English:«Directorate of taxes, statement 23.05.2007: Financial advance or advance billing and GBS13Advance billing». This means that when the goods or services are delivered an invoice must be issuedaccording to the rules in the Accounting regulations § 5-1 and § 5-2 even if the economicconsiderations already are levied through financial advance. The invoice settles the financialadvance. If the economic considerations exceed the financial advance, the buyer must pay theexcessive amount. If the economic considerations are lower than the financial advance, a negativeinvoice occurs, and the seller must repay the negative invoice amount.In cases of financial advance or on account invoicing a credit note must be issued following the rulesof the “Accounting regulations § 5-2-8» and “GBS 1 Issuing a credit note»(http://www.regnskapsstiftelsen.no/a9232422/uttalelser-om-gbs) to settle the previous invoice (ifthe specified considerations were too high).Invoice and Credit note July 5, 2013 Page 18 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06 DESCRIPTION OF SELECTED PARTS OF EHF INVOICE MESSAGESThis chapter describes selected parts of the information contents of the EHF messagesInvoice and Credit note. Go to chapter 7 for the complete information contents.6.1 ROLES AND ACTORThe following roles may be specified in the format. The same actor may play more thanone role depending on the handling routine.RolesSeller(AccountingSupplierParty)Buyer(AccountingCustomerParty)Payment receiver(AccountingPayeeParty)DescriptionSeller is mandatory information in EHF.Buyer is mandatory information in EHF.Payment receiver is optional information in EHF. If thisinformation is not supplied, the seller is the paymentreceiver.Example: Supplying seller information on the header level in an EHF invoice message.123456789Supp123Salescompany ltd.Main streetSuite 123Big city54321RegionANO123456789MVAVATThe Sellercompany ASA123456789Invoice and Credit note July 5, 2013 Page 19 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Big cityNOO. HansenAntonio Salemacher4621123046211231antonio@salescompany.noExample: Supplying buyer information on the header level in an EHF invoice message.

EHF Implementation guideVersion:Invoice and Credit note 2.051212305121231john@buyercompany.no6.2 ALLOWANCES AND CHARGES, GENERAL RULESa) Several allowances and charges may be supplied both on header level and line level. For the Priceelement the validation routine will produce a warning if more than one occurrence ofAllowanceCharge is present. The element AllowanceCharge with sub element AllowanceIndicatorindicates whether the instance is a charge (true) or an allowance (false).b) Specification of VAT for allowances and charges, AllowanceCharge/TaxCategory with subelements, may be supplied both on the header level and on the line level, but not for the Priceelement. Since allowances and charges on the Price element simply information, there is no VATcalculation on those.c) The sum of all allowances and charges on the header level must be specified inAllowanceTotalAmount and ChargeTotalAmount respectively (Ref. chap. 6.2.1.1.3).d) The sum of all allowances and charges on the line level must be taken into account, subtracted oradded, when calculating the LineTotalAmount . These line level allowances and charges must notbe calculated into the header level elements.e) Allowances and charges related to Price shall not be part of any other calculations.f) Allowances and charges related to Price may specify amount (AllowanceCharge/Amount), baseamount (AllowanceCharge/BaseAmount) and a multiplier(AllowanceCharge/MultiplierFactorNumeric).6.2.1 INVOICEThe EHF Invoice format has elements for AllowanceCharge on 3 levels:a) The header level, applies to the whole invoice and is included in the calculation of the invoicetotal amount.b) The line level, applies to the line level and is included in the calculation of the line amount.c) The line level Price element. Only a way to inform the buyer how the price is set. Is alsorelevant if the seller or buyer want to post the allowance or charge in their accountingsystems. The price itself shall always be the net price, i.e. the base amountreduced/increased with AllowanceCharge/Amount.6.2.1.1 EXAMPLE Net invoice amount exclusive VAT: NOK 3450. 2 invoice lines:o Line 1: 10 units of item A. NOK 100 per item and 10% discount.o Line 2: 15 units of item B. NOK 200 per item and 15% discount.• The price NOK 200 is included the campaign discount of 25% to illustratethe use of AllowanceCharge related to Price. Total discount: 2 % Invoice charge: NOK 75 Shipping cost: NOK 100Invoice and Credit note July 5, 2013 Page 21 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06.2.1.1.1 XML FOR ALLOWANCES AND CHARGES ON THE HEADER LEVELtrueFreight100.00S25.00VATtrueInvoice fee75.00S25.00VATfalse2% Discount69.00S25.00VAT6.2.1.1.2 XML FOR VAT ON THE HEADER LEVEL889.003556.00889.00S25.00VAT6.2.1.1.3 XML FOR THE HEADER LEVEL TOTALS3450.003556.00Invoice and Credit note July 5, 2013 Page 22 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.04445.0069.00175.000.004445.006.2.1.1.4 XML FOR ALLOWANCES ON THE LINE LEVELLine 1110.00900.00false10% Discount100.00S25.00VATLine 2215.002550.00false15% Discountt450.00S25.00VAT6.2.1.1.5 XML FOR ALLOWANCES RELATED TO PRICE FOR INVOICE LINE 2200.00false20% Discount (Campaign)0.20050.00250.00Invoice and Credit note July 5, 2013 Page 23 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06.2.2 CREDIT NOTEThe EHF Credit note format have elements for AllowanceCharge on 3 levels:a) The header level. Identical to the EHF Invoice format.b) The line level. Identical to the EHF Invoice format.c) The line level Price element. Identical to the EHF Invoice format.6.2.2.1 EXAMPLE Net invoice amount exclusive VAT: NOK 3450. 2 invoice lines:o Line 1: 10 units of item A. NOK 100 per item and 10% discount.o Line 2: 15 units of item B. NOK 200 per item and 15% discount.• The price NOK 200 is included the campaign discount of 25% to illustratethe use of AllowanceCharge related to Price. Total discount: 2 % Invoice charge: NOK 75 Shipping cost: NOK 1006.2.2.1.1 XML FOR ALLOWANCES AND CHARGES ON THE HEADER LEVELIdentical to the EHF Invoice.6.2.2.1.2 XML FOR VAT ON THE HEADER LEVELIdentical to the EHF Invoice.6.2.2.1.3 XML FOR THE HEADER LEVEL TOTALSIdentical to the EHF Invoice.6.2.2.1.4 XML FOR CREDIT NOTE LINESIdentical to the EHF Invoice except the InvoicedQuantity element. The name of this elementin the creditnote is CreditedQuantity.6.3 ROUNDINGa) Rounding shall, as a general rule, be performed on the final result of a calculation only and noton any intermediate calculation, for the result to be mathematically correct.b) Rounding shall result in a decimal figure with 2 decimal places. The third decimal digit beinggreater than 4 increases the second decimal digit with 1, whilst the third decimal digit being lessthan 5 leaves the second decimal digit as it is.c) The EHF format assumes that all amounts on the header level have a maximum of 2 decimalplaces. Calculated amounts with more than 2 decimal places, like most VAT calculations, must berounded. Results from calculations involving already rounded amounts are not subject torounding , like payable amounts and total amounts included VAT.6.3.1 ELEMENTS THAT MUST BE ROUNDEDa) One line’s total amount, LineExtensionAmount, must be rounded because it may be subject toposting in an accounting system. Note that the elements contained in theLineExtensionAmount (Price * Quantity, Allowances and Charges) must be rounded separatelywhen calculating the LineExtensionAmount.Invoice and Credit note July 5, 2013 Page 24 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0All rounded LineExtensionAmount shall be summed as the total line amount on the header level;MonetaryTotal/Line Extension Amount.The rounded LineExtensionAmount shall be subject to VAT calculation on the header level; TaxSubtotal/ TaxableAmount.b) The sum of the header level allowances must be rounded before it is specified to the elementMonetaryTotal/AllowanceTotalAmount.c) The sum of the header level charges must be rounded before it is specified to the elementMonetaryTotal/ChargeTotalAmount.d) The element TaxSubTotal/TaxableAmount which holds the value subject to VAT calculation.e) The element TaxSubTotal/TaxAmount which holds the VAT value calculated on the d) value.6.3.2 ROUNDING OF THE PAYABLE AMOUNTIt is possible to round the payable amount to the nearest integer. The elementMonetaryTotal/PayableRoundingAmount is used for this and is specified on the header level.This value must be added to the value in MonetaryTotal/TaxInclusiveAmount.Example: amount 999.81 rounded to 1000. PayableRounding Amount = 0.19.6.3.3 EXAMPLES OF ROUNDING Invoice with 3 lines:o Line 1: 24 units of item A. Kr. 51.304 per unit, 10% discount rate. 25% VAT.o Line 2: 15 units of item B. Kr. 44.7823 per unit, 15% discount rate. 25 % VAT.o Line 3: 21 units of item C. Kr. 134.95 per unit, 24.45 % discount rate. 15% VAT. Discount rate on total: 2.35 % Shipping cost: 100.345 Prepaid amount: 100 Payable rounding amount: -0.36 (note the negative value)6.3.3.1 CONTENTS OF AMOUNT ELEMENTSDiscount Price*units DiscountLine Price Units raterounded rounded Line total VAT %1 51,304 24 10 % 1231,3 123,13 1108,17 25 %2 44,7823 15 15 % 671,73 100,76 570,97 25 %3 134,95 21 24,45 % 2833,95 692,9 2141,05 15 %ValuesAllowanceCharge (Invoice)unroundedDiscount on total(25% mva) 2,35 % 89,774465Shipping cost(25% mva) 100,345VATcatg.VATbasisVATrateVATcalculatedVAT percategoryS 1689,72 25 % 422,43 422,43H 2141,05 15 % 321,1575 321,163830,77 743,5875 743,59 Total VATSum all lines 3820,19Invoice total exclusive VAT 3830,773820,19Invoice and Credit note July 5, 2013 Page 25 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Invoice total inclusive VAT and rounding 4574,00Allowances (discount on total) 89,77Charges (shipping cost) 100,35Prepaid amount 100,00Rounding amount -0,36Payable amount 4474,006.3.3.2 XML FOR ALLOWANCES AND CHARGES ON THE HEADER LEVELfalse2.35% Total discount89.7744S25.00VATtrueShipping cost100.345S25.00VAT6.3.3.3 XML FOR VAT ON THE HEADER LEVEL743,591689.72422.43S25.00VAT2141.05321.16H15.00VATInvoice and Credit note July 5, 2013 Page 26 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Line 2215.00570.971232false15% Discount100.760175S25.00VATVare BBBBS25.00VAT44.7823Line 3321.002141.051232false24.45% Discount692.9007H15.00Invoice and Credit note July 5, 2013 Page 28 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06.5.1 CURRENCY OTHER THAN NOKEHF 2.0 contains support for document currency other than NOK. In this case all VAT amounts mustbe stated in NOK in addition to the VAT amounts in the document currency. This is implemented bytwo occurences of the Taxtotal element.Example: Invoice total EUR 1000 EUR exclusive VAT. Exchange rate EUR/NOK = 8.00.250.001000.00250.00S25.00VAT2000.008000.002000.00S25.00VAT6.6 SPECIAL TAXES/CHARGESIf special taxes/charges are applicable, each one must be specified on an ordinary invoice line. Theonly valid tax scheme identifier is «VAT» (code list UN/ECE 5153 subset). If there is no separate linefor special tax, the assumption is that the special tax is included in the price.6.7 ORDER / ORDER NUMBER / ORDER REFERENCEThe customer will issue an order with a unique order number. This unique customer order numbermust be supplied as the order reference on the invoice.If the order reference is specified on the header level (OrderReference), the assumption is that theinvoice is based on one order only. Example:The header level:123The line level:Invoice and Credit note July 5, 2013 Page 30 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.01If the invoice is based on more than one order, the order number should be concatenated with theorder line number on each invoice line in this way “order number##order line number”. Example:The line level only:123##1…234##1The exact syntax should be agreed upon by the two parties.6.8 CONTRACT NUMBERTo reference or match an invoice to a signed purchase contract, the contract number could bespecified like this:Contract321Framework agreementIf other references than Order number and Contract number is needed, the element Additionaldocument reference (ref. ch. 6.11) may be used.6.9 ACCOUNTING INFORMATIONIf the customer wants to automatically post the costs, the accounting information must betransferred to the supplier before or with the order . The supplier should then return the accountinginformation on the invoice line level.Example:Project cost code 123The accounting cost element is just a simple text element. Posting in accounts payable and generalledger often requires several «dimensions». A structured solution regarding content in theaccounting cost string has been demanded from a number of stakeholders.Below you will a proposal regarding content in the account cost string. The structure of the stringwill be as follows: Format-ID. Fixed text indicating which Chart of Accounts is used. (NS4102 = Norwegainstandard) Fieldname. Up to 7 fields may be used:o Konto (Account)o Avd (Department)o Prod (Product)o Prosj (Project)o MVAkode (VAT code)o Dim6Invoice and Credit note July 5, 2013 Page 31 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0o Dim7ValueSeparator regarding fieldname and value: Use the ‘=’ characterSeparator regarding fields: Use the ‘;’ characterContent in general:;Konto=;Avd=;Prod=;Prosj=;MVAkode=;Dim6=;Dim7=Chart of Accounts must always be the first element in the string. No requirements regardingsequence of the other elements. If norwegian standard Chart of Accounts is used by the invoicereceiver, then NS4102 must be the leftmost content of the account cost string. For receivers usingstandard agricultural Chart of Accounts, version 1, the text ‘Landbruk_kontostreng_v01’ must theleftmost content of the accounting cost string.Any other posting requirements than account number, department, product, project and VAT code,may be implemented by using the Dim6 and Dim7 fields. In agricultural context there is a need for afield called ‘driftsgreinkode’. Dim6 may be used in this case.Example:NS4102;Konto=4010;Avd=25;Prod=5421;Prosj=4098;MVAkode=16.10 ATTACHMENTSBoth the invoice and the credit note formats support the use of attachments. The element to holdthe attachment information can be repeated multiple times (AdditionalDocumentReference) thusallowing multiple attachments.Attachments may be used to provide additional information to support the claim represented by theinvoice. Additional information can be time sheets, receipts, airfare tickets etc. Attachments are notmeant for transferring a pdf-version of the invoice/creditnote. If, however, the “pdf-version” issupplied as an attachment, the element “DocumentType” must specify “Commercial invoice” for aninvoice and “Credit note” for a creditnote.Attachments can also be graphs and images. The attachment could be sent as a binary object or as anexternal address to the object’s storage location (URI).It is recommended to send additional information included in the format (message) and not as anexternal address (URI), since many businesses are restricted from pursuing external links.If external link is used, the buyer is committed to download the information contained in the link andstore it with reference to the invoice/creditnote document. Such a solution requires according to theNorwegian tax authorities (Skattedirektoratet), an agreement between the parties. Thus use ofexternal links are not recommended.Invoice and Credit note July 5, 2013 Page 32 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Additional recommendations:CodingDocument formatRecommendationsBase64MIME types:Pdf – application / pdfTXT – text / txtGIF – image / gifTIFF – image / tiffJPEG, JPG – image / jpegPNG – image / pngSizeDescription ofattachment5MBIt is advised to supply a good description of each attachment and the element touse is:Invoice/Additional_DocumentReference/DocumentReference/DocumentType.Should only be used for description.This recommendation recognizes the fact that there are implementations that use different solutionsfor handling attachments. Any recommendation made in this document must not be perceived as acriticism of existing implementations nor as a demand or request to alter those. Any newimplementation or planned modification is advised to follow these recommendations to supportinteroperability unless specific business requirements have a higher priority.6.10.1 COPY OF THE INVOICE/CREDITNOTE AS AN ATTACHMENTThere is one special case where it is absolutely required to send the invoice/creditnote as anattachment (cf: FOR 2004-12-01 nr 1558: Forskrift om bokføring).Companies without the ability to send EHF formats will create an invoice or creditnote as usual, e.g.as a document meant to be printed and mailed. Those companies can use an «invoice portal» toregister necessary information about the invoice or creditnote and then add a pdf-version or animage of the invoice/creditnote as an attachment.In that case the element DocumentType must specify “Commercial invoice” for an invoice and“Credit note” for a creditnote.6.11 OTHER USE OF ADDITIONAL DOCUMENT REFERENCEThe need to distribute information not included in the EHF format arises from time to time. To satisfythis need, the element AdditionalDocumentReference is used. As mentioned above, this element canbe repeated multiple times. Examples of information to go into this element are packing lists andthe supplier’s order number.Important to notice, there is no code list for this element, and the interactive parties must agree onsyntaxes and semantics.Example:SuppOrder13001Invoice and Credit note July 5, 2013 Page 33 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Supplier’s order numberPacking13001PackingList for SuppOrder130016.12 INVOICING OF CONSUMERS (B2C)EHF Invoice 2.0 facilitates invoicing of consumers (B2C). This means that invoice issuers may usethe EHF 2.0 format both for business customers and consumers. Transmission of an invoice to aconsumer from an invoice issuer is performed by use of the consumers «netbank» assuming thatthe issuer has an agreement with a bank supporting e-invoicing.E-invoice reference (Efakturareferanse) must be placed in the ID element of AdditionalDocumentReference. DocumentType must be set to «efakturareferanse». The buyer’s legal entityis not mandatory when “efakturareferanse” is given as documenttype.Example, E-invoice reference:147987efakturareferanseIn the consumers market automatic debit (Avtalegiro) is widespread as payment method.Example, electronic invoice B2C with automatic debit (Avtalegiro):PaymentMeansCode: 3 (Automated clearing house debit)32013-06-250265590215686514010999996.13 PLACE OF DELIVERYPlace of delivery may be given at document (Mandatory) or line level (Optional). The deliveryelement contains an identifer (DeliveryLocation/ID) which may be used if the place of delivery isdefined through an identifier. Examples are GLN (Global Location Number) or GSRN (Global ServiceRelationship Number) both issued by GS1. GSRN is used in the norwegian market for identifyingmeasuring points in the energy sector. Ref. appendix 7.Example:2013-02-15 707057500022939815Storgata12Invoice and Credit note July 5, 2013 Page 34 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Bergen5000NO6.14 USE OF PARTY TAX SCHEME FOR ACCOUNTING SUPPLIER PARTYPartyTaxScheme under AccountingSupplierParty is an optional element, but according to EU COUNCILDIRECTIVE 2001/115/ the PartyTaxScheme must be specified if the invoice or the credit note have aVAT total. That means that the element almost always has to be specified. The specification should bethe supplier party’s organization number followed by the letters MVA, like this:123456789MVAVAT6.15 BANK ACCOUNTIf both BBAN (Basic Bank Account Number) and IBAN (International Bank Account Number) areavailable when the XML instance document is generated, the sequence should be BBAN first andIBAN last.Example:312013-06-25026559021568615032387680312013-06-250265590215686 NO7315032387680DNBANOKKXXXInvoice and Credit note July 5, 2013 Page 35 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06.16 ENDPOINTID / LEGAL REGISTRATIONIDEndpoint ID is used for specifying the electronic addresses issuers and receivers are using in theirmessage collaboration. Electronic addresses for norwegian participants in the PEPPOL infrastructureare the legal registration ID of the company and must be registered in ELMA.Legal registration ID (Company ID) is used for identifying the legal entity the invoice is linked to, ie.the legal entity responsible for the obligation.Small businesses normally have just one legal registration ID. For these the endpoint ID and the legalregistration ID will be compliant.Major businesses may have several legal registration IDs based on for instance location. If processingof incoming invoices are centralized for all legal entities within the business, the content of theendpoint ID and legal registration ID (Company ID) may be different. In this context it isrecommended that all legal entities are registrered in ELMA. Dissemination to a centralized invoiceprocessing function is implemented as part of the registration by the actual accesspoint. (Severalinvoice receivers share the same endpointID).The alternative to the solution above is to handle the endpointID as an «invoice receiver address».This means that the invoice receiver manually has to inform the trading partners of the endpointID touse in the message collaboration.6.17 TAX REPRESENTATIVETax representative party for the seller is relevant for sellers delivering goods and services in Norwaywithout having a permanent establishment in Norway. In such cases the name and address of thetax representative must be included in the invoice.Example:Company name ASSmall streetSuite 123Small city4321NO904312347MVAVATInvoice and Credit note July 5, 2013 Page 36 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.06.18 OPTIONAL ELEMENTSThe receivers invoice handling system must releate to all elements on an invoice (including alloptional elements) and at least display all filled elements in the control and verification process ofthe invoice.Dynamic display of invoice and creditnote based on XML instance documents will be developed byDifi.Invoice and Credit note July 5, 2013 Page 37 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.07 COMPLETE INFORMATION CONTENTSChapter 7.1 and 7.2 show the complete information contents of EHF Invoice and EHF Credit note.Here is a description of the columns in the tables.Name is the logical, explanatory name of the element. Names in blue colour representcommon aggregated elements and serve only as a header for the following elements.DescriptionReq.Cardis a complementary explanation of the element.Requirement shows if the element is:Mandatory (M)Optional (O)Recommended (R)shows the cardinality; number of required/valid occurrences0..1 Valid zero or 1 occurrence1..1 Required 1 and only 1 occurrence1..* Required at least 1 occurrence0..* Valid zero or infinite occurrencesExampleXML Elementshows how to specify the element.refers to the actual XML tag name in the EHF invoice message.Invoice and Credit note July 5, 2013 Page 38 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.07.1 EHF INVOICE INFORMATION CONTENTSName Description Req Max rep Example XML elementInvoice EHF invoice version 2.0 .. InvoiceUBL version The UBL version the invoice message is based on M 1 .. 1 2.1 cbc:UBLVersionIDCustomization IdentifierIdentifies the specification of content and rules that apply to thetransaction.Identifying the customization/implementation guide/contextualization of the syntax message and its extension thatapplies to the invoice transaction, enables the receiver to applythe correct validation to the received document as well as toroute the document to an appropriate service for processing.M 1 .. 1 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0 or urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0cbc:CustomizationIDProfile IdentifierInvoice numberIssue DateInvoice Type CodeNoteIdentifies the BII profile or business process context in which thetransaction appears.Identifying the profile or business process context in which thetransaction appears enables the buyer to direct the message to anappropriate service as well as controlling its relation to otherdocuments exchanged as part of the same process.An invoice instance must contain an identifier. An invoiceidentifier enables positive referencing the document instance forvarious purposes including referencing between documents thatare part of the same process.The issue date of an invoice is required by EU directives as wellas country laws. An invoice must therefore contain the date onwhich it was issued.A code that identifies the functional type of the invoice instance,such as commercial invoice, pro-forma invoice, final invoice.A code that identifies that the invoice is a commercial invoice.The textual note provides the seller a means for providingunstructured information that is relevant to the invoice. This canbe notes or other similar information for which the invoicespecification does not contain suitable qualified elements.Information given in as textual notes is mainly intended formanual processing. When “invoice clauses” or “declarations” areused they should be stated in full in the note element.M 1 .. 1 urn:www.cenbii.eu:profile:bii04:ver2.0 or urn:www.cenbii.eu:profile:bii05:ver2.0 or urn:www.cenbii.eu:profile:bii06:ver2.0 or urn:www.cenbii.eu:profile:biixy:ver2.0cbc:ProfileIDM 1 .. 1 123456 cbc:IDM 1 .. 1 2009-11-22 cbc:IssueDateM 1 .. 1 380 (Ordinary invoice), 393 (Factoring invoice) cbc:InvoiceTypeCodeO 0 .. 1 cbc:NoteTax Point Date The date applicable VAT O 0 .. 1 cbc:TaxPointDateDocument currency codeThe currency in which the monetary amounts are stated must be M 1 .. 1 NOK cbc:DocumentCurrencyCodestated in the invoice.Invoice and Credit note July 5, 2013 Page 39 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAccounting costThe invoice may contain a reference to the buyer's accounting O 0 .. 1 cbc:AccountingCostcode applied to the invoice as a whole, expressed as text ratherthan a code in order to facilitate automation in booking intoaccounts following an order to invoice transformation.Invoice period The period to which the Invoice applies O 0 .. 1 cac:InvoicePeriodPeriod start dateThe date on which the period starts. The start dates counts aspart of the period.For invoices that charge for services or items delivered over atime period is necessary to be able to state the start date of theperiod for which the invoice relates such as for metered servicesand subscriptions.O 0 .. 1 2013-01-06 cbc:StartDatePeriod end dateThe date on which the period ends. The end date counts as part O 0 .. 1 2013-06-30 cbc:EndDateof the period.It must be possible to state the end date of the period for whichthe invoice relates such as for metered services andsubscriptions.Order An assosiation to Order Reference R 0 .. 1 cac:OrderReferenceOrder reference identifierTo facilitate order–invoice matching an invoice may contain an M 1 .. 1 cbc:IDidentifier of an order (issued by the buyer) that the invoicerelates to. An invoice may only reference one order.Contract Reference to contract or framework agreement R 0 .. 1 cac:ContractDocumentReferenceContract identifierContract type, codePositive identification of the reference such as a uniqueidentifier.To positively identify relevant contractual issues the invoice maycontain an identifier of a contract that applies to the invoice.An invoice may contain the type of contract that is referred to(such as framework agreement) in a coded way to enableautomated processing based on the contract type.M 1 .. 1 cbc:IDO 0 .. 1 Codelist from BII: 1=Public contract,2=Establishment of a Framework agreement,3=Setting up a Dynamic Purchasing System,4=Public contract based on a Frameworkagreement, 5=Public contract based on aDynamic Purchasing System.cbc:DocumentTypeCodeDocument typeThe short description of what is reference such as contract type, O 0 .. 1 Framework agreement cbc:DocumentTypedocument type , meter etc.An invoice may contain the type of contract that is referred to(such as framework agreement)Additional Document Reference Reference to additional documents O 0 .. unbounded cac:AdditionalDocumentReferenceDocument identifier An identifier for the referenced document. M 1 .. 1 cbc:IDDescription A short description of the document type. O 0 .. 1 cbc:DocumentTypeInvoice and Credit note July 5, 2013 Page 40 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAttachmentReference to attached document, externally referred to, O 0 .. 1 cac:Attachmentreferred to in the MIME location or embeddedEmbedded binary objectThe attached document embeded as binary object.An invoice may contain an attached electronic document as anO 0 .. 1 cbc:EmbeddedDocumentBinaryObjectencoded object in the invoice in order to provide supportingdocuments such as timesheets, usages reports etc. The seller canonly expect the receiver to process attachments according to rule.External reference An attached document O 0 .. 1 cac:ExternalReferenceExternal referenceThe Uniform Resource Identifier (URI) that identifies where the O 0 .. 1 cbc:URIexternal document is located.SupplierOrganisation or person responsible som delivering the goods M 1 .. 1 cac:AccountingSupplierPartyand servicesSupplier An assosiation to Party M 1 .. 1 cac:PartyEndPointIDAn invoice may contain the sellers electronic address. Theaddress can be of any format and the format should be identifiedin the message.Electronic addresses for Norwegian actors using the PEPPOLtransport infrastructure shall be specified as NorwegianOrganization Number. with "NO:ORGNR" as attributeschemeID.R 0 .. 1 123456789 cbc:EndpointIDIdentification An assosiation to Party Identifiaction O 0 .. 1 cac:PartyIdentificationParty identifierAn invoice may contain a registered identifier for the seller. M 1 .. 1 cbc:IDInformation referenced by the identifier is not considered part ofthe message (i.e. the buyer is not required to look up theidentifier in the relevant registry and process additionalinformation)Supplier Name Name of supplier M 1 .. 1 cac:PartyNameNavnAn invoice must contain the name of the seller.M 1 .. 1 The Vendor ltd. cbc:NameIf the company types AS or ASA are being established it'srecommended that the invoice shows this. If the company typesAS, ASA and NUF are under liquidation, the supplier's name onthe invoice shall include this information.Address The suppliers address M 1 .. 1 cac:PostalAddressLine 1The main address line in a postal address usually the street nameand number.An invoice must contain the seller’s street name and number orP.O.box.O 0 .. 1 Bond street 34 cbc:StreetNameInvoice and Credit note July 5, 2013 Page 41 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementLine 2An additional address line in a postal address that can be used to O 0 .. 1 cbc:AdditionalStreetNamegive further details supplementing the main line. Common useare secondary house number in a complex or in a building.An invoice may contain an additional address line for selleraddress.CityThe common name of the city where the postal address is. The M 1 .. 1 Oslo cbc:CityNamename is written in full rather than as a code.An invoice must contain the seller’s city.Post codeThe identifier for an addressable group of properties according to M 1 .. 1 5010 cbc:PostalZonethe relevant national postal service, such as a ZIP code or PostCode.An invoice may contain the seller’s post code.Country subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.In some countries regions or other type of country sub divisionsare commonly used.An invoice may contain that information.Country Country code M 1 .. 1 cac:CountryCountry codeThe country where the address is. The country should always be M 1 .. 1 NO cbc:IdentificationCodegiven by using ISO code 3166 alpha 2The seller’s address country must be contained in an invoice inthe form of a two letter code (ISO 3166-1 alpha-2).Tax Scheme Tax scheme for the supplier O 0 .. 1 cac:PartyTaxSchemeVAT registration numberWhen the invoice is a VAT invoice it must state the sellers VATregistration number and tax scheme.The supplier's VAT-number (Norwegian MVA number) madeout of the organisational number and the letters MVA. Theattributes schemeID and schemeAgencyID must be «NO:VAT»and «82» respectively. Mandatory if the supplier is taxable.M 1 .. 1 Domestic: 987654321MVA, cross-border trade:NO987654321MVAcbc:CompanyIDTax scheme Tax scheme M 1 .. 1 cac:TaxSchemeIdentifier VAT is the only legal code M 1 .. 1 cbc:IDLegal entity Assosiation to Party Legal Entity M 1 .. 1 cac:PartyLegalEntityRegistration name The name under which the seller is legally registered. M 1 .. 1 Any supplier name cbc:RegistrationNameInvoice and Credit note July 5, 2013 Page 42 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementCompany IDAn invoice may contain the identifier assigned to the party bythe national company registrar.The supplying organisations legal organisation number. Fornorwegian suppliers: Attributes: schemeID="NO:ORGNR",schemeName="Foretaksregisteret" for companies AS, ASA andNUF, but is recommended for all companies registered in"Foretaksregisteret".schemeAgencyID="82"M 1 .. 1 987654321 cbc:CompanyIDLegal address The legal address of the supplier O 0 .. 1 cac:RegistrationAddressCity name The name of the city where the seller is legally registered. O 0 .. 1 Oslo cbc:CityNameCountry Country code O 1 .. 1 cac:CountryCountry The country in which the seller is legally registered. M 1 .. 1 NO cbc:IdentificationCodeContact The suppliers contact person R 0 .. 1 cac:ContactIdentifier The supplier's reference specified as "Our ref." R 0 .. 1 cbc:IDNameThe name of the contact person.R 0 .. 1 John Doe cbc:NameAn invoice may contain a person name for a relevant contact atthe seller.TelephoneA phone number for the contact person. If the person has a direct R 0 .. 1 +4712345678 cbc:Telephonenumber, this is that number.An invoice may contain a telephone number for a relevantcontact at the seller.TelefaxA fax number for the contact persons.O 0 .. 1 +4792612346 cbc:TelefaxAn invoice may contain a tele-fax number for a relevant contactat the seller.Electronic mailThe e-mail address for the contact person. If the person has a R 0 .. 1 supplier.contact@supplyingcompany.no cbc:ElectronicMaildirect e-mail this is that email.An invoice may contain a telephone number for a relevantcontact at the seller.Customer Customer party M 1 .. 1 cac:AccountingCustomerPartyParty An assosiation to party M 1 .. 1 cac:PartyEndpointIDAn invoice may contain the buyers electronic address. Theaddress can be of any format and the format should be identifiedin the message.Electronic addresses for Norwegian actors using the PEPPOLtransport infrastructure shall be specified as NorwegianOrganization Number. with "NO:ORGNR" as attributeschemeID.R 0 .. 1 998876543 cbc:EndpointIDInvoice and Credit note July 5, 2013 Page 43 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementIdentification An assosiation to Party Identifiaction O 0 .. 1 cac:PartyIdentificationCustomer identifiactionAn invoice may contain a registered identifier for the buyer. M 1 .. 1 cbc:IDInformation referenced by the identifier is not considered part ofthe message (i.e. The buyer is not required to look up theidentifier in the relevant registry and process additionalinformation)Customer name Name of customer M 1 .. 1 cac:PartyNameName An invoice must contain name of the buyer. M 1 .. 1 cbc:NameAddress The address of the customer M 1 .. 1 cac:PostalAddressLine 1The main address line in a postal address usually the street name O 0 .. 1 Baker street 13 cbc:StreetNameand number.An invoice must contain the buyer’s street name and number orP.O. box.Line 2An additional address line in a postal address that can be used to O 0 .. 1 cbc:AdditionalStreetNamegive further details supplementing the main line. Common useare secondary house number in a complex or in a building.An invoice may give an additional address line for buyer’saddress.City NameThe common name of the city where the postal address is. The M 1 .. 1 Bergen cbc:CityNamename is written in full rather than as a code.An invoice must contain the buyer’s city.Postal zoneThe identifier for an addressable group of properties according to M 1 .. 1 5000 cbc:PostalZonethe relevant national postal service, such as a ZIP code or PostCode.An invoice may contain the buyer’s post code.Country subdivisionFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.In some countries regions or other type of country sub divisionsare commonly used. An invoice may contain that information.Country Countrycode M 1 .. 1 cac:CountryCountry codeThe country where the address is. The country should always be M 1 .. 1 NO cbc:IdentificationCodegiven by using ISO code 3166 alpha 2The buyer’s address country must be given in an invoice in theform of a two letter code (ISO 3166-1 alpha-2).Tax scheme Tax scheme for the customer O 0 .. 1 cac:PartyTaxSchemeInvoice and Credit note July 5, 2013 Page 44 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementVAT registration numberAn invoice may contain the buyers VAT identifier In order tofacilitate reverse charge and intra community supply invoicing.The customers VAT-number (Norwegian MVA number) madeout of the organisational number and the letters MVA. Theattributes schemeID and schemeAgencyID must be «NO:VAT"and "82".M 0 .. 1 Domestic: 987654321MVA, cross-border trade:NO987654321MVAcbc:CompanyIDTax scheme Tax scheme M 1 .. 1 cac:TaxSchemeIdentifier VAT is the only legal code M 1 .. 1 cbc:IDLegal entity Assosiation to Party Legal Entity O 0 .. 1 cac:PartyLegalEntityLegal name The legal name of the customer M 1 .. 1 cbc:RegistrationNameCompanyIDAn invoice may contain the identifier assigned to the Party by M 1 .. 1 123456789 cbc:CompanyIDthe national company registrar.The organisation number. Attributes: schemeID="NO:ORGNR",schemeAgencyID="82".Address Adress for the legal entity O 0 .. 1 cac:RegistrationAddressCity The city of the legal address O 0 .. 1 Trondheim cbc:CityNameCountry Country code O 0 .. 1 cac:CountryCountry Country code of the legal address O 0 .. 1 NO cbc:IdentificationCodeContact The customers contact person M 1 .. 1 cac:ContactIdentifierWhen purchasing, a buyer may give a reference identifier to theseller and request the seller to state it on the invoice. Themeaning of the reference may have no relevance for the sellerand since it is issued by the buyer, who is the receiver of theinvoice. Consequently it does not have to be qualified.M 1 .. 1 3150xyz cbc:IDNameTelephoneTelefaxName or identifier specifying the customers reference (Egemployee number)The name of the contact person.An invoice may contain a person name for a relevant contact atthe buyer.A phone number for the contact person. If the person has a directnumber, this is that number.An invoice may contain the telephone number for a relevantcontact at the buyer.A fax number for the contact persons.An invoice may contain the tele-fax number for a relevantcontact at the buyer.O 0 .. 1 Phil Smith cbc:NameO 0 .. 1 +4732121200 cbc:TelephoneO 0 .. 1 +4712345679 cbc:TelefaxInvoice and Credit note July 5, 2013 Page 45 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementElectronic mailThe e-mail address for the contact person. If the person has a O 0 .. 1 customer.contact@buyingcompany.no cbc:ElectronicMaildirect e-mail this is that email.An invoice may contain an e-mail address for a relevant contactat the buyer.Payee An assosiation to the Payee O 0 .. 1 cac:PayeePartyIdentification Identification of the Payee O 0 .. 1 cac:PartyIdentificationPayee identifierUsed in absense of or in addition to the payee party name. Use M 1 .. 1 cbc:IDand identifier known to the document recipient.Name The name of the payee O 0 .. 1 cac:PartyNameName The neame of the payee party. M 1 .. 1 cbc:NameLegal entity Assosiation to Party Legal Entity O 0 .. 1 cac:PartyLegalEntityCompany IDAn invoice may contain the identifier assigned to the payee by M 1 .. 1 987654321 cbc:CompanyIDthe national company registrar.The organisation number. Attributes: schemeID="NO:ORGNR"and schemeAgencyID="82"Tax representative Information regarding the tax representative of the supplier O 0 .. 1 cac:TaxRepresentativePartyName Name of the tax reresentative M 1 .. 1 cac:PartyNameName The neame of the tax representative party. M 1 .. 1 cbc:NamePostal address The postal address of the tax representative O 0 .. 1 cac:PostalAddressLine 1The first line in the postal address of the tax representative, O 0 .. 1 cbc:StreetNamenormally streetname and numberLine 2 Additional address line O 0 .. 1 cbc:AdditionalStreetNameCity name The city name of the address O 0 .. 1 cbc:CityNamePostal zone The postal zone of the city O 0 .. 1 cbc:PostalZoneCountry subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.Country code Country code according to ISO 3361-1 M 1 .. 1 cac:CountryCountry code Country code based on ISO3166-1 M 1 .. 1 NO cbc:IdentificationCodeTax scheme Tax scheme for the tax representative O 0 .. 1 cac:PartyTaxSchemeVAT registration ID The tax representative party's VAT registration ID M 1 .. 1 981234567MVA cbc:CompanyIDTax scheme Tax scheme M 1 .. 1 cac:TaxSchemeIdentifier VAT is the only legal code M 1 .. 1 cbc:IDDelivery Delivery details M 1 .. 1 cac:DeliveryInvoice and Credit note July 5, 2013 Page 46 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementDelivery dateAn invoice may contain the actual delivery date on which goods M 1 .. 1 2013-06-15 cbc:ActualDeliveryDateor consignments are delivered from the seller. Also applicable forservice completion date.Delivery location Specification of where the goods or services were delivered M 1 .. 1 cac:DeliveryLocationLocation identifierAn invoice may contain an identifier for the location to which O 0 .. 1 cbc:IDthe items where delivered.Address Delivery address M 1 .. 1 cac:AddressLine 1The main address line in a postal address usually the street name O 0 .. 1 High street 123 cbc:StreetNameand number.An invoice may contain the address to which the items wheredelivered.Line 2An additional address line in a postal address that can be used to O 0 .. 1 cbc:AdditionalStreetNamegive further details supplementing the main line. Common useare secondary house number in a complex or in a building.An invoice may contain an additional address line in thedelivered to address.CityThe common name of the city where the postal address is. The M 1 .. 1 Trondheim cbc:CityNamename is written in full rather than as a code.An invoice may contain the name of the city to which the itemswhere delivered.Postal zoneThe identifier for an addressable group of properties according to M 1 .. 1 7000 cbc:PostalZonethe relevant national postal service, such as a ZIP code or PostCode.An invoice may contain the post code to which the items wheredelivered.Country subdivisionFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.In some countries regions or other type of country sub divisionsare commonly used. An invoice may contain the country subdivision to which the items where delivered.Country Country code M 1 .. 1 cac:CountryCountry codeThe country where the address is. The country should always be M 1 .. 1 NO cbc:IdentificationCodegiven by using ISO code 3166 alpha 2Since delivery country may affect VAT issues an invoice maycontain the country to which the items were delivered.Payment means Details regarding how the invoice will be payed M 1 .. unbounded cac:PaymentMeansPayment means codeAn invoice may contain an indication about how the paymentshould be handled.M 1 .. 1 CEFACT codelist 4461 is used - ListID = UN/ECE 4461. 31=debit transfercbc:PaymentMeansCodeInvoice and Credit note July 5, 2013 Page 47 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementDue datePayment IDAn invoice may contain the date on which payment is due.Latest date on which funds should have reached the accountreceivable.It must be possible to specify an identifier for the payment,issued by the seller as an invoice may contain an identifier forthe payment, issued by the seller as reference. Also known asend-to-end payment reference.M 1 .. 1 2013-07-20 cbc:PaymentDueDateR 0 .. 1 In Norway: KID number (customer identificationnumber)cbc:PaymentIDFinancial account Information regarding the payee's financial account M 1 .. 1 cac:PayeeFinancialAccountFinancial account IDThe identifier for the account. Depending on circumstances theidentifier can be in local format or standardized format such asIBAN. The identifier schema should be identified.To enable the buyer to issue a payment initiation to his bank theinvoice may contain the identifier for the financial account eitheras IBAN or in proprietary format.Attribute schemeID=IBAN or BBAN (ordinary bank accountnumber). BBAN is default, if schemeID is not presentM 1 .. 1 00050011111 cbc:IDFinancial Institution Branch The branch or department of the financial institution O 0 .. 1 cac:FinancialInstitutionBranchIDThe identifier for a branch or division of an organization may, insome countries, be used to positively identify the location of heaccount or supplement the financial institution identifier.The identifier for a branch or division of an organization may, insome countries, be used to positively identify the location of theaccount or supplement the financial institution identifier.M 1 .. 1 BIC (Swift code) cbc:IDFinancial institution The identifier of the financial institution (BIC) O 0 .. 1 cac:FinancialInstitutionInstitution IDAn identifier for the financial institution where the account is M 1 .. 1 cbc:IDlocated, such as the BIC identifier (SWIFT code).An invoice may contain the ISO 9362 BIC (Bank IdentificationCode) of a financial institution.Payment terms Description of payment terms O 0 .. unbounded cac:PaymentTermsPayment termsAn invoice may contain textual description of the payment terms M 0 .. 1 cbc:Notethat apply to the invoice due amount. E.g. penalty charges orintended collection procedures.Allowance Charge Description of allowances and charges on document level O 0 .. unbounded cac:AllowanceChargeAllowance/Charge indicator True = Charge, False = Allowance M 1 .. 1 cbc:ChargeIndicatorInvoice and Credit note July 5, 2013 Page 48 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementReason codeA coded specification of what the allowance or charge is.An invoice may contain a coded description of what is beingadded or deducted. E.g. „volume discount" or "packing charges",for each allowance or charge.Use codelist AllowanceChargeReasonCode, UN/ECE 4465,Version D08BO 0 .. 1 cbc:AllowanceChargeReasonCodeReasonA textual reason for the allowance or the charge. Can also be its R 0 .. 1 Freight charge cbc:AllowanceChargeReasonname.One textual description of what is being added or deducted. E.g.„volume discount" or "packing charges" must be stated for eachallowance and charge on document level in an invoice.AmountThe net amount of the allowance or the charge.M 1 .. 1 cbc:AmountFor each allowance or charge an invoice must contain theamount. Allowances are subtracted from the total invoice amountand charges are added to the amount. The amount is “net”without VAT.Tax category Specification av tax categories M 1 .. 1 cac:TaxCategoryVAT categoryA code that identifies to what VAT subcategory the allowance orcharge belongs to.An invoice may contain information about one VAT category foreach allowances and Charges on document level.M 1 .. 1 S (Standard = 25%), H (High = 15%) AA (Low= 8%), E (Exempt = 0%), Z (Null = 0%). Ref.chapter 6.5 for complete list of valid codes.Percent The VAT percentage that applies to the allowance/charge. O 0 .. 1 25 cbc:PercentTax scheme An assosiation to tax scheme (VAT) M 1 .. 1 cac:TaxSchemeIdentifier VAT is the only legal code M 1 .. 1 cbc:IDTax total Specification of tax total and tax per tax category M 1 .. unbounded cac:TaxTotalTotal VAT amountThe total VAT amount that is "added to the document total w/oVAT". This is the sum of all VAT subcategory amounts.An invoice may contain the total VAT amount. This amount isthe sum of each sub total for each VAT rate.An invoice may, in cases when invoices are issued in currenciesother than the national currency for VAT reporting, contain theVAT amount in the local currency.cbc:IDM 1 .. 1 cbc:TaxAmountTax subtotal Specification of tax subtotals M 1 .. unbounded cac:TaxSubtotalTaxable AmountThe amount that is the base for the VAT rate applied in thesubcategory.For each VAT category a invoice must contain the amount towhich VAT percent (rate) is applied to calculate the VAT subtotal amount for that category.M 1 .. 1 3400.25 cbc:TaxableAmountInvoice and Credit note July 5, 2013 Page 49 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementTax amountThe calculated amount of the tax derived by multiplying the M 1 .. 1 850.00 cbc:TaxAmounttaxable amount with the tax percentage.For each VAT category an invoice must contain the amount ofVAT for that category.Tax category Identification of tax category M 1 .. 1 cac:TaxCategoryIdentifierPercentA code that uniquelly identifies each subtotal within thetransaction.Each VAT category an invoice must be identified with a code.The tax rate that is to be applied to the taxable amount in orderto derive the tax amount.For each VAT category an invoice must contain the VATpercentage for each sub total taxable amount so that it can beused to calculate the VAT amount. Where VAT category code isstated then VAT category percentage must also be stated.M 1 .. 1 S (Standard = 25%), H (High = 15%) AA (Low= 8%), E (Exempt = 0%), Z (Null = 0%). Ref.chapter 6.5 for complete list of valid codes.cbc:IDM 1 .. 1 25 cbc:PercentVAT exemptionA textual description of the reason why the items belongin to the O 0 .. 1 cbc:TaxExemptionReasonsubtotal are exempted for VAT.An invoice may contain, as text, the reasons for why a valueamount in a category is exempted from VAT. Invoices onlysupport one category with an exemption reason pr. invoice.Tax scheme An assosiation to tax scheme (VAT) M 1 .. 1 cac:TaxSchemeIdentifier VAT is the only legal code M 1 .. 1 cbc:IDTotals Specifications of monetary totals M 1 .. 1 cac:LegalMonetaryTotalLine Extension AmountTax Exclusive AmountTax Inclusive AmountSum of line amounts in the document.An invoice must contain the sum of all line amounts. Theamount must be exclusive of VAT but inclusive of allowances orcharges applied to the lines as well as taxes, other than VAT.The "Sum of line amounts" plus "sum of allowances ondocument level" plus "sum of charges on document level".An invoice must contain the total amount of the invoice,including document level allowances and charges but exclusiveof VAT.The total value including VATAn invoice must contain the total amount of the invoiceinclusive VAT. I.e. the total value of the purchase irrespective ofpayment status.M 1 .. 1 400.00 cbc:LineExtensionAmountM 1 .. 1 400.00 cbc:TaxExclusiveAmountM 1 .. 1 5162.00 cbc:TaxInclusiveAmountInvoice and Credit note July 5, 2013 Page 50 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAllowance Total AmountCharge Total AmountPrepaid amountRounding amountAmount for paymentSum of all allowances on header level in the document.Allowances on line level are included in the line amount andsummed up into the "sum of line amounts"An invoice may contain the total amount of all allowances givenon document level. Line allowances are included in the net lineamount.Sum of all charge on header level in the document. Charges online level are included in the line amount and summed up intothe "sum of line amounts"An invoice may contain the total amount of all charges given ondocument level. Line charges are included in the net line amount.Any amounts that have been paid a-priory.An invoice may contain the sum of all prepaid amounts thatmust be deducted from the payment of this invoice. For fullypaid invoices (cash or card) this amount equals the invoice total.Any rounding of the "Document total including VAT"An invoice may contain the rounding amount (positive ornegative) added to the invoice to produce a rounded invoicetotal.The amount that is expected to be paid based on the document.This amount is the "Document total including VAT" less the"paid amounts" that have been paid a-priori.An invoice must contain the total amount to be paid that is due.If the invoice is fully paid i.e. cash or card, the due amount forthe invoice is zero.O 0 .. 1 cbc:AllowanceTotalAmountO 0 .. 1 cbc:ChargeTotalAmountO 0 .. 1 cbc:PrepaidAmountO 0 .. 1 cbc:PayableRoundingAmountM 1 .. 1 cbc:PayableAmountInvoice line An assosiation to one or more invoice lines M 1 .. unbounded cac:InvoiceLineLine identifierNoteInvoiced quantityEach line in an invoice must contain an identifier that is uniquewithin the document to make it possible to reference the line. Forexample, from other documents like credit notes and in disputes.Each line in an invoice may contain a free-form text. Thiselement may contain notes or any other similar information thatis not contained explicitly in another structure. Clauses ordeclarations that refer to a particular line should be entered infull as notes.Each line in an invoice must contain the invoiced quantity. Thequantity may be negative e.g. in case of returns.M 1 .. 1 1 cbc:IDO 0 .. 1 cbc:NoteM 1 .. 1 4 cbc:InvoicedQuantityInvoice and Credit note July 5, 2013 Page 51 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementLine amountEach line in an invoice must contain the total amount of the line.The amount is “net” without VAT, i.e. inclusive of line levelallowances and charges as well as relevant taxes, except VATwhich must be excluded from the amount.Line extension amount = Invoiced quantity * Unit Gross Price +Charges - Allowances. If applicable, allowances and chargesmust be provided.M 1 .. 1 250.67 cbc:LineExtensionAmountAccounting costAn invoice may contain a reference to the buyer's accounting R 0 .. 1 cbc:AccountingCostcode applicaple to the specific line, expressed as text rather thana code in order to facilitate automation in booking into accountsfollowing an order to invoice transformation.Period The period the invoice line covers O 0 .. 1 cac:InvoicePeriodStart dateThe date on which the period starts. The start dates counts aspart of the period.For invoices that charge for services or items delivered over atime period is necessary to be able to state the start date of theperiod for which the invoice relates such as for metered servicesand subscriptions.O 0 .. 1 2013-01-06 cbc:StartDateEnd dateThe date on which the period ends. The end date counts as part O 0 .. 1 2013-06-30 cbc:EndDateof the period.It must be possible to state the end date of the period for whichthe invoice relates such as for metered services andsubscriptions.Order Line Reference Refers to a single order line R 0 .. 1 cac:OrderLineReferenceOrder line referenceEach line in an invoice may contain a reference to the relevantorder line in the order that is identified on the document level inthe invoice.If the invoice contains several orders, the order reference is givenat the line level only. The order reference at line level must referto both the order and the actual orderline. The syntax forspecifying this should be agreed between the parties.Recommendation: Ordernumber##Order line numberM 1 .. 1 12 cbc:LineIDDelivery Delivery details O 0 .. 1 cac:DeliveryDelivery dateThe actual delivery date for the invoice goods/services on the M 1 .. 1 2013-06-15 cbc:ActualDeliveryDateinvoice lineDelivery location Information regarding the delivery location O 0 .. 1 cac:DeliveryLocationDelivery identifierA unique identifier (eg a GLN number) of where the goods isdeliveredO 0 .. 1 cbc:IDInvoice and Credit note July 5, 2013 Page 52 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAddress Delivery address O 0 .. 1 cac:AddressLine 1The address where the goods were deliverd, normally street name O 0 .. 1 cbc:StreetNamean building numberLine 2 Delivery address, additional line O 0 .. 1 cbc:AdditionalStreetNameCity Cityname O 0 .. 1 cbc:CityNamePostal zone The postal zone for the city O 0 .. 1 cbc:PostalZone0 .. 1 cbc:CountrySubentityCountry Country code M 1 .. 1 cac:CountryCountry code Country code based on ISO3166-1 M 1 .. 1 NO cbc:IdentificationCodeAllowance/Charge Allowances and charges related to line level O 0 .. unbounded cac:AllowanceChargeAllowance/Charge indicator True = Charge, False = Allowance M 1 .. 1 cbc:ChargeIndicatorReasonA textual reason for the allowance or the charge. Can also be its R 0 .. 1 Invoice charge cbc:AllowanceChargeReasonname.AmountThe net amount of the allowance or the charge exluding VAT. M 1 .. 1 cbc:AmountIn case of VAT, the same VAT scheme and rate has to apply toallowance/charge as to the invoice line item itself.Tax Tax amount O 0 .. 1 cac:TaxTotalAmountThe VAT amount for the invoice line. Calculated as a multiple of M 1 .. 1 cbc:TaxAmountline amount and line VAT rate. The VAT amount on line shouldonly be used informatively (i.e. not used as part validating theinvoice calculation of amounts) when required by nationallegislation.Item Information regarding the goods or services M 1 .. 1 cac:ItemDescriptionEach line in an invoice may contain attribute for the item. Forexample colour, size, meter numbers. This information supportsautomatically assigning accounting codes and matching to ordersand receiving documents.Description of additional data.Free-form field that can be used to give a text description the theitemO 0 .. unbounded cbc:DescriptionNameA short name for an item.M 1 .. 1 cbc:NameEach line in an invoice must contain the name of the invoiceditem.Sellers identification The sellers item number R 0 .. 1 cac:SellersItemIdentificationSellers identifierThe sellers identifier for the item.Each line in an invoice may contain the seller’s identifier for anitem.M 1 .. 1 cbc:IDInvoice and Credit note July 5, 2013 Page 53 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementStandard identification Identifies the product/service according to a standard system O 0 .. 1 cac:StandardItemIdentificationIdentifierA item identifier based on a registered schema.M 1 .. 1 cbc:IDEach line in an invoice may contain a registered item identifier.Origin Country Country code for the origin country of the goods O 0 .. 1 cac:OriginCountryCountry codeEach line in an invoice may contain the items country of origin. M 1 .. 1 DE cbc:IdentificationCodeWhen relevant this allows the buyer to identify whether furthercustoms procedures are required.Commodity classification Specification of commodity classification O 0 .. unbounded cac:CommodityClassificationClassification code The items CPV code M 1 .. 1 cbc:ItemClassificationCodeTax category Specifies the tax category for the goods/services M 1 .. 1 cac:ClassifiedTaxCategoryIdentifierEach line in an invoice may contain the VAT category/rate usedfor this invoice line. The category code acts as a key forsumming up line amounts pr. VAT category as well for relatingthe VAT category percentage given on document level, to theline. If the invoice is a VAT invoice each line must contain acategory code.M 1 .. 1 S (Standard = 25%), H (Higher = 15%) AA(Low = 8%), E (Excempt = 0%), Z (Null = 0%).Ref. chapter 6.5 for complete list of valid codes.PercentageThe VAT percentage rate that applies to the invoice line as O 0 .. 1 25 cbc:Percentwhole.Tax scheme Tax scheme specification M 1 .. 1 cac:TaxSchemeIdentifier Identifies the tax scheme (VAT) M 1 .. 1 cbc:IDAdditional properties Specify additional item properties O 0 .. unbounded cac:AdditionalItemPropertyName Property name M 1 .. 1 Weight, color cbc:NameValue Property value O 0 .. 1 12.5, blue cbc:ValueManufacturer Manufacturer party O 0 .. 1 cac:ManufacturerPartyName Name of manufacturer M 1 .. 1 cac:PartyNameName Name of manufacturer M 1 .. 1 cbc:NameLegal entity The manufacturer's legal entity O 0 .. 1 cac:PartyLegalEntityCompany ID The legal company ID of the manufacturer O 0 .. 1 cbc:CompanyIDPrice Price information M 1 .. 1 cac:PricePriceEach line in an invoice may contain the net price of the itemincluding all allowances or charges that directly relates to price(e.g. discount), and taxes but excluding VAT.The net price of an item including discounts or surcharges thatapply to the price.cbc:IDM 1 .. 1 123.45 cbc:PriceAmountInvoice and Credit note July 5, 2013 Page 54 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementBase quantityThe number of invoiced quantity units for which the price is O 0 .. 1 10 cbc:BaseQuantitystated. E.g. Invoiced quantity is 1000 LTR, price is €15 pr. 10LTR. The price base quantity must be stated in the same unit ofmeasure as the invoiced quantity.Allowance Charge Allowance and charge related to price O 0 .. unbounded cac:AllowanceChargeAllowance/Charge indicator True = Charge, False = Allowance M 1 .. 1 cbc:ChargeIndicatorReason Description of the allowance/charge R 0 .. 1 cbc:AllowanceChargeReasonMultiplier Allowance or charge percentage O 0 .. 1 cbc:MultiplierFactorNumericAmountThe total discount subtracted from the gross price to reach the M 1 .. 1 cbc:Amountnet price.Each line in an invoice may contain the amount of the pricediscount. The price discount amount is informative.List priceThe gross price of the item before subtracting discounts. E.g. listprice.Each line in an invoice may contain the list price for the item(e.g. catalogue price before discount)O 0 .. 1 cbc:BaseAmountInvoice and Credit note July 5, 2013 Page 55 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.07.2 EHF CREDIT NOTE INFORMATION CONTENTSName Description Req Max rep Example XML elementEHF CreditNote 2.0 .. CreditNoteUBL version Indicated the version of UBL the message is based on M 1 .. 1 2.1 cbc:UBLVersionIDCustomization identifierIdentifies the specification of content and rules that apply to thetransaction.Identifying the customization/implementation guide/contextualization of the syntax message and its extension thatapplies to the credit note transaction, enables the receiver toapply the correct validation to the received document as well asto route the document to an appropriate service for processing.M 1 .. 1 urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0 or urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0cbc:CustomizationIDProfile identifierCreditnote identifierCreditnote dateNoteCurrency codeAccounting stringIdentifies the BII profile or business process context in which thetransaction appears.Identifying the profile or business process context in which thetransaction appears enables the buyer to direct the message to anappropriate service as well as controlling its relation to otherdocuments exchanged as part of the same process.The profile identifier must be one of the profiles in the example.An credit note instance must contain an identifier. An credit noteidentifier enables positive referencing the document instance forvarious purposes including referencing between documents thatare part of the same process.The issue date of an credit note is required by EU directives aswell as country laws. A credit note must therefore contain thedate on which it was issued.The textual note provides the seller a means for providingunstructured information that is relevant to the credit note. Thiscan be notes or other similar information that is not containedexplicitly in another qualified element. Information given in astextual notes is mainly intended for manual processing. When“clauses” or “declarations” are used they should be stated in fullin the note element.The currency in which the monetary amounts are stated must bestated in the credit note.According to EU Directive a currency code from ISO 4217 mustbe supplied for all monetary amountsThe credit note may contain a reference to the buyer's accountingcode applied to the credit note as a whole, expressed as textrather than a code in order to facilitate automation in bookinginto accounts following an order to credit note transformation.M 1 .. 1 urn:www.cenbii.eu:profile:biixx:ver2.0, urn:www.cenbii.eu:profile:bii05:ver2.0, urn:www.cenbii.eu:profile:bii06:ver2.0 or urn:www.cenbii.eu:profile:biixy:ver2.0cbc:ProfileIDM 1 .. 1 654321 cbc:IDM 1 .. 1 2013-06-15 cbc:IssueDateO 0 .. unbounded cbc:NoteM 1 .. 1 NOK cbc:DocumentCurrencyCodeR 0 .. 1 cbc:AccountingCostInvoice and Credit note July 5, 2013 Page 56 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementCreditNote periode The period which the creditnote covers O 0 .. 1 cac:InvoicePeriodStart dateThe date on which the period starts. The start dates counts aspart of the period.For credit notes that charge for services or items delivered over atime period is necessary to be able to state the start date of theperiod for which the credit note relates such as for meteredservices and subscriptions.O 0 .. 1 2013-06-01 cbc:StartDateEnd datoThe date on which the period ends. The end date counts as part O 0 .. 1 2013-06-30 cbc:EndDateof the period.It must be possible to state the end date of the period for whichthe credit note relates such as for metered services andsubscriptions.Billing referenceA reference to the invoice which is the basis for thisM 1 .. 1 cac:BillingReferencecreditnoteInvoice Invoice identifier M 1 .. 1 cac:InvoiceDocumentReferenceDocument identifierThe identifier of the reference document.M 1 .. 1 cbc:IDDependent on the profileID. Is this urn:www.cenbii.eu:profile:biixx:ver2.0 (CreditNote only), the element is NOT Mandatoryotherwise the element is Mandatory.Contract Reference to contract or framework agreement R 0 .. 1 cac:ContractDocumentReferenceIdentifierContract typePositive identification of the reference such as a uniqueidentifier.To positively identify relevant contractual issues the credit notemay contain an identifier of a contract that applies to the creditnote.A credit note may contain the type of contract that is referred to(such as framework agreement) in a coded way to enableautomated processing based on the contract type.M 1 .. 1 cbc:IDO 0 .. 1 Codelist from BII: 1=Public contract,2=Establishment of a Framework agreement,3=Setting up a Dynamic Purchasing System,4=Public contract based on a Frameworkagreement, 5=Publiv contract based on aDynamic Purchasing Systemcbc:DocumentTypeCodeDocument typeThe short description of what is reference such as contract type, O 0 .. 1 Framework agreement cbc:DocumentTypedocument type , meter etc.A credit note may contain the type of contract that is referred to(such as framework agreement)Additional Document Reference Reference to additional documents O 0 .. unbounded cac:AdditionalDocumentReferenceDocument identifier An identifier for the referenced document. M 1 .. 1 cbc:IDDescription A short description of the document type. O 0 .. 1 cbc:DocumentTypeInvoice and Credit note July 5, 2013 Page 57 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAttachmentReference to attached document, externally referred to, O 0 .. 1 cac:Attachmentreferred to in the MIME location or embeddedEmbedded binary objectThe attached document embeded as binary object.A credit note may contain an attached electronic document as anO 0 .. 1 cbc:EmbeddedDocumentBinaryObjectencoded object in the credit note in order to provide supportingdocuments such as timesheets, usages reports etc. The seller canonly expect the receiver to process attachments according to rule.External reference An attached document O 0 .. 1 cac:ExternalReferenceExternal referenceThe Uniform Resource Identifier (URI) that identifies where the O 0 .. 1 cbc:URIexternal document is located.SupplierOrganisation or person responsible som delivering the goods M 1 .. 1 cac:AccountingSupplierPartyand servicesSupplier An assosiation to Party M 1 .. 1 cac:PartyElectronic addressA credit notee may contain the sellers electronic address. The R 0 .. 1 123456789 cbc:EndpointIDaddress can be of any format and the format should be identifiedin the message.Identification An assosiation to Party Identifiaction O 0 .. 1 cac:PartyIdentificationIdentifierA credit note may contain a registered identifier for the seller. M 1 .. 1 cbc:IDInformation referenced by the identifier is not considered part ofthe message (i.e. the buyer is not required to look up theidentifier in the relevant registry and process additionalinformation)Supplier Name Name of supplier M 1 .. 1 cac:PartyNameName A credit note must contain the name of the seller. M 1 .. 1 cbc:NameAddress The suppliers address M 1 .. 1 cac:PostalAddressLine 1Line 2CityThe main address line in a postal address usually the street nameand number.A credit note must contain the seller’s street name and number orP.O.box.An additional address line in a postal address that can be used togive further details supplementing the main line. Common useare secondary house number in a complex or in a building.A credit note may contain an additional address line for selleraddress.The common name of the city where the postal address is. Thename is written in full rather than as a code.A credit note must contain the seller’s city.O 0 .. 1 Bond street 34 cbc:StreetNameO 0 .. 1 cbc:AdditionalStreetNameM 1 .. 1 Oslo cbc:CityNameInvoice and Credit note July 5, 2013 Page 58 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementPost codeThe identifier for an addressable group of properties according to M 1 .. 1 5010 cbc:PostalZonethe relevant national postal service, such as a ZIP code or PostCode.A credit note may contain the seller’s post code.Country subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.In some countries regions or other type of country sub divisionsare commonly used. A credit note may contain that information.Country Country code M 1 .. 1 cac:CountryCountry codeThe country where the address is. The country should always be M 1 .. 1 NO cbc:IdentificationCodegiven by using ISO code 3166 alpha 2The seller’s address country must be contained in a credit note inthe form of a two letter code (ISO 3166-1 alpha-2).Tax Scheme Tax scheme for the supplier O 0 .. 1 cac:PartyTaxSchemeVAT registration numberWhen the credit note is a VAT credit note it must state the sellersVAT registration number and tax scheme.The supplier's VAT-number (Norwegian MVA number) madeout of the organisational number and the letters MVA. Theattributes schemeID and schemeAgencyID must be «NO:VAT»and «82» respectively. Mandatory if the supplier is taxable.M 1 .. 1 Domestic: 987654321MVA, cross-border trade:NO987654321MVAcbc:CompanyIDTax scheme Tax scheme M 1 .. 1 cac:TaxSchemeIdentifier Code for TaxScheme. VAT is the only legal value M 1 .. 1 VAT cbc:IDLegal entity Assosiation to Party Legal Entity M 1 .. 1 cac:PartyLegalEntityRegistration name The name under which the seller is legally registered. M 1 .. 1 Any supplier name cbc:RegistrationNameCompany IDA credit note may contain the identifier assigned to the party bythe national company registrar.The supplying organisations legal organisation number. Fornorwegian suppliers: Attributes: schemeID="NO:ORGNR",schemeName="Foretaksregisteret" for companies AS, ASA andNUF, but is recommended for all companies registered in"Foretaksregisteret".schemeAgencyID="82"M 1 .. 1 987654321 cbc:CompanyIDContact The suppliers contact person R 0 .. 1 cac:ContactIdentifier The supplier's reference specified as "Our ref." R 0 .. 1 cbc:IDNameThe name of the contact person.A credit note may contain a person name for a relevant contact atthe seller.O 0 .. 1 John Doe cbc:NameInvoice and Credit note July 5, 2013 Page 59 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementTelephoneA phone number for the contact person. If the person has a direct R 0 .. 1 +4712345678 cbc:Telephonenumber, this is that number.A credit note may contain a telephone number for a relevantcontact at the seller.TelefaxA fax number for the contact persons.O 0 .. 1 +4792612346 cbc:TelefaxA credit note may contain a tele-fax number for a relevantcontact at the seller.Electronic mailThe e-mail address for the contact person. If the person has a R 0 .. 1 supplier.contact@supplyingcompany.no cbc:ElectronicMaildirect e-mail this is that email.A credit note may contain a telephone number for a relevantcontact at the seller.Customer Customer party M 1 .. 1 cac:AccountingCustomerPartyParty An assosiation to party M 1 .. 1 cac:PartyEndpointIDA credit note may contain the buyers electronic address. Theaddress can be of any format and the format should be identifiedin the message.Electronic addresses for Norwegian actors using the PEPPOLtransport infrastructure shall be specified as NorwegianOrganization Number. with "NO:ORGNR" as attributeschemeID.R 0 .. 1 998876543 cbc:EndpointIDIdentification An assosiation to Party Identifiaction O 0 .. 1 cac:PartyIdentificationCustomer identifiactionA credit note may contain a registered identifier for the buyer. M 1 .. 1 cbc:IDInformation referenced by the identifier is not considered part ofthe message (i.e. The buyer is not required to look up theidentifier in the relevant registry and process additionalinformation)Customer name Name of customer M 1 .. 1 cac:PartyNameName A Credit note must contain name of the buyer. M 1 .. 1 cbc:NameAddress The address of the customer M 1 .. 1 cac:PostalAddressLine 1Line 2The main address line in a postal address usually the street nameand number.A credit note must contain the buyer’s street name and numberor P.O. box.An additional address line in a postal address that can be used togive further details supplementing the main line. Common useare secondary house number in a complex or in a building.A credit note may give an additional address line for buyer’saddress.O 0 .. 1 Baker street 13 cbc:StreetNameO 0 .. 1 cbc:AdditionalStreetNameInvoice and Credit note July 5, 2013 Page 60 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementCity NameThe common name of the city where the postal address is. The M 1 .. 1 Bergen cbc:CityNamename is written in full rather than as a code.A credit note must contain the buyer’s city.Postal zoneThe identifier for an addressable group of properties according to M 1 .. 1 5000 cbc:PostalZonethe relevant national postal service, such as a ZIP code or PostCode.A credit note may contain the buyer’s post code.Country subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.In some countries regions or other type of country sub divisionsare commonly used. A credit note may contain that information.Country Country code M 1 .. 1 cac:CountryCountry codeThe country where the address is. The country should always be M 1 .. 1 NO cbc:IdentificationCodegiven by using ISO code 3166 alpha 2The buyer’s address country must be given in a credit note in theform of a two letter code (ISO 3166-1 alpha-2).Tax scheme Tax scheme for the customer O 0 .. 1 cac:PartyTaxSchemeVAT registration numberA credit note may contain the buyers VAT identifier In order tofacilitate reverse charge and intra community supply billing.The customers VAT-number (Norwegian MVA number) madeout of the organisational number and the letters MVA. Theattributes schemeID and schemeAgencyID must be «NO:VAT"and "82".M 1 .. 1 Domestic: 987654321MVA, cross-border trade:NO987654321MVAcbc:CompanyIDTax scheme Tax scheme M 1 .. 1 cac:TaxSchemeIdentifier Code for TaxScheme. VAT is the only legal value M 1 .. 1 VAT cbc:IDLegal entity Assosiation to Party Legal Entity M 1 .. 1 cac:PartyLegalEntityLegal name The legal name of the customer M 1 .. 1 cbc:RegistrationNameCompanyIDA credit note may contain the identifier assigned to the Party by R 1 .. 1 123456789 cbc:CompanyIDthe national company registrar.The organisation number. Attributes: schemeID="NO:ORGNR",schemeAgencyID="82".Contact The customers contact person M 1 .. 1 cac:ContactIdentifierNameName or identifier specifying the customers reference (Egemployee number)M 1 .. 1 3150xyz cbc:IDThe name of the contact person.O 0 .. 1 Phil Smith cbc:NameA credit note may contain a person name for a relevant contact atthe buyer.Invoice and Credit note July 5, 2013 Page 61 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementTelephoneA phone number for the contact person. If the person has a direct O 0 .. 1 +4732121200 cbc:Telephonenumber, this is that number.A credit note may contain the telephone number for a relevantcontact at the buyer.TelefaxA fax number for the contact persons.O 0 .. 1 +4712345679 cbc:TelefaxA credit note may contain the tele-fax number for a relevantcontact at the buyer.Electronic mailThe e-mail address for the contact person. If the person has a O 0 .. 1 customer.contact@buyingcompany.no cbc:ElectronicMaildirect e-mail this is that email.A credit note may contain an e-mail address for a relevantcontact at the buyer.Payee An assosiation to the Payee O 0 .. 1 cac:PayeePartyIdentification Identification of the Payee O 0 .. 1 cac:PartyIdentificationPayee identifierUsed in absense of or in addition to the payee party name. Use M 1 .. 1 cbc:IDand identifier known to the document recipient.Name The name of the payee O 0 .. 1 cac:PartyNameName The neame of the payee party. M 1 .. 1 cbc:NameLegal entity Assosiation to Party Legal Entity O 0 .. 1 cac:PartyLegalEntityCompany IDAn credit note may contain the identifier assigned to the payee M 1 .. 1 987654321 cbc:CompanyIDby the national company registrar.The organisation number. Attributes: schemeID="NO:ORGNR"and schemeAgencyID="82"Tax representative Information regarding the tax representative of the supplier O 0 .. 1 cac:TaxRepresentativePartyName Name of the tax representative O 0 .. 1 cac:PartyNameName The neame of the tax representative party. M 1 .. 1 cbc:NameAddress The tax representatived address O 0 .. 1 cac:PostalAddressLine 1The first line in the postal address of the tax representative, O 0 .. 1 cbc:StreetNamenormally streetname and numberLine 2 Additional address line O 0 .. 1 cbc:AdditionalStreetNameCity name The city name of the address O 0 .. 1 cbc:CityNamePostal zone The postal zone of the city O 0 .. 1 cbc:PostalZoneCountry subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.Country Country code O 0 .. 1 cac:CountryCountry code Country code based on ISO3166-1 O 0 .. 1 NO cbc:IdentificationCodeTax scheme Tax scheme for the tax representative O 1 .. 1 cac:PartyTaxSchemeInvoice and Credit note July 5, 2013 Page 62 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementVAT registration ID The tax representative party's VAT registration ID M 1 .. 1 981234567MVA cbc:CompanyIDTax scheme Tax scheme M 1 .. 1 cac:TaxSchemeIdentifier Code for TaxScheme. VAT is the only legal value M 1 .. 1 VAT cbc:IDDelivery Delivery details O 0 .. 1 cac:DeliveryDelivery date The actual delivery date for the invoice goods/services M 1 .. 1 2013-06-15 cbc:ActualDeliveryDateDelivery location Specification of where the goods or services were delivered M 1 .. 1 cac:DeliveryLocationDelivery identifierA unique identifier (eg a GLN number) of where the goods is O 0 .. 1 cbc:IDdeliveredAddress Delivery address M 1 .. 1 cac:AddressLine 1The address where the goods were deliverd, normally street name O 0 .. 1 cbc:StreetNamean building numberLine 2 Delivery address, additional line O 0 .. 1 cbc:AdditionalStreetNameCity Cityname M 1 .. 1 cbc:CityNamePostal zone The postal zone for the city M 1 .. 1 cbc:PostalZoneCountry subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.Country Country code M 1 .. 1 cac:CountryCountry code Country code based on ISO3166-1 M 1 .. 1 NO cbc:IdentificationCodePayment means Details regarding how payments will be made O 0 .. unbounded cac:PaymentMeansPayment means code En kode som identifiserer hvordan betalingen blir foretatt. M 1 .. 1 CEFACT codelist 4461 is used - ListID = UN/ cbc:PaymentMeansCodeECE 4461. 31=debit transferDue dateLatest date on which funds should have reached the account O 0 .. 1 2013-07-20 cbc:PaymentDueDatereceivable.Payment ID In Norway: KID number (customer identification number) O 0 .. 1 1234561 cbc:PaymentIDFinancial account Information regarding the payee's financial account O 0 .. 1 cac:PayeeFinancialAccountFinancial account IDThe identifier for the account. Depending on circumstances the M 1 .. 1 00050011111 cbc:IDidentifier can be in local format or standardized format such asIBAN. The identifier schema should be identified. AttributeschemeID=IBAN or BBAN (ordinary bank account number).BBAN is default, if schemeID is not presentFinancial Institution Branch The branch or department of the financial institution O 0 .. 1 cac:FinancialInstitutionBranchIDThe identifier for a branch or division of an organization may, in M 1 .. 1 BIC (Swift code) cbc:IDsome countries, be used to positively identify the location of heaccount or supplement the financial institution identifier.Financial institution The identifier of the financial institution (BIC) O 0 .. 1 cac:FinancialInstitutionInvoice and Credit note July 5, 2013 Page 63 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementInstitution IDAn identifier for the financial institution where the account is O 0 .. 1 cbc:IDlocated, such as the BIC identifier (SWIFT code).Allowance Charge Description of allowances and charges on document level O 0 .. unbounded cac:AllowanceChargeAllowance/Charge indicator True = Charge, False = Allowance M 1 .. 1 cbc:ChargeIndicatorReason codeA coded specification of what the allowance or charge is.A credit note may contain a coded description of what is beingadded or deducted. E.g. „volume discount" or "packing charges",for each allowance or charge.Use codelist AllowanceChargeReasonCode, UN/ECE 4465,Version D08BO 0 .. 1 cbc:AllowanceChargeReasonCodeReasonA textual reason for the allowance or the charge. Can also be its R 0 .. 1 Freight charge cbc:AllowanceChargeReasonname.One textual description of what is being added or deducted. E.g.„volume discount" or "packing charges" must be stated for eachallowance and charge on document level in a credit note.AmountThe net amount of the allowance or the charge.M 1 .. 1 cbc:AmountFor each allowance or charge a credit note must contain theamount. Allowances are subtracted from the total credit noteamount and charges are added to the amount. The amount is“net” without VAT.Tax category Specification av tax categories M 1 .. 1 cac:TaxCategoryVAT categoryA code that identifies to what VAT subcategory the allowance orcharge belongs to.A credit note may contain information about one VAT categoryfor each allowances and Charges on document level.M 1 .. 1 S (Standard = 25%), H (High = 15%) AA (Low= 8%), E (Exempt = 0%), Z (Null = 0%). Ref.chapter 6.5 for complete list of codes.Percent The VAT percentage rate that applies to the allowance/charge O 0 .. 1 25 cbc:PercentTax scheme An assosiation to tax scheme (VAT) M 1 .. 1 cac:TaxSchemeIdentifier Code for TaxScheme. VAT is the only legal value M 1 .. 1 VAT cbc:IDTax total Specification of tax total and tax per tax category M 1 .. unbounded cac:TaxTotalTotal VAT amountA credit note may, in cases when credit note are issued incurrencies other than the national currency for VAT reporting,contain the VAT amount in the local currency.The total VAT amount that is "added to the document total w/oVAT". This is the sum of all VAT subcategory amounts.A credit note may contain the total VAT amount. This amount isthe sum of each sub total for each VAT rate.Must equal the sum of VAT amount per VAT subcategory.Must be rounded, 2 decimal places.cbc:IDM 1 .. 1 cbc:TaxAmountInvoice and Credit note July 5, 2013 Page 64 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementTax subtotal Specification of tax subtotals M 1 .. unbounded cac:TaxSubtotalTaxable AmountThe amount that is the base for the VAT rate applied in thesubcategory.For each VAT category a credit note must contain the amount towhich VAT percent (rate) is applied to calculate the VAT subtotal amount for that category.The basis for calculating the VAT for one tax rate. The basisshould equal the sum of the line amounts for this tax rate + thesum of charges on the header level for this tax rate - the sum ofallowences on the header level for this tax rate. Must be roundedto 2 decimal places.M 1 .. 1 3400.25 cbc:TaxableAmountTax amountThe calculated amount of the tax derived by multiplying the M 1 .. 1 850.00 cbc:TaxAmounttaxable amount with the tax percentage.For each VAT category a credit note must contain the amount ofVAT for that category.Must be rounded to 2 decimal places.Tax category Identification of tax category M 1 .. 1 cac:TaxCategoryIdentifierPercentA code that uniquelly identifies each subtotal within thetransaction.Each VAT category a credit note must be identified with a code.The tax rate that is to be applied to the taxable amount in orderto derive the tax amount.For each VAT category a credit note must contain the VATpercentage for each sub total taxable amount so that it can beused to calculate the VAT amount. Where VAT category code isstated then VAT category percentage must also be stated.M 1 .. 1 S (Standard = 25%), H (High = 15%) AA (Low= 8%), E (Exempt = 0%), Z (Null = 0%). Ref.chapter 6.5 for complete list of codes.cbc:IDM 1 .. 1 25 cbc:PercentVAT ExemptionA textual description of the reason why the items belongin to the O 0 .. 1 cbc:TaxExemptionReasonsubtotal are exempted for VAT.A credit note may contain, as text, the reasons for why a valueamount in a category is exempted from VAT. credit note onlysupport one category with an exemption reason pr. credit note.Tax scheme An assosiation to tax scheme (VAT) M 1 .. 1 cac:TaxSchemeIdentifier Code for TaxScheme. VAT is the only legal value M 1 .. 1 VAT cbc:IDTotals Specifications of monetary totals M 1 .. 1 cac:LegalMonetaryTotalInvoice and Credit note July 5, 2013 Page 65 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementLine Extension AmountTax Exclusive AmountTax Inclusive AmountAllowance Total AmountCharge Total AmountPrepaid amountRounding amountSum of line amounts in the document.A credit note must contain the sum of all line amounts. Theamount must be exclusive of VAT but inclusive of allowances orcharges applied to the lines as well as taxes, other than VAT.Must equal the sum of LineExtensionAmount on all linesThe "Sum of line amounts" plus "sum of allowances ondocument level" plus "sum of charges on document level".A credit note must contain the total amount of the credit note,including document level allowances and charges but exclusiveof VAT.Must equal the sum of line amounts + sum of charges - sum ofallowances on document levelThe total value including VATA credit note must contain the total amount of the credit noteinclusive VAT. I.e. the total value of the purchase irrespective ofpayment status.Sum of all allowances on header level in the document.Allowances on line level are included in the line amount andsummed up into the "sum of line amounts"A credit note may contain the total amount of all allowancesgiven on document level. Line allowances are included in the netline amount.Must be rounded, 2 decimal placesSum of all charge on header level in the document. Charges online level are included in the line amount and summed up intothe "sum of line amounts"A credit note may contain the total amount of all charges givenon document level. Line charges are included in the net lineamount.Must be rounded, 2 decimal placesAny amounts that have been paid a-priory.A credit note may contain the sum of all prepaid amounts thatmust be deducted from the payment of this credit note. For fullypaid credit note (cash or card) this amount equals the credit notetotal.Any rounding of the "Document total including VAT"A credit note may contain the rounding amount (positive ornegative) added to the credit note to produce a rounded creditnote total.Must be rounded, 2 decimal placesM 1 .. 1 400.00 cbc:LineExtensionAmountM 1 .. 1 400.00 cbc:TaxExclusiveAmountM 1 .. 1 5162.00 cbc:TaxInclusiveAmountO 0 .. 1 cbc:AllowanceTotalAmountO 0 .. 1 cbc:ChargeTotalAmountO 0 .. 1 cbc:PrepaidAmountO 0 .. 1 cbc:PayableRoundingAmountInvoice and Credit note July 5, 2013 Page 66 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAmount for paymentThe amount that is expected to be paid based on the document.This amount is the "Document total including VAT" less the"paid amounts" that have been paid a-priori.A credit note must contain the total amount to be paid that isdue. If the credit note is fully paid i.e. cash or card, the dueamount for the credit note is zero.M 1 .. 1 cbc:PayableAmountCreditnote line An assosiation to one or more creditnote lines M 1 .. unbounded cac:CreditNoteLineLine identifierNoteCredited quantityLine amountEach line in a credit note must contain an identifier that isunique within the document to make it possible to reference theline. For example, from other documents like credit notes and indisputes.Each line in a credit notee may contain a free-form text. Thiselement may contain notes or any other similar information thatis not contained explicitly in another structure. Clauses ordeclarations that refer to a particular line should be entered infull as notes.Each line in a credit note must contain the credited quantity. Thequantity may be negative in cases when the credit note is used toreverse an invoice line that was negative.Each line in a credit note must contain the total amount of theline. The amount is “net” without VAT, i.e. inclusive of linelevel allowances and charges as well as relevant taxes, exceptVAT which must be excluded from the amount.Must equal price * quantity -/+ AllowanceCharge on line level.Must be rounded to 2 decimal places. Note that price * antalland AllowanceCharge must be rounded separately.M 1 .. 1 1 cbc:IDO 0 .. unbounded cbc:NoteM 1 .. 1 4 cbc:CreditedQuantityM 1 .. 1 250.67 cbc:LineExtensionAmountAccounting costThe credit note may contain a reference to the buyer's accounting R 0 .. 1 cbc:AccountingCostcode applicaple to the specific line, expressed as text rather thana code in order to facilitate automation in booking into accountsfollowing an order to credit note transformation.Period The period the creditnote line covers O 0 .. 1 cac:InvoicePeriodStart dateThe date on which the period starts. The start dates counts as O 0 .. 1 2013-01-06 cbc:StartDatepart of the period.End dateThe date on which the period ends. The end date counts as part O 0 .. 1 2013-06-30 cbc:EndDateof the period.Order Line Reference Refers to a single order line R 0 .. 1 cac:OrderLineReferenceInvoice and Credit note July 5, 2013 Page 67 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementOrder line referenceEach line in a credit note may contain a reference to the relevantorder line in the order that is identified on the document level inthe credit note.If the creditnote contains several orders, the order reference isgiven at the line level only. The order reference at line levelmust refer to both the order and the actual orderline. The syntaxfor specifying this should be agreed between the parties.Recommendation: Ordernumber##Order line numberM 1 .. 1 12 cbc:LineIDBilling reference Reference to the invoice O 0 .. unbounded cac:BillingReferenceInvoice document referenceReference to the invoice which is the basis for this invoice M 1 .. 1 cac:InvoiceDocumentReferencelineInvoice document reference Invoice document reference M 1 .. 1 cbc:IDBilling reference line Reference to the invoice line O 0 .. unbounded cac:BillingReferenceLineInvoice line referenceEach line in credit note may contain a reference to the relevant M 1 .. 1 cbc:IDinvoice line in the original invoice that is being credited.Delivery Delivery details O 0 .. 1 cac:DeliveryDelivery date The actual delivery date for the invoice goods/services M 1 .. 1 2013-06-15 cbc:ActualDeliveryDateDelivery location Information regarding the delivery location O 0 .. 1 cac:DeliveryLocationDelivery identifierA unique identifier (eg a GLN number) of where the goods is O 0 .. 1 cbc:IDdeliveredAddress Delivery address O 0 .. 1 cac:AddressLine 1The address where the goods were deliverd, normally street name O 0 .. 1 cbc:StreetNamean building numberLine 2 Delivery address, additional line O 0 .. 1 cbc:AdditionalStreetNameCity Cityname M 0 .. 1 cbc:CityNamePostal zone The postal zone for the city M 0 .. 1 cbc:PostalZoneCountry subentityFor specifying a region, county, state, province etc. within a O 0 .. 1 cbc:CountrySubentitycountry by using text.Country Country code O 0 .. 1 cac:CountryCountry code Country code based on ISO3166-1 M 1 .. 1 NO cbc:IdentificationCodeTax Tax amount O 0 .. 1 cac:TaxTotalAmountThe VAT amount for the credit note line. Calculated as a M 1 .. 1 cbc:TaxAmountmultiple of line amount and line VAT rate. The VAT amount online should only be used informatively (i.e. not used as partvalidating the credit note calculation of amounts) when requiredby national legislation.Allowance/Charge Allowances and charges related to line level O 0 .. unbounded cac:AllowanceChargeInvoice and Credit note July 5, 2013 Page 68 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementAllowance/Charge indicator True = Charge, False = Allowance M 1 .. 1 cbc:ChargeIndicatorReasonA textual reason for the allowance or the charge. Can also be its R 0 .. 1 cbc:AllowanceChargeReasonname.Amount The net amount of the allowance or the charge exluding VAT. M 1 .. 1 cbc:AmountItem Information regarding the goods or services M 1 .. 1 cac:ItemDescriptionEach line in a credit note may contain attribute for the item. Forexample colour, size, meter numbers. This information supportsautomatically assigning accounting codes and matching to ordersand receiving documents.Description of additional data.Description of the goods/servicesO 0 .. 1 cbc:DescriptionNameA short name for an item.M 1 .. 1 cbc:NameEach line in a credit note must contain the name of the crediteditem.Length should be less than 50 charactersSellers identification The sellers item number R 0 .. 1 cac:SellersItemIdentificationSellers identifierThe sellers identifier for the item.M 1 .. 1 cbc:IDEach line in a credit note may contain the seller’s identifier foran item.Standard identification Identifies the product/service according to a standard system O 0 .. 1 cac:StandardItemIdentificationIdentifierA item identifier based on a registered schema.M 1 .. 1 cbc:IDEach line in a credit note may contain a registered itemidentifier.Origin Country Country code for the origin country of the goods O 0 .. 1 cac:OriginCountryCountry codeEach line in a credit note may contain the items country of O 0 .. 1 DE cbc:IdentificationCodeorigin. When relevant this allows the buyer to identify whetherfurther customs procedures are required.Commodity classification Specification of commodity classification O 0 .. unbounded cac:CommodityClassificationClassification code The items CPV code M 1 .. 1 cbc:ItemClassificationCodeTax category Specifies the tax category for the goods/services M 1 .. 1 cac:ClassifiedTaxCategoryIdentifierEach line in a credit note may contain the VAT category/rateused for this credit note line. The category code acts as a key forsumming up line amounts pr. VAT category as well for relatingthe VAT category percentage given on document level, to theline. If the credit note is a VAT credit note each line mustcontain a category code.M 1 .. 1 S (Standard = 25%), H (Higher = 15%) AA(Low = 8%), E (Excempt = 0%), Z (Null = 0%).Ref. chapter 6.5 for complete list of codes.cbc:IDInvoice and Credit note July 5, 2013 Page 69 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Name Description Req Max rep Example XML elementPercentageThe VAT percentage rate that applies to the credit note line as O 0 .. 1 25 cbc:Percentwhole.Tax scheme Tax scheme specification M 1 .. 1 cac:TaxSchemeIdentifier Code for TaxScheme. VAT is the only legal value M 1 .. 1 VAT cbc:IDAdditional properties Specify additional item properties O 0 .. unbounded cac:AdditionalItemPropertyName Property name M 1 .. 1 Weight, color cbc:NameValue Property value O 0 .. 1 12.5, blue cbc:ValueManufacturer Manufacturer party O 0 .. 1 cac:ManufacturerPartyName Name of manufacturer O 0 .. 1 cac:PartyNameName Name of manufacturer M 1 .. 1 cbc:NameLegal entity The manufacturer's legal entity O 0 .. 1 cac:PartyLegalEntityCompany ID The legal company ID of the manufacturer M 1 .. 1 cbc:CompanyIDPrice Price information M 1 .. 1 cac:PricePriceEach line in a credit note may contain the net price of the itemincluding all allowances or charges that directly relates to price(e.g. discount), and taxes but excluding VAT.The net price of an item including discounts or surcharges thatapply to the price.Must not be negative. Max 4 decimals.M 1 .. 1 123.45 cbc:PriceAmountBase quantityThe number of credit note quantity units for which the price is O 0 .. 1 10 cbc:BaseQuantitystated. E.g. credited quantity is 1000 LTR, price is €15 pr. 10LTR. Price base quantity must be given in the same unit ofmeasure as the credited quantity.Allowance Charge Allowance and charge related to price O 0 .. unbounded cac:AllowanceChargeAllowance/Charge indicator True = Charge, False = Allowance M 1 .. 1 cbc:ChargeIndicatorReason Description of the allowance/charge R 0 .. 1 cbc:AllowanceChargeReasonMultiplier Allowance or charge percentage O 0 .. 1 cbc:MultiplierFactorNumericAmountThe total discount subtracted from the gross price to reach the M 1 .. 1 cbc:Amountnet price.Each line in a credit note may contain the amount of the pricediscount. The price discount amount is informative.List priceThe gross price of the item before subtracting discounts. E.g. listprice.Each line in a credit note may contain the gross price, e.g. Listprice for the item.O 0 .. 1 cbc:BaseAmountInvoice and Credit note July 5, 2013 Page 70 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.08 VALIDATIONTo optimize the flexibility in the validation process, each EHF document is validated in different stages with shiftingfocus in every stage. The pyramid below illustrates the different stages.7.Companyrules6. Trade rulesEHF5. Norwegian publicrequirements4. Norwegian accountinglegislationSchematronCEN BIIPEPPOLHF3. PEPPOL2. CEN BII Core1. Technical structureXMLSchema8.1 VALIDATION PRINCIPLESStages in the validation process:1. Validation of syntax against UBL 2.1 Schema, for example: Tag names and attributes must be correctly written and follow the UBL 2.1 sequence All UBL 2.1 mandatory tag names must be present. The element’s contents must be according to the element’s type definition.2. Validation against CEN BII Core to verify that the message is according to international requirements, like: Valid codes for currencies, countries, tax etc. Mandatory tag names according to CEN BII Core. Logical correlations between information element, i.e. that start date is at least lower than end date,sub totals must be totaled, multiplications give the correct result etc.3. Validation against PEPPOL (EU) rules and regulations4. Validation against Norwegian accounting legislation, like:Invoice and Credit note July 5, 2013 Page 71 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Organisation number must be specified for the seller/supplier.5. Validation against Norwegian public requirements, like: «Your ref» must be specified. Addresses, postal zone number and post office/city must be specified for the buyer/customer.Validation stage 6 and 7 is decided upon by the trading parties if deemed necessary.8.2 DYNAMIC VALIDATIONThe combination of ProfileID and CustomizationID in an XML document defines the validation rules applied to thedocument.CustomizationID may be extended with more elements for specific trade or business validation rules.Invoice and Credit note July 5, 2013 Page 72 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.08.3 VALIDATION RULES PER PROFILEID AND CUSTOMIZATIONIDThe tables below show the validation rules for ProfileID and CustomizationID . The specific validation rules are described in Chapter 8.4.8.3.1 PROFILEID BII04, INVOICE ONLYDocument Norwegian Norwegian Profile ID Customization ID Validation rulesreceiver senderInvoice Yes Yes urn:www.cenbii.eu:profile:bii04:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0:extended:XSD validates against Invoice schemaBII, PEPPOL, Norwegianurn:www.difi.no:ehf:faktura:ver2.0Invoice Yes No urn:www.cenbii.eu:profile:bii04:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0XSD validates against Invoice schemaBII, PEPPOLInvoice No Yes urn:www.cenbii.eu:profile:bii04:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0XSD validates against Invoice schemaBII, PEPPOL8.3.2 PROFILEID BIIXX, CREDIT NOTE ONLYDocument Norwegian Norwegian Profile ID Customization ID Validation rulesreceiver senderCredit note Yes Yes urn:www.cenbii.eu:profile:biixx:ver2.0 urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.cenbii.eu:profile:biixx:ver2.0:extended:urn:www.difi.no:ehf:kreditnota:ver2.0XSD validates against CreditNoteschemaBII, PEPPOL, Norwegian8.3.3 PROFILEID BII05, INVOICE AND CREDIT NOTEDocument Norwegian Norwegian Profile ID Customization ID Validation rulesreceiver senderInvoice Yes Yes urn:www.cenbii.eu:profile:bii05:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:XSD validates against Invoice schemaBII, PEPPOL, Norwegianurn:www.difi.no:ehf:faktura:ver2.0Invoice Yes No urn:www.cenbii.eu:profile:bii05:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0XSD validates against Invoice schemaBII, PEPPOLInvoice No Yes urn:www.cenbii.eu:profile:bii05:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:# XSD validates against Invoice schemaInvoice and Credit note July 5, 2013 Page 73 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0DocumentNorwegianreceiverNorwegiansenderProfile ID Customization ID Validation rulesurn:www.peppol.eu:bis:peppol5a:ver2.0BII, PEPPOLCredit note Yes Yes urn:www.cenbii.eu:profile:bii05:ver2.0 urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:kreditnota:ver2.0Credit note Yes No urn:www.cenbii.eu:profile:bii05:ver2.0 urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0Credit note No Yes urn:www.cenbii.eu:profile:bii05:ver2.0 urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0XSD validates against CreditNoteschemaBII, PEPPOL, NorwegianXSD validates against CreditNoteschemaBII, PEPPOLXSD validates against CreditNoteschemaBII, PEPPOL8.3.4 PROFILEID BIIXY, INVOICE, CREDIT NOTE AND REMINDERDocument Norwegian Norwegian Profile ID Customization ID Validation rulesreceiver senderInvoice Yes Yes urn:www.cenbii.eu:profile:biixy:ver2.0 urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.cenbii.eu:profile.eu:biixy:ver2.0:extended:XSD validates against Invoice schemaBII, PEPPOL, Norwegianurn:www.difi.no:ehf:faktura:ver2.0Credit note Yes Yes urn:www.cenbii.eu:profile:biixy:ver2.0 urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.cenbii.eu:profile:biixy:ver2.0:extended:urn:www.difi.no:ehf:kreditnota:ver2.0XSD validates against CreditNoteschemaBII, PEPPOL, NorwegianReminder Yes Yes urn:www.cenbii.eu:profile:biixy:ver2.0 urn:www.cenbii.eu:transaction:biicoretrdm017:ver1.0:#urn:www.cenbii.eu:profile:biixy:ver1.0#urn:www.difi.no:ehf:purring:ver1XSD validates against ReminderschemaBII, PEPPOL, NorwegianInvoice and Credit note July 5, 2013 Page 74 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.08.4 VALIDATION RULESThe 2 tables below show the validation rules that apply to the invoice and the credit note.Description of the table columns: Element The data element that the rule applies to. Rule Business rule description. Message Each rule has its own message. E/W Severity. E=Error, the document is rejected. W=Warning, the document should be passed on. RuleID Identification of validation stage: BII CEN BII EU PEPPOL PCL Rules related to PEPPOL code lists NONAT Norwegian accounting legislation NOGOV Norwegian public requirements CL Rules related to general code lists8.4.1 INVOICEElement Rule Message E/W Rule IDMonetaryTotal/PayableAmountCould be negative.The element must be presentTotal payable amount on an invoice could benegative.An invoice MUST specify the total payable amount.WEEUGEN-T10-R019BIIRULE-T10-R038Must equal the sum of total amountexcl. VAT, total VAT and payablerounding amount.Invoice due is the tax inclusive amount minus whathas been prepaid.MonetaryTotal/TaxInclusiveAmount Could be negative. Tax inclusive amount in an invoice could benegative.EWBIIRULE-T10-R017BIIRULE-T10-R014Invoice and Credit note July 5, 2013 Page 75 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDMonetaryTotal/TaxExclusiveAmountMonetaryTotal/LineExtensionAmountMonetaryTotal/AllowanceTotalAmountMonetaryTotal/ChargeTotalAmountThe element must be presentMust equal the sum of total amountexcl. VAT, total VAT and payablerounding amount.The element must be present.Must equal the sum of the lineamounts plus the allowances andcharges on header level.The element must be present.Must equal the sum of the lineamounts.Must equal the sum of all allowanceson the header level.Must equal the sum of all charges onthe header levelAn invoice MUST specify the total amount withtaxes included.Invoice tax inclusive amount MUST equal the taxexclusive amount plus all the tax total amounts andthe rounding amount.An invoice MUST specify the total amount withouttaxes.Invoice tax exclusive amount MUST equal the sumof lines plus allowances and charges on headerlevel.An invoice MUST specify the sum of line amounts.Invoice total line extension amount MUST equalthe sum of the line totals.Total allowances MUST be equal to the sum ofallowances at document level.Total charges MUST be equal to the sum of chargesat document level.EEEEEEEEBIIRULE-T10-R039BIIRULE-T10-R013BIIRULE-T10-R042BIIRULE-T10-R012BIIRULE-T10-R043BIIRULE-T10-R011BIIRULE-T10-R015BIIRULE-T10-R016TaxTotal/Taxsubtotal The element must be present. An invoice MUST have a tax total referring to a E BIIRULE-T10-R009single tax scheme.TaxTotal The element must be present. An invoice MUST contain tax information. E BIIRULE-T10-R052TaxTotal/TaxAmountMust equal the sum of VAT amountsfor all VAT categories.Each tax total MUST equal the sum of the taxsubcategory amounts.TaxSubTotal/TaxableAmountThe element must be present. An invoice MUST specify the taxable amount perVAT subtotal.Must equal the TaxExclusiveAmount If the VAT total amount in an invoice exists thenthe sum of taxable amount in sub categories MUSTequal the sum of invoice tax exclusive amount.TaxSubTotal/TaxAmount The element must be present. An invoice MUST specify the tax amount per VATsubtotal.EEEEBIIRULE-T10-R010BIIRULE-T10-R046BIIRULE-T10-R028BIIRULE-T10-R047Invoice and Credit note July 5, 2013 Page 76 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDTaxSubTotal/TaxCategoryIdentifier The element must be present. Every tax category MUST be defined through an E BIIRULE-T10-R048identifier.TaxSubTotal/TaxSchemeIdentifier The element must be present. Every tax scheme MUST be defined through an E BIIRULE-T10-R049identifier.TaxSubTotal/TaxCategory/Percent The element must be present. For each tax subcategory the category ID and the E EUGEN-T10-R008applicable percentage MUST be provided.TaxSubTotal/TaxCategory/TaxThe exemption reason code should be If the category for VAT is exempt E) then the W EUGEN-T10-R009ExemptionReasonCodespecified.exemption reason SHOULD be provided.AllowanceCharge/Amount Must not be negative. An allowance or charge amount MUST NOT be E EUGEN-T10-R022negative.AllowanceCharge/ReasonText Should be specified. AllowanceChargeReason text SHOULD be specified W EUGEN-T10-R023for all allowances and charges.InvoiceLine/Price/AllowanceCharge/ Must not be negative. An allowance percentage MUSTNOT be negative. E BIIRULE-T10-R022MultiplierFactorNumericInvoiceLine/Price/AllowanceCharge/ Both or none should be specified. In allowances, both or none of percentage and W EUGEN-T10-R013MultiplierFactorNumericbase amount SHOULD be provided.InvoiceLine/ LineExtensionAmount The element must be present. Invoice lines MUST have a line total amount. E BIIRULE-T10-R050InvoiceLine/Price/PriceAmountMUST be equal to the price amountmultiplied by the quantity pluscharges minus allowances at the linelevel.The element must be present.Must not be negative..Invoice line amount MUST be equal to the priceamount multiplied by the quantity plus chargesminus allowances at the line level.Invoice lines MUST contain the item price.Prices of items MUST NOT be negative.EEEBIIRULE-T10-R018BIIRULE-T10-R051EUGEN-T10-R012UBLversionIdentifier The element must be present. An invoice MUST have a syntax identifier. E BIIRULE-T10-R029CustomizationID The element must be present. An invoice MUST have a customization identifier. E BIIRULE-T10-R030ProfileIDThe element must be present.Must be either:urn:www.cenbii.eu:profile:bii04:ver2.0An invoice MUST have a profile identifier.An invoice transaction must only be used inProfiles 4, 5, 6 or xy.E BIIRULE-T10-R031BIIPROFILE-T10-R001Invoice and Credit note July 5, 2013 Page 77 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDurn:www.cenbii.eu:profile:bii05:ver2.0urn:www.cenbii.eu:profile:bii06:ver2.0urn:www.cenbii.eu:profile:biixy:ver2.0ID The element must be present. An invoice MUST have an invoice number. E BIIRULE-T10-R024IssueDate The element must be present. An invoice MUST have the date of issue. E BIIRULE-T10-R024DocumentCurrencyCode The element must be present. An invoice MUST have a currency code for thedocument.E BIIRULE-T10-R034InvoicePeriod/StartDateInvoicePeriod/EndDateOrderReference/IDThe element must be present ifInvoicePeriod is present.Start date must be less than or equalto the end date.The element must be present ifInvoicePeriod is present.End date must be greater than orequal to the start date.The element must be present ifOrderReference is present.If the invoice refers to a period, the period MUSThave a start date.If the invoice refers to a period, the period MUSThave an end date.An invoice period end date MUST be later or equalto an invoice period start date.Any reference to an order MUST specify the orderidentifier.EEEEEUGEN-T10-R020EUGEN-T10-R021BIIRULE-T10-R001BIIRULE-T10-R035If profile isurn:www.cenbii.eu:profile:bii06:ver1.0the order number must be specified.An invoice transaction T10 in Profile 6 MUST havean order reference identifier.EBIIPROFILE-T10-R002ContractDocumentReference/IDAdditionalDocumentReference/IDThe element should be specifiedThe element must be present ifContractDocumentReference ispresent.The element should be specified.The element must be present ifAdditionalDocumentReference isAn association to Order Reference SHOULD beprovided according to EHF.Any reference to a contract MUST specify thecontract identifier.Contract Document Reference SHOULD beprovided according to EHF.Any reference to a document MUST specify thedocument identifier.EEWENOGOV-T10-R013BIIRULE-T10-R036NOGOV-T10-R005BIIRULE-T10-R037Invoice and Credit note July 5, 2013 Page 78 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDAccountingSupplierParty/Party/PartyName/NameAccountingSupplierParty/Party/PartyLegalEntity/CompanyIDAccountingSupplierParty/Party/PartyLegalEntity/RegistrationNameAccountingSupplierParty/Party/PartyTaxScheme/CompanyIDAccountingSupplierParty/Party/Contact/IDAccountingSupplierParty/Party/PostalAddress/ID, CityName, PostalZone, City, Countrypresent.The element must be present.The element must be present.The element must be present.The element must be present if totalamount incl. VAT is present.If cross border trade the elementshould be prefixed «NO»The element should be present.The element must be present.An invoice MUST contain the full name of thesupplier.The Norwegian legal registration ID for the supplierMUST be provided according to “FOR 2004-12-01nr 1558 - § 5-1-1. Point 2”The Norwegian legal registration name for thesupplier MUST be provided according to “FOR2004-12-01 nr 1558 - § 5-1-1. Point 2”If the VAT total amount in an invoice exists it MUSTcontain the suppliers VAT number.In cross border trade the VAT identifier for thesupplier SHOULD be prefixed by country code.A contact reference identifier SHOULD be providedfor AccountingSupplierParty according to EHF.A supplier postal address MUST contain at leastcity name zip code and country code.EEWEWWEBIIRULE-T10-R026NONAT-T10-R001NONAT-T10-R008EUGEN-T10-R007BIIRULE-T10-R003NOGOV-T10-R001NONAT-T10-R006EUGEN-T10-R001BIIRULE-T10-R002AccountingCustomerParty/Party/PartyName/NameAccountingCustomerParty/Party/PartyLegalEntity/CompanyIDAccountingCustomerParty/Party/PartyLegalEntity/RegistrationNameAccountingCustomerParty/Party/Contact/IDAccountingCustomerParty/Party/PostalAddress/ID, CityName, PostalZone, City, CountryThe element must be present.The element must be present exceptwhen consumer is invoiced (B2C).The element should be present exceptwhen consumer is invoiced (B2C).The element must be present.The element must be present.An invoice MUST contain the full name of thecustomer.PartyLegalEntity for AccountingCustomerPartyMUST be provided according to EHF.Registration name for AccountingCustomerPartyMUST be provided according to EHF.A contact reference identifier MUST be providedfor AccountingCustomerParty according to EHF.A customer postal address MUST contain at leastcity name, zip code and country code.EEWEEBIIRULE-T10-R027NOGOV-T10-R009NOGOV-T10-R015NOGOV-T10-R007NONAT-T10-R007EUGEN-T10-R002BIIRULE-T10-R004Invoice and Credit note July 5, 2013 Page 79 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDAccountingCustomerParty/Party/PartyIdentification/IDThe element should be present. A customer number for AccountingCustomerPartySHOULD be provided according to EHF.PayeeParty/Party Name/NameThe element must be present if If payee information is provided then the payeePayeeParty is present.name MUST be specified.Delivery/ActualDeliveryDate The element must be present The actual delivery date MUST be provided in theinvoice according to "FOR 2004-12-01 nr 1558 - §5-1-1. Point 4".Delivery/DeliveryLocation/Address/CityName, PostalZone, CountryPaymentMeans/PaymentMeansCodePaymentMeans/PayeeFinancialAccount/IDPaymentMeans/PayeeFinancialAccount/ID, SchemeID =IBANPaymentMeans/PayeeFinancialAccount/FinancialInstitution Branch/FinancialInstitution/IDPaymentMeans/PaymentDueDateThe elements must be present.The element must be present.If payment means code is 31 (Debit),the account number must be present.The element should contain the BICcode (Bank Identification Code)The element must be present andshould be greater than or equal to theinvoice date.A Delivery address in an invoice MUST contain atleast, city, zip code and country code according to"FOR 2004-12-01 nr 1558 - § 5-1-1. Point 4".When specifying payment means, the invoiceMUST specify the payment means code.If payment means is funds transfer, invoice MUSThave a financial account.PayeeFinancialAccount MUST be providedaccording to EHF.If bank account is IBAN the bank identifier SHOULDalso be provided.If the payment means are international accounttransfer and the account id is IBAN then thefinancial institution should be identified by usingthe BIC id.-If FinancialAccountID is IBAN then FinancialInstitutionID SHOULD be BIC code.Payment due date MUST be provided in the invoiceaccording to "FOR 2004-12-01 nr 1558 - § 5-1-1.Point 5".Payment means due date in an invoice SHOULD belater or equal than issue date.PaymentMeans/PaymentID The element should be specified. Payment Identifier KID number) SHOULD be usedaccording to EHF.WEEEEWEWWNOGOV-T10-R006EUGEN-T10-R010NONAT-T10-R003NONAT-T10-R004BIIRULE-T10-R044BIIRULE-T10-R007NOGOV-T10-R011BIIRULE-T10-R008EUGEN-T10-R004PCL-010-002BIIRULE-T10-R006NONAT-T10-R002NOGOV-T10-R012Invoice and Credit note July 5, 2013 Page 80 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDInvoiceLine The element must be present. An invoice MUST specify at least one line item. E BIIRULE-T10-R033InvoiceLine/Item/NameThe element must be present.Should not be more than 50Each invoice line MUST contain the product/servicename.Product names SHOULD NOT exceed 50 charactersEWBIIRULE-T10-R025BIIRULE-T10-R019characters.long.InvoiceLine/ID The element must be present. Invoice lines MUST have a line identifier. E BIIRULE-T10-R032InvoiceLine/Item/SellersItemThe element should be specified. The sellers ID for the item SHOULD be provided W NOGOV-T10-R002Identification/IDaccording to EHF.InvoiceLine/InvoicedQuantity The element must be present. Each invoice line MUST contain a quantityE NONAT-T10-R005according to "FOR 2004-12-01 nr 1558 - § 5-1-1.Point 3"InvoiceLine/InvoicedQuantity, attributeUnitCodeAttributes should be specified. The unit qualifier of the invoiced quantity SHOULDbe provided according to EHF.W NOGOV-T10-R010Each invoice line SHOULD contain the quantity andunit of measure.InvoiceLine/Item/StandardItemIf the element is present the attribute If standard identifiers are provided within an itemIdentification/IDSchemeID must also be present. description, a Scheme Identifier SHOULD beprovided e.g. GTIN)Standard item identifiers SHOULD be GTIN.InvoiceLine/Item/CommodityIf the element is present the attribute Classification codes within an item descriptionClassification/ItemClassificationCode SchemeID must also be present. SHOULD use a standard scheme for codes e.g. CPVor UNSPSC)Commodity classification SHOULD be one ofUNSPSC, eClass or CPV.InvoiceLine/AccountingCost The element should be present. The buyer's accounting code applied to the InvoiceLine SHOULD be provided according to EHF.InvoiceLine/OrderLineReference/LineID The element should be present. An association to Order Line Reference SHOULD beprovided according to EHF.WWWWWEUGEN-T10-R003BIIRULE-T10-R020PCL-010-005BIIRULE-T10-R021PCL-010-006NOGOV-T10-R003NOGOV-T10-R004Invoice and Credit note July 5, 2013 Page 81 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDValidation of codesInvoiceTypeCode Must be 380 (ordinary invoice) or 393(factoring invoice).DocumentCurrencyMust be a valid code from ISO codeCodelist 4217.Country/IdentificationCodeMust be a valid code from ISO codelist 3166-1.TaxSchemeMust be a valid code from code listUN/ECE 5153.PaymentMeansMust be a valid code from CEFACTcode list 4461.TaxCategory Must be one of the following codes: S,H, AA, E, Z, R eller K.InvoiceTypeCode in an invoice MUST be 380 fromUN/ECE 1001 code listDocumentCurrencyCode MUST be coded using ISOcode list 4217.CurrencyID MUST be coded using ISO code list4217.Country codes in an invoice MUST be coded usingISO code list 3166-1.Invoice tax schemes MUST be coded using UN/ECE5153 code list-Payment means in an invoice MUST be coded usingCEFACT code list 4461.Invoice tax categories MUST be one of thefollowing codes: S, H, AA, E, Z, R or K.EEEEEECL-010-001CL-010-002CL-010-003CL-010-004CL-010-005CL-010-006CL-010-0078.4.2 CREDIT NOTEElement Rule Message E/W Rule IDMonetaryTotal/PayableAmountCould be negative.The element must be present.Must equal the sum of totalamount excl. VAT, total VATamount and payable roundingamount.Total payable amount in a credit note MUST NOTbe negative.A Credit Note MUST specify the total payableamount.Amount due is the tax inclusive amount minuswhat has been prepaid.MonetaryTotal/TaxInclusiveAmount Must not be negative. Tax inclusive amount in a credit note MUST NOTbe negative.WEEWEUGEN-T14-R019BIIRULE-T14-R037BIIRULE-T14-R017BIIRULE-T14-R014Invoice and Credit note July 5, 2013 Page 82 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDMonetaryTotal/TaxExclusiveAmountMonetaryTotal/LineExtensionAmountThe element must be present.Must equal the sum of totalamount excl. VAT, total VATamount and payable roundingamount.The element must be present.Must equal the sum of the lineamounts and allowances andcharges on the header level.The element must be present.Must equal the sum of lineamounts.A Credit Note MUST specify the total amountwith taxes included.A credit note tax inclusive amount MUST equalthe tax exclusive amount plus all the tax totalamounts and the rounding amount.A Credit Note MUST specify the total amountwithout taxes.A credit note tax exclusive amount MUST equalthe sum of lines plus allowances and charges onheader level.A Credit Note MUST specify the sum of lineamounts.Credit note total line extension amount MUSTequal the sum of the line totals.Total allowances MUST be equal to the sum ofallowances at document level.Total charges MUST be equal to the sum ofcharges at document level.EEEEEEBIIRULE-T14-R038BIIRULE-T14-R013BIIRULE-T14-R040BIIRULE-T14-R012BIIRULE-T14-R041BIIRULE-T14-R011MonetaryTotal/AllowanceTotalAmount Must equal the sum of allallowances on the header level.E BIIRULE-T14-R015MonetaryTotal/ChargeTotalAmount Must equal the sum of all chargesE BIIRULE-T14-R016on the header level.TaxTotal/Taxsubtotal The element must be present. A credit note MUST have a tax total referring to a E BIIRULE-T14-R009single tax scheme.TaxTotal The element must be present. A credit note MUST contain tax information. E BIIRULE-T14-R052TaxTotal/TaxAmountTaxSubTotal/TaxableAmountMust equal the sum of the VATamount for all the VAT categories.The element must be present.The sum of all taxable amountsmust equal the total amount excl.VAT.Each tax total MUST equal the sum of the taxsubcategory amounts.A credit note MUST specify the taxable amountper VAT subtotal.If the VAT total amount in a Credit Note existsthen the sum of taxable amount in sub categoriesMUST equal the sum of credit note tax exclusiveamount.EEEBIIRULE-T14-R010BIIRULE-T14-R043BIIRULE-T14-R030Invoice and Credit note July 5, 2013 Page 83 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDTaxSubTotal/TaxAmount The element must be present. A credit note MUST specify the tax amount per E BIIRULE-T14-R047VAT subtotal.TaxSubTotal/TaxCategoryIdentifier The element must be present. Every tax category MUST be defined through an E BIIRULE-T14-R045identifier.TaxSubTotal/TaxSchemeIdentifier The element must be present. Every tax scheme MUST be defined through an E BIIRULE-T14-R046identifier.TaxSubTotal/TaxCategory/TaxThe exempt reason code should be If the category for VAT is exempt E) then the W EUGEN-T14-R013ExemptionReasonCodespecified.exemption reason SHOULD be provided.AllowanceCharge/Amount Must not be negative. An allowance or charge amount MUST NOT be E EUGEN-T14-R022negative.AllowanceCharge/ReasonText Should be specified. AllowanceChargeReason text SHOULD be W EUGEN-T14-R023specified for all allowances and charges.CreditNoteLine/Price/AllowanceCharge/ Must not be negative. An allowance percentage MUST NOT be negative. E BIIRULE-T14-R023MultiplierFactorNumericCreditNoteLine/LineExtensionAmount The element must be present. Credit note lines MUST have a line total amount. E BIIRULE-T14-R050Must equal the item pricemultiplied by the quantity pluscharges minus allowances; all onthe line level.Credit note line amount MUST be equal to theprice amount multiplied by the quantity pluscharges minus allowances at the line level.EBIIRULE-T14-R018CreditNoteLine/Price/PriceAmount The element must be present. Credit note line MUST contain the item price. E BIIRULE-T14-R051UBLversionIdentifier The element must be present. A Credit Note MUST have a syntax identifier. E BIIRULE-T14-R031CustomizationID The element must be present. A Credit Note MUST have a customization E BIIRULE-T14-R032identifier.ProfileIDThe element must be present.Must be eitherurn:www.cenbii.eu:profile:bii05:ver2.0urn:www.cenbii.eu:profile:bii06:ver2.0A Credit Note MUST have a profile identifier.A Credit Note transaction T14 must only be usedin Profiles 5, 6, xx or xy.E BIIRULE-T14-R033BIIPROFILE-T14-R001Invoice and Credit note July 5, 2013 Page 84 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDurn:www.cenbii.eu:profile:biixx:ver2.0urn:www.cenbii.eu:profile:biixy:ver2.0ID The element must be present. A Credit Note MUST have a Credit Note number. E BIIRULE-T14-R026IssueDate The element must be present. A Credit Note MUST have the date of issue. E BIIRULE-T14-R025DocumentCurrencyCode The element must be present. A Credit Note MUST specify the currency code forthe document.E BIIRULE-T14-R036InvoicePeriod/StartDateInvoicePeriod/EndDateBillingReference/InvoiceDocumentReference/IDBillingReference/CreditNoteDocumentReference/IDAccountingSupplierParty/Party/PartyName/NameAccountingSupplierParty/Party/PartyLegalEntity/CompanyID(AccountingSupplierParty/Party/PartyLegalEntity/RegistrationNameAccountingSupplierParty/Party/PartyTaxScheme/CompanyIDThe element must be present ifInvoicePeriod is present.Start date must be less than orequal to the end date.The element must be present ifInvoicePeriod is present.End date must be greater than orequal to the start date.The element must be specified ifthe profile is noturn:www.cenbii.eu:profile:biixx:ver2.0The element must be present.The element must be present.The element must be present.The element must be present iftotal VAT amount is specified.If cross border trade, prefix withIf the credit note refers to a period, the periodMUST have a start date.If the credit note refers to a period, the periodMUST have an end date.An invoice period end date MUST be later orequal to an invoice period start date.A credit note transaction T14 in Profile other thanxx MUST have an invoice or credit note referenceidentifier.A Credit Note MUST contain the full name of thesupplier.PartyLegalEntity for AccountingSupplierPartyMUST be provided according to “FOR 2004-12-01nr 1558 - § 5-1-1. Point 2”The Norwegian legal registration name for thesupplier SHOULD be provided according to “FOR2004-12-01 nr 1558 - § 5-1-1. Point 2”If the VAT total amount in a credit note exists itMUST contain the suppliers VAT number.In cross border trade the VAT identifier for theEEEEEEEEFEWEUGEN-T14-R020EUGEN-T14-R021BIIRULE-T14-R001BIIPROFILE-T14-R002BIIRULE-T14-R028NONAT-T14-R001NONAT-T14-R006EUGEN-T14-R007BIIRULE-T14-R003Invoice and Credit note July 5, 2013 Page 85 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDNO.supplier SHOULD be prefixed by country code.AccountingSupplierParty/Party/Contact/ID The element should be specified. A contact reference identifier SHOULD beprovided for AccountingSupplierParty accordingto EHF.AccountingSupplierParty/Party/The element must be specified. A supplier postal address MUST contain at leastPostalAddress/city name zip code and country code.ID, CityName, PostalZone, City, CountryWENOGOV-T14-R001NONAT-T14-R003EUGEN-T14-R001BIIRULE-T14-R002AccountingCustomerParty/Party/PartyName/NameAccountingCustomerParty/Party/PartyLegalEntity/RegistrationNameAccountingCustomerParty/Party/PartyLegalEntity/CompanyIDAccountingCustomerParty/Party/Contact/IDAccountingCustomerParty/Party/PostalAddress/ID, CityName, PostalZone, City, CountryAccountingCustomerParty/Party/PartyIdentification/IDThe element must be present.The element must be present.The element must be present.The element must be present.The element must be specified.The element should be specified.A Credit Note MUST contain the full name of thecustomer.Registration name for AccountingCustomer PartyMUST be provided according to EHF.PartyLegalEntity for AccountingCustomerPartyMUST be provided according to EHF.A contact reference identifier MUST be providedfor AccountingCustomerParty according to EHF.A customer postal address MUST contain at leastcity name, zip code and country code.A customer number forAccountingCustomerParty SHOULD be providedaccording to EHF.EFEEEWBIIRULE-T14-R029NOGOV-T14-R008NOGOV-T14-R004NOGOV-T14-R007NONAT-T14-R007EUGEN-T14-R002BIIRULE-T14-R004NOGOV-T14-R006CreditNoteLine The element must be present. A Credit Note MUST specify at least one line item. E BIIRULE-T14-R035CreditNoteLine/Item/NameThe element must be present.Should not be more than 50Each credit note line MUST contain theproduct/service name.Product names SHOULD NOT exceed 50EWBIIRULE-T14-R027BIIRULE-T14-R019characters.characters long.CreditNoteLine/ID The element must be present. Credit note lines MUST have a line identifier. E BIIRULE-T14-R034CreditNoteLine/Item/SellersItem The element should be specified. The sellers ID for the item SHOULD be provided W NOGOV-T14-R002Invoice and Credit note July 5, 2013 Page 86 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDIdentification/IDaccording to EHF.CreditNoteLine/CreditedQuantity The element must be present. Each credit note line MUST contain a quantityaccording to "FOR 2004-12-01 nr 1558 - § 5-1-1.Point 3"CreditNoteLine/CreditedQuantity, attribute The attribute should be specified. The unit qualifier of the Credit note quantityUnitCodeSHOULD be provided according to EHF.EWNONAT-T14-R002NOGOV-T14-R003CreditNoteLine/Item/StandardItemIdentification/IDCreditNoteLine/Item/CommodityClassification/ItemClassificationCodeCreditNoteLine/Item/ClassifiedTaxCategory/PercentIf the element is specified, theattribute SchemeID should also bespecified.If the element is specified, theattribute SchemeID should also bespecified.The element must be present.Each credit note line SHOULD contain thequantity and unit of measure.If standard identifiers are provided within an itemdescription, a Scheme Identifier SHOULD beprovided e.g. GTIN)Standard item identifiers SHOULD be GTIN.Classification codes within an item descriptionSHOULD use a standard scheme for codes e.g.CPV or UNSPSC)Commodity classification SHOULD be one ofUNSPSC, eClass or CPV.The item's tax rate, expressed as a percentageMUST be provided according to EHF.Commodity classification SHOULD be one ofUNSPSC, eClass or CPV.WWWEEUGEN-T14-R003BIIRULE-T14-R020PCL-014-005BIIRULE-T14-R021NOGOV-T14-R08PCL-014-006DocumentCurrencyCodeMust be a valid code from ISOcode list 4217.DocumentCurrencyCode MUST be coded usingISO code list 4217.CurrencyID MUST be coded using ISO code list4217.Country codes in a credit note MUST be codedusing ISO code list 3166-1.ECL-014-001CL-014-002Country codeMust be a valid code from ISO codeE CL-014-003list 3166-1.TaxScheme Must be a valid code from code list Credit Note tax schemes MUST be coded using E CL-014-004Invoice and Credit note July 5, 2013 Page 87 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.0Element Rule Message E/W Rule IDTaxCategoryUN/ECE 5153.MUST be one of the followingcodes: S, H, AA, E, Z, R or K.UN/ECE 5153 code list-Credit Note tax categories MUST be one of thefollowing codes: S, H, AA, E, Z, R or K.WCL-014-005Invoice and Credit note July 5, 2013 Page 88 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.08.5 VALIDATION SERVICEDifi’s Validator is an application program used to validate EHF XML-files.The Validator reads an XML-file and validates it against a set of validation rules and levels. For each ofthese levels, any warnings and error messages are accumulated and presented in a separate XMLfile.The Validator operates on 3 service levels:‣ Cut and paste:Paste your own XML tags (your file) to validate against the default set of rules.‣ Upload your file:Upload your XML-file and validate it against the default set of rules.‣ Web serviceCall the web service, supply your file and specify which EHF version it is based on. Ifthe version is not specified, the file is assumed to be based on the latest version.The Validator is available as open source code, downloadable from this address:- VEFAvalidatorApplication https://github.com/difi/VEFAvalidatorApp- VEFAvalidatorConfiguration and guide https://github.com/difi/VEFAvalidatorConfIf the EHF document is validated without errors in the Difi Validator it’s considered to be a validdocument and must not be rejected by any recipient.Invoice and Credit note July 5, 2013 Page 89 of 90

EHF Implementation guideVersion:Invoice and Credit note 2.09 APPENDICES9.1 APPENDIX 1 - STRUCTURESAppendix 1 is a table given a schematic view of the EHF invoice and EHF credit note.9.2 APPENDIX 2 – MESSSAGE TABLEAppendix2 shows complete message tables for EHF invoice and EHF credit note.9.3 APPENDIX 3 – CODE LISTSAppendix3 contains code lists for EHF invoice messages. These are based on the attached BII code list”BII_codelists-v1.00”.9.4 APPENDIX 4 - UBL 2.1 SCHEMAAppendix4 contains a link to the UBL 2.1 Schema that the EHF invoice messages are based on. Syntax validationis performed against these schemas.UBL 2.0 schema is available at: http://docs.oasis-open.org/ubl/prd3-UBL-2.1/xsd/maindoc/UBL-Invoice-2.1.xsd9.5 APPENDIX 5 - SCHEMATRON FILESAppendix5 contains a link to the Schematron files that are used when validating the messages.Schematron files are available at: https://github.com/difi/VEFAvalidatorConf/STANDARD/EHFInvoice/2.0/xsl9.6 APPENDIX 6 – EXAMPLE FILESAppendix6 contains EHF invoice and EHF credit note example files.Invoice and Credit note July 5, 2013 Page 90 of 90