Finance

# Finance — inbox

Wolfgang writes here when Matt routes a message to this agent.
Finance polls this file on cadence and appends responses below.

---

## 2026-05-23 21:40 UTC — decisions on the 4-question approval (from Matt via Wolfgang)

All four answered. See `queue/approvals-decided/finance-2026-05-23-2330-pre-launch-decisions.md` for the full annotated file.

Quick summary:
1. **Teller cost = $0.30/account/month** (lock that into your model)
2. **Lead with lifetime in launch outreach** — Marketing + Sales unblocked
3. **Matt is opening a Mercury Helm sub-account.** Use shared Hondo + descriptor tags until routing info lands.
4. **Sales tax = via Stripe Tax** — coordinate with Tech Architect to ensure Stripe Tax is enabled on the Helm account.

Action items for you tomorrow's standup:
- Update `specs/finance-launch-readiness.md` with the locked Teller rate
- Drop a handoff to Tech Architect: confirm Stripe Tax is enabled on Helm
- Add a "waiting on Matt's Mercury sub-account routing info" line to your launch checklist

— wolfgang


## 2026-05-24 00:31 UTC — decision on finance-2026-05-24-0030-stripe-account-1099k-gaps (Matt via dashboard)

All of these are set.

— wolfgang


## 2026-05-24 ~11:10 UTC — your 0730 Stripe approval is closed false-positive (Wolfgang)

Per Matt's Dashboard screenshots + Wolfgang's live API re-pull: EIN IS set (legacy `company.tax_id_provided` is a Connect-flow field; standard accounts store EIN on internal verification records). `requirements.currently_due: []` confirms Stripe considers the account fully verified.

Same caveat goes for `company.address` and `tos_acceptance.date` nullability — both are misleading on standard accounts.

For your 1099-K monitoring going forward, watch `requirements.currently_due` and `requirements.eventually_due` from `GET /v1/account` — those are the truth-telling fields. If something's actually missing for tax filing, Stripe will surface it there.

Approval moved to `queue/approvals-decided/finance-2026-05-24-0730-stripe-1099k-gaps-still-null.md` with full context appended.

The one real action item from your original 4-field list is the `Grould → Gould` typo, and even that's Dashboard-only (POST /v1/account against own account is blocked for ALL standard accounts).

— wolfgang

• - 00:30 UTC autonomous work cycle: processed TA's reply to 1099-K handoff (`queue/finance-pending/...` now deleted). TA found 4 gaps in Helm Stripe account that need Matt-in-Dashboard: (1) EIN missing — launch-week-critical for 1099-K; (2) `company.address` null (only `business_profile.support_address` set); (3) ToS not accepted by account holder; (4) `business_profile.support_email` null. Plus typo "Grould → Gould" in support address. Filed `queue/approvals/finance-2026-05-24-0030-stripe-account-1099k-gaps.md` framing as one 5-min Dashboard session, Mon-evening expiry, EIN flagged as weekly-follow-up if not done. Updated spec §5 to mark webhook endpoint ✅ (Wolfgang created `we_1TaOhF6HplA3FxptzK9QrNb6` at 00:15 UTC — events flow once PR #58 merges) + replace 🚨 webhook line with the new 🚨 4-Stripe-gaps line. Updated §5b 1099-K status with EIN-missing + escalation link. Updated first-sale checklist to point at the new webhook endpoint ID. Quiet on Mercury sub-account routing (still pending Matt) + Teller live creds (per Otto's spec) + Stripe Tax (deferred week-2).
• - 01:21 UTC autonomous work cycle: Matt resolved the 4-Stripe-gaps approval at 00:31 UTC ("All of these are set") — moved to approvals-decided. Updated spec §5 (4-gaps line ✅ resolved) + §5b 1099-K status ("✅ Matt resolved 00:31 UTC, 1099-K filing path clear, will re-verify via TA post-launch"). Created `finance/` working dir with 4 skeleton files per charter: `README.md` (conventions + cross-refs), `revenue-ledger.md` (append-only per-charge table with schema), `customers.md` (informal CRM table + churn-watch tally), `daily.md` (per-charter 9:23 AM EST sweep template), `weekly.md` (per-charter Friday 4:43 PM EST template). All four are populated with schema + conventions + "no entries yet" placeholders so the first-sale checklist has somewhere to write Tuesday. Noted in `weekly.md` that the Friday cash-report cron isn't yet in `~/.claude/finance-crons.json` — not blocking launch (can roll into Friday's standup) but worth a config addition in a future autonomy revision.
• - 02:21 UTC autonomous work cycle: inbox + finance-pending empty, all owned launch-readiness items either ✅ or upstream-pending (Mercury routing, Teller creds). Drafted `specs/finance-launch-day-playbook.md` — operational layer on top of the model spec. Covers: Monday EOD pre-launch verifications (Stripe account state, price IDs, webhook endpoint, Mercury baseline, finance/ skeleton, cron cadence); Tuesday hour-by-hour (T-2h test charge → T-0 dashboard watch → first-sale full checklist → T+4h signal sweep → T+24h first daily sweep); Wed-Fri week-1 daily cadence; refund handling procedure (Stripe webhook → revenue-ledger correction row → customers.md status flip → Mercury reconciliation tag); 5 fraud signals to escalate-don't-wait (fraudulent decline_code, velocity-exceeded, multi-customer-from-same-IP, Radar >75, chargebacks, unexpected refunds); 4 anomalies to expect-don't-alarm (first-payout 2-7d delay, instant-refunds, abandoned Stripe Checkouts, lifetime net within $1 of model). Wired `finance/README.md` cross-refs and `finance-launch-readiness.md` §4 to point at the playbook.
• - 04:21 UTC autonomous work cycle: inbox + finance-pending empty; CronList confirms both crons armed (work cycle every 71m + daily standup 13:23 UTC). Pre-staged Monday afternoon pre-launch state verification — filed `queue/tech-architect-pending/finance-2026-05-24-0430-monday-prelaunch-stripe-verification.md` bundling 4 Stripe API checks for TA to run between 14:00-18:00 UTC Monday: (1) re-verify Matt's 00:31 UTC 1099-K fixes still set, (2) confirm STRIPE_PRICE_ID + lifetime price resolve to correct $149/$1,499 on Railway, (3) webhook endpoint `we_1TaOhF6HplA3FxptzK9QrNb6` enabled with all 11 Otto events, (4) bonus — verify `trial_period_days: 7` is actually in code for the monthly tier (launch-blocker escalation to Otto if missing). Updated `specs/finance-launch-day-playbook.md` Monday section to point at the bundled handoff. Also corrected `finance/daily.md` cron-time note to distinguish EDT (current, launch-week) from EST (off-DST) and call out that the dedicated daily-sweep cron is folded into the standup cycle until a separate entry is added.
• - 05:21 UTC autonomous work cycle: inbox + finance-pending empty; reviewed Ops's new `ops-2026-05-24-0400-anthropic-key-dead-plus-resend-domain.md` (Anthropic LLM key dead + no helmhelps.com Resend domain — both launch-blockers, both Matt-action items, no Finance action required since cost model is unchanged). Added a Dunning handling section to `specs/finance-launch-day-playbook.md` covering: status transitions (trialing/active → past_due → recovery or canceled), Finance actions when `invoice.payment_failed` fires (mark past_due, don't book failed charge, exclude from MRR, heads-up to Support for high-value), decline-code interpretation (expired_card/insufficient_funds = likely recovery, fraudulent/velocity = fraud-path not retry-path), and a pre-existing-caveat noting Helm's `User::SUBSCRIPTION_STATUSES` lacks `trialing` per Designer's audit (Stripe is source of truth, app-state drift is TA/Designer concern). Updated `finance/customers.md` status list to add `past_due` definition + MRR-exclusion rule. Updated `finance/daily.md` schema to track dunning entries/recoveries/give-ups as distinct events. Reasoning: 7-day trial means day-8 dunning failures are an expected launch-week category (not an anomaly), worth a documented procedure rather than improvising Tuesday.
• - 06:21 UTC autonomous work cycle: inbox + finance-pending empty; 7 open approvals all owned elsewhere. Otto's launch-readiness spec shows 6 of 7 blockers merged — most relevant to Finance: **PR #58 (webhook persistence + retry) merged 2026-05-24 05:32** and **PR #54 (Stripe Customer Portal) merged 2026-05-24 04:32**. Removed "depends on #58" caveats from `finance-launch-readiness.md` first-sale checklist + `finance-launch-day-playbook.md` T-2h test charge + refund-handling step. Updated §5 webhook line to reflect events flow end-to-end now (endpoint exists + persistence in place). No other spec drift identified.
• - 18:21 UTC autonomous work cycle: Otto shipped `specs/2026-05-24-merge-digest.md` with all 20 Sunday PRs. Most Finance-relevant: **first monthly-trial conversions fire Friday 2026-05-29 ~13:00 UTC** (per PR #83 TrialReminderMailer wiring + Stripe's standard 7-day trial-end timing for Tuesday signups). Added a "Friday 2026-05-29 ~13:00 UTC — first trial-conversion wave (the *real* Finance Day-1)" section to `finance-launch-day-playbook.md` between Wed-Fri cadence and Friday weekly report — captures: watch Stripe Dashboard live during 12:00-14:00 UTC, each conversion runs the first-paying-customer checklist, healthy-conversion signal threshold (>50% good, <30% re-examine), first real MRR snapshot post-Friday. Reasoning: Tuesday gets lifetime customers (immediate charges) + monthly trials (no charges). The first wave of monthly conversions is the true Finance pulse-check, not Tuesday itself.
• - 16:21 UTC autonomous work cycle: TA shipped `scripts/preflight-check.sh` — self-serve launch verification covering Stripe account state (with correct Standard-account methodology), prices, webhook endpoint, Customer Portal, Resend sender domain, Anthropic + OpenAI APIs, Better Stack token. Exits 1 on FAIL. Updated `specs/finance-launch-day-playbook.md` Monday section to lead with `./scripts/preflight-check.sh` (replaces most of the per-cycle TA handoffs Finance previously filed for verification) + T-2h Tuesday flow to start with same script. Updated `finance/README.md` cross-refs. Bulk of pre-launch + Tuesday-morning verification work is now self-serve; Finance just runs the script and acts on FAIL.
• - 13:21 UTC autonomous work cycle: TA ran my Monday pre-launch Stripe verification 24h early (`queue/finance-pending/tech-architect-2026-05-24-1245-stripe-pre-launch-verification.md`, now deleted). **Mostly green — TA caught + self-fixed a real launch-blocker:** webhook endpoint had `invoice.paid` configured, but Helm's processor only handles `invoice.payment_succeeded` — different Stripe events. Past_due→active reactivation would have silently no-op'd. TA patched additively (kept invoice.paid for no-op, added invoice.payment_succeeded; endpoint now 14 events). All-positive findings: account launch-ready by correct methodology (`requirements.currently_due: null`, charges/payouts enabled, details submitted); both price IDs resolve correctly ($149 monthly recurring, $1,499 lifetime one_time); **lifetime price is now env-driven** (`HELM_STRIPE_LIFETIME_PRICE_ID`) not raw cents constant — pre-existing gap closed; **trial config (`trial_period_days: 7`) shipped via PR #79 09:01 UTC**; Grould→Gould typo fixed (TA notes "Ste R" suite designator absent in fix — Matt's call). Updated spec §5 with three new ✅ rows (lifetime env-driven, trial shipped, webhook event-name patched). Updated typo row to ✅ with the Ste-R note. TA will re-run Monday afternoon as final state-snapshot per the original handoff.
• - 11:21 UTC autonomous work cycle: **Wolfgang resolved my 07:30 re-escalation as a false positive.** Per Wolfgang's clarification (now in `queue/approvals-decided/finance-2026-05-24-0730-stripe-1099k-gaps-still-null.md`): Stripe Standard accounts (Helm's type) store EIN, `company.address`, and ToS acceptance in internal verification records — NOT on the public `company.tax_id_provided` / `company.address` / `tos_acceptance.date` fields. Those nullability checks are MISLEADING on Standard accounts (they're Connect-flow artifacts). Authoritative health signals are `requirements.currently_due: []`, `charges_enabled: true`, `payouts_enabled: true`, `details_submitted: true` — all green on Helm. **Only real action item from my list: the Grould→Gould typo** (also Dashboard-only — `POST /v1/account` is blocked for all standard accounts). Matt was right; my re-escalation generated noise. Updated spec §5 (4-gaps line → ✅ FALSE POSITIVE on 3 of 4) + §5b 1099-K methodology (use `requirements.currently_due` going forward, not field nullability). Updated `finance-launch-day-playbook.md` Monday pre-launch verification to use the correct signals. Lesson logged to memory.
• - 09:21 UTC autonomous work cycle: quiet — inbox + finance-pending empty, no new finance-relevant activity since last cycle. Caught a real correction in Otto's spec update: Helm uses Anthropic exclusively (`claude-opus-4-7` per `Agreements::Extractor`) for contract extraction — not Sonnet as my cost model assumed (~5x more expensive per-token). OpenAI is used separately by `StatementExtractionService` for bank statement parsing. Updated `specs/finance-launch-readiness.md` §2 vendor table to split Anthropic-contract from OpenAI-statement rows with correct Opus 4.7 pricing ($0.15/contract), §3 per-customer contribution to itemize both ($0.30 Anthropic + $0.10 OpenAI — same $0.40 total as before, just decomposed correctly). Updated `finance/vendor-costs.md` 2026-05 + 2026-06 tables to split same way. Net contribution per customer unchanged at $143.53 launch / $143.16 week-2-onwards — the decomposition is for accuracy not magnitude.
• - 08:21 UTC autonomous work cycle: inbox + finance-pending empty; my 07:30 re-escalation sitting in approvals waiting for Matt; nothing else for Finance to process. Drafted `finance/mrr-methodology.md` — authoritative computation rules for MRR / ARR / Lifetime cash banked / LTV / ARPU. Covers what counts (active monthly = MRR; trialing/past_due/lifetime/canceled = excluded), Lifetime treatment (zero MRR contribution by definition — cumulative cash banked instead), cancel-at-period-end timing (still active in MRR until Stripe transitions), Stripe-Tax-week-2 handling (MRR computed on gross $149 not net), ARR/LTV/ARPU formulas, "don't quote without context" guidance, and 5 explicit anti-patterns to avoid (lifetime-in-MRR error, double-counting refunds, extrapolating ARR from <30d, etc.). Added to `finance/README.md` file listing. Reasoning: trial + dunning + lifetime mix makes "what's our MRR" ambiguous without a documented method — better to publish the rule pre-launch than negotiate it ad-hoc with Matt/Otto/Sales asking for numbers Tuesday-Friday.
• - 07:21 UTC autonomous work cycle: **TA ran Monday verification 28h early** (`queue/finance-pending/tech-architect-2026-05-24-1015-monday-stripe-verification.md`, now deleted post-processing). **Major finding:** 3 of 4 Stripe Dashboard fields Matt reported "all set" at 00:31 UTC are **STILL NULL** on the live account (EIN, company.address, ToS acceptance — only support_email actually persisted); Grould→Gould typo also still there. Filed re-escalation `queue/approvals/finance-2026-05-24-0730-stripe-1099k-gaps-still-null.md` with field-by-field Stripe Dashboard instructions, two-paragraph explanation of what probably went wrong (Matt either didn't click final Save OR assumed values were complete and replied without changing), and weekly-follow-up commitment if still NULL Tue EOD. Updated spec §5 4-gaps line to 🚨 RE-ESCALATED + §5b 1099-K status to reflect 10:15 UTC verification. **Bonus TA finding:** webhook endpoint has 9 of Otto's 11 events — `charge.refunded` + `charge.dispute.created` missing (both Finance-critical for refund/chargeback signal). TA already filed Matt approval `tech-architect-2026-05-24-1015-stripe-webhook-charge-events.md`; added parallel row in spec §5 referencing it. **Bonus TA finding:** trial code (`trial_period_days: 7`) NOT yet in app — TA starts the PR next (was queued behind the 7-blocker chain which all landed today). Not flagging as launch-blocker per TA's reasoning (Tuesday signups route through existing immediate-charge flow until trial PR lands).
• - 03:21 UTC autonomous work cycle: inbox + finance-pending empty; reviewed 5 open approvals (all owned by other agents — Ops's STRIPE_SECRET_KEY drift correctly routed to Matt as banking-adjacent; TA's Stripe Customer Portal config is upstream of my churn-tracking but no decision needed from me). Created `finance/vendor-costs.md` — actuals-vs-model tracker scaffolded for 2026-05 (partial — ~$5 best-case) and 2026-06 (first full month), with drift methodology + thresholds (|drift|>$20 per vendor = note, total >$50 = revise spec) + cross-refs back to launch-readiness §2/§3/§5. Added vendor-costs to `finance/README.md` file listing. Quiet on Mercury sub-account routing + Teller live creds (both upstream-pending Matt). **Found significant gap:** Sales spec confirms Matt approved a 7-day free trial on monthly 2026-05-23 21:42 UTC that my Finance spec + playbook never reflected. Updated `specs/finance-launch-readiness.md` — added top-of-spec trial-config note + new § 6 "Free-trial financial impact" with revised 90-day projections (trial cuts monthly cumulative roughly in half through 50%-conversion assumption × 1-week delay; lifetime numbers unchanged so the lifetime tier becomes EVEN more important to launch-week cashflow); renumbered "What I'll do next" to § 7. Updated `finance/customers.md` schema to add `trialing` status value + `Trial ends (date)` column + churn-watch table now tracks new-trials / conversions / trial-cancels / active-cancels separately. Updated `finance/daily.md` schema to track trial signups + conversions + trial-cancels as distinct events from active charges. Updated `specs/finance-launch-day-playbook.md` to add first-trial-signup moment as distinct from first-sale (lifetime hits first-sale day-0, monthly hits it day-8) + T+4h sweep splits subscriptions by trialing/active + added two trial-related expected-anomalies (Tue-Fri lifetime-dominant + 30-50% normal trial-conversion range).
• Ran Finance's Monday-pre-launch Stripe checks early to give buffer. Caught real red: Stripe webhook endpoint we_1TaOhF6HplA3FxptzK9QrNb6 was configured with `invoice.paid` but `app/services/webhooks/stripe_processor.rb` only handles `invoice.payment_succeeded`. Past_due → active reactivation would have silently broken. Patched endpoint via API (additive only, added `invoice.payment_succeeded`; no events removed). Reply filed at `queue/finance-pending/tech-architect-2026-05-24-1245-stripe-pre-launch-verification.md`. Will re-run Monday afternoon.
• - **Yesterday:** Drafted `specs/finance-launch-readiness.md` ($149 mo / $1,499 lifetime, vendor cost inventory, breakeven, first-sale checklist) + processed Matt's 4-question decision packet (Teller $0.30/account-metered locked, lifetime-first launch comms approved, Mercury sub-account being opened, Stripe Tax via Stripe Tax).
• - **Today:** Iterated through 11+ work cycles — integrated 7-day trial impact (new §6: cuts 90-day monthly cumulative ~half, lifetime tier becomes even more important; $143.53/customer contribution); added dunning + past_due procedure; drafted `finance-launch-day-playbook.md` (Mon-prep → Tue hour-by-hour → Wed-Fri cadence + refund + 5 fraud signals); built `finance/` skeleton (revenue-ledger, customers w/ trial+past_due states, daily, weekly, vendor-costs, mrr-methodology); TA ran my Monday Stripe verification 24h early and caught + self-fixed a real launch-blocker (`invoice.paid` vs `invoice.payment_succeeded` event-name mismatch — past_due→active recovery would have silently no-op'd); Wolfgang corrected my false-positive 1099-K escalation (Standard accounts use `requirements.currently_due` not `company.*` nullability — methodology saved to memory).
• - **Blockers:** Mercury sub-account routing info still pending Matt (using shared Hondo + `STRIPE-HELM-<date>` descriptor tags as fallback per Q3 decision); Teller live creds still pending Matt per Otto's launch spec.