Payouts

Organization → Payouts is where an organization batches unpaid ledger work into payout runs, marks them paid after paying outside the platform, and hands out receipts. The platform records and computes; it never moves money.

The model behind it — what a run claims, frozen amounts, verification codes — is described in Contributions & payment → Payout runs. This page is the walkthrough of the surface itself.

Who can use it

Org Owners and Admins (and platform staff) — the tab is hidden for other roles and every payout endpoint refuses anyone else. On the desktop app the page is cloud-only: runs, receipts, and templates live on the cloud, and the page offers to open Payouts online instead.

The runs list

Every run gets a payout number the moment it is made (PO-2026-00042: the year it was made and the run's own number). It never changes, and it is on the list, the detail, every PDF and every CSV (payout_number), so it is the number to quote in your books and reports. The reference is a different thing: the payment's own, from whoever moved the money, added when the run is paid.

Runs are listed with period and payout number, member count, total and status (Draft or Paid on date). A status filter (All / Draft / Paid) sits above the list; 10 runs per page by default.

Title-row actions:

Action	Effect
+ New payout run	Opens the create flow below
Export CSV	Org-wide expenditure: one row per member × project from every run's frozen breakdown, with per-currency grand totals; honours the status filter. Disabled until there is at least one run.
Receipt templates	Opens template management (below)

Row actions: View (run detail), and for drafts Mark paid and Delete.

Create a run

1. Pick From (inclusive) and Until (exclusive) dates. As soon as both are valid the preview loads: entries, members, and total that a run with those dates would claim (flagged mixed currencies when projects pay in more than one).
2. Optionally add a Reference (≤ 100 chars, e.g. a mobile-money batch id) and a Note (≤ 200 chars, visible on the run).
3. Create run — enabled only when the preview shows at least one claimable entry.

Creating a run claims every unpaid ledger entry in the period across the org's projects, freezes the per-member breakdown and total, and notifies every member in the run (your payout is queued). A period with no unpaid entries cannot be created. Run creation is audit-logged.

Run detail

Opening a run shows status, entry count, total, reference, note, and the frozen per-member table (units, amount). Downloads:

• Download CSV / Download PDF — the whole run. The CSV is the one for your books.
• Receipt PDF per member — that member's slice only. Until the run is paid it is a Statement PDF: a receipt is for money that was paid.

PDFs render with the org's default receipt template. The default layout shows who was paid and by whom, the payout number, the period, when it was paid and the reference, the work by project and the total. The heading of every page carries what is needed to check the document: the verification code, where to check it (/verify-receipt) and a QR code, so a long list of projects never pushes them off the page. The sheet for a whole run names each person once, with what they get in all, and lists their projects beside the name. It carries your organisation's logo when its receipt template has one, else the platform's. Every PDF and CSV carries the verification code.

Mark paid

Pay outside the platform, then Mark paid (from the row or the detail). You confirm the period, member count, and total; the run is stamped with today's paid date and each member is notified (you were paid, with the reference if set and a pointer to their receipt). Audit-logged.

• A paid run cannot be marked paid again, deleted, or edited.
• If the org policy Passkey required for sensitive actions is on, the acting account needs a registered passkey or the action is refused — see Org policies.

Delete a draft

Deleting a draft run releases its entries back to the unpaid pool (a later run can claim them), notifies the affected members (draft payout withdrawn), and is audit-logged. Paid runs cannot be deleted.

Receipt templates

Receipt templates (title row) lists the three built-in layouts — Classic, Compact, Statement — plus the org's own templates, with the current Default badged.

Action	Effect
Make default	Every receipt PDF the org (or its members) downloads renders with this template from now on
Delete	Removes an org template from the picker. Built-ins cannot be deleted. Past receipts are unaffected — receipts are rendered on demand from the run's frozen breakdown, and a deleted default falls back to Classic.
+ New template	Opens the editor

New template — Guided

Name (required, ≤ 80 chars), base layout (Classic / Compact / Statement), optional accent colour (hex, e.g. #4c5fa9), header text (≤ 300 chars, e.g. legal name / address), footer text (≤ 200 chars), and an optional logo (PNG, JPEG, or GIF). Anything left blank falls back to platform branding.

New template — Custom HTML

Author the whole receipt document. The editor starts from a valid document, validates on the server as you type (about half a second after you stop), and shows a live preview with sample values. A clickable variable palette inserts {{variable}} tokens at the cursor; required ones are marked.

Variables: platform_name, org_name, run_id, payout_number, period_start, period_end, status, paid_at, reference, member_name, member_email, total_amount, currency, verification_code, breakdown_table, org_logo (the uploaded template logo — use it only as an <img src="{{org_logo}}">).

Required: run_id, total_amount, breakdown_table, verification_code — a template missing any of them cannot be saved.

Sanitisation rules (the server is the source of truth; errors block saving, warnings don't):

• Whitelisted tags only — no <a>, <script>, <iframe>, <form>, <object>, <embed>, <svg>, and similar. Inner text of a stripped tag is kept.
• No links of any kind: href never survives; url(...), @import, javascript:, expression(...), and CSS backslash escapes are removed from styles.
• Unknown variables are reported.

Preview PDF renders a watermarked SAMPLE — NOT A RECEIPT PDF from dummy values inside the editor; it is disabled while the template is invalid. The template is stored already sanitised, with Classic recorded as its fallback layout — if a custom document ever fails to render, the download falls back to that base layout instead of failing.

Template creation and deletion are audit-logged.

Receipts on the contributor's side

Members who have been paid see Your receipts on their own profile under Analytics — one row per paid run (paid date, organization, period, amount) with Receipt PDF / CSV downloads of their own slice, rendered with the paying org's default template. The list renders nothing until the user has at least one paid run, shows only the account owner's receipts, and on the desktop app directs the user to download online. Runs still in draft do not appear there.

Gotchas

• Until is exclusive. A run for March is 2026-03-01 → 2026-04-01.
• Preview ≠ claim. Two admins previewing the same period both see the same balance; only the first run to be created claims the entries — the second finds nothing claimable.
• Amounts are frozen at claim time. Rate-card changes after a run is created never change that run or its receipts.
• Mark paid is the only thing members see as "paid". Entries in a draft run still show as pending in their statements.
• Custom HTML can't be edited after saving — there is no edit action; create a replacement and delete the old one.

What's next

• Contributions & payment → — the ledger, rate cards, rate changes, and the payout-run model
• Org policies → — the passkey requirement that gates marking a run paid
• Account settings → — where contributors find their earnings and receipts