How Roiva calculates value

Most calculated value in Roiva comes from a value formula: arithmetic over figures Roiva can show you, run for one month at a time. This article follows a formula's number back to where it came from. For the vocabulary itself, see Metrics, baselines, and readings.

Not all value comes from a formula. A value source link books value from what the connection syncs: won deals from a CRM, Stripe payments, invoices from your books, tickets an AI agent resolved in Zendesk, Freshdesk or Intercom, and Salesforce Messaging conversations an AI agent handled without a person. These syncs price each deflected ticket or conversation rather than run a formula, which is why the Formula library has none for them. See How deflection value is booked.

Cash value and freed capacity

Value lands in one of two figures, and Roiva never adds them together.

Cash value is money that shows in the books: the margin on revenue gained, costs saved, losses and spend avoided, and freed capacity someone showed became cash. ROI is taken over cash value alone, which is why it's labeled Cash ROI.
Freed capacity is people's time and output given back, priced at what it costs. It's worth knowing, but payroll is the same afterwards, so it isn't cash. It's reported beside cash value on every page and in every report, and it's in no ROI.

What a formula counts as follows from what it prices. A formula that reads a labor rate, or a cost per ticket or per item that's mostly staff time or lost output, books freed capacity, and Roiva won't save it as cash. One that prices money changing hands (a vendor bill that fell, revenue at your margin, a penalty that wasn't paid) books cash. A cost per item that mixes the two, such as a truck roll that's mostly a technician's time, books as freed capacity, which under-claims. Invoice errors and billing disputes are priced apart instead: the staff time to correct an error is freed capacity, and a duplicate payment or a write-off it caused is cash, so each of their figures covers only its own part. The Formula library lists what each one counts as, and a formula's Value type is on its page.

Freed capacity becomes cash only when a person shows it did: a hire not made, a contract not renewed, overtime that fell. They record it, one month at a time, as Capacity realized as cash, and cite the document that shows it. It counts in cash value and comes out of freed capacity, so a dollar is never counted twice. Roiva never does this on its own. See Adding costs and value entries.

What a formula reads

A formula is an expression, such as (baseline_minutes - current_minutes) × invoices × labor_rate, and each variable in it reads one kind of figure:

A reading — a metric's value for the month being calculated, or the most recent one before it: this month's ticket count, synced from a connection or entered by hand. Only readings taken since the initiative started count. Most connections write a month's total (spend, tickets, runs) only for a month that had some, so an entry that carries one forward from an earlier month waits for a person. Where a metric is read from several connections combined, one with nothing for the month adds nothing, and the entry waits for a person if that connection had a total the month before. When none of them has a figure for the month, each one's latest is carried forward, and the entry waits if those are totals. An average, or a level such as MRR or open pipeline, carries forward as it would from a single connection, without waiting.
A baseline — the initiative's before-value for a metric.
An assumption — a figure taken as given, like a loaded labor rate or a price per million tokens.

A money figure carries its currency: a CRM's won deal value is in the deals' currency, an accounting system's revenue in the company's. A formula whose money inputs share one currency books its entry in it, and the entry counts in dollars at the European Central Bank's average rate over its month. A formula whose money inputs are in two currencies doesn't calculate, and its page says so: Roiva doesn't add or compare two currencies in one figure.

Roiva's own formulas also use a few terms you never enter: the number of days, working days, weeks or months in the month being calculated, and arithmetic over the other inputs, such as an average deal value worked out from won revenue and won deals.

Because each entry is one month's value, a figure stated for a year counts only that month's share of it. Audit cycles a year, storm events a year, annual tuition per student and an annual cost of capital are each multiplied by the months calculated ÷ 12, so a formula books a twelfth of a year's saving in a month rather than the whole year again every month.

Most of the formulas Roiva ships are a before/after pair on one metric: the baseline of a metric compared with a reading of the same metric, so both sides are measured the same way. The difference, multiplied by volume and a rate, is the value.

When the count moves with how busy you are

Some before/after pairs are on a count or a spend that rises and falls with volume whatever the AI does: calls a month, truck rolls, scrap cost, fleet miles, a cloud bill, or the hours a team spends on work that arrives in volume, like payroll or invoice matching. Compared as raw totals, a busy month would show a loss and a quiet one a saving the initiative had no part in.

So those formulas also read the volume the count moves with, before and now, and compare the count per unit of it: calls per service request, scrap cost per unit produced, miles per stop, cloud cost per unit of demand. The change in that rate, multiplied by this month's volume, is the value. Both figures are measured, so nothing here is a judgment. The formula asks for the volume as a baseline and as a reading alongside the count, and waits until it has both.

This sets aside the volume the formula reads and nothing else. Calls per request takes out a seasonal surge in requests; truck rolls per subscriber takes out growth in the base but not a storm.

A formula you write, or one read from a document or suggested by the Assistant, is checked the same way. If it compares one of these counts as a raw total, or against a figure typed in rather than this month's reading, it still saves, but every entry it calculates is marked Not adjusted for volume and waits for a person's approval, whatever the auto-approve setting. The mark shows on the entry, in Approvals and on ROI → Provisional. Once such an entry is approved, the Value Evidence Register counts it, and the board brief says how much of the quarter's cash came from these formulas. Fix the formula to compare the count per unit of its volume, or, if it really doesn't scale with volume (a fixed reserved-instance bill, say), clear the mark on the formula's page with the reason. Someone other than whoever wrote the formula's arithmetic clears it, unless nobody else could approve or your account lets people approve their own work. Who cleared it, when and why is kept in the audit log, and the mark comes back if the formula's arithmetic changes.

For a cloud bill you choose the unit of demand: API requests, transactions, orders or active customers. So each figure you record for it names the unit it counted, and the name shows beside the figure on the initiative's Setup tab, on the metric entry and among the value entry's inputs. A later reading starts from the unit the baseline counted. If a reading names a different one, Roiva says so wherever the figure appears and holds the entry for review, because cost per request compared with cost per customer is not a saving. Record one of the two again so both count the same thing.

When the outcome has other causes

Some before/after pairs measure a step the AI performs, such as the hours an adjuster spends on a claim or the error rate of an extraction the AI does. The change there is the AI's to claim.

Others measure a business-wide outcome that the AI is only one cause of. An insurer's loss ratio moves with weather, catastrophe losses, rate changes and reserve development. A churn rate moves with price, product and competitors. A win rate moves with the market. Crediting the initiative with the whole change would claim all of that for it.

So those formulas multiply the change by the share of it you credit to this initiative, a figure from 0 to 1. It's your judgment, not a measurement: Roiva doesn't run experiments and doesn't measure what caused the change (see Method). Roiva ships no default for it:

The formula doesn't calculate until someone sets the share. It's listed on the Missing Inputs page and on the initiative's Setup tab.
The share belongs to the initiative, not the account. Two initiatives on the same book each set their own, and one initiative credited with part of its loss ratio and part of its LAE ratio sets each separately.
The figure, who set it, when, and the reason they gave are kept in its history, which the Setup tab and each calculated entry link to. Changing it later adds a new version from that date. Approved entries keep the share they were calculated with.
Every entry that reads a share waits for a person's approval, whatever the auto-approve setting.
The rule holds however the formula was written. A formula that compares a business-wide outcome without multiplying by the share doesn't save, whether its before-value is a baseline or a figure typed in, and the message names the share to add. Nor does one that reads the share inside an IF, MIN or MAX, where it could credit the whole change once the share passes some figure. One saved before the rule keeps calculating, and is held to it the next time its arithmetic changes.

The formula library marks which formulas read a share, and names the other causes for each.

Revenue is booked at your margin

A formula that values added revenue (deals won, subscribers kept, orders recovered from a stockout, rooms sold at a higher rate) books it at your contribution margin: the part of each dollar left after the costs that grow with a sale. Revenue isn't return. Premium isn't profit, and a deal's value isn't what your company keeps from it. ROI sets value against costs you actually paid, so value has to be what you actually keep. Entries from these formulas are recorded as revenue gained, not as cost savings.

The margin is a figure from 0 to 1, and Roiva ships no default for it: published margins are averages across whole industries, and a gross margin leaves out the commissions and fees that grow with a sale. Until one is set, those formulas wait on Missing Inputs. Won CRM deals, invoices and Stripe payments linked to an initiative book at the same margin (see Linking connections to initiatives).

Use the margin on the revenue the initiative adds, not your company's average. They can be far apart. A higher rate on a hotel room that would have sold anyway adds almost no cost, a vacant unit leased sooner earns rent it would not have, and salaried staff cost the same billed or on the bench, so nearly all of that revenue is kept. An added sale, by contrast, carries its cost of goods and its commission. Each formula's margin field says which costs grow with the revenue it values.

So the margin is set at two levels:

For the account, under Method → Assumptions. It serves every initiative that hasn't set its own. Only an Owner or Admin can set it, because one figure prices every revenue formula, deal, invoice and payment in the account.
For one initiative, on its Setup tab or on Missing Inputs. It replaces the account's figure for that initiative's formulas, its linked deals, invoices and payments, and its planned revenue. An Owner, an Admin or the initiative's owner can set it. Use the account's margin on the Setup tab puts it back.

Setting a margin of 1 books revenue in full. That's yours to choose, and like any figure it's on the record: who set it and when is in its history, and each entry keeps the margin it was booked at.

A few formulas recover the price of work already delivered, such as a denied claim paid on appeal or hours worked and now billed. That price is all margin, because the work was paid for either way, so they book it in full.

Revenue that arrives sooner

A deal that closes ten days sooner is the same deal, arriving earlier. Its revenue isn't added, so the formulas for a shorter sales cycle, a faster proposal, a faster contract signature and faster customer onboarding don't book the days of revenue. They book what having the money sooner is worth: the margin on those deals × the days saved × your cost of capital, recorded as a saving rather than as revenue gained. At a 7% cost of capital, ten days on $1,000,000 of won deals at a 40% margin is about $770, not the $11,000 that ten days of those deals' margin would come to.

Roiva ships a default cost of capital, a published average for the market or your industry, which you can replace with your own on the Assumptions page. The onboarding formula also needs how many years an account stays open, which has no default.

Filling something that would otherwise sit empty is different. A unit leased sooner earns rent on days it would have earned nothing, so that formula books the rent as revenue gained.

Some templates carry two formulas that would count the same money, and an initiative gets one of them. There are two kinds of pair:

The same saving in different units, because providers report different things: AI spend per request where the provider reports requests, per million output tokens where it reports only tokens.
One formula counts part of what the other does. Revenue kept by lower churn is inside net revenue retention. Adjuster time is part of an insurer's loss adjustment expense. A consultant's hour moved off the bench is either billed or no longer paid for, not both.

An initiative gets the one its connected sources can feed, and the template's default when nothing feeds either. Roiva moves an untouched copy to the other if your sources change. An initiative that held both, from before the two were paired, keeps the one its sources pick and the other is archived. A formula you edited, or one that has recorded value, is never moved or archived on its own. When your sources feed the other formula, Missing Inputs offers to switch it: the old one is archived with the months it booked, and the new one books from the month after the last of them. The formula library says in a formula's description when it is one of a pair.

When a formula runs

You don't run formulas yourself. A formula is calculated for the current month:

when a reading it uses arrives, from a sync, a CSV import or by hand, or is edited or deleted;
when the formula is created or changed;
when your account saves its own figure for an assumption the formula reads;
and every night, for every active formula, which catches a new month starting and any change to a Roiva default.

Earlier months are calculated too, once an initiative is live: each complete month since it went live that has no entry yet, when someone records that it went live on an earlier date and when a sync brings in months it has been live. A month is calculated only when every reading in it describes that month. See The initiative lifecycle.

Each run writes one value entry per formula per month. Running again rewrites that month's entry while it's still waiting for review. An approved entry is never rewritten by a formula. If a reading it was calculated from changes afterwards, the Inbox lists it under Changed since approval, where someone who could approve it can send it back to be recalculated.

A reading in dollars worked out from deals in several currencies is converted at the ECB's latest rate until the month's rates are published, then at the month's average. An entry calculated from it waits for a person and can't be approved until it's calculated again at the average, which happens on its own once the rates are in. One whose reading left out a currency the ECB publishes no rate for waits for a person too.

If any input has no figure, the formula doesn't calculate and nothing is booked. It waits, and the figure it needs is listed on the Missing Inputs page. See What an initiative needs before it has a number.

What a calculated entry shows

Open a calculated value entry from the initiative's Value Entries tab. Its Formula Inputs section shows the expression and the value of every input at the time it was calculated, and where each came from: a reading, a baseline, an assumption. A reading that came from a sync links to What's behind it, the synced records the figure was counted from. The Provenance section names the formula, the Formula Version it was calculated with, and the moment it ran.

Assumptions and Roiva defaults

Roiva ships a default for most of the assumptions its formulas read, most with the source they come from. It ships none for your own economics, like your average deal value or your contribution margin, or for the share of an outcome's change you credit to an initiative (see above). Some, like labor rates, differ by industry, and Roiva uses the one for your account's industry. Method → Assumptions lists them:

In Use is every assumption one of your formulas reads, plus the price of a deflected ticket or conversation when a Zendesk, Freshdesk or Intercom connection, or a Salesforce connection that books conversations, is linked to an initiative as a value source, and the labor rate when that link's tickets are priced from a time study. Each shows where it stands: Missing (what reads it can't calculate), Roiva default, or Set. Used by names the formulas and help desk links that read it.
Library is everything your formulas could read: Roiva's defaults and your own figures.

A row on a Roiva default has Confirm or override, which opens the figure with its source. Save it as it is to confirm it, or change it. Either way it becomes your account's own figure. A missing one has Set it. Anyone on the account can set an assumption, except the margin on added revenue, which takes an Owner or Admin (or, for one initiative's own margin, that initiative's owner).

An assumption is never edited in place. A new figure applies from its Effective from date, and the one it replaces stays in the history: the link under each row's date opens every version, who set it and when. Approved entries keep the figure they were calculated with.

Each month is priced at your figure for that month, and your earliest figure also covers every month before its date. So a labor rate you confirm today prices last year's months too, when an initiative's past months are calculated. A calculated entry says so beside the figure: "used for this earlier month". If the rate was different then, edit the figure and give the earlier rate a date before the current one. It covers the months before that date, and the current figure stays as it is. Entries not yet approved are recalculated with the figure for their month. Roiva's defaults are read as they stand today, for every month: a newer default is Roiva correcting its estimate, not the rate changing.

Why value waits while a formula runs on a Roiva default

A Roiva default is a reasonable basis for showing a number, but not for putting one into approved value unattended. So while any input a formula reads is still a Roiva default, what it calculates never approves itself: it waits in Approvals for a person. Once you confirm or change the figure, the entries waiting on it are recalculated with your figure. Until then, ROI → Provisional lists the waiting value that rests on Roiva's figures, beside approved cash ROI and never in it, so you can see which defaults to confirm first.

Baselines

Every baseline records its baseline method, how it was measured: From history, Time study before go-live, Without-AI sample, Benchmark or Estimate. The method decides what a figure calculated from it rests on: a measured baseline, a reconstructed one (a without-AI sample) or an estimate (a benchmark or a judgment). Reports say how much value rests on each. See Baselines for an initiative that's already live.

Roiva fills some baselines in itself:

From your history. When your connected systems have figures for any of the three complete months before the initiative started (for one already running, the go-live date you recorded), Roiva works out the baseline from them: the same arithmetic the formula uses for the figure now, month by month, averaged over the months it could calculate. A month counts only when every figure in it describes that month. The baseline's notes list the months and figures it came from.
A Roiva estimate. Where there's no history, Roiva may estimate the baseline when the initiative is set up from a template, and marks it as an estimate. If those months sync in later (you connect the platform after the initiative started, and it backfills), Roiva replaces the estimate with a baseline from your history and recalculates the entries not yet approved that used the estimate.
From a time study. A time study that timed the work without the AI becomes the baseline from the month its window started: measured when nothing in the study used the AI, otherwise a without-AI sample. Its with-AI arm, if it timed one, becomes a reading. Value calculated from it after its re-study date is marked Re-study due. A later study applies from its own window, and the months before it keep the figure they were calculated from. Its figure can't be edited, only timed again.

A baseline you enter or import is yours, whatever its method, and Roiva never overwrites it.

What moved an AI spend saving

A saving in what your AI spend buys can come from two places, and they are not worth the same. Your team can earn it — routing simple requests to a smaller model, turning on prompt caching, trimming context. Or your provider can hand it to you by cutting its prices, with nothing on your side changing at all.

Both look identical in the figures: your cost per unit of work falls. So where the saving is a drop in what a unit of AI work costs, and Roiva can read your provider's cost by model and token type, the entry shows a What moved this saving section splitting it in two:

Vendor price changes — what your provider's prices alone would have saved you at your baseline months' usage: same models, same caching, same prompts. Nothing you did.
What you ran — everything else. The models you chose, what you cached, how you shaped the work.

The two add up to the amount booked. The amount itself doesn't change and still reconciles to your bill — the split explains the number rather than restating it.

Roiva works this out from what you were actually billed, not from a provider's list prices: Anthropic's cost report gives spend per model per token type, and its usage report the tokens behind it. So tiers, batch rates and any discount you negotiated are already in it, and the figures reconcile to your invoice. Where it can't split the saving, the entry says so and why, which is not the same as saying your provider's prices held — use the entry's notes to record which it was.

Where the split covers only part of a period's AI spend — because you read more than one provider into it — the entry says what share it speaks for.

The Formula Trace

ROI → Initiatives, then an initiative and Formula Trace, shows how that initiative's cash ROI breaks down: cash value and total cost, the largest types of each, and the platform each came from where a connection booked it. Each branch opens the entries behind it. Freed capacity is a line under the tree rather than a branch of it, because it's in no ROI.

Adding or changing a formula

Adopting a template copies its formulas onto the initiative, which is how most formulas start. To add your own, open the initiative's Measurement tab, then Formulas, and click New Formula. Method → Formulas has the same button, with a choice of initiative. Give the expression, then map each variable to a Reading, a Baseline or an Assumption. Result is in says whether the expression gives dollars or cents. Value type says which kind of value it books, and has no default: a formula that prices your people's time can only book freed capacity. A formula is calculated for the current month as soon as it's saved.

To change one, open it and click Edit. A change to its arithmetic makes a new version, and the formula's History lists every version, so an entry calculated before the change still names the one it used (see What makes a figure auditable). Changing only an input's label or description makes no new version and recalculates nothing. Formulas Roiva ships in the library can be viewed but not edited.

Changing a formula's expression also recalculates its earlier months' entries that are still waiting in Approvals. Approved entries keep the figure they were approved at. If the changed formula reads a figure nobody has set yet, those months can't be recalculated: their entries show Waiting to recalculate, leave Approvals and can't be approved, because the figure on them comes from arithmetic the formula no longer uses. The formula appears under Missing Inputs, and the entries recalculate and return to Approvals once the figure is set. A month gone by takes its figure on the initiative's page for the months since it went live, which an entry waiting on one links to. The same happens when Roiva updates a library formula you adopted and whose expression and inputs you haven't changed. A copy whose inputs you only reworded still follows, and keeps your words.

A formula's Value type can't change while any of its entries are approved as a different type from the one you're changing to: an approver signed them off as that type, and changing it would turn cash into freed capacity, or one kind of cash into another, with nobody approving it. Send those entries back for review first, and they take the new type and go to an approver again. Entries still waiting for approval simply take the new type. If Roiva changes the value type of a library formula you adopted, and whose expression and inputs you haven't changed, while you have approved entries from it, your copy keeps its value type and follows the rest of the change. If the new arithmetic prices your people's time, which only freed capacity can book, your copy stays as it was until those entries are sent back for review, and then follows the change at Roiva's next update, unless someone has changed its expression or inputs.

On a formula's own page, Data Availability shows every input's current value and whether it's ready. When they all are, Calculate & Send for Approval calculates a period you choose. The entry it creates goes straight to approvers, not to drafts, and waits for a person whatever the auto-approve setting.

Auto-approval

Auto-approve is off unless the account Owner turns on Auto-approve formula-derived value entries under Organization Settings → Approvals. With it on, an entry from a formula Roiva supplied (from a template, say) approves itself when:

a person has already approved one of that formula's entries (confirming its inputs doesn't count);
the amount is between half and double the formula's last entry a person approved (an auto-approved one doesn't move the band);
every input came from a real figure, none of them zero;
no input is a Roiva default, no before-value is Roiva's estimate, and no count or amount entered by hand is from an earlier month;
no input is a total a connection synced for an earlier month (spend, tickets, runs) standing in for this one;
no figure read from several connections combined is missing one that had a total the month before;
no input is a time study's figure past its re-study date;
no reading counted a different unit from the baseline it's compared with;
no input is the share of an outcome's change you credit to the initiative, or the share of an IT incident's time its users were blocked;
the entry is calculated the way the initiative's signed measurement charter says, if it has one;
no warehouse query an input came from has a new version since the formula's last approved entry;
the amount isn't above the senior approval threshold, or far outside the initiative's planned value;
and the initiative isn't sample data.

An entry dated in a locked month never approves itself: it waits until the month is reopened. Anything else waits for review, and a formula you wrote yourself always waits. Auto-approved entries show Auto-approved as their status, and each one is recorded in the audit log. See Approving value and initiatives.