Estonia E-Invoicing Requirements: Recipient Routing Guide

Since 1 July 2025, an Estonian accounting entity marked as an e-invoice recipient in the commercial register may require its supplier to submit a structured e-invoice. The European Commission's Estonia eInvoicing country page confirms that all accounting entities registered as e-invoice recipients are entitled to receive e-invoices by default and that all public-sector entities are registered. EN 16931 is the default standard when the parties have not agreed another relevant standard, while there is no equivalent B2C mandate.

These Estonia e-invoicing requirements are driven by the buyer's registry status, not by a universal network mandate. The status establishes whether the buyer can invoke the registered-recipient rule; the operator or endpoint still determines how the invoice reaches it.

An e-invoice in this context is structured data that an accounting system can process automatically. A PDF attached to an email is an electronic document, but it is not a machine-processable e-invoice merely because it was sent digitally.

Use this four-scenario decision aid:

• Estonian public-sector body: The body is registered as an e-invoice recipient and can require a structured invoice. Start with EN 16931 unless another relevant standard has been agreed, then verify the exact legal recipient and its receiving operator or endpoint.
• Registered private-sector accounting entity: The buyer may require the seller to submit an e-invoice. Start with EN 16931 unless the parties agree another relevant standard, then route through the named operator, an interoperable provider, or a confirmed Peppol endpoint.
• Unregistered private-sector accounting entity: The statutory recipient-registration right does not establish a default demand for an e-invoice, although the parties can agree to exchange one. Obtain written format and channel instructions rather than inferring acceptance from the company name.
• Consumer: B2C e-invoicing is not mandatory under this regime. Follow the invoicing form permitted for the transaction and accepted by the consumer rather than the recipient-register route.

The register therefore answers the first question: can this buyer invoke the registered-recipient rule? The operator or channel data answers the second: where must the structured invoice go? A supplier needs both answers. A correct EN 16931 invoice sent to an unconfirmed endpoint can still fail operationally, just as a PDF delivered to the right email address can fail the structured-invoice requirement.

Check the buyer in Estonia's e-Business Register

Start with the buyer's legal identity, preferably the eight-digit Estonian registry code shown on its order or contract. A trading name can point to the wrong company in a group; an exact registry code avoids that ambiguity.

For a manual check:

1. Open RIK's English detailed search of a legal person.
2. Search by registry code or VAT number. If only a name is available, use the legal name and verify the address before continuing.
3. Open the matching company card or its PDF extract.
4. Find Receipt of e-invoices. A populated field identifies the receiving service provider shown in the register.
5. Save a dated extract or record the result in the vendor master together with the registry code.

A populated receipt field establishes that the entity has a registered receiving relationship and supplies the operator clue needed for routing. If the field is absent, do not turn that absence into a guessed delivery rule. Ask the buyer to confirm whether it wants a structured invoice by agreement, which format it accepts, and which channel should receive it. An email address in the contact section does not prove that an attached PDF satisfies the buyer's invoicing instructions.

Teams that need to validate many customers can use RIK's contract-free query for e-invoice recipients. The query accepts registry codes. Its response can include the customer's registry code, name and teenusepakkuja, the service-provider identifier, along with a processing status. RIK defines OK as a valid relationship; the other documented outcome covers a code that was not found, is faulty, or has no active relationship.

The human-readable provider name and the machine-facing service-provider identifier serve different purposes. Store the raw returned value and pass it to the supplier's e-invoice operator or integration team. Do not rewrite it as a Peppol address: the register response identifies the recipient relationship, while the sending provider still has to resolve the network route and endpoint.

Turn the register result into a working delivery route

Give the register's operator or channel information to the supplier's own e-invoice provider. The provider should confirm that it can reach the recipient through a direct connection, a roaming agreement with the Estonian operator, or a Peppol access point. Estonia uses a decentralized model: the register identifies who receives for the buyer, but it does not force every invoice through one government platform.

Format and transport are separate decisions. EN 16931 defines the semantic content of a compliant European e-invoice. It does not prescribe one operator, network or XML syntax. When a registered Estonian recipient demands an e-invoice, EN 16931 is the default if the parties have not agreed another relevant standard. A buyer and supplier can agree a different permitted format, but that agreement should be explicit enough for both systems to validate the same payload.

Peppol is one possible transport route, not a universal Estonian requirement. OpenPeppol's official participant-identifier code list assigns scheme 0191 to Estonia's company code, an eight-digit registry identifier. That makes 0191 plus the registry code a common basis for an Estonian participant ID. It does not prove that a particular company is registered on Peppol or can receive the intended invoice profile.

Before sending through Peppol, have the buyer or access point confirm the exact participant identifier, supported document type and process capability. Before sending through an operator-to-operator route, have the sending provider resolve the service-provider identifier returned by the register. In either case, validate the payload against the agreed profile before transmission.

For the first live invoice, the routing record should contain:

• the buyer's legal name and registry code;
• the receiving operator or exact endpoint;
• the agreed standard, syntax and profile;
• required buyer references, including a purchase-order, contract or contact reference where applicable;
• the successful validation result; and
• a network delivery acknowledgement or recipient acceptance message.

A transport acknowledgement proves that the network handled the message. It is not always the same as business acceptance by the buyer's AP system, so retain both when the route produces both statuses.

When E-arveldaja is a practical sending option

E-arveldaja, called E-Financials in RIK's English guidance, is web-based accounting software in the e-Business Register portal. It can create and send structured invoices, but it is not a central clearance platform through which every invoice in Estonia must pass.

RIK's E-Financials sending guidance states that businesses can send e-invoices to the public sector free of charge in unlimited numbers and without a time limit. That condition is narrower than “E-arveldaja is free”: the no-charge treatment applies when the environment is used to create and send digital invoices to public authorities and no other accounting entries are made. Private-sector use and broader bookkeeping activity are subject to the service's normal contract and pricing rules.

The documented access path assumes an eligible entity and Estonian electronic identification:

1. Sign in with an Estonian ID card, Mobile-ID or Smart-ID.
2. Select the associated entity in the portal.
3. Conclude the E-Financials software agreement.
4. Create and confirm the sales invoice.
5. Choose the e-invoice sending option when the system makes it available for that customer.

RIK lists management-board members of Estonian companies, partnerships, non-profit associations, foundations and European companies, as well as self-employed persons, among those who can conclude the contract. Authorized users such as accountants can work in the environment once the entity and access relationship have been established.

E-Financials connects to operators operating in Estonia and can send to those operators' customers. If the e-invoice option is unavailable for the chosen customer, RIK notes two practical causes: the recipient may not have selected a receiving operator, or the invoice may need to name a different legal recipient. For example, the responsible municipality rather than a subordinate institution may be the registered party.

A foreign supplier without the required entity relationship or Estonian login method should not plan around E-arveldaja. Its own e-invoice operator, a Peppol access point, or the route nominated by the Estonian buyer is the workable alternative.

A routing workflow for non-resident suppliers

The supplier's country of establishment does not replace the buyer-status test. If the Estonian customer is a registered recipient and invokes its right to an e-invoice, a foreign supplier should not assume that a PDF becomes acceptable because it lacks Estonian accounting software or digital identity. The buyer and its receiving provider determine the cross-border route that can carry the required structured invoice.

Use this sequence before the first invoice:

1. Resolve the contracting entity. Match the purchase order or contract to the Estonian legal name and eight-digit registry code.
2. Capture the recipient record. Record the receiving operator shown in the e-Business Register, or obtain the buyer's written confirmation if the record is absent or unclear.
3. Confirm the delivery specification. Ask the buyer for its exact endpoint, the accepted EN 16931 profile or agreed alternative, mandatory buyer references, and any test-invoice procedure.
4. Prove reachability. Have the supplier's operator or Peppol access point confirm that it can reach the nominated recipient before releasing a production invoice.
5. Validate and monitor. Validate the structured file, retain the transmission ID, and monitor both technical delivery and business acceptance or rejection.

If the sending platform cannot reach the named Estonian operator, the providers should determine whether a roaming connection exists. Otherwise, ask the buyer for another endpoint it actively supports. Replacing the structured payload with an email attachment is a valid fallback only when the buyer agrees to that form and the applicable rule permits it.

The neighboring systems are useful comparisons only when their different mechanics remain visible. Finland's e-invoicing requirements and address-registry model likewise make reliable recipient addressing operationally important. By contrast, Lithuania's SABIS public-sector e-invoicing workflow uses a named public-sector system and should not be copied onto Estonia's decentralized operator model.

Retain the dated registry result or buyer confirmation, the agreed format and channel, the validation report, the network transmission identifier, and the acceptance or rejection response. If an invoice is rejected and corrected, keep the rejection reason and the link between the original and resubmitted message.

Archive the invoice and transmission evidence for seven years

Estonia's Accounting Act requires an accounting entity to preserve an accounting source document for seven years from the end of the financial year in which the underlying transaction was recorded. The clock therefore starts at the relevant financial year-end, not on the invoice's issue date alone.

Section 12 of the current Accounting Act also governs the form of preservation. The documents and data must be kept in machine-processable form, with written reproducibility, plain-text legibility and evidential value maintained throughout the retention period. Another form that can continuously be reproduced in writing is permitted only where creating machine-processable preservation would require disproportionate cost or effort.

Storage outside Estonia is not prohibited by a blanket location rule. Under the Value-Added Tax Act's record-keeping provisions, a taxable person may choose where and how invoices are stored on the condition that the invoices, or the information stored in them, can be made immediately available to the Estonian tax authority on request. Where VAT on the transaction is payable in another Member State, the same immediate-access condition extends to that state's competent authority.

An operator's “delivered” status is only one part of the retained record. A controlled archive for structured invoices should keep:

• the original structured payload and a legible rendering;
• any attachment or external document incorporated into the invoice record;
• the syntax and business-rule validation result;
• the operator, endpoint and transmission identifiers;
• delivery, acceptance and rejection messages; and
• a stable link from those records to the accounting entry and any corrected invoice.

The cited provisions do not set out one standalone tariff for a “wrong e-invoice.” A failure can instead engage the particular accounting, invoice, audit or tax obligation that was breached. Penalty figures copied from general compliance summaries are therefore unsafe unless they are tied to the applicable offence, enforcement authority and current statutory basis.

What is enacted now, and what remains proposed for 2027

Status at 16 August 2026: Estonia's enacted e-invoice exchange rule remains the buyer-choice regime in section 7¹ of the Accounting Act. An accounting entity registered as an e-invoice recipient may require the seller to submit an e-invoice, and EN 16931 is the default standard unless the parties agree another relevant standard.

KMD INF is a separate VAT reporting obligation. It reports specified sales- and purchase-invoice data to the Estonian Tax and Customs Board; it is not an e-invoice transport network and does not show that a buyer has a receiving endpoint. Under the current KMD INF guidance, the reporting rule generally uses a EUR 1,000 transaction-partner threshold within the tax period for the covered domestic invoices, subject to the stated scope and exclusions.

The frequently reported 2027 universal mandate comes from a reform proposal, not from the current buyer-choice provision. On 4 December 2024, the Ministry of Finance proposed mandatory e-invoicing for VAT-registered B2B transactions together with removal of the EUR 1,000 reporting threshold. The ministry said an act developed from that proposal could take effect in 2027.

A later EIS consultation entry, RAM/26-0853, opened on 27 July 2026 around a draft dated 25 June 2026, does not enact that proposal. Its published draft package concerns VAT-refund conditions and invoice evidence for foreign missions, diplomats and specified defence-related recipients; it does not introduce a universal B2B e-invoice duty.

The European Commission country page still describes that direction, but it also says drafting was expected in 2025. That timetable is no longer a reliable description of the legislative stage. Based on the current Accounting Act and published Value-Added Tax Act texts reviewed for this guide, no universal domestic B2B e-invoice mandate with a 2027 commencement date had been enacted by 16 August 2026. This is a status finding, not a prediction that the proposal will be abandoned.

An ERP or supplier-policy change should be triggered by an adopted amending act in Riigi Teataja, not by a target year in a consultation summary. Check the final scope, definitions, exceptions and commencement provisions, then look for implementing guidance from the Ministry of Finance or the Estonian Tax and Customs Board before changing validation profiles or routing instructions.