Estonian E-invoice Standard

The Estonian e-invoice (e-arve) is a structured XML text file compliant with "Establishment of a Machine-Readable Original Document Guide" regulation. The file contains the same info as a regular invoice, but in a machine-readable format, allowing different accounting programs and systems to interoperate. The development of the Estonian e-invoice format has in practice stopped, but used to be the purview of the Estonian Information Technology and Telecommunications Association's e-invoice working group. You can find the Estonian e-invoice specifications and XML schemas below.

The Estonian e-invoice standard does not cover transmission, but in Estonia, operators (like Billberry) and an operator network have emerged to transmit e-invoices to recipients based on their organization registry codes. Technically, e-invoices can also be transmitted via email or other protocols if both parties agree. However, using operators tends to be more convenient, as many companies' accounting systems have directly integrated with operators. You can send e-invoices for free through Billberry, whether through a web interface or via an application programming interface (API).

Below is a brief description of the Estonian e-invoice standard, in case you wish to generate e-invoices yourself (e.g. for sending from an e-commerce site or another service). As an accountant, it's likely easier to create e-invoices with your accounting software, but for developers generating them shouldn't be difficult. You can find the documentation for sending invoices on Billberry's developer page.

E-invoice XML

As mentioned, the Estonian e-invoice is in the XML format. The XML elements do not have a namespace, so unlike many other XML-based formats, you don't need to specify any xmlns attributes for the <E_Invoice> root element.

Unfortunately, there's no standardized MIME type for e-invoices (e.g. for the HTTP Content-Type headers). Therefore, when uploading them on the web or sending them via email, you should use the general XML MIME type application/xml.

For basic use, creating the XML for an e-invoice is not complicated. A minimal e-invoice with only mandatory fields would look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<E_Invoice>
  <Header>
    <Date>2021-06-18</Date>
    <FileId>aa949b90e0bd214c</FileId>
    <Version>1.2</Version>
  </Header>

  <Invoice
    invoiceId="INV123456"
    regNumber="70000272"
    sellerRegnumber="70004502"
  >
    <InvoiceParties>
      <SellerParty>
        <Name>Kaitseministeerium</Name>
        <RegNumber>70004502</RegNumber>
      </SellerParty>

      <BuyerParty><Name>Rahandusministeerium</Name></BuyerParty>
    </InvoiceParties>

    <InvoiceInformation>
      <Type type="DEB" />
      <DocumentName>Invoice</DocumentName>
      <InvoiceNumber>1337</InvoiceNumber>
      <InvoiceDate>2021-06-18</InvoiceDate>
    </InvoiceInformation>

    <InvoiceSumGroup>
      <TotalSum>13.37</TotalSum>
    </InvoiceSumGroup>

    <InvoiceItem>
      <InvoiceItemGroup>
        <ItemEntry>
          <Description>Üks kalakarp</Description>
        </ItemEntry>
      </InvoiceItemGroup>
    </InvoiceItem>

    <PaymentInfo>
      <Currency>EUR</Currency>
      <PaymentDescription>Invoice 1337</PaymentDescription>
      <Payable>YES</Payable>
      <PayDueDate>2021-07-10</PayDueDate>
      <PaymentTotalSum>12.66</PaymentTotalSum>
      <PayerName>Rahandusministeerium</PayerName>
      <PaymentId>1337</PaymentId>
      <PayToAccount>EE909900123456789012</PayToAccount>
      <PayToName>Kaitseministeerium</PayToName>
    </PaymentInfo>
  </Invoice>

  <Footer>
    <TotalNumberInvoices>1</TotalNumberInvoices>
    <TotalAmount>12.66</TotalAmount>
  </Footer>
</E_Invoice>

You can find the more detailed specification and XML schema at the end of the page, but for an introduction, let's go through the various sections of an e-invoice and the common elements you'll likely need for all e-invoices.

It's important to remember that the e-invoice XML schema defines a specific order for its elements. Even though there's only a single operator as of 2024 validating the element sequence, it's better to create standards compliant e-invoices. Failing to do so, in the best case, you'll receive an error message immediately when sending an invalid invoice. In the worst case, the e-invoice might simply get lost in an operator or accounting service system.

E-invoice File (<E_Invoice>)

The root element of the e-invoice is <E_Invoice>, which I'll be referring to as the "e-invoice file" to distinguish it from individual invoices. Invoices (<Invoice> elements) are children of this root element, between the header <Header> and footer <Footer>. There may be one or more e-invoices, <Invoice> elements, but for simplicity, it is advisable to stick to one. Importing multiple invoices may not be supported in every situation and by every software.

Typically, the header and footer are regenerated by operators during delivery, so you shouldn't rely on information there to reach the recipient.

Header (<Header>)

Only three fields are mandatory in the header: the standard's version number, the file date, and its identifier. The file identifier could be used theoretically to detect duplicates, but as mentioned, operators regenerate the header during delivery, including its <FileId>. Although the latest e-invoice standard carries the version number 1.2.EN, the e-invoice file version should still be set to 1.2.

<Header>
  <Date>2021-06-18</Date>
  <FileId>aa949b90e0bd214c</FileId>
  <Version>1.2</Version>
</Header>

The file identifier is limited to 20 characters, so using a UUID for random identifiers is not possible. Since the operator regenerates the e-invoice file and identifier on delivery anyways, there's no need to worry about the identifier being globally unique either. Typically, systems check the uniqueness of the e-invoice file within the sender's context – different senders can use identical file identifiers.

One optional field I recommend adding to the header is <AppId> – the name and version of the application/system that generated the e-invoice. This can later be useful for identifying the software that generated the invoice — handy for working around app-specific bugs.

<AppId>Moneybooks v1.35</AppId>

Although not all operators retain <AppId> today, it's worth adding to the invoice file for situations where the e-invoice moves outside operator networks or through operators that preserve it. For example, Billberry always forwards the initial <AppId> to other operators.

E-invoice (<Invoice>)

There can be one or more invoices in an e-invoice file. Each invoice's recipient and seller registry code is set as attributes on the <Invoice> element — namely, regNumber and sellerRegnumber. Operators use these to verify the sender and route the invoice to the recipient. The recipient does not have to be the buyer, for example, when the invoice is directed to an accounting firm. The invoice identifier invoiceId should be unique within the e-invoice file, but uniqueness outside a single file does not seem to be enforced by operators or external systems.

<Invoice
  invoiceId="INV123456"
  regNumber="70000272"
  sellerRegnumber="70004502"
>

Parties' Contact Information

Contact information for different parties is described in the <InvoiceParties> element. In addition to the mandatory <SellerParty> and <BuyerParty>, there may be four others.

<InvoiceParties>

The <Invoice> element's sellerRegnumber attribute should match the <SellerParty>'s <RegNumber> element. The <Invoice> element's regNumber attribute (recipient) should match at least one of the other <*Party> element's <RegNumber>. Without this, some operators may not accept the invoice.

<SellerParty>
  <Name>Ministry of Defence</Name>
  <RegNumber>70004502</RegNumber>
</SellerParty>

In addition to the mandatory <Name> and <RegNumber> elements, the VAT registration number <VATRegNumber>, contact information <ContactData> and bank details <AccountInfo> may come inhandy.

<SellerParty>
  <Name>Kaitseministeerium</Name>
  <RegNumber>70004502</RegNumber>
  <VATRegNumber>EE10031337</VATRegNumber>

  <ContactData>
    <PhoneNumber>+3725123456</PhoneNumber>
    <E-mailAddress>info@example.com</E-mailAddress>

    <LegalAddress>
      <PostalAddress1>Narva mnt 1</PostalAddress1>
      <City>Tallinn</City>
      <PostalCode>10123</PostalCode>
      <Country>EE</Country>
    </LegalAddress>
  </ContactData>

  <AccountInfo>
    <AccountNumber>123456789012</AccountNumber>
    <IBAN>EE909900123456789012</IBAN>
    <BIC>EEUHEE2X</BIC>
    <BankName>SEB Pank AS</BankName>
  </AccountInfo>

  <AccountInfo>
    <AccountNumber>123456789013</AccountNumber>
    <IBAN>EE909900123456789013</IBAN>
    <BIC>HABAEE2X</BIC>
    <BankName>Swedbank AS</BankName>
  </AccountInfo>
</SellerParty>

The bank account number also appears later in the <PaymentInfo> element, but the <AccountInfo> element shown above can include multiple accounts for situations where the seller has accounts in multiple banks.

General Information

Then comes the <InvoiceInformation> element for general information.

<InvoiceInformation>
  <Type type="DEB" />
  <DocumentName>Invoice</DocumentName>
  <InvoiceNumber>1337</InvoiceNumber>
  <InvoiceDate>2021-06-18</InvoiceDate>
</InvoiceInformation>

The <Type> specifies whether it is a debit (DEB) or credit invoice (CRE). For credit invoices, you can also include a reference to the previous invoice inside the <Type> element using <SourceInvoice>. Strangely, the reference to the source invoice is limited to only 20 characters, whereas the invoice number allows up to 100 characters.

<Type type="DEB">
  <SourceInvoice>N123</SourceInvoice>
</Type>

The invoice number doesn't have to be just a number. It can be free-form text, up to a maximum of 100 characters. The invoice date is in ISO 8601 format, i.e., YYYY-MM-DD.

The invoice's "name" or <DocumentName> is also free-form text. It was probably intended to better name of special types of invoices (like "cover sheet"), but it's uncertain whether services/accounting programs other than Billberry display the invoice name. For most, specifying the invoice type (<Type>) would suffice, but since <DocumentName> is a mandatory element, it's advisable to set it to "Invoice" or "Arve" ("invoice" in Estonian) there.

Among other allowed fields, the most useful ones are probably the payment due date, late payment interest, and reference number.

<InvoiceInformation>

<InvoiceInformation>
  <Type type="DEB" />
  <DocumentName>Invoice</DocumentName>
  <InvoiceNumber>1337</InvoiceNumber>
  <PaymentReferenceNumber>313373</PaymentReferenceNumber>
  <InvoiceDate>2021-06-18</InvoiceDate>
  <DueDate>2021-07-10</DueDate>
  <FineRatePerDay>2</FineRatePerDay>

  <Period>
    <StartDate>2021-05-01</StartDate>
    <EndDate>2021-05-31</EndDate>
  </Period>
</InvoiceInformation>

Sum

The invoice total, tax-related information, and customer balance are reflected in the <InvoiceSumGroup> element.

<InvoiceSumGroup>
  <TotalSum>13.37</TotalSum>
</InvoiceSumGroup>

While only the final sum <TotalSum> is mandatory, it's worth also specifying the net amount, VAT, and currency.

<InvoiceSumGroup>

<InvoiceSumGroup>
  <Balance>
    <BalanceDate>2021-06-18</BalanceDate>
    <BalanceEnd>-11.15</BalanceEnd>
  </Balance>

  <InvoiceSum>11.15</BalanceEnd>
  <PenaltySum>0.50</PenaltySum>

  <Addition>
    <AddContent>Regular customer discount</AddContent>
    <AddSum>-3.50</AddSum>
  </Addition>

  <VAT>
    <VATRate>20</VATRate>
    <VATSum>2.23</VATSum>
  </VAT>

  <TotalSum>13.37</TotalSum>
  <TotalToPay>25.02</TotalToPay>
  <Currency>EUR</Currency>
</InvoiceSumGroup>

Invoice Lines

Invoice lines – sold goods or services – are defined in the <InvoiceItem> element as groups in <InvoiceItemGroup>.

<InvoiceItem>
  <InvoiceItemGroup>
    <ItemEntry>
      <Description>One fish tank</Description>
    </ItemEntry>
  </InvoiceItemGroup>
</InvoiceItem>

Every e-invoice must have at least one invoice line <ItemEntry>. The only required element for an invoice line is the description <Description>, but similar to the invoice amount element, it's advisable to also include net and gross prices.

<ItemEntry>

<ItemEntry>
  <Description>Calls</Description>

  <ItemDetailInfo>
    <ItemUnit>pcs</ItemUnit>
    <ItemAmount>12</ItemAmount>
  </ItemDetailInfo>

  <ItemDetailInfo>
    <ItemUnit>sec</ItemUnit>
    <ItemAmount>15000</ItemAmount>
  </ItemDetailInfo>

  <ItemSum>9.94</ItemSum>

  <Addition>
    <AddContent>Regular customer discount</AddContent>
    <AddSum>-3.50</AddSum>
  </Addition>

  <VAT>
    <VATRate>20.00</VATRate>
    <VATSum>1.988</VATSum>
  </VAT>

  <ItemTotal>11.928</ItemTotal>
</ItemEntry>

Since e-invoices support grouping of invoice lines (<ItemEntry>), even those invoices do not require grouping must wrap their lines in a <InvoiceItemGroup> element. Grouping of invoice lines can be useful when you want to include different users' expenses on a single invoice. Telephone companies, for example, group expenses made by different phone numbers – call minutes, text messages, etc. Along with the <GroupEntry> element that describes it, a group looks like this:

<ItemEntry>
  <InvoiceItemGroup groupId="5031337">
    <ItemEntry>
      <Description>Calls</Description>

      <ItemDetailInfo>
        <ItemUnit>pc</ItemUnit>
        <ItemAmount>12</ItemAmount>
      </ItemDetailInfo>

      <ItemDetailInfo>
        <ItemUnit>sec</ItemUnit>
        <ItemAmount>15000</ItemAmount>
      </ItemDetailInfo>

      <ItemSum>9.94</ItemSum>

      <VAT>
        <VATRate>20.00</VATRate>
        <VATSum>1.988</VATSum>
      </VAT>

      <ItemTotal>11.928</ItemTotal>
    </ItemEntry>

    <GroupEntry>
      <GroupDescription>Mobile number 5031337</GroupDescription>
      <GroupSum>20.32</GroupSum>
      <GroupTotal>24.384</GroupTotal>
    </GroupEntry>
  </InvoiceItemGroup>
</ItemEntry>

There would be a separate <InvoiceItemGroup> element for each phone number.

Attachment

It's possible to attach a single file with any invoice using the <AttachmentFile> element. Typically, this attachment is a PDF file containing the invoice content, although the idea of e-invoices was to eliminate the need for PDFs.

<AttachmentFile>
  <FileName>invoice.pdf</FileName>

  <FileBase64>
    JVBERi0xLjAKMSAwIG9iajw8L1BhZ2VzIDIgMCBSPj5lbmRvYmogMiAwIG9iajw8L0tpZHNbMyAw
    IFJdL0NvdW50IDE+PmVuZG9iaiAzIDAgb2JqPDwvTWVkaWFCb3hbMCAwIDMgM10+PmVuZG9iagp0
    cmFpbGVyPDwvUm9vdCAxIDAgUj4+Cg==
  </FileBase64>
</AttachmentFile>

Unfortunately, there are multiple operators in Estonia that require PDF attachments with e-invoices. Billberry is not one of them and is trying to convince operators to let go of PDFs. The source of truth is in the e-invoice XML, after all, and including a PDF introduces the risk of data inconsistency and unnecessary complexity. Recipients who need PDFs should generate them with their own accounting software. For e-invoices sent for bank recurring payments, for example, PDFs are not required nor supported.

Convincing other operators takes time, so in the meanwhile, you can be creative with attachments. If you can't generate a PDF for technical reasons, feel free to add a static PDF to the e-invoice with a note saying, "This is an e-invoice."

Payment Info

The last element of an e-invoice includes payment information inside <PaymentInfo>. Most elements there are mandatory.

<PaymentInfo>
  <Currency>EUR</Currency>
  <PaymentDescription>Invoice 1337</PaymentDescription>
  <Payable>YES</Payable>
  <PayDueDate>2021-07-10</PayDueDate>
  <PaymentTotalSum>12.66</PaymentTotalSum>
  <PayerName>Ministry of Finance</PayerName>
  <PaymentId>1337</PaymentId>
  <PayToAccount>EE909900123456789012</PayToAccount>
  <PayToName>Ministry of Defense</PayToName>
</PaymentInfo>

Instead of the payment description, you can also set a reference number.

<PaymentInfo>

The <PaymentInfo> element allows only a single bank account. If the seller has accounts in multiple banks, you can specify different accounts using the <SellerParty> <AccountInfo> elements, as shown in the example above.

Note that in the e-invoice XML schema, the <PaymentRefId> comes before the <PaymentDescription> element, but in the PDF example, the reference number comes after the payment description. In this case, it's best to follow the XML schema.

Footer (<Footer>)

The <Footer> of the e-invoice file is used for verification and contains the total number of <Invoice> elements and the sum of their <PaymentTotalSum> elements (ignoring currency).

In the example invoice above, there was only one <Invoice>, and the amount to be paid was 12.66:

<Footer>
  <TotalNumberInvoices>1</TotalNumberInvoices>
  <TotalAmount>12.66</TotalAmount>
</Footer>

Estonian E-invoice Standard Specifications

Estonian E-invoice v1.1

Published December 1, 2009.

• Estonian e-invoice standard v1.1 (in Estonian)
• Estonian e-invoice standard v1.1 (in English)
• Estonian e-invoice standard v1.1 XML schema (XSD)

Estonian E-invoice v1.11

Published November 1, 2012.

• Estonian e-invoice standard v1.11 XML skeem (XSD)

Differences from v1.1:

• Added the <AppId> element to the <Header> element.
• Added the presentment attribute to the <Invoice> element.
• Added the invoiceGlobUniqId attribute to the <Invoice> element.
• Added the sellerContractId attribute to the <Invoice> element.
• Added the sellerRegnumber attribute to the <Invoice> element.
• Added the <PayToBIC> element to the <PaymentInfo> element.

Estonian E-invoice v1.2

Published December 1, 2013.

• Estonian e-invoice standard v1.2 (in Estonian)
• Estonian e-invoice standard v1.2 (in English)
• Estonian e-invoice standard v1.2 XML skeem (XSD)

Differences from v1.11:

• Added the <AttachmentFile> element to the <Invoice> element.
• Made the sellerRegnumber attribute mandatory for the <Invoice> element.
• Made the <RegNumber> element mandatory for the <SellerParty> element.
• Added the <TransactionPartnerCode> element to the <SellerParty> element.
• Added the <FactorParty> element to the <InvoiceParties> element.
• Changed the data type of the <Description> element within the <ItemEntry> element. <Description> must no longer be empty.
• Added the <GLN> element to the <*Party> (invoice parties) element.
• Made the <VATRate> element mandatory for the <VAT> element.
• Made the <VATSum> element mandatory for the <VAT> element.

E-arveldaja Customizations

The Registry and Information Systems Centre operator, e-arveldaja, validates with a customized schema based on v1.2, that includes stricter requirements for payment information fields.

• Estonian e-invoice standard v1.2 e-arveldaja XML schema (XSD)

Differences from v1.2:

Estonian E-invoice v1.2.EN

Published August 28, 2018.

Expands the v1.2 standard with extensions (<Extension>) that allow for mapping the Estonian e-invoices to and from the European UBL v2.1 and UN/CEFACT Cross Industry Invoice formats.

• Estonian e-invoice standard v1.2.EN (in Estonian)
• Estonian e-invoice standard v1.2.EN (in English)
• Estonian e-invoice standard v1.2.EN XML schema (XSD)