eGet Fakturaformat Brukerdokumentasjon

Transcription

BSK implementation guide
e2b-format v.3.3
Banks common implementation guide
based on version 3.3 of the
e2b Invoice Format
Version: 1.02
3. September 2012
Bankenes Standardiseringskontor
Postbox 2644 Solli
0203 OSLO
Tel. 23 28 45 10
Email: [email protected]
BSK Implementation guide B2B e-invoice
V er s ion: 1 .0 1
Change log (English version)
DATE
VER
DONE BY
CHANGES
21.09.2010
1.0
Morten Krøgenes
Approved BSK IG for e2b format version 3.3 (English
translation)
01.02.2011
1.01
Morten Krøgenes
Updated in order to open the possibility for attachements
16.04.2012
1.02
Morten Krøgenes
Updated with governments requirements connected to the
EHF format
3.9.2012
1.02
Morten Krøgenes
Removed bullet in appendix 2, kap. 1.7.3 which was
connected to mapping of attachments between the EHF/e2b
format.
Note: Se change log at end of the document.
BSK
20120903 Bank IG 1v02 e2bformatet3v3 English
Side 2 av 62
V er s ion: 1 .0 1
Table of contents
1.
Introduction .................................................................................................................. 5
1.1
1.2
1.3
2.
PREREQUISITES .........................................................................................................................5
TARGET GROUP FOR THIS DOCUMENT ......................................................................................5
EXPLANATION OF THE TABLES .................................................................................................6
Invoice - Overall description of the format ................................................................. 7
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
BUSINESS DOCUMENTS ............................................................................................................7
INDUSTRY-SPECIFIC EXTENSIONS .............................................................................................8
TECHICAL GUIDELINES .............................................................................................................8
FILLING IN AMOUNT FIELDS......................................................................................................8
USE OF STATUS MESSAGE .......................................................................................................11
DUPLICATE CONTROL .............................................................................................................11
TEMPLATE VIEW .....................................................................................................................11
MAPPING RELATED TO THE EHF FORMAT (REF. THE GOVERNMENTS REQUIREMENTS
RELATING TO ELECTRONIC INVOICE) ..................................................................................................12
3.
Invoice - Structure of the message ............................................................................13
3.1
NAME STANDARD INVOICE FILES ...........................................................................................13
3.2
STRUCTURE OVERVIEW ..........................................................................................................13
3.3
INTERCHANGE ........................................................................................................................15
3.4
ENVELOPE...............................................................................................................................15
3.5
INVOICE MESSAGE..................................................................................................................16
3.6
INVOICE HEADER ....................................................................................................................17
3.7
PARTY INFORMATION .............................................................................................................21
3.7.1
Supplier ............................................................................................................................ 21
3.7.2
Buyer ................................................................................................................................ 26
3.7.3
Factoring .......................................................................................................................... 31
3.7.4
Other parties..................................................................................................................... 34
3.8
INVOICE DETAILS ....................................................................................................................38
3.9
INVOICE DISCOUNT, CHARGES AND TAX ................................................................................45
3.10 INVOICE TOTALS .....................................................................................................................47
Appendix 1: Example of an invoice file.............................................................................50
Appendix 2: Advice for using the format ..........................................................................54
1.
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
1.7.1.
1.7.2.
1.7.3.
1.7.4.
1.7.5.
BSK
THE USE OF THE FORMAT........................................................................................................54
ACTORS/ROLES.......................................................................................................................54
USE OF FIELDS IN RELATION TO REFERENCES ........................................................................54
SPECIAL FIELDS AND INDUSTRY SPECIFIC SOLUTIONS ...........................................................56
LEVELS ...................................................................................................................................57
CONSOLIDATED INVOICE ........................................................................................................58
POSTAL AND STREET ADDRESS ...............................................................................................59
MAPPINGRULES CONNECTED TO THE EHF FORMAT...............................................................59
RULE - MAPPING OF INVOICE AMOUNT AND THE AMOUNT TO BE PAID ..................................59
RULE - MAPPING OF FACTORING PARTY (E2B) AND PAYEE PARTY (EHF) ............................59
RULE - MAPPING OF ATTACHEMENTS BETWEEN E2B AND EHF..............................................59
UNIT CODES ............................................................................................................................60
DEPENDENCIES BETWEEN THE AMOUNT FIELDS.....................................................................60
Side 3 av 62
BSK
V er s ion: 1 .0 1
Side 4 av 62
V er s ion: 1 .0 1
1. Introduction
This implementation guide is prepared by BSK.
This implementation guide describes how e2b version 3.3 format is to be used for sending
electronic invoices in the banking network. The format can be used both for B2B and B2C.
The documentation must be read in conjunction with the bank’s User Guidelines.
This document is a translation of the equivalent Norwegian documentation for the BSK
Implementation Guide for e2b-format ver. 3.3. In the event of any discrepancies between
the two versions, the Norwegian one shall be regarded as the master version and the
correct one.
1.1 Prerequisites
To be able to send e-invoices in the banking network, the following prerequisites must be
met:
1. Agreement with bank
- both the invoice recipient and invoice issuer must enter into a service
agreement with its bank
2. Addressing:
- The banks offer addressing based on e-invoice ID and organisational number.
The invoice issuer and the invoice receiver are responsible for exchanging the
address information between them.
3. Adaptions in ERP-systems:
- The addressinginformation (e-invoice ID / organisational number) for both the
invoice issuer and invoice recipient must be included in the invoice file. It may
therefore be necessary to make adjustments in the ERP system.
1.2 Target group for this document
The target group for this document is technical personnel which is responsible for the
implementation of e-invoice solutions at the organisation of the e-invoice issuer or the
organisation of the e-invoice receiver.
BSK
Side 5 av 62
V er s ion: 1 .0 1
1.3 Explanation of the tables
Below is an explanation of the columns in the tables in Chapter 3 and 6
Name of XML element refers to the actual tag name in XML
Description specifies rules for data content, legal code values, etc.
Fields in italics are not guaranteed delivered if the invoice recipient uses another format
than e2b version 3.3.
Requirement indicates whether the field is
M = Mandatory (Must be part of the message)
K = Optional (May be included in the message)
A = Dependent (Use is dependent on specific criteria)
Repetition indicates how many times the field should / can be repeated. See below:
1
Mandatory, used, only once
1..3
Mandatory, used minimum once, may be used up to 3 times
1..*
Mandatory, used minimum once, may be used many times
0..1
Optional, used maximally once
0..*
Optional, the field may be used many times
Type specifies the type of value to be transferred to the appropriate element in the XML
notation
String = Alfanumeric
Integer = Numbers
Decimal = Desimalnumbers
Date = Date (YYYY-MM-DD)
Time= Time (HH:MM:SS)
DateTime = Date+Time (YYYY-MM-DDTHH:MM:SS)
Attributes are marked with the prefix @.
BSK
Side 6 av 62
V er s ion: 1 .0 1
2. Invoice - Overall description of the format
2.1 Business Documents
The implementation Guide supports the following business documents:
Functional
Business
Document
Sending
role
Receiving
role
Description
Invoice
Supplier
Buyer
An invoice is a clear and unified sales
document that presents the seller's /
supplier's outstanding accounts towards the
Buyer and documents the Buyer’s rights to
receive products and services.
Credit Note
Supplier
Buyer
Credit Note is used by the supplier to
disclose information about the credit amount
the Buyer has against the supplier.
Reminder
Supplier
Buyer
Reminders are used by the supplier to
disclose information about the payment of
outstanding claims that has not been
received by the supplier as described in the
invoice. The solution facilitates that the
supplier may also send reminders to the
Buyer.
Notification of debt collection should be sent
via mail (formal requirements acc. Law).
Interest
invoice
Supplier
Buyer
Interest invoice is used by the supplier to
disclose information about outstanding
interest claim the supplier has on the Buyer
Electronic
invoice
State
Electronic invoice is an invoice in a unified
structured form that is transported
electronically from the invoice issuer to the
invoice recipient and which can be further
processed by machine at the invoice
recipients in-house ERP systems. It is not
sufficient that the bill is "electronic" or
machine available. The data must be
structured in such a way that the document
can "float" between different systems. This
means that a file (such as pdf or image
format) that are made on the basis of a paper
invoice, do not normally meet the definition of
electronic invoice.
Note connected to coding of the business documents in the format:
The code i InvoiceType denotes if it is an invoice, creditnote og reminder. Notice that the
same code is used for both invoice and reminder. The difference between these is
specified in @codetext. The coding for reminder is therefore be InvoiceType=380 and
@codetext “Purring”.
BSK
Side 7 av 62
V er s ion: 1 .0 1
2.2 Industry-specific extensions
All invoices must contain a minimum of basic information on the head-, detail- and
sumlevel.
In addition, an invoice can contain information related to a particular industry. This
information is necessary to describe the product or service that is the basis for billing.
Such industry-specific extensions may also be included on the head and detail.
To ensure that the structure is met in all kinds of messages, the following principles are
established for using industry-specific extensions in the format:
 If the industry-specific extension contains information on more than one level
(consolidated invoice / multi-order invoice), they must be added before the basic
details so that the base details represents a sum level of the industry-specific details.
 If the industry-specific extension contains information on one level, this should be
added directly after the base details for each invoice line.
Banks do not guarantee that the information in industry-specific extensions can be
distributed to the invoice recipient.
2.3 Techical guidelines



Character set: Unicode UTF-8 (the banks also supports ISO-8859-1)
Date format: YYYY-MM-DD
Decimal character: Dot
2.4 Filling in amount fields
The amount at line level that is to be added to the invoice total must be positive in the
invoice and in the credit note.
The amount at the line level that is to be deducted from the invoice total must have a
negative sign in both the invoice and the credit note.
VAT amounts, discountamounts, taxamounts and other additional amounts must to be
positive.
The figure below shows the relationship between the amounts in the message. It is used
+, - and =. Otherwise, the summation is indicated by the cardinality / hierarchy between
classes. Relation "many-to-one" means that many amounts are merged into one amount.
That part of the relationship that has no symbol can be repeated several times and the
amounts can be summarized in the class where the relationship is marked with "♦". The
figure is best read from below.
BSK
Side 8 av 62
V er s ion: 1 .0 1
InvoiceDetails
LineItemPreDiscountAmount
+ ChargesAmount -
DiscountAmount + TaxAmount
0..*
0..*
ChargesTotals
Description
Amount
= LineItemAmount
0..*
InvoiceDiscountChargesAndTax
0..1
0..*
0..1
VatAmount
0..1
VatAmount
InvoiceTax 1 0..1
VatAmount
InvoiveDiscount 1
DiscountTotals
Amount
0..*
1..*
InvoiceCharges 1
Description
VatAmount
0..1
0..*
0..*
0..*
0..*
0..*
TaxTotalsInfo
Description
Amount
0..1
VatTotalsInfo 0..1
VatPercent
VatAmount
0..*
1
0..1
LineItemTotalsAmount
1
InvoiceSummary 0..1
ChargesTotalsAmount
0..1
0..1
DiscountTotalsAmount TaxTotalsAmount
0..1
1
NetAmount
0..1
0..1
VatTotalsAmount
0..1
RoundingAmount
1
0..1
1
GrossAmount
BSK
Side 9 av 62
V er s ion: 1 .0 1
The example below shows the calculation of line sums, charges / discounts and invoice
totals in an e2b invoice.
Calculation of line sums, charges/discounts and invoice totals
Line level
XML-tag
<BaseItemDetails><Description>
<BaseItemDetails><QuantityInvoiced>
*
<BaseItemDetails><UnitPrice>
=
<BaseItemDetails><LineItemPreDiscountAmount>
<BaseItemDetails><Discount><Percent>
*
=
<BaseItemDetails><Discount><Amount>
- = <BaseItemDetails><TaxInfo><BaseAmount>
<BaseItemDetails><TaxInfo><Percent>
*
<BaseItemDetails><TaxInfo><Amount>
=
<BaseItemDetails><VatInfo><VatBaseAmount>
+=
*
<BaseItemDetails><VatInfo><VatPercent>
=
<BaseItemDetails><VatInfo><VatAmount>
+=
Invoice level
<InvoiceDiscountChargesAndTax><InvoiceCharges>
<BaseAmount>
<InvoiceDiscountChargesAndTax><InvoiceCharges><Percent>
*
<InvoiceDiscountChargesAndTax><InvoiceCharges><Amount>
<InvoiceDiscountChargesAndTax><InvoiceCharges><VatInfo>
<VatBaseAmount>
=
*
<VatPercent>
=
<VatAmount>
+=
Invoice totals
<InvoiceSummary><InvoiceTotals><LineItemTotalsAmount>
=
<InvoiceSummary><InvoiceTotals><ChargesTotalsAmount>
=
<InvoiceSummary><InvoiceTotals><VatTotalsAmount>
+=
+
<InvoiceSummary><InvoiceTotals><RoundingAmount>
=
<InvoiceSummary><InvoiceTotals><GrossAmount>
BSK
Product
Product1
Quantity
5
Unit price
2,5
Total unit price
12,5
Discount percentage
20 %
Discount
2,5
Total incl. discount
10
Environmental
tax
percentage
10 %
Environmental tax
percentage
Total incl.
environmental tax
VAT percentage
VAT
Total incl. VAT
1
11
25 %
2,75
13,75
Freight basis
Freight percentage
11
6%
Freight
0,66
VAT percentage
VAT
Total incl. VAT
0,17
0,83
Linesum
Additional amount
VAT
Sum
Rounding
Sum after rounding
25 %
11
0,66
2,92
14,58
0,02
14,60
Side 10 av 62
V er s ion: 1 .0 1
2.5 Use of status message
The use of status messages is in principle the same as the status message defined in the e2b
standard.
The use in the different banks may differ and the bank must be contacted for detailed user
documentation.
2.6 Duplicate control
Each invoice file is controlled for duplicate against previously submitted invoices.
The following elements may be included in the duplicate control:
Element
XML element
Address (eInvoiceID /
organisational number)
InvoiceHeader/Supplier/PartyId
Invoicenumber
InvoiceHeader/InvoiceNumber
Invoice date
InvoiceHeader/InvoiceDate
Invoice type
InvoiceHeader/InvoiceType
Suppliers organisation number
InvoiceHeader/Supplier/OrgNumber
Note: Combinations of fields must be unique.
The following items may invalidate the duplicate control:
Element
XML element
InvoiceStatus
InvoiceHeader/InvoiceStatus
2.7 Template view
Banks have prepared a joint template view for the e2b format that users can use.
Contact your bank for more information.
BSK
Side 11 av 62
V er s ion: 1 .0 1
2.8 Mapping related to the EHF format (ref. the governments requirements
relating to electronic invoice)
Governmental/public sector require (from 1. July 2012) the use of the EHF format for
receipt of invoices and credit notes in the establishment of new sales contracts. This
may mean that invoices and credit notes from issuers using BSK IG for e2b format in
many cases will have been mapped to the EHF format.
In this IG, it is added comments in information elements subject to specific
requirements given in the EHF format. As a general rule, all fields that are required in
the EHF e2b format should be used in this format. Contact the bank in the case of
further questions.
Special mapping rules related to the EHF format can also be found in Appendix 2:
Tips for using the format
Issuers should note the following regarding the document type for "Reminder":
The banks have decided not to offer automatically mapping between e2b format and
EHF format of the document type "reminder". When issuing reminder in e2b, this will
be sent to e2b recipients, while other recipients will receive the reminder as agreed
with own bankconnection. The reason for this is the following:



It is not possible to map an EHF reminder to a valid document in e2B format.
The mapping from an e2b reminder to EHF reminder is not possible because EHF do not
have corresponding information fields as those presented in the e2b format.
The handling of reminders is based on different routines in the issuer / receiver systems
than invoices and credit notes. This, and the fact that EHF reminder only refer to a
previous invoice, while a e2b reminders can be communicated in the same way as an
ordinary invoice, gives unsolvable challenges related to mapping from EHF to e2b.
Note: Any use of the documenttype reminder based on the EHF format and distribution
towards recipients using EHF must be agreed with the individual bank.
BSK
Side 12 av 62
V er s ion: 1 .0 1
3. Invoice - Structure of the message
3.1 Name standard invoice files
Based on agreement between the bank and the bank's customer (invoice issuer / invoice
recipient)
3.2 Structure Overview
The invoice format (based on e2b) is built up as shown in the figure below.
The contents of the coloured modules are included in the basic format and are described
in subsequent chapters. Contents of the white modules are additions that are described in
separate documents (industry specific extensions).
Fields in italics are not guaranteed delivered to invoice recipients that use another e
invoice format than e2b version 3.3.
The following notation is used to define the requirements for filling in the chart below:
1 = One instance (mandatory)
1..* = One or many instances
0..1 = None or one instance (conditional)
0..* = None or many instances
The use of attachement is described in a separate appendix.
BSK
Side 13 av 62
BSK Implementation guide B2B eFaktura
V er s ion: 1 .0 2
Interchange
0..1
0..1
0..*
MessageHeader
Envelope
1..*
1
InvoiceHeader
CardHeader
0..1
InsuranceHeader
1
InvoiceMessage
1..*
InvoiceDetails
0..*
FreeText
TelecomHeader
0..1
EnergyHeader
BuildingHeader
CardDetails
0..1
InvoiceTotals
0..*
InvoiceCharges/Allowance
0..* SubInvoice
0..1
0..1
1
1..*
BaseItemDetails
InsuranceDetails
BSK
InterchangeHeader
EnergyDetails
BuildingDetails
0..1
0..1
0..1
0..1
0..* TravelDetails
0..*TelecomDetails
0..* CarrierDetails
0..*TransportDetails
Side 14 av 62
V er s ion: 1 .0 2
3.3 Interchange
“Interchange” is the package of the transfer file and is just a tag that marks the start and end of the file. (There are no other elements
related to this)
BSK have not identified the need for making bankspecific IG’s for bankspesific use of the Interchange Header and Message Header.
These documents is described in separate documents and can be collected at www.e2b.no website.
Reference to the XML style sheet that is included in your submitted file, eg. as a declaration
<?xml-stylesheet type="text/xsl"href="EHF-faktura NO 5.xslt"?>
should always be passed on to the recipient, This gives the sender the opportunity to influence how the presentation of the invoice will
done at the recipient and ensures that the sender's information is included in the recipient's view.
3.4 Envelope
Not used. (Envelope from invoice issuer may be accepted, but the envelope functions are not used).
BSK
Side 15 av 62
V er s ion: 1 .0 2
3.5 Invoice Message
Name of XML-element
Description
Req. Repetition Type
Invoice
M
1
@MessageOwner
Fixed value: e2b
M
1
String
@MessageType
Fixed value: Invoice
M
1
String
@MessageVersion
@language
Legal value: 3.3
Language code (ISO 639 two letter code)
M
K
1
0..1
String
String
MessageNumber
Unique number that identifies the message within an interchange
K
0..1
String
MessageTimestamp
Message date. Date and time when the message is generated.
Format: YYYY-MM-DDTHH:MM:SS
(Timerule Rulebook)
Number of detail lines in the invoice
States if this is an Expense (K), Product (V) or Service (T) invoice.
Legal values are: ”K”, ”V” and ”T”
Codes which state what line of business the invoices are regarded as:
Legal values:
1=Credit card, 2=Travel, 3=Telecom, 4=Transport, 5=Carrier,
6=Insurance, 7=Energy, 8=Building, 9=General goods
M
1
K
0..1
Integer
K
0..1
String
K
0..1
String
Code description. Optional description of attribute
K
0..1
String
NumberOfLines
InvoiceContent
LineOfBusiness
@codetext
BSK
DateTime
Side 16 av 62
V er s ion: 1 .0 2
3.6 Invoice header
Name of XML-element
InvoiceHeader
Req.
Repetition Type
Invoice header
M
1
Legal values are:
380 = Invoice (Faktura)
381 = Credit Note (Kreditnota)
M
1
String
Code description: Optional description in attribute:
Eg. Invoice (380) Reminders (380) Interest invoice (380), Credit Note
(381). Other Descriptions can be used and will be forwarded.
If not completed, the codetext for the code in InvoiceType is used default.
K
1
String
Document status: Legal values are:
9 = Original
10 = Copy
53 = Test (between invoice issuer and invoice recipient in production)
Note: When using code 10 Copy or code 53 Test, the bank must be
contacted.
M
1
String
Code description: Optional description in attribute
K
0..1
String
InvoiceNumber
Invoice number or Credit note number
Mandatory element in the EHF format
M
1
String
InvoiceDate
Invoice Date: Date of issue of invoice
Suggested code values connected to tax:
NIL = Line item net amounts, invoice level tax
GIL = Line item gross amounts, invoice level tax
NLL = Line item net amounts, line-level tax
GLL = Line item gross amounts, line-level tax
NON = Tax does not apply to this invoice
M
1
Date
K
0..1
String
Suggested code values for discount management:
K
K
0..1
0..1
String
String
InvoiceType
@codetext
InvoiceStatus
@codetext
TaxTreatment
@codetext
DiscountTreatment
BSK
Description
Side 17 av 62
Name of XML-element
V er s ion: 1 .0 2
Description
Req.
Repetition Type
UN = Line item unit price, net of discount
UG = Line item unit price, gross of discount
TN = Line item amount, net of discount
TG = Line item amount, gross of discount
@codetext
Supplier
InvoiceIssuer
Buyer
Invoicee
OrderedBy
DeliveryPart
UltimateCustomer
ShippedFrom
BSK
K
0..1
The actor who delivers the commodity or service.
The content is described in Section 3.7.1, Actor Information.
To be used if different from Supplier.
M
1
PartyType
(ref. kapittel 3.7.1)
K
0..1
PartyType
The actor who ordered the commodity or service.
The content is described in Section 3.7.2, Buyer.
Invoice Recipient: The actor who receives the invoice/credit note. May be
stated if different from buyer.
May be stated if the procurement is made of an intermediary different
from the Buyer.
M
1
PartyType
K
0..1
PartyType
K
0..1
PartyType
Describes the actor on the place where the commodity is delivered.
May be stated if different from buyer.
Specification of the delivery address is required EHF format (street
address, zip code, city)
Describes ultimate receiver of the commodity. May be stated if different
from delivery part or buyer.
K
0..1
PartyType
K
0..1
PartyType
Describes the actor on the place where the goods are shipped from, or
brought by the Buyer (DeliveryPart). The ”ShippedFrom” may be stated
in addition to “DeliveryPart” or “UltimateCustomer“
K
0..1
PartyType
String
Side 18 av 62
Name of XML-element
Factoring
Description
Req.
0..1
PartyType
K
0..1
InvoiceReferences
Type
Order number: Reference to the buyers ordernumber. Required when
invoices are to be matched with the order (used for instance for electronic
matching). The use of this field is recommended.
Recommended element in the EHF format
Reference to the buyer’s order date. Mandatory for matching. The field
is recommended.
K
0..1
String
K
0..1
Date
BuyersProjectCode
Reference to the buyer’s project code
K
0..1
String
InvoiceNumber
Reference to original invoice in a credit note.
Mandatory element in the EHF format in relation wit creditnote and
reminder
K
0..1
String
SuppliersOrderNumber
Reference to the supplier’s order number.
K
0..1
String
DeliveryTerms
DeliveryTermsCode
Free text
Code for delivery terms: E.g. reference to INCOTERM-code for those
using this.
K
K
0..1
0..1
String
String
DeliveryTermsPlace
Delivery place associated with delivery terms
K
0..1
String
DeliveryNoteNum
Reference to the delivery note number.
K
0..1
String
DeliveryDate
Date of delivery with reference to delivery note number.
Payment information: Must occur once
K
0..1
Date
M
1
BuyersOrderNumber
BuyersOrderDate
Payment
States if the Supplier uses Factoring to handle payment transactions.
The content is described in Section 3.7.3, Factoring.
References
Repetition Type
K
InvoiceReferences
BSK
V er s ion: 1 .0 2
PaymentType
DueDate
Date when the invoice is due to payment
K
0..1
Date
Currency
Currency code: ISO Alpha code (3 characters) ISO 4217
M
1
String
Side 19 av 62
Name of XML-element
Description
Req.
Repetition Type
KidNumber
KID-number (Norwegian payment identification)
K
0..1
String
PaymentTerms
PaymentDiscount
Payment terms in free text
Zero or many instances
K
K
0..1
String
DiscountPercent
Discount percent
M
1
Decimal
DiscountDays
The number of days the discount take effect from
K
0..1
Decimal
Overdue interestcharge in percent
K
0..1
Decimal
Reference to the file with attachements, for instance an image file or
tickets. Zero or many instances.
See separate appendix
Reference: General reference field with code.
Zero or many occurrences.
K
0..*
String
K
0..*
RefWithCodeType
Code
Code stating type of references.
M
1
String
Text
Reference value.
FreeText General information that cannot be placed in other fields.
Zero or many occurences.
Business specific extension on header level for credit card
invoices.
K
0..1
String
K
0..*
String
K
0..1
CardHeaderInfo
Type
OverDuePercent
Attachments
Ref
FreeText
CardHeaderInformation
0..*
InsuranceHeader
Business specific extension on header level for insurance
invoices.
K
0..1
InsuranceHeader
Type
TelecomHeader
Business specific extension on header level for telecom invoices.
K
0..1
TelecomHeader
Type
EnergyHeader
Business specific extension on header level for energy invoices
(power and power supply).
The content is described in a specific document.
Business specific extension on header level for invoices related
to building, electro and VA/VVS.
K
0..1
EnergyHeader
Type
K
0..1
BuildingHeader
Type
BuildingHeader
BSK
V er s ion: 1 .0 2
Side 20 av 62
V er s ion: 1 .0 2
3.7 Party information
3.7.1 Supplier
Name of XML-element
Description
PartyType
Actor information
M
1
Actor number: Unique identifier
M
1
IdentifierType
PartyId
Use of either:
”efakturaId”
(efakturaId is built up with a BIC and a IBAN with a
hyphen between):
Example: XXXXXXXXXXX-NOXX15020012345
or
Organisational number (one string, do not use space or hyphen)
Example: 123456789 (recommended) or NO123456789
BSK
@schemeId
Identification of identifier
If an efakturaId is used in PartyId, then "efakturaId" shall be used.
If an organisational number is used in PartyId, then "Orgnr" shall be
used (if only the 9 digit organization is specified in PartyId) If NO is used
in the organisation number, then "NO: Orgnr" shall be used.
M
1
String
@schemeName
Name of identifier
If an efakturaId is used in PartyId, then "efakturaId" shall be used.
If an organizational number is used in PartyId, then
"Organisasjonsnummer" shall be used
M
1
String
Side 21 av 62
Name of XML-element
@schemeAgencyName
V er s ion: 1 .0 2
Description
Name of organization which administrates the identifier
If efakturaId is used in PartyId, then the BIC value of the bank that have
issued the efakturaId is used in this field.
If organisation number is used in PartyId, then the text “Enhetsregisteret
ved Bronnoysundregisterne”shall be used.
M
1
Location number For example GLN (Global Localisation Number).
Identification of identifier, for example GLN
K
K
0..1
0..1
IdentifierType
String
@schemeName
Name of identifier, for example GLN
K
0..1
String
@schemeAgency
Name of organization which administrates the identifier, for example
GS1
K
0..1
String
Name
Company name
M
1
String
ContactInformation
Contact information for the company
K
0..1
PhoneNumber
Company’s Telephone number
K
0..1
ContactInformation
Type
String
FaxNumber
Company’s Telefax number
K
0..1
String
EmailAddress
Company’s Email address
K
0..1
String
WebAddress
Company’s Web address
K
0..1
String
Street address: Zero or one occurrence
Street-/visitor address 1
K
K
0..1
0..1
AddressType
String
Address2
K
0..1
String
Address3
K
0..1
String
PostalCode
Post number related to the street address
K
0..1
String
PostalDistrict
Post district related to the street address
K
0..1
String
CountryCode
2 character code in accordance with ISO 3166
K
0..1
String
CountryName
Name of country in accordance with code
K
0..1
String
LocationId
@schemeId
StreetAddress
Address1
BSK
String
Side 22 av 62
Name of XML-element
PostalAddress
Description
Zero or one occurrence
PostalAdress must be included if invoice receiver uses the EHF
format
K
0..1
AddressType
Address1
Post adress 1
K
0..1
String
Address2
Post adress 2
Post adress 3
K
0..1
String
K
0..1
String
PostalCode
Postnumber related post address
K
0..1
String
PostalDistrict
Post district related to post address
K
0..1
String
CountryCode
K
0..1
String
K
0..1
String
Zero or many occurrence
Contact person name: Recommended format: ”Surname, First name,
Middle name”
Contact persons First name: Recommended format: ”First name
Middle name”
K
0..*
ContactPersonType
M
1
String
K
0..1
String
Address3
CountryName
ContactPerson
Name
FirstName
LastName
Contact persons Surname
K
0..1
String
Function
Contact persons Function (employment, role)
K
0..1
String
Department
Contact persons Department
K
0..1
String
ContactInformation
Contact information for contact person
K
0..1
Phone number to contact person
K
0..1
ContactInformation
Type
String
PhoneNumber
BSK
V er s ion: 1 .0 2
Side 23 av 62
Name of XML-element
Description
FaxNumber
Fax number to contact person
K
0..1
String
EmailAddress
Email address to contact person
K
0..1
String
WebAddress
Web address to contact person
K
0..1
String
Organization number (9 digits). Mandatory for Supplier.
Example: 123456789 or NO123456789
M
1
String
K
0..1
String
OrgNumber
VatId
Department
AccountInformation
AccountNumber
IbanNumber
SwiftNumber
ProjectRef
ContractNumber
BSK
V er s ion: 1 .0 2
Note that this will be shown on the invoice. Required element of the EHF
format
Rule: Organisation number from EHF shall always be mapped to
OrgNumber
VAT number: Mandatory when invoicing is decucted to Vat (14
characters).
Example: 123456789MVA or NO123456789MVA (the inclusion of NO is
not mandatory)
Rule: If the VAT number is specified in the EHF format, this must also be
entered in VatID)
Department within a company
Information about accounts for national and international
payments
K
0..1
String
K
0..1
AccountInformation
Type
The company’s domestic bank account number
Note! Not used when Factoring is used.
Mandatory element in the EHF format if used at this level
Account number for international payments
Mandatory element in the EHF format if IBAN is given
Swift number/BIC for international payments
K
0..1
String
K
0..1
String
K
0..1
String
Project reference
Contract number
The contract number between seller and buyer that the invoice is related
to. Recommended element in the EHF format
K
K
0..1
0..1
String
String
Side 24 av 62
Name of XML-element
Description
K
0..*
RefWithCodeType
Code
General reference fields with codes.
Zero or many occurrences
Code which states type of reference
M
0..1
String
Text
The actual reference number
K
0..1
String
Ref
BSK
V er s ion: 1 .0 2
Side 25 av 62
V er s ion: 1 .0 2
3.7.2 Buyer
Name of XML-element
Description
PartyType
Actor information
M
1
M
1
PartyId
IdentifierType
B2B (between businesses):
Use of either:
”efakturaId”
(efakturaId is built up with a BIC and a IBAN with a
hyphen between):
Example: XXXXXXXXXXX-NOXX15020012345
or
Organisational number (one string, do not use space or hyphen)
Example: 123456789 (recommended) or NO123456789
Other id’s can be agreed between the Invoice issuer and the invoice
issuers bank
B2C (business to consumers):
Here the einvoice reference (eFakturareferansen) is used.
BSK
Side 26 av 62
Name of XML-element
@schemeId
V er s ion: 1 .0 2
Description
Identification of identifier
M
1
String
M
1
String
M
1
String
K
0..1
IdentifierType
@schemeId
K
0..1
String
@schemeName
K
0..1
String
@schemeAgency
GS1
K
0..1
String
B2B: either ”efakturaId”, “NO:ORGNR” (if NO is included in PartyId)
or "Orgnr" (if only the 9 digit organization specified in PartyId)
B2C: ”efakturaRef”
Other identifiers: Must be agreed between the invoice issuer and the
invoice issuers bank.
@schemeName
Name of identifier
B2B: ”efakturaId” or “Organisasjonsnummer”
B2C: ”efakturaRef”
@schemeAgencyName
Name of organization which administrates the identifier
B2B: Receiving banks BIC or ”Enhetsregisteret ved
Bronnoysundregisterne”.
B2C: ”BBS” is currently used.
LocationId
BSK
Side 27 av 62
Name of XML-element
V er s ion: 1 .0 2
Description
Name
Company name
M
1
ContactInformation
K
0..1
PhoneNumber
K
0..1
ContactInformation
Type
String
FaxNumber
K
0..1
String
EmailAddress
K
0..1
String
WebAddress
K
0..1
String
K
K
0..1
0..1
AddressType
String
Address2
K
0..1
String
Address3
K
0..1
String
PostalCode
K
0..1
String
PostalDistrict
K
0..1
String
CountryCode
K
0..1
String
CountryName
K
0..1
String
K
0..1
AddressType
Address1
Post adress 1
K
0..1
String
Address2
Post address 2
Post address 3
K
0..1
String
K
0..1
String
PostalCode
Post number related post address
K
0..1
String
PostalDistrict
K
0..1
String
StreetAddress
Address1
PostalAddress
Address3
BSK
String
Side 28 av 62
Name of XML-element
CountryCode
CountryName
ContactPerson
Name
FirstName
V er s ion: 1 .0 2
Description
K
0..1
String
K
0..1
String
Middle name”
Mandatory element in the EHF format (“Deres Ref”)
Middle name”
K
0..*
ContactPersonType
M
1
String
K
0..1
String
LastName
K
0..1
String
Function
K
0..1
String
Department
K
0..1
String
ContactInformation
K
0..1
PhoneNumber
K
0..1
ContactInformation
Type
String
FaxNumber
K
0..1
String
EmailAddress
K
0..1
String
WebAddress
K
0..1
String
Organization number (9 digits). Recommended used.
Example: 123456789 or NO123456789
K
0..1
String
OrgNumber
Note that this will be shown on the invoice. Required element of the EHF
format
Rule: Organisation number from EHF shall always be mapped to
OrgNumber
BSK
Side 29 av 62
Name of XML-element
VatId
Department
AccountInformation
V er s ion: 1 .0 2
Description
VAT number: Mandatory when invoicing is deducted to Vat (14
characters).
Example: 123456789MVA or NO123456789MVA (the inclusion of NO is
not mandatory)
Rule: If the VAT number is specified in the EHF format, this must also be
entered in VatID)
payments
K
0..1
String
K
0..1
String
K
0..1
AccountNumber
K
0..1
AccountInformation
Type
String
IbanNumber
K
0..1
String
SwiftNumber
K
0..1
String
ProjectRef
Project reference
K
0..1
String
ContractNumber
Contract number
Note: Contract Number between buyer and seller that the invoice is
connected to is placed under the Supplier and not under the Buyer
K
0..1
String
Ref
K
0..*
RefWithCodeType
Code
For example “CustomerNumber” will be given here
M
1
String
Text
For example “CustomerNumber” will be given here
K
0..1
String
BSK
Side 30 av 62
V er s ion: 1 .0 2
3.7.3 Factoring
Name of XML-element
Description
PartyType
Actor information
K
0..1
K
0..1
IdentifierType
@schemeId
The Factoring company’s ID number for the invoice issuer.
Identification of identifier, for example supplier identifier
K
0..1
String
@schemeName
Name of identifier, for example suppliers identifier
K
0..1
String
Name of organization which administrates the identifier, for example the
supplier
K
0..1
String
K
K
0..1
0..1
IdentifierType
String
@schemeName
K
0..1
String
@schemeAgency
GS1
K
0..1
String
Name
Company name
M
1
String
ContactInformation
K
0..1
PhoneNumber
K
0..1
ContactInformation
Type
String
FaxNumber
K
0..1
String
EmailAddress
K
0..1
String
WebAddress
K
0..1
String
K
K
0..1
0..1
AddressType
String
Address2
K
0..1
String
Address3
K
0..1
String
PostalCode
K
0..1
String
PartyId
@schemeAgency
LocationId
@schemeId
StreetAddress
Address1
BSK
Side 31 av 62
Name of XML-element
Description
PostalDistrict
K
0..1
String
CountryCode
K
0..1
String
CountryName
K
0..1
String
K
0..1
AddressType
Address1
Post address 1
K
0..1
String
Address2
Address3
Post address 1
Post address 1
K
K
0..1
0..1
String
String
PostalCode
K
0..1
String
PostalDistrict
K
0..1
String
CountryCode
CountryName
K
K
0..1
0..1
String
String
Middle name”
Middle name”
K
0..*
ContactPersonType
M
1
String
K
0..1
String
PostalAddress
ContactPerson
Name
FirstName
LastName
K
0..1
String
Function
K
0..1
String
Department
K
0..1
String
ContactInformation
K
0..1
PhoneNumber
K
0..1
ContactInformation
Type
String
FaxNumber
K
0..1
String
EmailAddress
K
0..1
String
WebAddress
K
0..1
String
Organization number (9 digits). Mandatory for Supplier. Recommended
used.
K
0..1
String
OrgNumber
BSK
V er s ion: 1 .0 2
Side 32 av 62
Name of XML-element
V er s ion: 1 .0 2
Description
VatId
VAT number: Mandatory when invoicing is deducted to Vat (14
characters). Recommended used.
K
0..1
String
Department
payments
K
0..1
String
K
0..1
AccountInformation
Type
AccountNumber
IbanNumber
The factoring company’s bank account number
K
K
0..1
0..1
String
String
SwiftNumber
K
0..1
String
Project reference
Contract number
K
0..1
String
K
0..1
String
K
0..*
RefWithCodeType
AccountInformation
ProjectRef
ContractNumber
Ref
BSK
Code
Here ”AssignedClaused” is used.
M
0..1
String
Text
Infringement text
K
0..1
String
Side 33 av 62
V er s ion: 1 .0 2
3.7.4 Other parties
Contains information about InvoiceIssuer, Invoicee, DeliveryPart, OrderedBy, UltimateCustomer, ShippedFrom
Name of XML-element
Description
PartyType
Actor information
K
0..1
0..1
0..1
IdentifierType
String
PartyId
@schemeId
Identification of identifier, for example supplier identifier
K
K
@schemeName
Name of identifier, for example suppliers identifier
K
0..1
String
@schemeAgency
Name of organization which administrates the identifier, for example the
supplier
K
0..1
String
K
K
0..1
0..1
IdentifierType
String
@schemeName
K
0..1
String
@schemeAgency
GS1
K
0..1
String
Name
Company name
M
1
String
ContactInformation
K
0..1
PhoneNumber
K
0..1
ContactInformation
Type
String
FaxNumber
K
0..1
String
EmailAddress
K
0..1
String
WebAddress
K
0..1
String
K
K
0..1
0..1
AddressType
String
Address2
K
0..1
String
Address3
K
0..1
String
PostalCode
K
0..1
String
PostalDistrict
K
0..1
String
CountryCode
K
0..1
String
LocationId
@schemeId
StreetAddress
Address1
BSK
Side 34 av 62
Name of XML-element
CountryName
Description
K
0..1
String
Post address 1
K
K
0..1
0..1
AddressType
String
Address2
Post address 1
K
0..1
String
Address3
Post address 1
K
0..1
String
PostalCode
K
0..1
String
PostalDistrict
K
0..1
String
CountryCode
K
0..1
String
CountryName
K
0..1
String
K
M
0..*
1
ContactPersonType
String
K
0..1
String
LastName
Middle name”
Middle name”
K
0..1
String
Function
K
0..1
String
Department
K
0..1
String
ContactInformation
K
0..1
PhoneNumber
K
0..1
ContactInformation
Type
String
FaxNumber
K
0..1
String
EmailAddress
K
0..1
String
WebAddress
K
0..1
String
Organization number (9 digits). Mandatory for Supplier. Recommended
used.
VAT number: Mandatory when invoicing is decucted to Vat (14
characters). Recommended used.
K
0..1
String
K
0..1
String
K
0..1
String
PostalAddress
Address1
ContactPerson
Name
FirstName
OrgNumber
VatId
Department
BSK
V er s ion: 1 .0 2
Side 35 av 62
Name of XML-element
V er s ion: 1 .0 2
Description
payments
K
0..1
AccountNumber
K
0..1
AccountInformation
Type
String
IbanNumber
K
0..1
String
SwiftNumber
K
0..1
String
ProjectRef
Project reference
K
0..1
String
ContractNumber
K
0..1
String
K
0..*
RefWithCodeType
Code
Contract number
M
0..1
String
Text
K
0..1
String
AccountInformation
Ref
BSK
Side 36 av 62
BSK
V er s ion: 1 .0 2
Side 37 av 62
V er s ion: 1 .0 2
3.8 Invoice details
Invoice details may consist of:

Free text. A description/specification of an invoice line

Base item details. A general invoice line containing sufficient information for most business sectors and applications
The base item details are normally imported by all recipients. It is therefore important that these information elements is placed at the
same place in the message structure, regardless how the rest of the message is structured. In addition to the base item details, different
business sectors may require specific information to be sent on detail level. This information is defined in separate business specific
extensions which are conditional to use. The following rules are applicable for the definition of business specific extension in e2b on
details level (see also chapter 2.2):
 Business specific extensions that have multi order structure or consists of information on more than one level, is placed before the
base item details
 Business specific extensions that consists of information on one level only, is placed after the base item details
Name of XML-element
Invoice details
M
1..*
SubInvoice: General multi order structure on line level
Invoice header: Standard e2b header information.
K
M
0..*
String
1..*
BaseItemDetailsType
K
M
0..1
1
SubInvoiceType
HeaderType
Details: Standard e2b base of details.
One or many occurrences.
M
1..*
DetailsType
TravelDetails
Business specific extension for travel invoices.
K
0..1
TravelDetailsType
TelecomDetails
Business specific extension for telecom invoices.
K
0..1
TelecomDetailsType
TransportDetails
Business specific extension for transport invoices.
K
0..1
TransportDetailsType
CarrierDetails
Business specific extension for carrier invoices.
K
0..1
CarrierDetailsType
InvoiceDetails
FreeText
BaseItemDetails
SubInvoice
Header
Details
BSK
Description
Side 38 av 62
Name of XML-element
LineItemNum
Description
Line number in the invoice. Numbers in serial order from issuer.
States the level in the invoice and can be used to aggregation / subinvoicing
Only integer numbers is to be used: 1, 2, 3, ...etc.
Se detailed description in Appendix 2, chapter 1.4
K
0..1
String
K
0..1
String
SuppliersProductId
Supplier’s article-/product-/service number
K
0..1
String
Description
Description of a article/product/service
M
1
String
BuyersProductId
The Buyer’s article-/product-/service number
Additional product identification:
Can be a reference to a product code in a procurement portal
or a trade specific code i.e. EPD, GTIN (previous EAN article
number) or NOBB.
K
0..1
String
K
0..*
AdditionalProductIdType
M
1
String
ProductId: Actual value.
K
0..1
String
Based on pricetype
Price description. Will be stated if price is given in a unit
different from amount.
Legal values are:
AAA (Net price including allowance/charge)
AAB (Gross price without allowance/charge)
K
0..1
Decimal
K
0..1
String
K
0..1
String
Code description. Optional description in attribute
K
0..1
String
PerQuantity
Price per. quantity which unit price passes for
K
0..1
Decimal
LineItemPreDiscount
Amount
Line amount before allowance/charge
K
0..1
Decimal
PrePaidAmount
Contains amount paid in advance
K
0..1
Decimal
Level
AdditionalProductId
Code
Text
UnitPrice
PriceDenomination
PriceType
@codetext
BSK
V er s ion: 1 .0 2
Side 39 av 62
Name of XML-element
CommissionAmount
LineItemAmount
LineItemGrossAmount
QuantityInvoiced
UnitOfMeasure
ExchangeInformation
Currency
Description
For instance in connection with the use of traveling bureaus
Line amount without VAT, but included possible
allowances/charges. Either LineItemAmount or
LineItemGrossAmount must be sent.
Line item amount included VAT and possible
allowances/charges. Either LineItemGrossAmount or
LineItemAmount must be sent.
Invoiced quantity
Unit in accordance with ISO standard 31
UNECE Recommendation No.20 is an extended list of unit values,
based on the ISO standard 31 It is recommended that
Recommendation No. 20 is used for mapping from the EHF format to
the e2b format. See Appendix 1 (1.7.4).
Recommended element in the EHF format (DIFI has prepared a
mappingtball of the most common unit codes thta can be downloaded
from their website).
Information about amount in different currency.
Currency code: ISO Alpha code (3 characters) ISO 4217
K
0..1
Decimal
A
1
Decimal
A
1
Decimal
K
0..1
Decimal
K
0..1
String
K
0..1
ExchangeInformationType
M
1
String
M
1
Decimal
ExchangeRate
Amount in another currency: i.e. use of bankcards in a foreign
currency
Exchange rate used by conversion to NOK
K
0..1
Decimal
ExchangeDate
Valid date for exchange rate
K
0..1
Date
Information about the buyers order.
K
0..1
OrderAndDeliveryInfoType
UnitOfMeasure
If different from invoiced unit
K
0..1
String
UnitPrice
Unit price for the ordered unit
K
0..1
Decimal
PriceType
Price type for the ordered unit
K
0..1
String
ForeignAmount
OrderInformation
BSK
V er s ion: 1 .0 2
Side 40 av 62
Name of XML-element
V er s ion: 1 .0 2
Description
Quantity
Ordered quantity related to the ordered unit
K
0..1
Decimal
LineNum
Reference to the order’s line number
Information about de delivery.
K
0..1
String
K
0..1
DeliveryInformation
UnitOfMeasure
Unit delivered: If different from invoiced unit
K
0..1
String
UnitPrice
Unit price for the delivered unit
K
0..1
Decimal
PriceType
Price type for the delivered unit
K
0..1
String
Quantity
Delivered quantity
K
0..1
Decimal
K
0..1
String
K
0..1
LineNum
Reference to the line number on the list of contents
SuppliersOrderInformati Information about the supplier’s internal orders.
on
UnitOfMeasure
If different from invoiced unit of measure.
K
0..1
String
UnitPrice
Unit price in the supplier’s order
K
0..1
Decimal
PriceType
Price type in the supplier’s order
K
0..1
String
Quantity
Quantity in the supplier’s order
K
0..1
Decimal
LineNum
Reference to line number in the supplier’s order
VAT which is calculated on the line amount.
Note: VatPercent or VatBaseAmount can not be given alone
K
0..1
String
K
0..*
VatInfoType
VAT-percent: Eg. 25
Basis for the VAT calculation for the particular rate.
K
0..1
Decimal
K
0..1
Decimal
Amount for the particular rate
Taxes on line level except VAT.
K
K
0..1
0..*
Decimal
DiscountChargesAndTaxType
Code
Code for tax in accordance with contract.
K
0..1
String
Description
Description of type of tax, ref. Code
K
0..1
String
VatInfo
VatPercent
VatBaseAmount
VatAmount
TaxInfo
BSK
Side 41 av 62
Name of XML-element
Description
Percent
Tax Percent
K
0..1
Decimal
BaseAmount
Base amount for calculation of tax
K
0..1
Decimal
Amount
Quantity
Tax amount
To be used if tax is related to quantity
K
K
0..1
0..1
Decimal
Decimal
UnitOfMeasure
Unit related to quantity
K
0..1
String
RatePerUnit
To be used if tax is calculated based on rate per unit.
K
0..1
Decimal
VatInfo
VAT which is calculated on the tax
K
1
VatPercent
Vat-percent Ref. Standing rates issued by the Norwegian government.
K
0..1
Decimal
VatBaseAmount
Basis for the Vat calculation for the particular rate
K
0..1
Decimal
States the sequence for calculation if more than one tax
Discount on line level.
K
K
0..1
0..1
Decimal
String
K
0..*
VatAmount
CalculationSequence
Discount
VatInfoType
Code
Code for discount in accordance with contract.
K
0..1
String
Description
Percent
Description of type of discount, ref. Code
Discount percent
K
K
0..1
0..1
String
Decimal
BaseAmount
Base amount for discount calculation
K
0..1
Decimal
Amount
Quantity
Discount amount
To be used if the discount is related to quantity.
K
K
0..1
0..1
Decimal
Decimal
UnitOfMeasure
K
0..1
String
RatePerUnit
To be used if discount is calculated based on rate per unit.
K
0..1
Decimal
VatInfo
VatPercent
VAT which is calculated on the discount
Vat-percent: Ref. Standing rates issued by the Norwegian government.
K
K
1
0..1
VatInfoType
Decimal
VatBaseAmount
K
0..1
Decimal
VatAmount
K
0..1
Decimal
States the sequence for calculation if more than one discount
K
0..1
String
CalculationSequence
BSK
V er s ion: 1 .0 2
Side 42 av 62
Name of XML-element
Description
Charges on line level.
K
0..*
Code
Code for charges in accordance with contract
K
0..1
String
Description
Percent
Description of type of charges, ref. code
Charge percent
K
K
0..1
0..1
String
Decimal
BaseAmount
Base amount for calculation of charge
K
0..1
Decimal
Amount
Quantity
Charge amount
To be used if charge is related to quantity
K
K
0..1
0..1
Decimal
Decimal
UnitOfMeasure
K
0..1
String
RatePerUnit
To be used if the charge is calculated based on a rate per unit.
K
0..1
Decimal
VatInfo
VatPercent
VAT which is calculated on the addition
Vat-percent Ref. Standing rates issued by the Norwegian government.
K
K
1
0..1
VatInfoType
Decimal
VatBaseAmount
K
0..1
Decimal
VatAmount
K
0..1
Decimal
States the sequence for calculation if more than one charge
K
0..1
String
Invoicee
Invoice receiver: If Invoicee must be stated on Invoice line.
K
0..1
PartyType
(ref. chapter 3.7)
Licencee
If Licensee is different from Supplier/Seller
K
0..1
PartyType
(ref. chapter 3.7)
Duration
Duration, e.g. weeks or days
K
0..1
String
Unit for duration. Mandatory attribute
Start date for periodic invoicing
K
0..1
String
StartDate
K
0..1
Date
EndDate
End date for periodic invoicing
K
0..1
Date
SpecialCond
Special conditions. Suggested conditions are:
1 = Campaign
2 = Neither subject to bonus nor subject to commission
3 = Subject to bonus
4 = Subject to commission
5 = Both subject to bonus and subject to commission
K
0..1
String
Charges
CalculationSequence
@unitCode
BSK
V er s ion: 1 .0 2
Side 43 av 62
Name of XML-element
PostingInformation
Description
Code
The complete posting string defined by the Buyer
The content of the posting string.
General concept, for instance a department or project.
Code for relevant dimension
Reference: General reference fields with codes.
Code which states type of reference.
M
1
String
Text
K
0..1
String
Free text: General information which cannot be placed in other fields.
Business specific extension for credit card invoices.
K
0..1
String
K
0..1
CardDetailsInfoType
K
0..1
InsuranceDetailsType
K
0..1
EnergyDetailstype
K
0..1
BuildingDetailstype
PostingDetails
Dimension
PostingCode
Ref
FreeText
CardDetailsInformation
InsuranceDetails
EnergyDetails
BuildingDetails
BSK
V er s ion: 1 .0 2
Business specific extension for invoices related to an
insurance settlement.
Business specific extension for energy invoices (power,
power supply). The content is described in a specific document.
Business specific extension for invoices related to
building, electro and water, sewage and plumbing.
K
0..1
String
K
0..*
PostingDetailsType
M
1
String
M
1
String
K
0..*
RefWithCodeType
Side 44 av 62
V er s ion: 1 .0 2
3.9 Invoice discount, charges and tax
Name of XML-element
Req.
Repetition Type
Invoice discounts, charges and tax on invoice level.
K
0..1
Discounts on invoice total.
K
0..1
DiscountCharg
esAndTaxType
Code
Code for discount in accordance with contract.
K
0..1
String
Description
Percent
Description of type of discount, ref. Code
Discount percent
K
K
0..1
0..1
String
Decimal
BaseAmount
K
0..1
Decimal
Amount
Quantity
Discount amount
To be used if the discount is related to quantity.
K
K
0..1
0..1
Decimal
Decimal
UnitOfMeasure
K
0..1
String
RatePerUnit
To be used if discount is calculated based on rate per unit.
K
0..1
Decimal
VatInfo
VatPercent
VAT which is calculated on the discount
K
K
0..1
0..1
VatInfoType
Decimal
VatBaseAmount
K
0..1
Decimal
VatAmount
K
0..1
Decimal
States the sequence for calculation if more than one discount
Charges added to the invoice total.
K
0..1
String
K
0..1
DiscountCharg
esAndTaxType
Code
K
0..1
String
Description
Percent
Charge percent
K
K
0..1
0..1
String
Decimal
BaseAmount
K
0..1
Decimal
Amount
Quantity
Charge amount
K
K
0..1
0..1
Decimal
Decimal
InvoiceDiscount
ChargesAndTax
InvoiceDiscountInfo
CalculationSequence
InvoiceChargesInfo
BSK
Description
Side 45 av 62
Name of XML-element
Description
Req.
Repetition Type
UnitOfMeasure
K
0..1
String
RatePerUnit
To be used if charges are calculated based on rate per unit.
K
0..1
Decimal
VatInfo
VAT calculation based on charges
K
0..1
VatInfoType
VatPercent
K
0..1
Decimal
VatBaseAmount
K
0..1
Decimal
Governmental tax added to the invoice total.
K
K
0..1
0..1
Decimal
String
K
0..*
DiscountCharg
esAndTaxType
VatAmount
CalculationSequence
InvoiceTaxInfo
Code
K
0..1
String
Description
Percent
Charge percent
K
K
0..1
0..1
String
Decimal
BaseAmount
K
0..1
Decimal
Amount
Quantity
Charge amount
K
K
0..1
0..1
Decimal
Decimal
UnitOfMeasure
K
0..1
String
RatePerUnit
VatInfo
VAT which is calculated on the tax.
K
K
0..1
0..1
Decimal
VatInfoType
VatPercent
K
0..1
Decimal
VatBaseAmount
K
0..1
Decimal
K
K
0..1
0..1
Decimal
String
VatAmount
CalculationSequence
BSK
V er s ion: 1 .0 2
Side 46 av 62
V er s ion: 1 .0 2
3.10 Invoice totals
Name of XML-element
InvoiceSummary
Invoice totals
M
1
FreeText
One or more lines
K
0..*
InvoiceTotals
Must occur once
M
1
LineItemTotalsAmount
Sum total line amount
Required element in the EHF format. The element is recommended to
always be used. If this element is not included, the invoice may be in risk
of being rejected.
K
0..1
Decimal
DiscountTotalsAmount
Sum total discounts on detail and invoice level
K
0..1
Decimal
ChargesTotalsAmount
Sum total charges on detail and invoice level
K
0..1
Decimal
TaxTotalsAmount
Sum total taxes on detail and invoice level
K
0..1
Decimal
PrePaidAmount
CommissionAmount
Sum total prepaid amount. For instance pay on account
Sum total commission amount. For instance, the use of a travelling
agency
K
K
0..1
0..1
Decimal
Decimal
GrossAmount
Invoice amount included VAT
M
1
Decimal
VatTotalsAmount
Sum total VAT amount
M
1
Decimal
NetAmount
Invoice amount excluded VAT
Rounding off to the nearest ”øre”: On total gross amount
VAT-specification: Specification of total VAT per rate.
Zero or many occurrences. It is recommended in addition to include
sum for VAT rate 0 (zero) when the element is used.
Required element if the receiver uses the EHF format (i.e. governmental
organisastions). If this element is not included, the invoice may be in risk
of being rejected.
M
1
Decimal
K
0..1
Decimal
0..*
VatInfoType
RoundingAmount
VatTotalsInfo
BSK
Description
K
String
InvoiceTotalstype
Side 47 av 62
Name of XML-element
Description
VatPercent
K
0..1
Decimal
VatBaseAmount
The total basis for VAT calculation for this particular rate
K
0..1
Decimal
VatAmount
K
0..1
Decimal
K
0..*
TaxTotalsInfoType
TaxCode
Specification of total taxes beyond VAT per code/type.
Code for tax code in accordance with contract
K
0..1
String
TaxDescription
Description of type of tax, ref. code.
K
0..1
String
TaxAmount
Tax amount for this particular code.
Specification of total discount per code.
K
0..1
Decimal
K
0..*
Code
Code for discount in accordance with contract
K
0..1
DiscountCharges
AndTaxType
String
Description
Description of type of tax, ref. code.
K
0..1
String
Percent
Discount percent
K
0..1
Decimal
BaseAmount
K
0..1
Decimal
Amount
Discount amount
K
0..1
Decimal
Quantity
To be used if discount is related to quantity.
K
0..1
Decimal
UnitOfMeasure
K
0..1
String
RatePerUnit
To be used if discounts are calculated based on rate per unit
K
0..1
Decimal
VatInfo
VatPercent
VAT calculated on the discount.
Vat-percent: Ref. Standing rates issued by the Norwegian government
K
K
0..1
0..1
VatInfoType
Decimal
VatBaseAmount
K
0..1
Decimal
VatAmount
K
0..1
Decimal
Sequence for calculation if more than one discount (not relevant for
totals)
K
0..1
String
TaxTotalsInfo
DiscountTotals
CalculationSequence
BSK
V er s ion: 1 .0 2
Side 48 av 62
Name of XML-element
Description
Specification of total charges per code.
K
0..*
Code
Codes for charges in accordance with contract.
K
0..1
DiscountCharges
AndTaxType
String
Description
Description of type of charges, ref. Code
K
0..1
String
Percent
Charge percent
K
0..1
Decimal
BaseAmount
K
0..1
Decimal
Amount
Charge amount
K
0..1
Decimal
Quantity
To be used if charges are related to quantity.
K
0..1
Decimal
UnitOfMeasure
K
0..1
String
RatePerUnit
K
0..1
Decimal
VatInfo
VatPercent
VAT which are calculated on the charge
Vat-percent: Ref. Standing rates issued by the Norwegian government
K
K
0..1
0..1
VatInfoType
Decimal
VatBaseAmount
K
0..1
Decimal
VatAmount
K
0..1
Decimal
Sequence for calculation if more than one discount (not relevant for
totals)
To be used if payment shall be done in a different currency than
invoiced amount.
Mandatory element in the EHF format (mapping rules i described in
appendix 2)
ISO Alpha Code (3 characters) ISO 4217
K
0..1
String
K
0..1
Decimal
K
0..1
String
K
0..1
Integer
K
0..1
–nteger
K
0..1
String
ChargesTotals
CalculationSequence
ActualPayment
@Currency
@integerValue
@decimalValue
@modulus
BSK
V er s ion: 1 .0 2
Integer value of real amount
Decimal value of real amount
Modulus code
Side 49 av 62
V er s ion: 1 .0 2
Appendix 1: Example of an invoice file
The example shows an invoice sent from Invoice Issuer AS, PO Box 234, 0253 OSLO using a bank that is connected to a service provider to the Recipient
Company AS, PO Box 12, 1370 ASKER that is using a bank that is linked to another service provider.
<?xml version="1.0" encoding="UTF-8"?>
<Interchange xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.e2b.no/XMLSchema"
xsi:schemaLocation="http://www.e2b.no/XMLSchema H:\e2b_Invoice_v3p3\Schema\e2b_Invoice_Interchange_v3p3.xsd">
<Invoice MessageVersion="3.3" MessageOwner="e2b" MessageType="Invoice">
<MessageTimestamp>2008-09-16T09:30:47.0Z</MessageTimestamp>
<NumberOfLines>1</NumberOfLines>
<InvoiceHeader>
<InvoiceType codetext="Faktura">380</InvoiceType>
<InvoiceStatus codetext="Original">9</InvoiceStatus>
<InvoiceNumber>92345</InvoiceNumber>
<InvoiceDate>2008-04-13</InvoiceDate>
<Supplier>
<PartyId schemeId="efakturaId" schemeName="efakturaId" schemeAgencyName="ESSENOKX">ESSENOKXNO0015020012345</PartyId>
<Name>Fakturautsteder AS</Name>
<PostalAddress>
<Address1>Postboks 234</Address1>
<PostalCode>0203</PostalCode>
<PostalDistrict>Oslo</PostalDistrict>
<CountryCode>NO</CountryCode>
</PostalAddress>
<ContactPerson>
<Name>Ole Olsen</Name>
</ContactPerson>
<OrgNumber>987654321</OrgNumber>
<VatId>MVA987654321NO</VatId>
<Department>IT</Department>
<AccountInformation>
<AccountNumber>5005051234</AccountNumber>
</AccountInformation>
<ProjectRef>Project1</ProjectRef>
BSK
Side 50 av 62
V er s ion: 1 .0 2
<ContractNumber>54125412</ContractNumber>
</Supplier>
<Buyer>
<PartyId schemeId="efakturaId" schemeName="" schemeAgencyName="ESSENOKX">ESSENOKX-NO0000000000000</PartyId>
<Name>Mottakerbedrift AS</Name>
<PostalAddress>
<Address1>Postboks 12</Address1>
<PostalCode>1370</PostalCode>
<PostalDistrict>ASKER</PostalDistrict>
<CountryCode>NO</CountryCode>
</PostalAddress>
<ContactPerson>
<Name>Hanne Hansen</Name>
</ContactPerson>
<OrgNumber>998877665</OrgNumber>
<VatId>MVA998877665NO</VatId>
</Buyer>
<InvoiceReferences>
<BuyersOrderNumber>54321</BuyersOrderNumber>
<BuyersOrderDate>2008-04-10</BuyersOrderDate>
<DeliveryTerms>Fritt levert pr. bil</DeliveryTerms>
<DeliveryDate>2008-04-11</DeliveryDate>
</InvoiceReferences>
<Payment>
<DueDate>2008-09-28</DueDate>
<Currency>NOK</Currency>
<KidNumber>123456789</KidNumber>
<PaymentTerms>14 dager</PaymentTerms>
<PaymentDiscount>
<DiscountPercent>2</DiscountPercent>
<DiscountDays>10</DiscountDays>
</PaymentDiscount>
<OverDuePercent>2.5</OverDuePercent>
</Payment>
<Attachments>String</Attachments>
</InvoiceHeader>
<InvoiceDetails>
BSK
Side 51 av 62
V er s ion: 1 .0 2
<BaseItemDetails>
<Level>1</Level>
<SuppliersProductId>55555</SuppliersProductId>
<Description>Product1</Description>
<UnitPrice>2.5</UnitPrice>
<PriceType>AAB</PriceType>
<LineItemPreDiscountAmount>12.5</LineItemPreDiscountAmount>
<LineItemAmount>10</LineItemAmount>
<QuantityInvoiced>5</QuantityInvoiced>
<UnitOfMeasure>Stk</UnitOfMeasure>
<VatInfo>
<VatPercent>25</VatPercent>
<VatBaseAmount>11</VatBaseAmount>
<VatAmount>2.75</VatAmount>
</VatInfo>
<TaxInfo>
<Description>Miljøavgift</Description>
<Percent>10</Percent>
<BaseAmount>10</BaseAmount>
<Amount>1</Amount>
</TaxInfo>
<Discount>
<Description>Konsern</Description>
<BaseAmount>12.5</BaseAmount>
<Amount>2.5</Amount>
</Discount>
</BaseItemDetails>
</InvoiceDetails>
<InvoiceDiscountChargesAndTax>
<InvoiceCharges>
<Description>Frakt</Description>
<BaseAmount>11</BaseAmount>
<VatInfo>
BSK
Side 52 av 62
V er s ion: 1 .0 2
<VatBaseAmount>0.66</VatBaseAmount>
</VatInfo>
</InvoiceCharges>
</InvoiceDiscountChargesAndTax>
<InvoiceSummary>
<InvoiceTotals>
<LineItemTotalsAmount>11</LineItemTotalsAmount>
<DiscountTotalsAmount>0</DiscountTotalsAmount>
<ChargesTotalsAmount>0.66</ChargesTotalsAmount>
<TaxTotalsAmount>0</TaxTotalsAmount>
<GrossAmount>14.60</GrossAmount>
<VatTotalsAmount>2.92</VatTotalsAmount>
<NetAmount>11.66</NetAmount>
<RoundingAmount>0.02</RoundingAmount>
</InvoiceTotals>
<VatTotalsInfo>
<VatBaseAmount>11.66</VatBaseAmount>
</VatTotalsInfo>
<TaxTotalsInfo>
<TaxDescription>Miljøavgift</TaxDescription>
<TaxAmount>1</TaxAmount>
</TaxTotalsInfo>
<DiscountTotals>
<Description>Rabatt</Description>
</DiscountTotals>
</InvoiceSummary>
</Invoice>
</Interchange>
BSK
Side 53 av 62
BSK Implementationguide B2B efaktura
V er s ion: 1 .0 2
Appendix 2: Advice for using the format
1. The use of the format
This appendix describes some of the information items in the format and gives advice
about how to use the fields and what information to be placed in the field to ensure the
precise distribution. The goal is that it should be easier for the invoice issuer to
generate files and easier for the invoice recipient to receive files from different invoice
issuers. Equal use of the different information elements prevents that the invoice
recipient must analyze the files received from different issuers every time.
1.1. Actors/Roles
Actor/Roles
E2b
Comment
Supplier
Supplier
Invoice Issuer - is the part the supplies the
purchased goods/services and who has
entered into an agreement with its bank
about the role of "Invoice issuer".
Buyer
Buyer
Invoice Recipient - the part who is the
customer and who has entered into an
agreement with their bank about the role as
"invoice recipient".
Invoice issuer
InvoiceIssuer
Invoice Sender - the part that has sent the
invoice on behalf of themselves or others
who have signed an agreement with their
bank about the role of "Invoice issuer". May
be a technical part defined in the service
agreement the "Supplier" has signed with its
bank.
Invoice receiver
Invoicee
Invoice Recipient - the part that receives the
invoice on behalf of themselves or others
and who have signed an agreement with
their bank about the role as "Invoice issuer".
May be a technical part defined in the
service agreement the "Buyer" has signed
with its bank
Factoring
Factoring
Factoring - the part that shall receive the
payment from the buyer / invoice recipient
1.2. Use of fields in relation to references
Invoice issuer and invoice recipient needs to enter the various references in the invoice
when communicating with each other. This may for instance be related to a customer
number, an order number or project number. In those cases where the reference has a
unique field in e2b format (eg. order number) the specific field shall be used. But for other
required references this is not the case. The table below shows some references that have
no unique field in the e2b format. For these references, the banks recommend the following
use:
BSK
2 0 1 2 0 9 0 3 B a n k I G 1 v0 2 e 2 b f o r m a t e t 3 v3 E n g l i s h
Side 54 av 62
V er s ion: 1 .0 2
Type of reference
Recommended use in the common bank
IG
Comments
Customer number
The invoice issuer’s customer number for
invoice receiver:
InvoiceHeader/Buyer/Ref
where the Code = ”CustomerNumber” and
Text contains the actual customer number
Supplier number
The invoice issuer’s supplier number at the
invoice receiver:
InvoiceHeader/Supplier/Ref
where the Code = ”SupplierNumber” and
Text contains the value for the supplier
number.
Our reference (invoice
issuer)
where the Code = ”OurReference” and Text
contains the value for ”Our reference”.
Your reference (invoice
receiver)
InvoiceHeader/Buyer /Ref
where the Code = ”YourReference” and Text
contains the value for ”Your reference”.
Payment reference that is
not a Norwegian KID
InvoiceHeader/Ref
where the Code = ”PaymentReference” and
Text contains the value for the “Payment
reference”.
The Norwegian KID shall be
given in
“InvoiceHeader/Payment/KidNu
mber.”
The field is also used in relation
with cross border invoicing.
Note that information that is
given in other unique fields in
the format shall NOT be
duplicated in this field (Payment
reference).
AvtaleGiro (B2C) (invoice
receiver)
where the Code = ”AvtaleGiro”
This is used for the B2C
solution in Norway to indicate
that this is an ”AvtaleGiro”.
Property identification
number
(Gårds- og bruksnummer.)
where the Code = ”GaardsBruksNr” and
Text contains the value for the property
identification number (gårds- og
bruksnummer).
Internet address (Link)
where the Code equals ”Linknr” (for identify
viewing etc.) and the linktext is the URL (eg.
http://www.test.no).
The supplier number identifies
the supplier in the buyers
internal systems.
The principle for the use of ”Ref”-fields should also be followed for other references that
do not have an unique field in the format.
BSK
Side 55 av 62
V er s ion: 1 .0 2
1.3. Special fields and industry specific solutions
It is many types of businesses that have ”special fields”. Industry specific fields give for
example insurance number, meter identification, card number, property identification
number etc. Even if there is industry specific extensions for many of these special
fields, there is very few invoice receivers that have implemented solutions in their
systems for receiving and process these industry specific extensions.
Therefore, it is recommended that any invoice issuers use of industry specific fields is
agreed with the respective invoice receiver. If it is not possible to make an agreement
or the invoice receiver cannot receive a business specific extension, it is recommended
that the “special field” information is put into the general “Ref”-fields. In the e2b format
(InvoiceHeader/Ref), this recommends to be used as follows:
Example:
<Ref>
<Code>card number</Code>
<Text>40061001</Text>
</Ref>
Note! It is important to limit the number of ”Ref”-fields to a minimum. All information
elements that can be put in unique fields in the e2b standard, shall not be put in the
general ”Ref”-field.
It is recommended that the invoice receiver always makes ready space for additional
Ref fields in their style sheet so they can view any additional references that may be
given in the invoice.
BSK
Side 56 av 62
V er s ion: 1 .0 2
1.4. Levels
The general use of Levels will be as follows:
 Level 1 is the least detailed product line level (Summary) and Level 4 is the most
detailed level (”productline”).
 Level 2 and 3 is used for specifying different groupings.

Level 1 is summary of all the following Levels 2, 3 and 4.
o Level 2 is summary of all the following Levels 3 and 4.
 Level 3 is summary of Level 4.
 Level 4 is the actual product lines.
Note: For energy invoice (LineOfBusiness=7), only Level 1 and Level 2 is used for product
lines, and Level “Maalerstand” is used for reporting meter stand (B2C).
Kode example:
BSK
Side 57 av 62
V er s ion: 1 .0 2
<InvoiceDetails>
<BaseItemDetails>
<Level>1</Level>
<Description>Prosjekt</Description>
</BaseItemDetails>
<BaseItemDetails>
<Level>2</Level>
<Description>Underprosjekt</Description>
</BaseItemDetails>
<BaseItemDetails>
<Level>3</Level>
<Description>Aktivitet</Description>
</BaseItemDetails>
<BaseItemDetails>
<Level>4</Level>
<Description>Tjeneste 1</Description>
</BaseItemDetails>
<BaseItemDetails>
<Level>4</Level>
<Description>Tjeneste 2</Description>
</BaseItemDetails>
</InvoiceDetails>
1.5. Consolidated Invoice
The term ”Consolidated invoice” is used for different types of invoices:
 The e2b format implies that an invoice only has ONE (1) order number since order
number is defined at the invoice level and not at the row level. If it is not necessary
to include the order number, it is possible to give on order per row
(InvoiceDetails/BaseItemDetails) in the invoice. An example is pizza deliveries
where each delivery (order) in a certain period of time or to a specific department
can be specified as one row in an invoice.
 A consolidated invoice that demands the use of sub rows
(InvoiceDetails/BaseItemDetails/SubInvoice) should not be used/distributed.
Instead, it is recommended that Levels is used, as specified in chapter 1.4 above.
 For the energy industry, it is only permitted one Meter ID (MålerpunktID) per
invoice.
BSK
Side 58 av 62
V er s ion: 1 .0 2
1.6. Postal and street address
In those cases when the format contains both a postal address and a street address, it
will be the postal address that is selected when mapping the information to other
systems and in the case of printing. It is therefore recommended that the postal
address is used if the format gives an option.
In e2b, address 1, 2 and 3 is used. It is not stated in the format what part of the
address is to be given in the different line. In this solution, the following rule is followed:
 Address 1 is the street address (ex. Firmaveien 12)
 Address 2 is optional.
 Address 3 is used for the post box address (ex. Postboks 123 Solli).
1.7. Mappingrules connected to the EHF format
1.7.1. Rule - mapping of invoice amount and the amount to be paid
Both invoice amount and amount to be paid requires content in the EHF format and
can either contain the same amount (most commonly) or different (such as invoices
related to the credit card).
 When mapping from the EHF to e2b, the respective amount values is put in the fields of
Gross Amount (Monetary Total. Inclusive Tax Amount. Amount) and ActualPayment
(Monetary Total. Payable_ Amount. Amount). Note that PayableAmount in e2b is
divided into separate fields for amount and desimals and that this must be taken into
account whn mapping the Payable Amount.
 If ActualPayment (optional element) is missing when mapping from e2b to EHF, then
the same “GrossAmount” is to be mapped to both "Monetary Total. Tax Inclusive
Amount. Amount” and" Monetary Total. Payable Amount. Amount" as both fields are
required.
 Note that in ActualAmount in the e2b format is divided into separate fields for amount
and desimals and that this must be taken into account in the mapping.
1.7.2. Rule - mapping of Factoring Party (e2b) and Payee Party (EHF)
When mapping from e2b to the EHF format, the Factoring Party will be mapped to
Payee Party in the EHF format. If the Payee Party is used in the EHF format, then
the Party information must be mapped to the Factoring Party in e2b, as it is not
possible to separate if the Party is related to Factoring Party or Party Payee.
1.7.3. Rule - mapping of attachements between e2b and EHF
When mapping invoices with attachments between e2b format and the EHF format,
the following factors has to be taken into account:
 The EHF format supports specified file types as attachements. e2b supports all
file types, but with invoices relevant for mapping from e2b to the EHF format
the relevant issuer must pay attention to which filetypes that can be sent with
the EHF format.
BSK
Side 59 av 62
V er s ion: 1 .0 2
1.7.4. Unit codes
Unit codes according to ISO31 are in practice not used in the e2b format. Freetext
format is common practice. In other words, anything may occur as a unit code in the
e2b format.
In EHF, unit codes are used according to the UNECE Recommendation 20. Note
that all the codes defined in ISO 31 is covered by UNECE Recommendation 20, but
not the other way around.
It is an advantage that users of the e2b format are used in accordance with device
codes. ISO 31 or the Norwegian term specified in the mapping table published by
DIFI. If the other device codes in text format are used, these will be converted
according to. list defined in the agreement a bank or a default code such pieces.
1.7.5. Dependencies between the amount fields
Note: In some cases, there are added a control whether the amount sum adds up
correctly against the various line amounts in the EHF invoices, for example the
corresponding fields for the e2b field "Invoice / InvoiceSummary / InvoiceTotals /
NetAmount". Thus this control should be implemented in the e2b message for these
fields.
BSK
Side 60 av 62
V er s ion: 1 .0 1
Change log
Changes done in version 1.01 from version 1.0
Chapter
3.2
3.2
3.3
3.6
Change
Note
The following sentence is included:
”The use of attachment is described in a
separate appendix.”
Figure: It is opened for use of ”Interchange
Header”and ”Message Header”.
The following sentence is included:
” BSK have not identified the need for making
bank specific IG’s for banks use of the
Interchange Header and Message Header.
These documents are described in separate
documents and can be collected at
www.e2b.no website.”
The elementet ”Attachements“ is opened for
use.
Changes done in version 1.02 from version 1.01
Chapter
1.1
2.1
2.3
2.6
2.7
2.8
3.3
3.5 - 3.10
General
changes
BSK
Change
Note
Revised so that orgnummer is included as
possible addressing mechanism.
Added note related to the type of business
documents.
Added clarification that banks also supports
ISO-8859-1
Revised elements that can be used for
duplication control by adding orgnummer as an
element.
New chapter with regard to banks' template
view
New chapter with reference to the EHF format.
Added reference to how process template is to
be included
Added reference to the information elements
that are required and recommended in the EHF
format.
General corrections that do not affect the
content meaning are made .
Side 61 av 62
3.6
Field type for ”BuyersOrderDate” is changes
from ”String” to ”Date”.
3.8/3.9/3.10
Appendix 2,
chap 1.7
Changed text connected to valid codes for VAT
to a general text ” Ref.: Statens gjeldende MVA
satser”
Supplier PartyID updated in order to also
handle adressing with organisastional number
Buyer PartyID updated in order to also handle
adressing with organisastional number
It is specified that contract number between
buyer and seller that the invoice is connected
to, is to be placed under Supplier and not
under Buyer.
Note connected to mapping of unitcodes
added.
Included information that VatAmount must be
included if the receiver uses the EHF format
Included specific mapping rules between the
e2b and the EHF format.
Appendix 2,
chap. 1.7.3
Last bulletpoint deleted. It is possible to send
more than one attachment in the EHF format.
Appendix 2,
chap. 1.7.5
New
3.7.1
3.7.2
3.7.1 / 3.7.2
3.8
3.9
BSK
V er s ion: 1 .0 1
”String” is changed
from e2b version 3.3
to ”Date” in version
3.4/3.4.1
Side 62 av 62

eGet Fakturaformat Brukerdokumentasjon

Transcription

Similar documents

CIS 265 Homework 3 Due: Th. Mar 19th Fall 2015 â Prof. Matos

Flemish String Board Attachment

Basic Information - Tecnológico de Monterrey

READY TO FLY!!!

Instructions for Final Tuning of Arledge Optimized Piano Strings

Zoë and her Zebra Mobile

Workshop Registration

Leasing Procedures

1. Make simple calculations using Python, for example the

Resonance Problem Set 2