E-invoicing in Estonia: a practical guide for businesses

What is an e-invoice in plain English?

A normal PDF invoice is primarily designed for a person: it can be opened, read, printed or emailed. An e-invoice is a structured electronic document that another software system can interpret automatically.

The receiving system can identify the seller and customer, invoice number and date, line items, quantities, prices, VAT, total amount, payment due date and payment information. The buyer’s accounting software does not merely display the invoice — it can process the invoice data.

The value of an e-invoice is not the XML file itself. The value is that the same information can move from one system to another without being entered manually again.

• An e-invoice is not a PDF: it is a structured, machine-readable document.
• You do not need to create XML by hand: Arveteha prepares the technical invoice data from the invoice you already created.
• The recipient must be able to receive e-invoices: Arveteha checks recipient availability before sending.

A PDF and an e-invoice are not the same thing

Take a simple example: a company provides a service worth €500. A human-readable invoice might travel as Company → PDF → email → customer. The same transaction as a machine-readable invoice can travel as Company → Arveteha → e-invoicing infrastructure → customer system.

The commercial transaction does not change: the seller, customer, invoice number, amount, VAT and payment due date are the same. What changes is how the invoice data reaches the customer.

A PDF effectively says: “Here is a document — please read it.” An e-invoice says: “Here is structured invoice data — process it.”

Why does e-invoicing need infrastructure?

If every business used the same software, e-invoicing would be simple. In reality, the seller may use one system and the buyer another. One customer accepts PDF invoices, another expects e-invoices, a third uses an ERP system and a fourth has its own accounting platform.

That is why generating XML is only one part of the process. A complete e-invoicing workflow may need to structure the invoice data, identify the recipient, check whether the recipient can receive e-invoices, prepare the correct document, send it through the infrastructure and report the result.

How does an e-invoice move in Estonia?

Estonia uses a decentralised e-invoicing environment. Businesses do not all have to use one central application: different accounting and invoicing systems can be connected through e-invoicing infrastructure.

In simplified form, the route is: Seller → seller software → e-invoicing infrastructure → buyer software → accounting.

For an Arveteha user, the experience should feel simpler: Seller → Arveteha → e-invoice → buyer. The user should not have to manage every technical step in between.

Where does Arveteha fit in?

Arveteha sits on the seller’s side of the process — this is where the invoice is created. The system already contains the information about who is selling, who is buying, what is being sold, the price, the VAT treatment and the payment terms.

The same invoice data can be used to produce a PDF for a person or structured data for system-to-system delivery. You create the invoice once. After that, you choose how it should be delivered to the customer.

That means the e-invoice does not have to be rebuilt in a separate service. The customer, products, invoice lines, VAT and payment details are already in Arveteha.

How to send an e-invoice with Arveteha

1. Create and confirm the invoice. Select the company and customer, add products or services, quantities, prices, VAT and payment terms. Review the seller, buyer and invoice-line information and confirm the invoice.
2. Choose e-invoice sending. On the confirmed invoice, select the e-invoice sending option. You do not need to download an XML file and upload it to a separate service.
3. Arveteha checks whether the recipient can receive the e-invoice. If the recipient has e-invoice reception enabled, you can continue. If not, Arveteha tells you before the invoice is sent.
4. Confirm the sending action. Arveteha prepares the machine-readable data and passes the document into the e-invoicing infrastructure.
5. Check the result. The interface shows the sending result or status. The recipient system receives structured invoice data so the core information does not have to be typed in again.

Why is an XML file alone not enough?

E-invoices are often associated with XML, which can make the process sound like nothing more than clicking “Download XML”. In practice, XML is only one technical component.

The wider process is: invoice data → machine-readable document → validation → recipient identification → sending → delivery → processing in the buyer’s system.

So an e-invoicing service is not simply an XML generator. It is a complete electronic document-exchange workflow.

Why e-invoicing matters more in Estonia now

From 1 July 2025, an accounting entity that is registered in the Estonian Commercial Register as an e-invoice recipient may require the seller to issue an e-invoice. Unless the parties agree otherwise, the statutory starting point is an e-invoice that complies with the European standard EN 16931-1.

One customer may ask for an invoice by email, while another simply says: “Please send an e-invoice.” For the seller, it is much easier when both delivery options are available in the same invoicing workflow.

You should not need two separate invoice-creation processes. One customer can receive a PDF and another an e-invoice — the delivery channel changes, not the work of creating the invoice.

2-corner, 3-corner and 4-corner models: how systems connect

2-corner model: the seller system connects directly to the buyer system. This can work between two large long-term partners, but it does not scale well when a business has many customers using different systems.

3-corner model: the seller and buyer use the same service provider. This is simpler, but the model becomes restrictive when the parties want to use different providers.

4-corner model: the seller has one service provider and the buyer has another. The providers communicate with each other, allowing both businesses to keep working in their preferred systems.

For an Arveteha user, the practical point is straightforward: you should not have to log into your customer’s software just because the customer uses a different system. Create the invoice in Arveteha and let the infrastructure handle the route.

A mobile-network analogy — and where Peppol fits

Think about mobile networks. You may use one mobile operator while your customer uses another. You do not need to become a customer of their operator just to call them — the networks handle the connection.

Peppol becomes especially relevant when structured business documents need to move across systems and national borders. It provides an international interoperability framework and common rules for exchanging standardised business documents.

For an Arveteha user, the principle matters more than the network name: a business should be able to work in its own system while the infrastructure helps the document reach another system.

Delivery is not enough: systems must understand the invoice

E-invoicing has two separate challenges. The first is transport: how the document travels from seller to buyer. The second is semantics: how the buyer’s software knows which value is the invoice number, who the seller is, what VAT applies and how much must be paid.

That is why standards matter. In European e-invoicing, EN 16931 provides a common semantic model for core invoice information so different systems can interpret key business data consistently.

From the user’s perspective, this standardisation should stay in the background. The business works with the invoice content; the software and infrastructure handle the technical format and delivery.

What are you actually paying for with an e-invoicing service?

A PDF can simply be downloaded. With an e-invoice, the value is not the file extension — it is the integrated workflow.

• Machine-readable document creation. Normal invoice data is converted into a structured format.
• Direct sending. You do not have to download a file and upload it into a second environment.
• One workspace. Customers, products, invoices and documents remain in the same system.
• Less repeated work. The same information does not need to be entered multiple times.

The more invoices a business creates, the more visible the time saving becomes. Twenty invoices a month means 240 invoices a year; fifty a month means 600. A few minutes of avoidable manual work can repeat hundreds of times.

Sending e-invoices from Arveteha

Arveteha’s active e-invoice service is designed for sending outgoing e-invoices to businesses.

Create the invoice in the normal way, choose e-invoice sending and Arveteha passes the document through the appropriate official channels to the recipient system.

The recipient must have an e-invoice reception service on their side. Arveteha does not currently provide incoming supplier e-invoice reception.

Which Arveteha plan should you choose?

Business Starter — €0/month.
PDF and XML invoices, invoice export for Estonian accounting software, invoice storage and history, customers, products, services, bank accounts and the core tools needed for everyday invoicing.

Business Pro — €6/month + VAT.
Everything in Business Starter, plus direct e-invoice sending to businesses from Arveteha.

Need a free workspace for PDF and XML invoices? Business Starter.
Need to send e-invoices directly to businesses? Business Pro.

Why does Business Pro cost €6?

Business Pro is not a paid button called “Create XML”. It is a different level of workflow automation.

Instead of create invoice → download file → open another service → find the customer → upload document → send, the workflow can become create invoice → send e-invoice.

The process stays in the same environment where the company, customers, products, services, bank accounts and document history already exist. The value of Business Pro is not the number of files created, but the manual steps the business no longer has to repeat.