/merit-stripe

name: merit-stripe
version: 1.0.0
description: >
  How Stripe payments must be set up and recorded in Merit Aktiva — the canonical
  clearing-account method. Stripe is a payment intermediary, not your bank: never book
  the bank deposit as revenue (it arrives NET of fees). Each Stripe payout is booked as
  ONE summary GL batch — gross card sales as revenue + output VAT, Stripe fees as a
  separate expense, through a clearing account the real bank row then clears.
  Use when: setting up Stripe in Merit, booking Stripe payouts, reconciling card sales,
  deciding the VAT treatment of Stripe fees, or fixing how Stripe revenue is recorded.
  TRIGGERS: "stripe", "stripe payout", "stripe payouts", "stripe fees", "card sales",
  "card payout", "book stripe", "record stripe", "reconcile stripe", "stripe clearing",
  "stripe vahekonto", "stripe revenue", "stripe vat", "payment processor accounting",
  "platform payout", "ticket sales accounting", "how to book stripe".

Merit Stripe

How Stripe card payments are set up and recorded in Merit Aktiva. The implementation is the `elnora-merit reconcile` command; this skill is the *why* and the *rules* so any agent books it correctly and can spot a wrong entry.

**The one thing to get right: Stripe is a clearing account, not your bank.** Stripe holds the money, deducts its fee, then pays out the NET in batches. So you cannot book the bank deposit as revenue — it is already net of fees. Revenue is booked GROSS, the fee is a separate expense, and a clearing account in between holds the payout net until the real bank-import row clears it.

The booking model — one summary GL batch per payout

Each Stripe payout is booked as a single balanced `sendglbatch`. Card sales are aggregated (no per-buyer customer or invoice — the canonical treatment for high-volume B2C card sales; genuine company invoices that need an A/R record are booked separately).

Dr  Clearing      gross        all card sales in the payout, VAT-inclusive
Cr  Revenue       net          gross ÷ 1.24 — carries the 24% TaxId + VatAmount
   [Cr VAT payable vat]        output VAT — IMPLICIT, Merit posts it from the tag
Dr  Stripe fees   fees         processing + platform fees, a separate expense
Cr  Clearing      fees
Dr  Refunds  / Cr Clearing     only when the payout contains refunds

The clearing account is left holding exactly the **payout net**, which the real bank-import row clears against (one manual match in the Merit UI).

VAT period — date each batch on the CHARGE month (§11), not the payout arrival

Estonian time of supply (KMS §11) is the earlier of supply or payment — for a card sale the **charge/capture date**, not when Stripe pays out. `reconcile` dates each batch on the charge month: usually equal to the payout arrival, except a month-end **straddle** (charges captured in month N, paid out in N+1), which it dates back to the charge month so the output VAT lands in the correct KMD period.

A payout whose charges span **two or more months** cannot be dated to one VAT month. The tool flags it in `preview` and `run` **skips it** (marked not bookable) rather than mis-dating it — it does **not** auto-split (yet). Book it by hand as **one GL batch per charge month** (DocNo `po_…-MAY` / `po_…-JUN`), splitting gross/net/VAT/fees **per charge**, not by dividing the aggregate ÷ 1.24. Per-charge rounding ties to the cent and matches the tool's single-month batches; the aggregate method is ~1 cent off per batch. The two batches together net to the payout and are cleared by the single bank row.

Account map (per company — set in the map, never hard-coded)

Configured in `stripe-map.json` in the references dir (`MERIT_REFERENCES_DIR`, default `~/.config/elnora-merit`); `reconcile init` writes a placeholder. Confirm every code and the VAT guid against your own company — from the **company profile** (`elnora-merit profile sync` → `company-profile.json`; `profile show --section accounts|taxes`) or live (`accounts list` / `taxes list`).

| Role | Maps to | Notes | |---|---|---| | `clearing` | a 10xx clearing / vahekonto account | nets to zero per payout | | `revenue` | your sales-revenue account | booked NET, VAT via the tag | | `vatPayable` | your output-VAT account | Merit posts here implicitly — never an explicit row | | `stripeFees` | a bank-service expense account | VAT-exempt payment service (see VAT below) | | `platformFees` | a fee-expense account | platform / application fee (e.g. an events platform's commission) | | `refunds` | contra-revenue account | | | `vat.code` / `vat.rate` | the standard-rate `TaxId` from `taxes list` / the rate (e.g. `0.24`) | tags the revenue line for the KMD |

VAT — two rules, one of them counter-intuitive

1. **Output VAT is tagged, never an explicit row.** The revenue line carries `TaxId` + `VatAmount`; Merit *both* posts the VAT credit to the output-VAT account *and* flows it onto the KMD from that tag. The batch's explicit rows are intentionally short by exactly the VAT amount — Merit's implicit credit balances it. Adding a separate VAT-account row double-posts and Merit rejects the batch (`PR kanne ei ole tasakaalus`). An *untagged* VAT row lands in the GL but never reaches the KMD. So: tag the revenue line, add no VAT row.

2. **Stripe processing fees are a VAT-EXEMPT payment service — NO reverse charge.** Book them to your bank-services expense account (e.g. 4340) like an ordinary pangateenus, with no `TaxId` and no KMD reverse-charge lines. This is the explicit exception to `[merit-reverse-charge]`: a payment service under the Payment Institutions Act §3 is exempt under KMS §16(2¹)(4) regardless of who provides it, so it is NOT reverse-charged even though Stripe is foreign (EMTA VAT-department position). Do not treat the Stripe fee like a US/EU SaaS bill.

Nuance — a **platform fee** (e.g. an events platform's commission) is not the payment service; strictly it is a reverse-chargeable platform