The cost of an AI-CRM is a forecastable line
Two decades of CRM spend has drifted from licence fees to per-seat fees to consumption fees to a cloud of SKUs no one can add up. AI adds a third dimension: tokens, model routing, retries — a running meter with no ceiling and no receipt.
Actionary treats spend as a design surface. The CRM is free. The agent is metered. Everything else is priced per-module. Every dollar Stripe collects composes onto one Subscription per tenant, one line per capability, and every line traces to a mechanism you can name.
Spend that scales with value
Three metered surfaces compose on one Stripe Subscription per tenant.
Metered agent usage — cost-plus. Every agent turn records what the model provider charged that turn. A nightly sweep sums yesterday’s raw cost, multiplies by the platform margin (default 3.0×, clamped 1.0× to 10.0×), and posts one usage record per tenant per day. A Stripe outage does not double-bill — the day-bucketed idempotency key makes reruns a no-op. Invoice lines read “Assistant usage: N units × $0.01”.
Per-module flat. Turn a module on and one flat charge appears on the Subscription. Turn it off and it vanishes. The core CRM has no price. It stays free.
Per-module per-seat. Same wiring, priced per active user. Every invite or removal syncs the seat count to Stripe. The call is skipped when the count has not moved, so you never see phantom charges from a hiccup.
Default daily cap is $5, monthly $100, calendar-bounded and hard-blocked at 100%. A runaway workflow cannot spend more than you agreed to spend. See pricing for the per-module list.
Cost-plus means the meter is auditable
A power-user turn costs more than a casual one, billed in proportion. Flat per-turn pricing loses money on heavy turns and overcharges light ones — both are silent transfers between customer and vendor.
Every trace is visible. A billing-status endpoint returns turn counts and dollars billed for the day, yesterday, and month-to-date — computed from the same raw cost column Stripe eventually bills. Platform staff see the platform-wide margin on their own billing page; tenants see their line items on theirs. The multiplier is a printed number you can read.
Bring-your-own-key on the model provider applies the same way to speech-to-text and embeddings as it does to the chat model — a tenant on its own key pays the raw provider rate.
The full AR pipeline lives in the database
Every record renders to PDF inside the app itself — no external service, no headless-browser sidecar, no third-party rendering account. Invoices ship with four template variants (Standard, Totals only, Hours-based, Units-based), each cloneable through a Duplicate button and editable in a drag-drop designer.
Per-customer defaults: pick a template for an account once and every new invoice for that account auto-fills it. The per-invoice picker overrides for one-offs.
Invoice total, subtotal, tax, amount paid, and amount outstanding are stored columns. Five composing triggers keep them current the instant a line item or payment writes. Payment allocations are many-to-many and polymorphic on the target — one bank deposit splits across invoices, allocates to a project before any invoice exists, or lands against whatever entity your AR model uses. No schema change per tenant.
Bill-to address copies onto the invoice at create time and freezes on issuance. The issued invoice is a legal record that reads the same in five years as it did the day it was sent, even if the customer moves office.
The aged-debtors report at /<workspace>/aged-debtors uses the canonical five-bucket ageing. Every row drills through to the underlying invoice in one click.
Billing status is one signal
A tenant’s billing status is one of five values — inactive, trialing, active, past due, or cancelled. Stripe webhooks are the only writer. Every state change writes one audit-log row with the source event attached. Dunning lives inside that single status.
The gate sits on the agent turn. Past due refuses agent turns; the CRM keeps writing. Records still list, workflows still run, invoices still render.
No migration tax when you outgrow us
Every load-bearing layer is replaceable. PostgreSQL 16 is the substrate; pg_dump produces a portable backup of the whole stack, retrieval index included. S3-compatible storage swaps between the major providers with one setting. The model provider is per-tenant configuration.
There is no proprietary language to learn. No vendor SDK sits on the critical path. No formula syntax your successor needs a consultant to translate. The substrate is what you would build if you were building it yourself. See how the same portability argument reads to a CEO evaluating platform risk.
The takeaway
The CRM is free. The agent bill is SUM(cost_usd) × margin × 100 — one column, one multiplier, one nightly sweep, receipts by day. Per-module lines are one Stripe Price ID each. If you outgrow us, pg_dump walks the whole stack out the door. Predictable spend is a property of the schema.