Guidelines for Description of Estonian Electronic Invoice ... · Page 5 / 20 2 Use-case: sending e-invoice to the bank and e-invoice standing order service With regard to the use

Page 1 / 20

Guidelines for Description of Estonian

Electronic Invoice. Sending e-invoices to the bank and

presentment of e-invoices at the bank

Version 1.0

Page 2 / 20

Contents

Contents .................................................................................................................................................. 2

1 Definitions ........................................................................................................................................ 3

2 Use-case: sending e-invoice to the bank and e-invoice standing order service .............................. 5

2.1 Note: Updates and revisions to the Estonian e-invoice description ......................................... 5

2.2 Explanations regarding the e-invoice description when presenting the e-invoice to bank ...... 6

2.2.1 Documenting information necessary for addressing invoice – attributes of the <Invoice>

element ........................................................................................................................................... 6

2.2.2 Documentation of invoice parties (recommended fields) – <InvoiceParties> element .... 6

2.2.3 Documenting general information in invoice – <InvoiceInformation> element ............... 7

2.2.4 Total price of good or services – <InvoiceSumGroup> element ........................................ 7

2.2.5 Detailed information on good or services - <InvoiceItem> ................................................ 7

2.2.6 Documenting additional information on invoice – <AdditionalInformation> ................... 7

2.2.7 E-invoice payment order information – <PaymentInfo> element .................................... 7

2.3 Example of e-invoice in the form of XML conforming to the Estonian e-invoice supplemented

description .......................................................................................................................................... 8

3 Use-case: e-invoice presentment at bank ...................................................................................... 11

3.1 E-invoice presentment in full in the bank’s electronic channels............................................. 11

3.2 E-invoice limited presentment via bank’s electronic channels ............................................... 12

3.3 E-invoice standing order service ............................................................................................. 13

3.4 Unsuccessful presentment of e-invoice by bank (VEA) ........................................................... 13

4 Ordering e-invoices via bank .......................................................................................................... 16

4.1 Submitting e-invoice request to seller via bank ...................................................................... 16

4.2 E-invoice ordering message from bank to e-invoice sender (EAA – e-invoice request)......... 16

4.3 Seller/buyer hierarchy (explanatory image) ........................................................................... 18

5 Seller agreement ............................................................................................................................ 19

5.1 Entering into seller agreement ................................................................................................ 19

5.2 Notifying the seller of the agreement and responding to the latter – SCNew and SCAcc

formats .............................................................................................................................................. 19

Page 3 / 20

1 Definitions

e-invoice sender – either the seller or operator who sends e-invoices to the payer’s bank on behalf

of the seller;

description of Estonian e-invoice – http://pangaliit.ee/et/arveldused/e-arve;

e-invoice – electronic invoice which is created, sent, recorded and retained in an electronic

environment, i.e. the handling of which takes place electronically (document in xml format based on

the description of the Estonian e-invoice at http://www.pangaliit.ee/arveldused/e-arve/);

e-invoice address – payer’s or buyer’s bank account number or personal identification code/registry

code at the bank to which the invoice is addressed. The e-invoice address in different banks is

different (personal identification code/registry code or account number) and the bank provides

information on this in its e-invoicing service conditions;

e-invoice request – the buyer’s or payer’s request to the seller or the operator to send e-invoices to

the bank. Information on relevant request may be found in contract of sale of goods or services. The

e-invoice request specifies the payer’s bank, the identity of the payer, e-invoice address, restrictions

on display of e-invoice and other conditions;

e-invoice agreement (seller agreement) – agreement between seller and operator on the basis of

which the operator sends e-invoices issued by the seller to the payer’s bank. Described in more

detail in chapter 5;

e-invoice sending agreement – bilateral framework agreement between operator or seller and the

payer bank, which governs the rights and responsibilities of the operator or seller and payer bank in

sending the e-invoices issued by the seller;

limited presentment of e-invoice – parameter defined at the request of the buyer or payer and by

the seller upon sending e-invoice, for partial presentment of the e-invoice to the payer. The limited

presentment use-case is described in more detail in chapter 3.2;

e-invoice standing order service – bank service for payer allowing e-invoices issued by the seller to

be paid on the basis of standing order, i.e. a credit transfer that may have a variable amount. The

service can be used only to pay SEPA area euro payments. Provision of service and detailed

conditions depend on the bank and are available in the banks;

e-invoice standing order agreement – agreement between payer and payer bank, whereby the

payer gives an order in advance for paying each successive e-invoice related to a specific seller or

ServiceId;

payer – bank customer paying the e-invoice (may be the buyer or another person authorized by the

buyer to receive and/or pay e-invoices);

seller – issuer of invoice or e-invoice who is a party to the contract of service or sale that is the basis

for the e-invoice;

http://pangaliit.ee/et/arveldused/e-arve

Page 4 / 20

buyer – buyer of good/service who is in a contractual relationship with the seller;

operator – person who sends e-invoices from seller to the payer’s bank on the basis of the e-invoice

sending agreement. Operators may be either banks or third-party service providers;

bank electronic channel – electronic solution for the bank customer for making the e-invoice

services available (e.g. internet bank, mobile bank etc). The specific solution depends on the bank;

serviceId (service code) – unique code for buyer’s service agreement at a seller; it identifies the flow

of periodic invoices submitted to the payer (customer code, customer number, agreement number

etc). E-invoices are ordered on this basis. In the bank, the payer can use this information to enter

into an e-invoice standing order agreement and set a limit on it;

SEPA - the Single Euro Payment Area;

Estonian e-invoice updated description – e-invoice in XML format conforming to version 1.1. of the

Estonian e-invoice description, to which the addenda described in clause 2.1 have been added.

Page 5 / 20

2 Use-case: sending e-invoice to the bank and e-invoice standing

order service With regard to the use of the Estonian e-invoice description, the e-invoice must conform to all rules

that derive from the description:http://pangaliit.ee/images/files/E-arve/e-invoice_ver1_1_eng.pdf.

2.1 Note: Updates and revisions to the Estonian e-invoice description To ensure, upon sending to the bank of e-invoices conforming to the Estonian e-invoice description,

both ordinary e-invoice presentment accompanied with manual or automatic payment (using the e-

invoice standing order service) as well as limited e-invoice presentment accompanied by manual or

automatic payment, it is necessary to introduce the following updates.

1. Add to the file header an optional code regarding the file contents (AppId, value EARVE).

2. Add the “presentment“ attribute (optional attribute) of the <Invoice> element – used to

limit e-invoice information presentment. Fixed value:

a. “YES” (default value if there is no attribute or if the attribute value is not NO) – e-

invoice presentment in full

b. “NO” – the presentment of limited e-invoice information described in chapter 3.2.

3. Add the attribute “invoiceGlobUniqId“ (optional attribute) of the <Invoice> element – a

unique identifier assigned by the e-invoice sender (for each e-invoice sender), which ensures

trackability of the e-invoice The attribute “invoiceGlobUniqId” is returned to the e-invoice

sender in a message on defective e-invoices, whereby the e-invoice sender unequivocally

identifies an e-invoice sent with errors. Implementing this removes the restriction on

invoices sent to banks that the invoiceID value of the element <Invoice> must be unique

within the bounds of one invoice file.

4. Adding the optional element “PayToBic” to the PaymentInfo element – the seller bank ID

code to which the payment is received.

5. Use of the account number in the e-invoice XML file is, in connection with the transition

from local BBAN account numbers to IBAN numbers, regulated as follows:

a. when documenting information for the seller party in the <AccountInfo> element, it

is obligatory as of 1 Feb 2014 to show the account number in IBAN format, i.e. it is

obligatory to fill in the <IBAN> element. Effective as of the same date, it is not

required to fill in the <AccountNumber> element.

b. The <PayToAccount> element in the <PaymentInfo> element must, effective 1

February 2014, be filled in in the IBAN format.

6. Add the attribute “sellerContractID” in the <Invoice> element (optional attribute). This is the

identifier of the e-invoice agreement, i.e. the seller agreement, the use of which is described

in more detail in chapter 4.2 and chapter 5.

7. Add the attribute “sellerRegNumber” in the <Invoice> element (optional attribute). This is

the seller’s registry code.

Based on the updates, this document is accompanied by the updated Estonian e-invoice description

(.xsd file) – e-invoice_ver1.11.xsd.

Page 6 / 20

2.2 Explanations regarding the e-invoice description when presenting the

e-invoice to bank The subsequent chapters detail the elements that, as a rule, must be documented in a relevant e-

invoice which conforms to the Estonian e-invoice description and is sent to the bank. The

explanations are followed by an illustrative example of the XML in a relevant e-invoice conforming to

the supplemented Estonian e-invoice description. The number of required elements and the final

number of combinations of elements is set out in the supplemented Estonian e-invoice description.

One e-invoice file and other xml files specified in the document may simultaneously contain the data

for more than one seller.

2.2.1 Documenting information necessary for addressing invoice – attributes of the

<Invoice> element

1. invoiceId – e-invoice number

2. regNumber – registry code or personal identification code of buyer

3. serviceId – unique code of the buyer’s service agreement at seller

4. channelId – code, BIC code for the payer bank as the e-invoice channel

5. channelAddress – e-invoice address at the relevant bank, which shall be either the account

number or the personal identification/registry code. Note: The bank uses this field to

determine whom a relevant e-invoice is addressed to. If the address is an account number,

the IBAN and BBAN account numbers are to be used in parallel during the transition;

6. presentment – possible values are “YES” or “NO”. The attribute determines e-invoice

presentment – either in full (YES) or limited presentment (NO) (see chapter 3.2)

7. invoiceGloblUniqId – unique identifier attributed to invoice by the e-invoice sent

8. sellerContractId – seller agreement ID

9. sellerRegNumber – seller registry code

2.2.2 Documentation of invoice parties (recommended fields) – <InvoiceParties>

element

1. seller – <SellerParty>

a. <Name> – name of seller

b. <RegNumber > – seller’s registry code

c. <VATRegNumber> – VAT registry number, if the seller is liable to value added tax

d. <LegalAddress> – seller’s address

i. <PostalAddress1> – postal address

ii. <City> – city/town

e. <AccountInfo> – information on seller’s receiving account(s)

i. <AccountNumber> – number of the receipts account (as of 1 February 2014

the account number does not have to be sent in BBAN format)

ii. <BankName> – name of bank at which the account is located

iii. <IBAN> – international account number (as of 1 February 2014, the account

number must always be sent in IBAN format)

2. buyer – <BuyerParty>

a. <Name> – name of buyer

b. <RegNumber> – buyer’s registry code or personal identification code

Page 7 / 20

c. <LegalAddress> – buyer’s address

i. <PostalAddress1> – postal address

ii. <City> – city/town

2.2.3 Documenting general information in invoice – <InvoiceInformation> element

1. <Type> – type of e-invoice (credit or debit)

2. <DocumentName> – name of document being sent (invoice, payment notice etc)

3. <InvoiceNumber> – e-invoice number

4. <InvoiceDate> – e-invoice date

2.2.4 Total price of good or services – <InvoiceSumGroup> element

1. <InvoiceSum> – e-invoice total, not including VAT

2. <VAT> – information on VAT related to the e-invoice if the seller is liable to value added tax

a. <VATRate> – VAT rate

b. <VATSum> – VAT total

3. <TotalSum> – total e-invoice amount

4. <Currency> – currency of the e-invoice

2.2.5 Detailed information on goods or services – <InvoiceItem>

In the case of an invoice, detailed information on the good or services is documented under

<InvoiceItem>, in <InvoiceItemGroup>, in which pursuant to the e-invoice rows there is one

<ItemEntry> element for each row of the e-invoice.

The following is to be documented under <ItemEntry>:

1. <Description> – name of good or service

2. <ItemDetailInfo> – detailed information on quantity of good or volume of service

a. <ItemUnit> – good or service unit

b. <ItemAmount> – volume of good or service

c. <ItemPrice> – unit price of good or service

3. <ItemSum> – value of good or service not including VAT

4. <VAT> – information on VAT related to the good or service if the seller is liable to value

added tax

a. <VATRate> – VAT rate

b. <VATSum> – VAT total

5. <ItemTotal> – total value of good or service

2.2.6 Documenting additional information on invoice – <AdditionalInformation>

Additional information can be documented on the invoice. To do this, the following

<AdditionalInformation> elements are used:

1. <InformationName> – name of additional information

2. <InformationContent> – message to buyer

2.2.7 E-invoice payment order information – <PaymentInfo> element

To create a payment order in the bank, it is necessary to document the following elements in the

<PaymentInfo> element:

Page 8 / 20

1. <Currency> – currency of the e-invoice

2. <PaymentRefId> – e-invoice reference number (if one exists)

3. <PaymentDescription> – payment details. Recommended example: “Invoice number

123456“.

4. <Payable> – if the value is NO, the invoice is presented at the bank but it is not payable

5. <PayDueDate> – e-invoice payment due date

6. <PaymentTotalSum> – amount payable, which the bank shall enter on the payment order

for the payer to confirm or which is to be paid in the framework of the e-invoice standing

order service. The amount payable must be a positive number or zero.

7. <PayerName> – name of buyer (informational field)

8. <PaymentId> – e-invoice number

9. <PayToAccount> – payee’s account. Starting 1 Feb 2014, must appear in IBAN format.

10. <PayToBIC> – Code of the payee’s bank, conforming to ISO rules (optional element) needed

in certain cases for executing interbank payments within Europe.

11. <PayToName> – name of payee

Note: A number of data fields in the PaymentInfo element and in the e-invoice information have a

recurrent nature (invoice number, payment deadline, reference number etc). In creating the

payment order on the basis of the e-invoice (including in the case of e-invoice standing order

service), the bank shall proceed from the data in the PaymentInfo element.

2.3 Example of e-invoice in the form of XML conforming to the Estonian e-

invoice supplemented description The following is an example of an e-invoice conforming to the Value Added Tax Act, in the form of an

XML file conforming to the supplemented Estonian e-invoice description:

<?xml version="1.0" encoding="UTF-8"?>

<E_Invoice xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="e-

invoice_ver1.11.xsd">

<Header>

<Date>2012-11-01</Date>

<FileId>123456</FileId>

<AppId>EARVE</AppId>

<Version>1.1</Version>

<SenderId>SENDER</SenderId>

<ReceiverId>RECEIVER</ReceiverId>

</Header>

<Invoice invoiceId="45678" regNumber="123456" serviceId="1234" channelId="ABCDEE2X"

channelAddress="EE306240693469621624" presentment="YES" invoiceGlobUniqId="ARVE_123456"

sellerContractId="Contract" sellerRegnumber="1234">









<InvoiceParties>

<SellerParty>

<Name>TESTSELLER AS</Name>



Page 9 / 20

<RegNumber>1234</RegNumber>

<VATRegNumber>EE1234</VATRegNumber>

<ContactData>

<LegalAddress>

<PostalAddress1>KAIKA 2</PostalAddress1>

<City>Tallinn</City>

</LegalAddress>

</ContactData>

<AccountInfo>

<AccountNumber>12345678910</AccountNumber>

<BankName>Bank</BankName>

<IBAN>EE765408082924162799</IBAN>

</AccountInfo>

</SellerParty>

<BuyerParty>

<Name>TESTBUYER AS</Name>

<RegNumber>12345678</RegNumber>



<ContactData>

<LegalAddress>

<PostalAddress1>KAIKA 2</PostalAddress1>

<City>Tallinn</City>

</LegalAddress>

</ContactData>

</BuyerParty>

</InvoiceParties>

<InvoiceInformation>

<Type type="DEB"/>

<DocumentName>Invoice</DocumentName>

<InvoiceNumber>45678</InvoiceNumber>

<InvoiceDate>2012-11-01</InvoiceDate>

</InvoiceInformation>

<InvoiceSumGroup>

<InvoiceSum>1.12</InvoiceSum>

<VAT>

<VATRate>0</VATRate>

<VATSum>0</VATSum>

</VAT>

<TotalSum>1.12</TotalSum>

<Currency>EUR</Currency>

</InvoiceSumGroup>

<InvoiceItem>

<InvoiceItemGroup>

<ItemEntry>



<Description>Service purchased</Description>

<ItemDetailInfo>

<ItemUnit>qty</ItemUnit>

<ItemAmount>1</ItemAmount>



<ItemPrice>1.12</ItemPrice>

</ItemDetailInfo>

<ItemSum>1.12</ItemSum>



<VAT>

<VATRate>0</VATRate>

<VATSum>0</VATSum>

<!—VAT rate-->

</VAT>

<ItemTotal>1.12</ItemTotal>

Page 10 / 20



</ItemEntry>

</InvoiceItemGroup>

</InvoiceItem>

<AdditionalInformation>

<InformationName>Reminder</InformationName>

<InformationContent>We appreciate timely payment!</InformationContent>

</AdditionalInformation>

<PaymentInfo>

<Currency>EUR</Currency>

<PaymentRefId>1234567</PaymentRefId>

<PaymentDescription>Invoice 45678</PaymentDescription>

<Payable>YES</Payable>

<PayDueDate>2012-11-15</PayDueDate>

<PaymentTotalSum>1.12</PaymentTotalSum>

<PayerName>TESTBUYER AS</PayerName>

<PaymentId>45678</PaymentId>

<PayToAccount>EE765408082924162799</PayToAccount>

<PayToName>TESTSELLER AS</PayToName>

</PaymentInfo>

</Invoice>

<Footer>

<TotalNumberInvoices>1</TotalNumberInvoices>

<TotalAmount>1.12</TotalAmount>

</Footer>

</E_Invoice>

Page 11 / 20

3 Use-case: e-invoice presentment at bank

In addressing the e-invoice, the bank shall use the following attributes of the <Invoice> element:

1. channelId (BIC code, which identifies the payer bank)

2. channelAddress (account number or personal identification/registry code, which identifies

the specific payer to whom the e-invoice is shown). If the channelAddress is incorrect or the

bank is not able to identify a payer conforming to that address, the bank shall notify the e-

invoice sender of the incorrect address (see 3.4). If the address is an account number, the

IBAN and BBAN formats shall be used in parallel during the transition period.

3.1 E-invoice presentment in full in the bank’s electronic channels E-invoice presentment at the bank takes place only if bank services so permit. If it is not possible to

display the e-invoice in full but the bank has a standing order agreement for automatic payment of

e-invoice, the e-invoice sender shall be notified with the relevant information in the unsuccessful e-

invoices file (chapter 3.4). The e-invoice shall be displayed in full – that is, with all of the information

– to the payer, if:

1. the attribute “presentment“ in the <Invoice> element of e-invoice is missing or

2. the value “YES” has been assigned to the attribute “presentment“.

Internet bank users can open the e-invoice in HTML format in order to browse the goods or services

listed on the e-invoice. They can also print out the e-invoice in PDF format. The invoice is displayed

to the customer in the standard design, unless agreed otherwise with the seller.

The information in the e-invoice <PaymentInfo> element is displayed to the payer by payment order.

If the bank provides e-invoice standing order service, the payer can configure e-invoice standing

order service and e-invoices that arrive in future will be automatically paid – pursuant to the

payment order information specified by the seller (amount, payment term, reference number,

payment order explanation etc.). Precise list in chapter 2.2.7.

Example of standard e-invoice design.

Page 12 / 20

3.2 E-invoice limited presentment via bank’s electronic channels The e-invoice is displayed in limited extent to payers if the value “NO” has been assigned to the

“presentment“ attribute of the <Invoice> element.

The seller shall assign the value “NO” if:

1. To the seller’s knowledge, the payer does not have access to the bank’s electronic channels

but wishes to use e-invoice standing order service.

The e-invoice arrives at the bank and the bank executes the payment pursuant to the

conditions for the e-invoice standing order service. Full presentment of the invoice does not

take place.

2. The payer is not the buyer and does not have privileges for obtaining detailed e-invoice

information but, on agreement with the buyer, wishes to pay the e-invoice from his/her own

account.

If the payer has access to electronic banking service, only the payment order data are

displayed to the payer accompanied by the information described below. Full presentment

of the invoice does not take place.

If the full presentment of the e-invoice does not take place, the bank is justified to show the payer

solely the following invoice information over the electronic banking channel:

Page 13 / 20

payment order information (chapter 2.2.7) – PaymentInfo

seller information – InvoiceParties. SellerParty.Name, InvoiceParties. SellerParty.RegNumber

buyer information – InvoiceParties. BuyerParty.Name

invoice date – InvoiceInformation.InvoiceDate

If the seller sends to the bank an e-invoice for limited presentment, the seller must take into

consideration that the full delivery of the e-invoice to the buyer will not take place through the bank

and sending of the invoice in full shall take place pursuant to agreement between the seller and

buyer in some other manner.

If the seller sends the e-invoice to the payer with limited presentment (Presentment = NO) and

sends to the buyer an e-invoice or invoice in some other form, it is advisable for the seller to notify

the buyer of the secondary sending of the e-invoice (e.g.: “This invoice has additionally been sent to

bank ‘X’ at address ‘Y’.“)

3.3 E-invoice standing order service Provision of the e-invoice standing order service depends on the bank. An e-invoice sent to the bank

can be paid by the payer either by approving a pre-filled-in payment order on the basis of each e-

invoice singly or by entering into an e-invoice standing order agreement, if the payer bank provides

e-invoice standing order service as a possibility of paying e-invoices. E-invoice standing order

agreement can in general be concluded on the basis of an e-invoice already sent to the bank in

advance, or then simply to enter into an e-invoice standing order agreement using the seller’s data

and the unique code of the buyer’s service agreement at the seller (serviceId).

In preparing the e-invoice standing order agreement, the bank must notify the seller that the e-

invoice standing order service works only if the seller sends the e-invoice to the bank. In order for

the seller to know to send the e-invoice to the bank, the bank must refer the payer to the seller or

help the payer to set up a corresponding e-invoice request to the seller via the bank (chapter 4).

Upon terminating an e-invoice standing order agreement, the bank must notify the payer that

termination of the e-invoice standing order agreement does not terminate sending of the e-invoice

to the bank. If the payer wishes to also terminate sending of e-invoices to the bank, the bank must

refer the payer to the seller or help the payer to set up a corresponding e-invoice request to the

seller via the bank (chapter 4).

3.4 Unsuccessful presentment of e-invoice by bank (VEA) By agreement, the bank shall verify at least the following parameters on e-invoices sent to it:

Conformity of file to agreed-upon e-invoice description (XML validation)

Business-logic and technological verification of information in file

If any of the verifications are unsuccessful or if the bank is unable for some reason to send the e-

invoice to the payer, the bank shall not accept the e-invoice for processing and notify the e-invoice

sender with the corresponding error codes.

Page 14 / 20

Error code Reason

File-related errors

51,62 file structure incorrect

59 lacks reference DTD or XSD file

85 file sender/recipient incorrect

64,65 file with same ID or name already exists

56 total invoices amount in file incorrect (the TotalAmount element in the Footer element)

61 total number of invoices in file incorrect (the TotaNumberInvoices element in the Footer element)

81,66 AppId incorrect

63 file name does not conform to standard

E-invoice header related (element Invoice) errors

82 file is lacking e-invoice address

3, 10 e-invoice address does not exist at bank

22 e-invoice address is not intended for sending e-invoices (because it is not a current account or related reason)

32,33 e-invoice addressee lacks electronic possibility for presenting invoice (Internet bank lacking or closed)

86 e-invoice addressee lacks possibility for presenting invoice electronically (Internet bank lacking or closed) but a standing order service agreement has been concluded for the invoice serviceId

20 e-invoice address is temporarily unavailable (account blocked, Internet bank agreement blocked etc)

21 e-invoice address is idle (has not been used for a long time)

76,78 e-invoice channel is incorrect

87 An e-invoice with the same invoiceGlobUniqId from the same e-invoice sender exists

80 serviceId incorrect (does not conform to seller’s agreement)

18 e-invoice not issued to buyer

Invoice content related errors

14 the e-invoice information needed for factoring is incorrect

79 buyer’s postal address missing

Seller-related errors (if the seller information is verified)

11 e-invoice’s seller information (registry code) incorrect

57 seller’s agreement missing/blocked

70 seller lacks privilege to send e-invoices

E-invoice payment order information related errors (PaymentInfo element)

6 reference number incorrect (PaymentRefId element does not conform to standard)

50 payment order reference number and details missing (PaymentRefId=““, PaymentDescription=““)

9 amount payable incorrect (PaymentTotalSum<0)

7 currency payable incorrect (Currency)

49 e-invoice payment due date incorrect (PayDueDate<Today)

Page 15 / 20

12 e-invoice with the same PaymentId from the same seller exists (If invoiceGlobUniqId is not specified for the invoice, the uniqueness of the PaymentId shall be verified in the PaymentInfo element.)

48 PaymentId missing

54 payee’s pay-to account incorrect (PayToAccount)

55 seller incorrect (PayToName), can be verified if the seller’s bank is the same as the payer’s bank

88 BIC code incorrect (PayToBIC)

The bank responds to a unsuccessful e-invoice with an XML message with the following structure:


<FailedInvoice>

<Header appId="VEA" date="2012-11-01" receiverId="RECEIVER" senderId="SENDER"/>

<Invoice>

<ChannelId>ABCDEE2X</ChannelId>



<InvoiceId>1234</InvoiceId>



<InvoiceGlobUniqId>123456</InvoiceGlobUniqId>



<ServiceId>1234</ServiceId>



<SellerRegNumber>12345678</SellerRegNumber>



<FailReason>33</FailReason>



</Invoice>

<Footer totalNr="1"/>

</FailedInvoice>

Page 16 / 20

4 Ordering e-invoices via bank

4.1 Submitting e-invoice request to seller via bank As of agreed with seller, the bank may intermediate the payer’s e-invoice order request – the payer’s

e-invoice request.

In general, the e-invoice can be ordered to the bank only by the buyer, i.e. a person who has

concluded an agreement with the seller. The bank must notify the person submitting the request

that in order to order an e-invoice the submitter of the request must be the buyer. A possible

exception can be a case where the e-invoice is ordered by the payer who is not the buyer but who

wishes to pay by e-invoice upon agreement with the buyer (invoice sent with limited presentment

possibilities) (see chapter 3.2 Type=Pay).

The bank must notify the person ordering the e-invoice (the person submitting the e-invoice

request) that the e-invoice can be ordered solely by the buyer (i.e. the person who has concluded an

agreement with the seller). In addition to the above, the person ordering must be aware that

ordering the e-invoice to the bank (Type=Full) will cancel other means of sending invoice or e-invoice

by the seller, except for limited presentment e-invoice (Type=Pay), if the latter is addressed to

another address. If the person ordering the e-invoice is not the buyer but still wishes to pay a

specified e-invoice, they must order the e-invoice to the bank with the limited presentment option.

The person ordering must take into consideration the possibility that the seller may not necessarily

send out the e-invoice without a respective agreement with the buyer. If, as a result of the request,

the seller sends the invoice with limited presentment option to the bank to a payer who is not the

buyer, the seller shall still send the full invoice in the form agreed upon with the buyer.

The payer may, at the bank, add to the e-invoice ordered to the bank the e-invoice standing order

service (see chapter 3.3) if the bank enables it.

If the payer wishes to discontinue via the bank the e-invoice (and submits a relevant request to the

seller through the bank), the bank must recommend that the payer discontinue the e-invoice

standing order service agreement made on the basis of the relevant e-invoice.

In addition to bank channels, the payer can submit to the seller the request to change the e-invoice

address through various channels (e.g. in the seller’s self-service or operator’s e-invoice

environment). The seller must, if possible, inform the payer that the latter’s wish to change the e-

invoice address may lead to a situation where the payment of the relevant e-invoice at the bank will

no longer take place using the e-invoice standing order service (if the payer had e-invoice standing

order service at the bank to which the e-invoice was previously sent). The payer must make sure that

the relevant e-invoice would be paid in some other manner.

4.2 E-invoice ordering message from bank to e-invoice sender (EAA – e-invoice

request) Upon ordering the e-invoice, the bank shall send a message with the relevant content to the seller: <?xml version="1.0" encoding="UTF-8"?>

<ApplicationBank appId="EAA" date="2012-11-01" receiverId="RECEIVER" senderId="SENDER">

Page 17 / 20

<Application>

<SellerRegNumber/>

<-- mandatory, seller’s registry/personal identification code-->

<SellerContractId/>



<Action/>



<ServiceId/>



<ChannelId/>



<ChannelAddress/>



<PresentmentType/>



<CustomerIdCode/>



<CustomerName/>



<CustomerEmail/>



<CustomerPhone/>



<TimeStamp/>



</Application>

</ApplicationBank>

Page 18 / 20

4.3 Seller/buyer hierarchy (explanatory image)

seller's reg code / personal identification

code

seller

seller Contract ID 1

if one seller has more than one e-invoice agreement that are managed separately

buyer's reg code or personal identification

code 1

buyer

ServiceId 1

buyer's agreement with seller identifies one

group's services

Objects and other logical items subject to being

settled in the jurisdiction of ServiceId

ServiceId 2

buyer's agreement with seller identifies a second

group's services

seller Contract ID 2

if one seller has more than one e-invoice agreement that are managed separately

buyer's reg code or personal identification

code 1

buyer

ServiceId 3

buyer's agreement with seller identifies one

group's services

Objects and other logical items subject to being

settled in the jurisdiction of ServiceId

ServiceId 4

buyer's agreement with seller identifies one group's services

Page 19 / 20

5 Seller agreement

5.1 Entering into seller agreement An e-invoice agreement for sending e-invoices to the bank’s electronic channels shall be concluded

with the seller.

The following parameters are important when entering into an agreement with the seller:

operator code (<Operator>) – code of operator who intermediates the seller’s e-invoices to

the bank;

name of seller (<SellerName>);

registry or personal identification code of seller (<SellerRegNumber>);

seller’s contract ID (distinguishes different agreements of the same seller if the latter wishes

to treat e-invoices for different services in a different manner ) (<SellerContractId>);

seller’s contract parameter, as to whether the seller wishes to send to the bank also e-

invoices meant for limited presentment (whether the seller uses the “Presentment=NO”

parameter) (<LimitedPresentment>);

seller’s agreement parameter, as to whether the given seller allows the e-invoice request to

be presented through the bank (<OrderInBank>);

seller’s serviceId name and verification rules;

design – whether the standard design or special design is used (<Design>);

beginning and end of the e-invoice payment period, as optional information

(<PaymentPeriod>).

5.2 Notification of seller agreement and responding to the latter – SCNew

and SCAcc formats If the seller’s e-invoice contract was concluded at the operator, the latter may notify the bank(s) of

the addition of a new seller by way of notification in XML format.


<SellerContractNew appId="SCNew" date="2012-11-01" receiverId="RECEIVER" senderId="SENDER">

<SellerContract>

<ChannelId>DCBAEE2X</ChannelId>



<SellerName>TESTSELLER</SellerName>









<Design>DESIGN</Design>



<LimitedPresentment>YES</LimitedPresentment>



<Ordering>

Page 20 / 20



<OrderInBank>YES</OrderInBank>



<NameOfServiceId>Contract number</NameOfServiceId>



<MinLength>5</MinLength>



<MaxLength>6</MaxLength>



<CheckDigit>YES</CheckDigit>



</Ordering>

<PaymentPeriod>



<FirstDay>10</FirstDay>



<LastDay>20</LastDay>



<Accepted>YES</Accepted>



<SellerName>TESTSELLER</SellerName>









<Comment>123456789</Comment>



</ContractAccepted>

</SellerContractAccepted>

Guidelines for Description of Estonian Electronic Invoice ... · Page 5 / 20 2 Use-case: sending e-invoice to the bank and e-invoice standing order service With regard to the use

Documents