/merit-vat-kmd

name: merit-vat-kmd
version: 1.2.0
description: >
  How VAT and the Estonian VAT return (käibedeklaratsioon / KMD) work in Merit Aktiva, and
  how to get them right from the elnora-merit CLI. Covers the tax-code model, paying the
  VAT, what feeds
  each KMD line, time-of-supply, and pulling supporting VAT figures. The KMD itself is
  generated and filed in the Merit UI — the API has no KMD endpoint.
  Use when: preparing or checking the VAT return, choosing a VAT/tax code, understanding a
  KMD line, reconciling VAT figures, or asking why the GL VAT balance differs from the KMD.
  TRIGGERS: "KMD", "käibedeklaratsioon", "VAT return", "VAT declaration", "tax code",
  "VAT code", "käibemaks", "input VAT", "output VAT", "käibeandmik", "KMD line", "VAT INF",
  "tax point", "time of supply", "VAT reconciliation".

Merit VAT & KMD (käibedeklaratsioon)

> **Scope:** this skill describes the **Estonian** VAT regime (KMS, EMTA, the KMD return, > the 24% standard rate). On the Polish localization (`360 Księgowość`) the VAT rules, > rates, and return differ — use the CLI's tax/account mechanics here, but apply your local > Polish VAT rules rather than the EE specifics below.

How Merit computes VAT and produces the monthly KMD, and how to support it from `elnora-merit`. **The API has no KMD endpoint** — Merit builds and files the KMD in the UI from the invoices you enter. The CLI's job is to get the per-line VAT right and to pull the figures that verify it.

> Get the VAT codes (TaxId guids + rates) from the **company profile** > (`elnora-merit profile sync` → `company-profile.json`; `profile show --section taxes`). > Filing cadence and standing VAT rules come from your prose books reference if you keep one. > Load what applies before relying on this.

How the KMD is built (the one mental model)

Merit auto-fills the KMD from every saved **sales** and **purchase** invoice. The **VAT code (`TaxId`) on each invoice line routes that line's amounts to the correct KMD row.** You never type figures into the KMD. So a correct KMD is entirely a function of:

1. The right `TaxId` on every invoice line (`taxes list` → the guid), and 2. Every invoice for the period entered before the KMD is generated.

Get the line codes right and the declaration is right. Fix a wrong KMD by fixing the source invoice's code/date/amount, not the declaration.

The tax codes

elnora-merit taxes list      # [{ Id (guid), Code "24%", Name, TaxPct }]

• The Estonian standard rate is **24% from 01.07.2025** (was 22%, earlier 20%). Use the

`Id` of the current standard-rate row on standard domestic supply.

• VAT codes are bound to specific built-in GL accounts. When a new code is genuinely

needed it's added in the UI (Settings → Finance → Käibemaks) — do **not** invent GL accounts for it; Merit assigns them.

• `taxes create` exists but is documented only for OSS codes (`--tax-type 12`). Adding

everyday rates is a UI task.

What feeds each KMD line

Standard EMTA KMD form; Merit populates it from each line's tax code. The rows that matter:

| Line | Meaning | Fed by | |---|---|---| | **1** | Standard-rate (24%) taxable supply | Domestic sales at the standard code | | **2** | Reduced-rate (9% / 5%) supply | Sales at a reduced code | | **3 / 3.1 / 3.1.1** | 0% supply; intra-EU supply of goods+services / goods | EU sales to a customer with valid EU country + VAT no. | | **4** | VAT due (computed) | — | | **4.1** | Import VAT declared on KMD (KMS §38²) | GL via the §38² import-VAT account; mirrored to 5 & 5.1, net 0 | | **5 / 5.1** | Input VAT deductible / on imports | Purchase invoices' deductible VAT; import VAT | | **5.3 / 5.4** | VAT on a 100% / 50%-business car | The `100% auto` / `50% auto` codes | | **6 / 6.1 / 7** | Reverse-charge acquisitions (intra-EU goods+services / goods / other) | Reverse-charge purchases — see `merit-reverse-charge` | | **10 / 11** | Adjustment increasing / decreasing input VAT | Manual GL correction (e.g. proportional-VAT year-end) |

Reverse charge appears on 6/6.1/7 (and mirrored 4/5), and Merit **does** post a GL entry for it: the purchase invoice debits the reverse-charge VAT account and credits the sales-VAT account for the self-assessed amount, and the monthly KMD closing entry clears the pair. (The account codes are whatever your own chart of accounts uses — read them from `accounts list`, don't assume.) So the GL VAT accounts and the KMD are expected to agree; a gap between them is a real break to investigate, not a by-product of reverse charge.

Merit zeroes the invoice's *payable* VAT, so a reverse-charge purchase reports `TaxAmount = 0` on the invoice header. **That header value is not the test.** To confirm reverse charge actually applied, read the posted GL batch (`gl get <GLBId>`) and look for the self-assessed debit/credit VAT pair. `TaxAmount = 0` on a foreign-vendor purchase that carries a standard-rate line is correct, not missing VAT — do not "fix" it. Full procedure: `merit-reverse-charge`.

Time of supply (tax point)

Merit routes each line to its period by the invoice's VAT/posting date; the taxable period is always the **calendar month**. Estonian KMS §11 tax-point rules (e.g. prepayments are a tax point at receipt) are not enforced by the UI — set the line/invoice dates so the amount lands in the correct month. Your books reference states any standing rule (e.g. prepaid items declared by payment month).

Paying the KMD

There is no pay-the-tax endpoint beyond the normal bank flow. When you pay the VAT, the KMD liability appears in the bank-import **Võlgnevused** window as a `KD-MM-YYYY` debt against the **tax-authority vendor (Maksu- ja Tolliamet)**, due the **20th** of the following month, or the **next working day** when the 20th falls on a public holiday or weekend (MKS § 50 lg 1 applies TsÜS § 136 lg 8). Take the due date EMTA itself shows rather than assuming the 20th. Match the payment there — Merit nets it against any standing tax-a