Revenue reporting with Stripe
Explain a quarter's revenue movement from read-only financial tools, with stated assumptions.
Financial reporting is the routine with the least tolerance for a confident guess. Build it read-only, state the reporting window in the output, and make the assumptions part of the deliverable.
What you get: a quarterly revenue narrative with key movements, supporting figures, caveats, and follow-up questions.
Prerequisites
- A Stripe MCP server registered as a self-managed connection, using read-restricted credentials.
- A tool-capable model.
Use a restricted key
Stripe supports restricted API keys. Create one with read access to the resources this routine needs and nothing else, then store it in the connection headers — they are encrypted at rest and never returned by the API. The routine's tool policy is a second boundary, not the only one.
Configure it
Start from the template
Routines → New routine → Quarterly revenue report. Suggested schedule:
0 9 1 1,4,7,10 * — 09:00 on the first day of January, April, July, and
October.
Set reportingCurrency, for example USD, and reference it as
{{reportingCurrency}}.
Define the arithmetic
Say exactly how each figure is computed, because the model will otherwise pick a plausible definition and change it next quarter:
Report in {{reportingCurrency}} for the completed quarter:
- Gross revenue, net revenue, and refunds
- New, expansion, contraction, and churned subscription revenue
- Quarter-over-quarter and year-over-year change for each
State the exact date range used, and list every assumption made about
proration, trials, currency conversion, and disputed charges.Forbid every write path
Enable read tools only: balances, subscriptions, invoices, charges. A revenue routine must never be able to initiate, refund, or modify a transaction. Do not grant automatic execution to anything that writes.
Prove it against a closed quarter
Run it manually and reconcile two or three headline figures against Stripe's own dashboard for the same range. If they disagree, the definition in the instructions is ambiguous — fix the instructions, not the result.
Tuning
- Quarter boundaries and timezones. The schedule fires in the routine's IANA timezone. If your finance calendar closes in a different zone, say so in the instructions and set the timezone to match the calendar, not the reader.
- Currency mixing. Multi-currency accounts need an explicit conversion rule, including which rate and as-of date. Without one the totals are not comparable across quarters.
- Delivery. Financial reports usually belong somewhere other than the dashboard. Add a webhook and route the result into your own store.