{
 "notes": "Top priority tonight is giving Maren and Tobias's team concrete evidence to reconcile the revenue numbers, rather than just re-asserting my figure. I've cross-checked internally: my €53,186 fee revenue / €1,991,449 gross volume for 2025 is consistent across two independent reports (merchant-level and corrected vertical-level) built with an explicit, auditable method (status='paid', exact-date EUR conversion). Notably, Kofi's €93,583 figure is almost exactly 1.76x mine — the same ratio as the original buggy vertical report I caught and fixed in week 1 — which strongly suggests his team's query has a similar join fan-out (likely against exchange_rates or a one-to-many table), not a genuine methodology difference. A clean currency-level breakdown tonight will (a) give me hard evidence to bring to a joint session with Tobias's team, and (b) double as the FX-exposure view Tobias asked for. I'm also using tonight's other two slots on items Maren explicitly wants resolved this week outside the bigger unit-economics scoping: testing whether the refund uptick is concentrated (per Kofi's claim) or broad, and building the \"accounts to watch\" risk snapshot (which also answers Tobias's receivables-aging question). I'm deliberately not starting the cost-to-serve/unit-economics build yet — that needs a design conversation with Tobias before I spend slots on it.",
 "requests": [
  {
   "title": "2025 payout fee revenue and volume by currency",
   "question": "Does our 2025 fee-revenue total hold up when broken down by currency, and which currencies carry our FX exposure?",
   "grain": "one row per payout currency_code",
   "columns": [
    "currency_code",
    "payout count",
    "total gross amount (native currency, unconverted)",
    "total fee amount (native currency, unconverted)",
    "total gross volume (EUR)",
    "total fee revenue (EUR)",
    "implied average rate (native currency per EUR, = total fee native / total fee EUR)",
    "share of total EUR fee revenue (%)"
   ],
   "details": "Source: payouts only, filtered to status='paid' and paid_at >= 2025-01-01 and paid_at < 2026-01-01 (the validated definition of settled payouts from last week's reconciliation). Convert each payout row to EUR individually via exchange_rates (base_code='EUR', quote_code=payouts.currency_code, as_of=date(paid_at)) before summing, exactly as in the validated merchant/vertical reports — no fan-out joins (aggregate at the payout row level first, do not join to any one-to-many table like payout_items, ledger_entries, or tenants before this aggregation). I want this to double-check against a competing figure from Finance (€93,583 fee revenue vs my €53,186 for the same 2025 window) — please confirm in the report notes that summing total_fee_revenue_eur across all currency rows reproduces €53,186 (if not, flag immediately, something changed). Order by fee revenue EUR descending, tie-break by currency_code ascending.",
   "builds_on": [
    "Payout status & date-field reconciliation",
    "Revenue by vertical, trailing 12 months (corrected)"
   ]
  },
  {
   "title": "Merchant refund-rate spike check, Q4 2025 vs 2025 baseline",
   "question": "Is the Q4 2025 refund-rate increase concentrated in a handful of merchants, or spread broadly across the merchant base?",
   "grain": "one row per merchant (tenant)",
   "columns": [
    "merchant name",
    "vertical",
    "refund rate Q4 2025 (%)",
    "refund rate Q1-Q3 2025 baseline (%)",
    "change vs own baseline (percentage points)",
    "refund amount Q4 2025 (EUR)",
    "order count Q4 2025"
   ],
   "details": "Source: payment_refunds (status='succeeded', processed_at in quarter, amount converted to EUR via exchange_rates as_of processed_at date) as the numerator, divided by payments (status in 'captured','partially_refunded','refunded', captured_at in quarter, amount converted to EUR via exchange_rates as_of captured_at date) as the denominator, both joined to orders->tenants (or directly via payments.order_id->orders.tenant_id) to attribute to a merchant. Compute refund rate = 100 * refund EUR / captured payment EUR, once for Q4 2025 (2025-10-01 to 2026-01-01) and once pooled across Q1-Q3 2025 (2025-01-01 to 2025-10-01) as each merchant's own baseline. 'Change vs own baseline' lets us separate merchants with a structurally high rate (e.g. apparel, reportedly ~20% normally) from merchants whose rate genuinely jumped in Q4. Include only merchants with at least 10 orders in Q4 2025 to avoid noise from tiny volumes. Order by change vs own baseline descending (biggest jumps first), tie-break by refund amount Q4 2025 descending. Note total merchant count returned.",
   "builds_on": []
  },
  {
   "title": "Merchant risk signals snapshot: receivables, traffic and revenue trend",
   "question": "Which merchants look at risk right now, based on unpaid invoices, traffic decline, and revenue trend — our 'accounts to watch' list?",
   "grain": "one row per merchant (tenant)",
   "columns": [
    "merchant name",
    "vertical",
    "unpaid invoice balance (EUR, open+past_due invoices)",
    "web traffic change Q4 vs Q3 2025 (%, session count)",
    "fee revenue change Q4 vs Q3 2025 (%)",
    "days since last order placed (as of 2026-01-05)",
    "tenant status"
   ],
   "details": "Source: invoices (status in 'open','past_due', amount_due summed per tenant, converted to EUR using the most recent available exchange_rates as_of date on or before 2025-12-31) for unpaid balance; web_sessions (started_at in Q3 2025 vs Q4 2025, count per tenant) for traffic change; payouts (status='paid', paid_at in Q3 2025 vs Q4 2025, fee_amount converted to EUR) for revenue change; orders (max placed_at per tenant, any status) for recency; tenants for name/vertical/status (exclude deleted_at not null). Traffic and revenue change = 100*(Q4-Q3)/Q3, null if Q3 value is zero. Order by unpaid invoice balance EUR descending, tie-break by traffic change ascending (most negative first), then merchant name. Print top 50 rows and note total merchant count with any non-zero unpaid balance or traffic/revenue decline.",
   "builds_on": []
  }
 ]
}