KMD 2027 in Estonia: how e-invoicing changes the flow of VAT data

Enter once, reuse the data

A business creates an invoice once. The document already contains seller and customer details, invoice number and date, amounts, VAT rate and other relevant fields. If the customer or accountant then types the same information into another system and some of it is entered again for tax reporting, the process creates duplicate work and additional opportunities for error.

This does not mean that every e-invoice is automatically sent from the seller directly to the tax authority. The e-invoice provides structured source data. Accounting and VAT treatment still need to be determined and checked before the required reporting data are sent to MTA.

Why e-invoices become more important

A PDF invoice is primarily a document for a person to read. A person can see the invoice number, date, description, amount and VAT, but another software system may still need the information to be re-entered or extracted.

A structured e-invoice works differently. The receiving system can identify fields such as seller, customer, registration number, invoice date, net amount, VAT rate, VAT amount and total automatically.

If the seller has already created correct data once, the buyer or accountant should not have to recreate them. The same source data can then support accounting and, after the proper VAT treatment is applied, tax reporting.

What changes in KMD from 2027?

According to MTA, from April 2027 businesses will submit the transaction and accounting-operation data underlying KMD rather than treating a completed KMD form as the starting point of the submission.

MTA will create the declaration from the submitted data and calculate the tax liability. The business or accountant can retrieve a summary view, detailed view and error report. The resulting declaration must still be confirmed using PIN2.

What does “transaction data” actually mean?

The phrase can sound as if MTA will begin receiving every commercial detail from every invoice — the exact service description, quantities and all line-level business information.

MTA’s own explanation is more specific: the level of detail of invoice data being transmitted does not increase. Instead, data are organised more clearly by transaction types and counterparties, and the relevant transaction or operation type must be selected.

A useful way to understand this is VAT-relevant invoice data plus the tax character of the transaction: who the counterparty is, which document supports the transaction, invoice date and number, relevant amounts and VAT treatment.

Will MTA receive the whole invoice or access accounting software?

No. MTA states that businesses retain control over their data. The business or accountant decides when data are submitted, and MTA does not receive access to the company’s accounting or business software.

MTA also states that it does not receive more information than is required for tax calculation. It is therefore more accurate to describe the reform as structured VAT-data submission, not direct access to a company’s entire accounting database.

Why VAT classification matters more

An invoice amount and VAT rate are not always enough to determine how a transaction should be reported. The tax nature of the transaction matters.

• domestic sales and purchases in Estonia;
• intra-EU supplies and acquisitions;
• exports and imports;
• reverse-charge transactions;
• VAT-exempt turnover;
• credit notes;
• transactions where input VAT deduction is restricted.

This is why KMD automation cannot simply mean adding together all VAT shown on invoices. The system needs to know how each transaction should be treated for VAT purposes.

What about purchase invoices and input VAT?

Suppose a company receives a structured invoice with a net amount of €1,000, VAT of €240 and a total of €1,240. The system can read the €240 VAT amount automatically.

That does not automatically mean that the entire €240 is deductible input VAT. Depending on the transaction, the deductible amount may be full, partial or zero. Structured data reduce manual entry, but professional VAT treatment and control are still required.

What changes for accountants?

Accountants do not disappear. The nature of the work changes. As more information moves automatically between systems, less time should be spent retyping the same figures.

The accountant’s value increasingly lies in data quality, correct tax classification and professional judgement rather than repetitive data entry.

What changes for business owners?

With good software, the practical outcome should be less complexity for the business owner. The owner should not need to learn XBRL GL, XML structures or technical interface specifications — those are primarily software-provider responsibilities.

• Are our invoices created with correct source data?
• Can our business send and receive structured e-invoices?
• Do invoice data reach accounting without retyping?
• Can transactions be given the correct VAT treatment?
• Will our software support the KMD 2027 data-based process?

The old and new data flows

This is why e-invoicing fits naturally with data-based reporting. Structured information exists from the beginning of the process instead of being recreated manually at each later stage.

VD, automation and error control

MTA says that intra-EU turnover information currently reported through the separate VD form will be submitted as part of KMD. This follows the same principle: one data set can support multiple reporting obligations.

Automation can reduce typing mistakes, duplicate entry and figures being copied into the wrong place. It cannot eliminate incorrect tax interpretation. If a transaction is classified incorrectly, software can transmit the wrong data very efficiently.

Control therefore remains essential, but the focus shifts from copying numbers to checking the meaning of the transaction and the resulting VAT treatment.

What should businesses check before spring 2027?

MTA plans to open the new solution for software-provider testing on 1 January 2027 and file-upload testing in the user interface from March 2027.

• ask your software provider whether KMD 2027 support will be included;
• review how much invoice information is still entered manually today;
• use structured e-invoices where practical instead of relying only on PDFs;
• agree with your accountant who is responsible for checking VAT classification;
• do not worry about implementing XBRL GL yourself — the technical format is primarily a software-provider task.

The real meaning of KMD 2027

KMD 2027 is not simply another redesign of a tax form. It changes how businesses, accounting systems and the state can use the same underlying data.

Invoice data created correctly once should be able to move on to the customer, accounting and later tax reporting without being manually re-entered at every stage.

An e-invoice does not replace accounting judgement. It creates better structured source data, while people remain responsible for the part software cannot determine from numbers alone — the substance of the transaction and the correct VAT treatment.