/merit-purchase-invoices

name: merit-purchase-invoices
version: 1.1.0
description: >
  How to enter vendor bills (ostuarve) correctly in Merit Aktiva via the elnora-merit
  CLI — vendor resolution, invoice rows + VAT, posting straight to the ledger vs the
  approval queue (kinnitamata ostuarved / kinnitusring), purchase credit notes, and
  expense claims. For EU/foreign suppliers see the merit-reverse-charge skill.
  Use when: entering a purchase invoice, recording a vendor bill, booking a supplier
  receipt/expense, creating a draft invoice for approval, issuing a purchase credit note,
  or entering an employee expense claim.
  TRIGGERS: "purchase invoice", "enter a bill", "vendor bill", "ostuarve", "supplier invoice",
  "book an expense", "record a receipt", "purchase credit note", "ostu kreeditarve",
  "expense claim", "kuluaruanne", "pending invoice", "kinnitamata ostuarve", "approval ring".

Merit Purchase Invoices (ostuarve)

How to enter vendor bills correctly with `elnora-merit purchase-invoices`. Every endpoint is **POST with a JSON body**. Writes hit the live books and feed input VAT — confirm the payload before posting.

> For real expense-account codes and VAT guids, load the **company profile** > (`elnora-merit profile sync` → `company-profile.json`); vendor conventions come from your > prose books reference if you keep one. Load what applies before posting.

Decide the path first

| Situation | Command | Effect | |---|---|---| | Booking a confirmed bill straight to the ledger | `create` (`sendpurchinvoice`) | Posts the GL entry immediately. | | Company uses an approval ring, or you want a draft | `create-pending` (`sendpurchorder`) | Waits for bookkeeper approval; **no** GL records until approved (in the Merit UI). | | Employee out-of-pocket costs (no company-paid receipts) | `create` / `create-pending` with `"ExpenseClaim": true` | Books a liability to the reporting person. |

If the company has the approval ring (kinnitusring) switched on, an invoice **cannot be posted** until an approver confirms it in the UI — use `create-pending` and hand off.

The rules that prevent most mistakes

1. **Resolve the vendor first.** Reuse by `Id`; create only when none matches. `vendors list` MUST be filtered (unfiltered returns a server error). 2. **VAT is a `TaxId`, not a percentage.** From `elnora-merit taxes list`. Put it on each `InvoiceRow` and mirror it in the top-level `TaxAmount` array. `TotalAmount` is net **without** VAT. 3. **Every code must already exist.** GL account / department / project / cost-centre / location / dimension codes referenced in the body must already be defined in Merit, or the call fails. Look them up (`accounts list`, `taxes list`, etc.) first. 4. **EU / foreign suppliers → reverse charge is driven by the vendor's COUNTRY**, not a VAT code. Set `CountryCode` right, leave the standard rate on the lines, and Merit self-assesses the reverse charge. Full procedure in the `merit-reverse-charge` skill — do not improvise it here. 5. **Don't double-book the payment.** If the bill is settled from a bank account whose statement you import, do **not** add a `Payment` block here — match it later in the imported statement (see `merit-payments-bank`). Only mark payment inline for cash / card / reporting-person settlements.

Resolve / create the vendor

elnora-merit vendors list --name "AWS"          # broad match — always filter
elnora-merit vendors list --reg-no 12345678     # exact

Create (required: `Name`, `CountryCode`, `VatAccountable` lowercase `"true"`/`"false"`):

elnora-merit vendors create --data '{"Name":"Amazon Web Services EMEA SARL",
  "CountryCode":"LU","VatAccountable":"true","VatRegNo":"LU26888617",
  "Email":"","BankAccount":""}'

Set `CountryCode` correctly — it drives reverse-charge treatment. Uncheck VAT liability (`"VatAccountable":"false"`) only for genuinely non-VAT-registered vendors.

Create the invoice

Read the full schema with `elnora-merit purchase-invoices create --help`. Minimum body:

{
  "Vendor": { "Id": "<vendor-guid>" },
  "DocDate": "20260601",
  "DueDate": "20260615",
  "BillNo": "INV-99812",
  "InvoiceRow": [
    { "Item": { "Code": "CLOUD", "Description": "Cloud hosting", "Type": 2 },
      "Quantity": 1, "Price": 340.00, "TaxId": "<taxid>", "GLAccountCode": "<expense-acct>" }
  ],
  "TaxAmount": [ { "TaxId": "<taxid>", "Amount": 81.60 } ],
  "TotalAmount": 340.00
}

elnora-merit purchase-invoices create --file bill.json          # straight to ledger
elnora-merit purchase-invoices create-pending --file bill.json  # awaits approval

• `DocDate` / `DueDate` are `YYYYMMDD` in the purchase body (note: different from the

sales body's `YYYYMMDDHHMMSS`). `Item.Type`: `1` stock, `2` service, `3` item.

• Attach the source receipt as `Attachment: { FileName, FileContent }` (valid Base64 PDF

— broken Base64 is a common server-side failure).

• `--v2` adds header/row `Dimensions` and `Receiver` support.
• To verify the attachment landed, fetch the invoice back with `--v2` (the v2 `get` returns

the Base64 `Attachment`; the v1 `get` omits it).

Representation vs ordinary expense (EE)

A common, costly miscoding when you pick the expense account: **food / catering at an event you sell tickets to** (training, seminar, conference, hackathon) is an **ordinary deductible expense with full input-VAT recovery**, *not* representation (vastuvõtukulud, TuMS § 49). EMTA's test is the **contractual relationship**: representation is hosting **guests or business partners you have no contract with**; paying ticket-holders are customers, so catering provided to them is a direct cost of the taxable service sold. Book it to a normal event / operating-expense account, deduct the input VAT, and keep evidence the catering was part of the paid package available to all attendees. A separate free, invite-only dinner for partners / sponsors *is* representation (TuMS § 49 monthly li