Estonia KMD INF Guide: Threshold, Scope, Deadline

KMD INF is Estonia's invoice-level annex to the VAT return KMD. In plain terms, it is the appendix that certain VAT taxpayers use to report invoice data for issued invoices in Part A and received invoices in Part B once transactions with a single partner reach EUR 1,000 excluding VAT during the tax period. It is filed together with the VAT return by the 20th day of the following month, and it is periodic reporting rather than a real-time clearance model, as summarized in the Estonian Tax and Customs Board guidance on filing KMD and KMD INF.

That direct definition is the starting point for any Estonia KMD INF guide, but it also helps to see where the annex fits. KMD is the main VAT return. KMD INF sits next to it and adds invoice-level detail once the reporting trigger is met. So the task is not just "submit another form." Your team has to make sure the invoice data behind the annex matches the same sales and purchase activity that feeds the broader VAT return.

The most useful way to think about KMD INF is as a monthly invoice-data workflow. You are preparing records by partner, separating outgoing from incoming invoices, checking whether the threshold has been crossed, and making sure the annex reflects the same tax period as the underlying VAT return. That workflow perspective matters because many English-language pages blur KMD INF into much broader Estonia tax digitization discussions.

What finance teams usually need instead is something more concrete: who has to report, how the threshold works in practice, what belongs in Part A versus Part B, which invoices are commonly left out, how filing works through Estonia's official channels, and how the annex differs from Estonia's separate e-invoicing rules.

Who Must Report and How the EUR 1,000 Threshold Works

The threshold is the rule that determines whether invoice-level reporting enters the picture for a given transaction partner in a given tax period. The practical question is not whether your business is generally subject to KMD INF every month in the abstract. The real question is whether your reportable transactions with a specific partner reach EUR 1,000 excluding VAT during that period.

That partner-by-partner logic is where teams often get tripped up. If you issue or receive several invoices involving the same counterparty in the same period, you do not assess each document in isolation and stop there. You look at the total activity with that partner for the period and then determine whether the reporting threshold has been reached. Because the amount is measured excluding VAT, your review process has to use the net taxable values rather than the gross invoice totals.

In operational terms, this means KMD INF matters to any VAT taxpayer whose finance team needs to reconcile sales and purchase activity at a counterparty level before filing. Accountants and controllers often discover that the hard part is not understanding the headline rule. It is building a clean partner-level view of the period so they can tell which invoice sets belong in Estonia KMD INF invoice reporting and which do not.

A workable monthly process usually looks like this:

• close the tax period and pull the issued and received invoice population
• group invoices by transaction partner
• review net amounts excluding VAT for each partner
• decide whether the threshold is met for that partner in that period
• move only the relevant invoice data into the KMD INF preparation flow

That last point is important. KMD INF is periodic reporting, so the answer can change from one month to the next. A partner that does not trigger the annex in one period can cross the threshold in the next. That is why finance teams benefit from treating the Estonia KMD INF threshold as a repeatable review rule inside the monthly close, not as a one-time setup decision.

What Goes Into Part A and Part B

The clearest way to understand KMD INF Part A vs Part B is to separate the annex by invoice direction. Part A covers issued invoices. Part B covers received invoices. That sounds straightforward, but it becomes more useful when you connect those labels to the way finance data is actually prepared.

Issued invoices usually come from the sales side of the ledger. They reflect what your business billed to customers or counterparties during the period. Received invoices come from the purchase side, where your team is recording supplier documents and input VAT positions. KMD INF keeps those two streams distinct because they originate from different workflows, even though both ultimately need to align with the same VAT return.

For finance teams, the real task is not memorizing the form headings. It is making sure each invoice record is:

• assigned to the right partner
• tied to the right tax period
• separated correctly as issued or received
• traceable back to the underlying source document and ledger entry

That is why KMD INF often exposes data-quality gaps. If partner names are inconsistent, if invoice direction is misclassified, or if purchase and sales data are being prepared in different systems without a clean review step, Part A and Part B become harder to populate accurately. By contrast, when the issued-invoice and received-invoice populations are already clean, the Estonia VAT return appendix invoices are much easier to review before submission.

This split also explains why many businesses assign different owners to different parts of the annex. Sales operations or receivables staff may know the issued-invoice side best, while accounts payable or tax staff may be closest to the received-invoice side. KMD INF brings those records together, but it still expects them to be prepared with clear boundaries.

Which Invoices Are Commonly Left Out of KMD INF

One reason KMD INF can feel harder than the headline definition suggests is that not every invoice linked to a VAT period automatically belongs in the annex. Once a team understands the threshold, the next question is usually whether a given invoice should enter the report at all.

The common exclusion themes are fairly consistent. Finance teams usually start by checking whether the transaction involves natural persons in situations that are generally outside the reporting set, whether the reporting conditions have actually been met for that counterparty, and whether the invoice falls into exempt or zero-only situations that are typically outside the reportable KMD INF population under the official rules. Those are practical filters, not shortcuts.

That distinction matters because over-reporting and under-reporting can come from the same mistake: treating KMD INF like a dump of every invoice in the period. In reality, the annex is narrower than your full accounting record. Your VAT return may reflect a broader set of activity than the invoice-level appendix does.

A safer workflow is to build an explicit review step before filing:

1. identify the invoice universe for the period
2. test partner-level threshold status
3. separate issued from received invoices
4. remove items that do not belong in the annex under the current rules
5. review the remaining reportable set against the KMD and supporting records

If your team is unsure about an exclusion, the right move is to check the current interpretation against Estonian Tax and Customs Board guidance and the facts of the transaction. The important operational point is that exclusions are part of the process design. They should be reviewed deliberately, not discovered after the file is already prepared.

---

How Businesses Submit KMD INF in Practice

Once the reportable invoices have been identified, the next step is choosing how to submit the annex. The Estonia KMD INF deadline stays the same whichever route you use: the annex is filed with the VAT return by the 20th day of the following month. The filing routes described in official guidance are manual entry in e-MTA, structured XML or CSV upload, and X-tee integrations. The legal obligation is the same across those paths, but the work behind them looks different.

Manual entry in e-MTA is the most direct route when invoice volumes are modest or when a team wants closer hands-on review before submission. Structured XML upload or CSV upload becomes more useful when the business is already preparing invoice data in a consistent format and wants to avoid rekeying. X-tee integrations sit further along the automation spectrum because they depend on upstream systems producing the right data in the right structure.

Whichever route you use, the underlying preparation steps are similar:

• collect the issued and received invoices for the tax period
• group them by transaction partner
• apply the threshold test excluding VAT
• confirm which items belong in Part A and which belong in Part B
• remove invoices that do not belong in the annex
• validate that the final invoice list reconciles to the broader VAT return process

This is where KMD INF looks less like a tax note and more like an invoice-data workflow. If partner matching is inconsistent, if source documents are hard to trace, or if the business cannot explain why a record appears in Part A instead of Part B, structured submission does not fix the problem. It only exposes it faster.

That pattern is not unique to Estonia. Other jurisdictions also depend on invoice-register style preparation before filing, which is why it can be helpful to compare KMD INF with Lithuania's i.SAF invoice-register workflow. The systems are different, but the same control mindset also shows up in Kosovo's Purchase and Sales Book EDI workflow, where invoice data has to be organized for periodic purchase and sales book submissions.

---

KMD INF vs E-Invoicing, Real-Time Reporting, and Reform Plans

The most common source of confusion in English search results is that KMD INF is often discussed next to e-invoicing or fiscalization, as if all three describe the same obligation. They do not. KMD INF is periodic appendix reporting linked to the VAT return. It is based on invoice data, but it is not a real-time clearance model and it does not mean Estonia currently requires every invoice to be reported to the tax authority at the moment of issue.

That is why it helps to separate today's annex from Estonia's separate e-invoicing rules. E-invoicing focuses on how invoices are exchanged and formatted in the relevant rule set. KMD INF focuses on what invoice data has to be reported as part of the periodic VAT workflow once the reporting conditions are met. A business can understand one topic poorly if it only reads articles that bundle both together.

The contrast is even clearer when you look at a true near-real-time model such as Hungary's real-time invoice reporting model. Hungary's system is designed around rapid transmission of invoice data to the tax authority. Estonia's KMD INF guide belongs in a different category because the annex is reviewed and filed with the VAT return on a periodic basis.

Reform discussions do matter, especially because policy conversations have included removing the EUR 1,000 threshold and expanding Estonia's wider digital-reporting approach. But those discussions should be treated as future-state context, not as a substitute for the current rules your team has to follow now. The operational priority is still the same: prepare clean invoice data by partner and period, understand the Part A and Part B split, and monitor official announcements before changing the workflow.

If your goal is practical compliance, that framing keeps the topic manageable. First understand how KMD INF works today. Then watch for reform signals from the authorities. Mixing future plans with current filing obligations is exactly what makes this topic harder than it needs to be.