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. Seats × modules for the platform. Metered on top for the agent. A hard tenant cap on both. 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 billing surfaces compose on one Stripe Subscription per tenant.
Seat licensing. Every active user carries a seat charge. Adding a user re-syncs the seat count to Stripe; deactivating one takes it back down. The reconciliation is idempotent — the call is skipped when the count has not moved, so you never see phantom charges from a hiccup.
Per-module flat. Turn a module on and one flat charge appears on the Subscription. Turn it off and it vanishes. Each module carries its own Stripe price id and an audit row on every change.
Per-module per-seat. Same wiring, priced per active user of that module. Enabling a module for a user increments the module’s seat line; removing a user takes it back down.
The assistant, on the seat. Each seat carries a monthly allowance on every metered line — things asked, documents written, transcription minutes, and two lines the workspace shares. Ordinary use of the assistant produces no invoice line at all, because the seat price has already paid for it.
Anything past the allowance, only if you ask. A line that runs out pauses that line and nothing else. An administrator either buys more or lets it wait for the renewal date. Nothing is bought on your behalf unless you turn that on, and when you do it runs under a ceiling you set and cannot be exceeded. A runaway workflow cannot spend more than you agreed to spend, and the ceiling is enforced at the moment of purchase rather than checked afterwards. See pricing for the shape of the invoice.
Predictable because it is bounded, not because it is small
A budget you can commit to a year in advance is worth more than a rate you have to model. Seats × plan is the whole number, and the only way past it is a purchase somebody made deliberately.
Every unit is traceable. Each purchase records what was bought, when, on which line, and the total it was sold at — and the nightly posting reads those recorded totals rather than today’s rate card, so a price change next quarter cannot restate an invoice you have already paid. A re-run after an outage replaces the day rather than adding to it.
Your own screens answer the same questions ours do: what each person has left, what the workspace has bought this period, and which day each charge covers.
Bringing your own model-provider key is available on Enterprise, and applies the same way to speech-to-text and embeddings as it does to the chat model.
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 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
Seats × plan is the number. The seat carries the assistant, and most months nothing else appears — anything that does is a unit somebody chose to buy, recorded at the price it was sold at, under a ceiling you set. Per-module lines are one Stripe Price each. If you outgrow us, a standard Postgres dump walks the whole stack out the door. Predictable spend is a property of the schema.