Estonia's KMD INF Threshold
Is Per Partner, Not Per Invoice
KMD INF is not a summary of your VAT return. It is a list of individual invoices that the Estonian Tax and Customs Board (EMTA) matches against the list your counterparty filed, invoice number by invoice number.
That is why the €1,000 rule is so often misread. It is a test on the monthly total with one partner, not on each invoice, and it runs separately for sales and purchases, then again for credit notes. Get the test wrong in either direction and the annex is wrong in a way the tax authority can see before anyone opens an audit.
Key Takeaways
- The €1,000 threshold tests your monthly total with one partner, which is why a stack of €40 receipts can matter more than one €999.99 invoice.
- Hit €1,000 in total with one partner and every invoice is listed, including the €40 invoice and every credit note.
- Two correct files can still disagree on the amount column, because Part A reports before VAT and Part B after.
KMD INF Is a Matching File, Not a Summary
The annex exists so that one company's sales invoice can be compared with the same invoice in its customer's purchase list. Estonia KMD INF reporting is built from individual invoices, and that single fact explains most of the rules below. Section 27(1²) of the Value-Added Tax Act requires a monthly annex to the VAT return (KMD) listing invoices issued to, and received from, other VAT-registered businesses once the monthly total with each partner reaches €1,000. Both the return and the annex are due by the 20th day of the following month. Part A holds the invoices you issued. Part B holds the invoices you received and deducted. That is why Estonia VAT invoice reporting turns on identity: which invoice, from which partner, in which period, with which number.
EMTA does not need to audit a company to find a discrepancy. It needs the counterparty's file. In 2023 the tax authority assessed €25 million in VAT from differences found by comparing invoice data on KMD INF, according to the Finance Ministry's explanatory note quoted in the Estonian Taxpayers Association's MaksuMaksja magazine. The same note says the differences often come from declaration errors made while entering invoice data by hand, not from evasion.
The annex is unusual in that respect. Countries that report VAT as totals make the preparation work about classification. Spain's Modelo 303 is assembled from totals by rate and casilla, which is why Spanish prep guides are about mapping amounts to boxes.
Every row you file is a claim your counterparty can confirm or contradict.
What Belongs on the Annex and What Stays Off
Only domestic business-to-business invoices that carry Estonian VAT at 24, 13 or 9 percent belong on the annex. The standard rate has been 24 percent since 1 July 2025, up from 22 percent. The reduced rates cover accommodation at 13 percent and books, press publications and medicines at 9 percent. A transitional 5 percent rate still applies until 31 December 2026 for cash-accounting businesses on press publications invoiced and supplied before 1 January 2025 and paid later. Credit notes against older invoices keep the rate of the original supply, which is why 22 percent and 20 percent still appear in the instructions.
The counterparty must be a legal person, a self-employed person (FIE), or a state, municipal or city authority. A sale to a private individual is not reported, even if that person asks for an invoice in their own name. A foreign supplier with no Estonian register code is not reported either, which removes most intra-EU purchases from the annex entirely. Part B adds one more filter: the VAT on the invoice must be deductible in full or in part in field 5 of the KMD.
| Invoice | On the annex? | Why |
|---|---|---|
| Estonian supplier, 24% VAT, €1,400 in the month | Part B | Estonian code, taxable supply, input VAT deducted |
| Estonian customer, 24% VAT, one invoice of €1,500 | Part A | Issued to a business with an Estonian registry code |
| German supplier, intra-EU acquisition, 0% on the invoice | No | No Estonian VAT and no Estonian code. It goes on KMD field 6, not the annex |
| German company with an Estonian VAT registration | Part B | Listed under its Estonian non-resident code |
| Estonian law firm, invoice covered by professional secrecy | Optional | The supplier need not declare it; the recipient may |
| Estonian supplier, VAT not deductible because the cost serves exempt sales | No | Part B covers only VAT that is deducted |
| Retail sale to a private individual, €5,000 | No | Private individuals are outside the annex |
An invoice carrying only 0% or exempt supply is not a KMD INF invoice, however large it is.
The KMD INF Threshold Is Per Partner, Not Per Invoice
The KMD INF threshold is a test on the total of all invoices with one partner in one calendar month, not a limit on each invoice. The wording is "at least €1,000", so €1,000 exactly is in scope and €999.99 is not. Once the total reaches the limit, every invoice with that partner in that period is declared, including a €40 one and including credit notes.
Three separations matter. Issued and received invoices are tested separately, so the same partner can appear on Part A and not on Part B. Ordinary invoices and credit invoices are tested separately, which is covered below. And each member of a VAT group, where several companies share one VAT number, counts its own limit even though the group files one return. An invoice also counts toward the limit only once, in the period when it is first declared; if the same invoice is declared again later because the supply continues, it does not count a second time. EMTA's instructions for the KMD INF form set out the test and the four-line limit per invoice.
| Activity with one partner in the month (amounts excluding VAT) | Declare? | Reason |
|---|---|---|
| One invoice of €1,000 | Yes | The rule is "at least", not "more than" |
| One invoice of €999.99 | No | Below the limit, unless you choose to declare it voluntarily |
| Four invoices of €300 | Yes, all four | The partner total is €1,200 |
| Three invoices of €300 plus a credit note of €50 | No | Ordinary total €900, credit total €50; neither reaches the limit |
| Invoices of €1,050 plus a credit note of €1,200 | Yes, every row | Either test triggers the full listing for that partner |
| One invoice of €1,100, of which €200 is exempt supply | Yes | The whole €1,100 counts toward the limit, and the invoice is listed with exception code 03, which flags an invoice that mixes rates or carries exempt amounts |
| One invoice of €900 plus €216 VAT | No | The gross figure is not the test. €900 is below the limit |
| Invoice of €2,000 with no right to deduct the VAT | No, on Part B | Input VAT is not deducted, so the invoice stays off the annex |
The rule is easy to state and easy to miss in practice. A tax practitioner writing in the same magazine describes being handed a box of simplified invoices twice a year, mostly fuel receipts, each already stamped with the company's name and VAT number. A few fills a month at one service station reach €1,000 without anyone deciding to report anything.
Credit Notes Get Their Own €1,000 Test
A credit note is not subtracted from the invoices it corrects before the limit is applied. Ordinary invoices and credit invoices are totalled separately. If the ordinary total reaches €1,000, every invoice for that partner is declared, credit notes included. If the credit total alone reaches €1,000, the same thing happens: the full set for that partner is declared, not just the credit notes that triggered it.
On the form, credit notes and reductions of taxable value carry a minus sign. A €4,000 invoice in March and a €4,000 credit note in April produce a row in March and a row in April. The year nets to zero; neither month is empty.
Netting a credit note against the invoice it cancels produces a partner total that neither side can match.
Part A and Part B Do Not Mirror Each Other
Part A reports the amount before VAT and Part B reports the amount after VAT, so both files can be correct and still disagree on the amount column. That is not a bug in the form. Each side answers a different question.
Part A reports what you supplied and how much of it was declared as taxable supply in the KMD. Part B reports what you received and how much input VAT you actually deducted this period. On a purchase invoice with a 50 percent deduction, column 8 holds half the VAT printed on the invoice, and exception code 11 explains why. Code 12 marks a domestic reverse-charge purchase. Under the cash accounting scheme, where VAT is accounted when the invoice is paid, column 8 holds zero until payment. Neither number is the VAT printed on the page.
| Part A: invoices issued | Part B: invoices received | |
|---|---|---|
| Amount column | Total excluding VAT | Total including VAT |
| VAT columns | Taxable value by rate, plus the part declared in the KMD | VAT printed on the invoice, plus the input VAT deducted this period |
| Rows per invoice | Up to four, split by rate and special scheme | Usually one, with exception codes 11 or 12 where they apply |
| Period trigger | When the supply is incurred | When the input VAT is deducted |
| Extra filter | None beyond the scope rules | The VAT must be deductible, in full or in part |
These differences are legitimate. A purchase can be fully valid and fully paid and still be absent from Part B, because the VAT on it was never deducted. A credit note can appear in a month with no matching invoice. A partner's totals can differ from yours by the timing of a single delivery. None of that is a filing error, and none of it can be resolved by forcing the two files to agree.
A purchase invoice can be valid, paid, and still absent from Part B, because the VAT on it was never deducted.
The Period Comes From the Supply, Not the Invoice Date
An invoice is declared in the period when the supply happened or the deduction arose, not the period printed on the invoice. EMTA's own example makes the consequence concrete: a €1,000 invoice issued in January for goods not yet delivered, paid €240 in February and €1,000 in April, is declared on Part A in February and again in April. January and March carry no row for it at all.
The invoice date column still says January in both rows. A counterparty comparing by month sees a January invoice sitting in February and April, which looks like a period error and is not one. The same logic applies on the purchase side: if the invoice arrives after the 20th, the input VAT is deducted in the month the invoice is received, so the Part B row moves with the deduction, not with the supply.
This is also why the limit is counted once. A €1,000 invoice first declared in February and declared again in April counts toward the limit in February only. The April row does not re-run the test.
The date column is the invoice date. The period is the supply date. The row carries one and is filed under the other.
The Fields That Decide Whether the Match Works
Seven fields decide whether your row matches your counterparty's row. The first four identify the invoice; the last three carry the money. The rest of the row can be right and the match will still fail if one of these is wrong.
| Field | Where it comes from | What fails when it is wrong |
|---|---|---|
| Partner registry code | The Business Register code, not the VAT number. Foreign VAT-registered partners use their Estonian non-resident code | A partner with no Estonian code at all cannot be listed, however large the invoice |
| Partner name | Exactly as registered | e-MTA checks the spelling when you type a name. Entering the code alone avoids the check |
| Invoice number | As printed on the invoice | It is the join key between your Part B row and the supplier's Part A row. Reformatting it breaks the match |
| Invoice date | The issue date, not the bookkeeping date | A posting date will not match the date on the supplier's copy of the same invoice |
| Amount | Excluding VAT on Part A, including VAT on Part B | Using the wrong basis makes every row differ by the VAT amount |
| Rate and taxable value | One line per rate, up to four lines per invoice | Collapsing a mixed-rate invoice into one line leaves the KMD totals unexplained |
| Input VAT deducted | Column 8 on Part B, which is not always the VAT printed | Partial deduction and cash accounting make the printed VAT the wrong figure |
The registry code is the field that fails silently. The e-MTA filing portal will auto-fill the name when you enter a code, and it will validate a name when you type one, but it cannot invent a code that your supplier master never had. Missing a code is not automatically treated as a failure to file if the tax authority can identify the person from the data you submitted, according to the form instructions, but the row is still weaker than one with a code.
The invoice number is what ties your row to theirs. Every amount can be right and the match still fails.
Building the Annex From the Invoices
The annex is one row per invoice, so the work is to turn a folder of PDFs into that row before the 20th. That is a data entry problem before it is a tax problem, and it is where the manual errors in the ministry's note come from.
ImageToTable.ai approaches it with Custom Column Extraction: you type the column names you want, and the AI locates each value on each invoice by understanding what the field means, not by matching a fixed position or a per-supplier template. A telecom bill, a fuel receipt and a utility statement can go into the same batch and land in the same columns. That matters here because the annex fields sit in different places on every supplier's layout, and the supplier who redesigns their invoice in March should not require a new setup.
A workable column set for the annex: partner registry code, partner name, invoice number, invoice date, total excluding VAT, total including VAT, VAT rate, taxable value at that rate, and VAT amount. Add a computed column named something like Rate Lines Check (sum of rate lines, output the difference from the printed total), so a mixed-rate invoice that does not add up is visible before it reaches the form. A computed column is a calculation the tool performs during extraction and writes into the table as its own column, which is faster than checking the arithmetic afterwards.
Upload the month's invoices as one batch. Batch processing means multiple files go in at once and come out as one table, one row per invoice, which is the shape the annex needs. Then use Review Mode with Bbox on the three fields that drive the match: invoice number, invoice date and amount. Clicking a cell highlights the region it came from on the original page, so a number that was read from the wrong line can be caught without re-reading the whole document.
Files are processed securely and not stored.
The €1,000 test itself is not a column. It is a pivot. Group the rows by registry code, sum the amount excluding VAT, and flag every partner at or above €1,000. Run the same pivot again on credit notes only. That two-pass check is the part a spreadsheet does better than an extraction tool, and it is the part that most often gets skipped when the deadline is close.
Extraction gives you a clean row per invoice. The €1,000 test is a pivot, not a column.
Where Extraction Stops
The tool produces the rows; it does not decide what belongs on the annex. The boundary matters more here than in most invoice work, because a wrong judgment is a compliance problem rather than a messy spreadsheet.
- It does not file or transmit. KMD INF goes to e-MTA manually, by XML or CSV upload, or through X-tee, the state's data exchange layer, from your accounting software. The tool does not connect to any of those channels.
- It does not determine tax treatment. Whether VAT is deductible, whether an invoice is inside the scope of the annex, and which period the supply belongs to are judgments about the transaction, not readings of the page.
- It does not reconcile. It cannot compare your file with your counterparty's filing or with EMTA's own data, because neither is an input.
- It cannot supply a missing registry code. If the code is not on the invoice, it has to come from your supplier master. That is a one-time mapping, not a monthly task.
- It does not apply the per-partner limit. That test runs across invoices, and it belongs in the pivot described above.
For the broader field set behind an invoice, including line items and tax breakdowns, the complete guide to invoice data extraction covers the parts this article deliberately leaves out.
What Changes in April 2027
From April 2027 the annex stops being a form and becomes a data feed, but the invoice-level detail does not go away. EMTA is replacing the KMD return with a data-based submission in which the tax return is generated from the transaction data the business sends. Parts A and B are replaced by four sections: sales, reverse-charge acquisitions, adjustment entries and purchases.
The transport changes too. Data moves from accounting software to e-MTA machine to machine in XBRL GL, a structured format for accounting data, with a transition CSV format and no more of the old XML. Intra-Community supply data, previously form VD, is folded into the same submission. The detail required per invoice does not change, but each record must carry the transaction type and the partner or invoice identifier. The €1,000 exclusion survives in EMTA's current guidance: invoices under €1,000 and invoices to private persons still do not need to be declared.
The practical effect is that the file becomes a direct reflection of the invoice data in your ledger. A missing invoice number or a partner without a code stops being a form-filling problem and becomes a data problem in the source system. Estonia is moving in the same direction as France and Germany, though it keeps periodic reporting rather than real-time clearance.
EMTA estimates the change will save businesses up to 5 million working hours a year, mostly by removing repeated manual entry into e-MTA. The invoice fields described above are the same fields in the new envelope. The work of getting them off the page accurately does not move.
The 2027 change moves the same fields into a different envelope.
FAQ
Does an invoice of €999 have to be reported on KMD INF?
No, not on its own. The limit applies to the total with that partner in the month, excluding VAT, so a single €999 invoice stays off unless other invoices with the same partner push the total to €1,000. You may declare invoices below the limit voluntarily under section 27(1³), and some companies do that to keep the file consistent, but it is not required.
Should credit notes be netted against sales invoices before applying the limit?
No. Ordinary invoices and credit invoices are totalled separately for the €1,000 test. If either total reaches the limit, every invoice with that partner in the period is declared, including the credit notes, which carry a minus sign. Netting first can hide a partner that should have been listed.
Do I report an invoice from a German supplier?
Only if the supplier has an Estonian register code, in which case the invoice goes on Part B under its non-resident code. A normal intra-EU acquisition with 0% VAT and reverse charge is not a KMD INF item at all; it is reported on the KMD return itself, in the intra-Community acquisition field and in the input VAT field.
What if the buyer's registry code is missing from the invoice?
The partner cannot be listed properly, because the annex identifies counterparties by registry code. Leaving the code out is not automatically treated as a failure to file if the tax authority can identify the person from the data submitted, but relying on that is not a control. Fix the supplier or customer record once and the problem stops recurring.
Can I report one line per partner instead of one line per invoice?
No. The option to submit summarised partner totals ended in 2015, and the form has been filled invoice by invoice since 2016. A single invoice can occupy up to four rows when it mixes rates or special schemes, and those rows must repeat the invoice identity.
What does an inaccurate KMD INF actually cost?
The first consequence is usually administrative rather than financial. EMTA's guidance says inaccurate annex data can create differences in the tax behaviour ratings, the 1 to 3 compliance scores it shows each company, and can cause the VAT return to be redirected to control. Penalty payments imposed to enforce submission of the same return are capped at €3,300, but where incorrect data leads to underpaid VAT the fine can reach €32,000, with late payment interest of 0.06 percent per day.
Can ImageToTable.ai file KMD INF for me?
No. It extracts the invoice fields and produces the table. Filing, the scope decision and the reconciliation against your counterparty remain with you or your accountant.
The annex is judged invoice by invoice, and the fields it needs exist only on the invoice. Every month, that table is rebuilt from documents that were never designed to be compared.