Put an MRR figure YOU computed onto the MRR card.

This tool measures nothing. It takes the figure and its method as input and returns them for rendering. Call it only after you have computed the recurring revenue yourself and can state every field below from your own work — never to "get" an MRR.

The server derives no MRR of its own. The figure on the card is the one you state here, which is why every field below is required: the policy behind a number is the only thing that makes it checkable.

At its smallest size the card draws the figure alone. It carries the figure, the window it averages and the trend chip. At its wider sizes it draws a donut of by_context when you send it, and the donut labels each slice from its key. The recurring contexts reach the card only through that split; they are not drawn as a list. Everything else you state below is REQUIRED and is not drawn. All of it comes back in this tool's text result, which is what you write the prose from. The card is the measure; the explanation is yours.

OPTIONAL, and sent whenever you can state it:

• by_context — the same average split by billing context: one entry per key in recurring_contexts, each { key, amount }, where amount is that context's own monthly average over the same window, the same divisor and the same conversion as amount. Send EVERY recurring context, the largest first, and do not group any of them yourself: the server keeps the 4 largest by name and folds the rest, and every slice under 1.5% of the total, into one "Other" slice. Send no label and no share. The server names each context from its key and derives each share from the amounts, and returns both. When a context nets negative over the window, send no by_context at all: a split cannot draw a negative slice, and the figure still renders alone.

REQUIRED, because a figure whose method is not stated cannot be checked:

• amount — the recurring revenue per month in currency, net of tax and of credit notes, as the sum returned it

• window — the months the average divides by, not the months that carried revenue

• months_in_window and months_with_revenue — a window with dark months reports LOWER than its typical month. When the two differ you MUST say so in prose: how many months recorded recurring revenue, and that the average still divides by the whole window

• recurring_contexts — the billing contexts the reader confirmed as recurring, as the keys the card recorded. "unclassified" among them means the reader counted the invoices with no billing context (the sum rows whose billing_context is null) as recurring. This is the reader's half of the policy. The card names a few of them at most, and none at its smallest size, so an answer that does not name them leaves the figure unchecked

• invoice_count, unattributed_count and unclassified_count — how much of the window the figure could reach at all. invoice_count is the issued invoices; unattributed_count is the SEPARATE set Well could place on neither side, reported beside it rather than inside it, and it may be larger. An unattributed invoice may still be recurring revenue. An unclassified one carries no billing context: it is in the figure only when recurring_contexts holds "unclassified", and when it is, say in prose that the reader chose to count it. Send null for a count the sum returned as null: it is unmeasured, not zero

• excluded — what fell out, as three invoice COUNTS kept apart: one_off (issued invoices under a context the reader did not count), credit_notes (the credit_note_count netted into the figure) and unreadable_rows (the sum's excluded_malformed, null when unmeasured)

REFUSED rather than rendered, each because your own figures disagree with each other:

• a negative amount — the credit notes outweighed the recurring invoices, so net recurring revenue fell below zero. That is a finding to report in prose, not a figure to put on a card, and never one to flip to its magnitude

• an empty recurring_contexts — an MRR with nothing counted as recurring is not an MRR of zero, it is a policy nobody stated. Say the figure has nothing to measure instead

• months_with_revenue above months_in_window, or unclassified_count above invoice_count

• a months_in_window that disagrees with the months window spans — the two state one fact

• a window whose bounds are not month starts — a month-average divides by whole months

• change with no baseline, a baseline.value of zero, a baseline that does not start before the window or spans a different number of months, or a change whose magnitude or sign its own two figures contradict

• a per_month series that does not name each month of the window once in order, does not average to amount, or disagrees with months_with_revenue

• a by_context whose keys are not exactly recurring_contexts (a key the list does not hold, a key sent twice, or a recurring context left out), whose amounts are negative, whose amounts do not add up to amount (a cent of slack per entry), or whose entries are not sorted by amount, largest first

Send baseline and change as a pair or send neither. Do not send a direction: the card's colour is decided server-side from the figures. Revenue is higher-is-better, which is the opposite of the burn card and exactly why a caller does not get to state it.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.