Contributions & payment

Payment support is the rarest feature in the dataset-tooling ecosystem — and its absence is why contributor payment usually lives in a spreadsheet that drifts from the truth. AfriAnnotate makes the record automatic and the math transparent: the platform counts and computes; you pay however you pay — it never moves money itself.

The ledger

An append-only ledger records validated work automatically — every kind of contribution on the platform, text and speech alike, not just recordings:

Entry	Earned when	Who earns
annotation_accepted	A reviewer accepts an annotation — any project type: translation, NER, sentiment, transcription, …	The annotator
vote_cast	A validation vote is cast	The voter
prompt_accepted	A submitted sentence is accepted (prompt collector)	The author
clip_validated	The crowd validates a recording (Listen)	The speaker

Design properties that keep it trustworthy:

• Credit lands at validation, not submission — rejected work earns nothing, so the incentive is quality, not volume.
• Idempotent — every entry is keyed to the exact thing it credits; no replay, retry, or sync hiccup can double-count.
• Append-only — entries are never edited or deleted; corrections are new entries. The history is the audit trail.
• Non-blocking — accounting can never break the annotation or validation flow it observes.

Rate cards

Project Settings → Contributions:

• Set a rate per unit kind (per accepted annotation, per vote, per accepted prompt, per validated clip) in a free-text currency — NGN, ETB, KES, "airtime", any unit your campaign actually pays in.
• Choose whether contributors see the card. Recommended: yes — posted rates are how fair campaigns advertise themselves: shared cards show a "Pays …" line on the project's Discover card, visible before anyone joins. Amounts are always labeled owner-declared.
• Every credit is stamped with the rate it was earned under — like a consent signature binding to a template version. The deal your work was done under is fixed at the moment it's validated.
• Self-dealing is bounded. Nobody can validate their own work into earnings — self-review and self-votes are blocked platform-wide. Owners who genuinely contribute can earn like anyone (their entries are named in every breakdown and export); orgs that want a hard line tick "Managers don't accrue earnings" on the rate card, and owners, admins, and managers stop accruing ledger entries on that project entirely.

Rate changes

Changing a live rate card is a contract change, and the platform treats it like one:

• The owner picks a scope at save time: future work only (done work keeps its old rate — the default) or also reprice validated unpaid work. Work frozen into payout runs is untouchable either way.
• Contributors are told immediately — an in-app notification, and a blocking modal for anyone actively annotating showing old → new rates side by side. Exactly two choices: Accept & continue, or Reject — pay out my work, which records their decision, ends their participation, keeps their validated balance owed, and notifies the owner of the amount to include in the next payout run.
• Several changes before someone looks? One modal, one decision: the contributor sees the rates they last worked under against the card as it is now ("N changes since you last reviewed") — never intermediate states — and their single decision acknowledges every change in the span, each with its own recorded acknowledgement.
• Every change and every decision is recorded (who changed what, when, what each contributor chose, and what they were owed at that moment) — any later dispute has a complete paper trail. Rate changes are also audit-logged.

Statements and payouts

• Contributors see their own statement — validated units per project, with amounts when the project shares its rate card — on their profile under Analytics → Earnings, with paid/pending headline chips and per-currency totals. It is visible only to the account owner: earnings are private financial data, so even org admins viewing another member's analytics don't see it (admins have the org Payouts and expenditure surfaces instead). It renders nothing for non-contributors; no empty chrome.
• Contributors own their financial data. The Earnings tab has a Download CSV of the full statement, and a Your receipts list — one branded receipt (PDF) per payout run that paid them, identical to what the org side would issue.
• Owners see per-contributor totals in Settings → Contributions and export a payout CSV for any date window (payout runs are usually "last month"): email, name, facilitator, units per kind, amount, currency.
• Field campaigns slice by coordinator: the CSV's facilitator column and per-facilitator grouping match how field payment actually flows.

Payout runs

Organization → Payouts (org owners and admins) turns "pay last month" into a first-class record instead of a spreadsheet:

• Preview, then claim. Pick a date period and the run preview shows the unpaid balance — members, units, amounts. Creating the run claims every unpaid ledger entry in that period across the org's projects; an entry can only ever belong to one run, so nothing can be paid twice.
• Frozen amounts. The run snapshots the per-member breakdown (units × the rate card at claim time). Changing rates later never rewrites an existing run or its receipts.
• Draft → paid. Pay outside the platform — mobile money, bank, airtime — then mark the run paid (with an optional batch reference, e.g. a mobile-money batch id). The paid date is stamped on the run. Draft runs can be deleted, which releases their entries back to unpaid; paid runs cannot.
• Receipts. From the run detail, download a CSV for the whole run (period, units per kind, amounts, reference) and a receipt PDF per member.
• Branded PDF receipts. The same downloads are also available as PDFs carrying the platform's name, color, and logo, in three built-in layouts (classic, compact, statement). Orgs can save their own templates on top — a built-in layout plus their accent color, header/footer text, and logo — and pick the org default used for downloads (built-ins or their own). Deleting a template never affects past receipts: receipts are generated on demand from the run's frozen breakdown, so a deleted template simply disappears from the picker. CSV downloads are unchanged.
• Custom HTML templates. Orgs can also author a full receipt document in HTML (New template → Custom HTML tab), with live validation, an in-editor preview, and a watermarked sample-PDF preview. Templates are sandboxed — no links, no scripts, no external fetches, images limited to the uploaded template logo — and must include the run number, amounts, itemized breakdown, and verification code, so a custom receipt can never omit the figures that make it verifiable. A template that fails to render falls back to the classic layout rather than breaking a download.
• Receipts are verifiable. Every receipt (PDF footer and CSV) carries a verification code computed server-side from the run's frozen record. Anyone handed a receipt — a bank, a facilitator, an adjudicator — can enter the run number and code on the public verify page at /verify-receipt (no account needed; the page URL is printed on the receipt) and see the platform's own frozen figures; an altered amount, date, or reference on the document won't match. The stored run itself remains the source of truth in any dispute — paid runs can never be edited or deleted.
• Org-wide expenditure export. The Payouts page's Export CSV flattens every run's frozen breakdown — run, period, paid date, reference, member, project, units per kind, amount — with per-currency grand totals, and respects the status filter (e.g. paid runs only).
• Contributors see the status. The "My contributions" statement gains a Paid / Pending filter, per-currency totals, and shows "paid on <date>" once the covering run is marked paid. Entries in a draft run still count as pending — only a marked-paid run changes what contributors see.
• Run creation, payment, and deletion are audit-logged. As everywhere in the ledger, the platform records and computes — it never moves money.