Building an AI ROI tracker yourself

You can build this yourself. The method Roiva uses isn't proprietary. It's published in these docs and on the methodology page, and an analyst, or an AI assistant reading these pages, can turn it into tables, formulas and an approval flow.

This page covers when building is the sensible choice, what a build and its upkeep take, and where home-built trackers tend to fail. It also says which of those failures Roiva handles and which it leaves with you.

When a spreadsheet is enough

For a small portfolio, a spreadsheet or a few tables in a warehouse you already run is a reasonable answer. Roughly, that means up to five initiatives and two or three spend sources, plus someone other than each initiative's owner who will sign off its figures every month. At that size you can check for double-counted cost by eye, a formula change is a note beside the cell, and one person can hold the whole thing in their head.

The method matters more than the tool. Whatever you build, keep these rules:

Only approved value counts, and every cost counts whether anyone approved it or not.
Report value minus cost, never value on its own.
Store each figure with the version of the formula that produced it and the inputs it used, so it can be re-run later and come out the same.
Record how each baseline was measured, and keep an estimate labeled as an estimate.
Whoever prepared a figure doesn't approve it.
A reported month doesn't change unless someone reopens it and records why.

The breakpoint is less about the number of initiatives than about sources and people. Once the same vendor shows up in more than one system, or initiatives change owners, the spreadsheet stops being a record and becomes something one person maintains.

What a build takes

A tracker that a finance team will accept, for a portfolio of about a dozen initiatives, needs these pieces:

Cost pipelines from each provider's billing API or export, your ERP's vendor bills and your card program, with rules for when the same spend arrives from two of them.
Metric pulls from the systems that hold the before and after figures: the support desk, the CRM, source control, and your own operational data.
Versioned formulas with input snapshots. Each monthly figure stores which version of the arithmetic produced it and a copy of every input it used.
An insert-only audit record. A status change is a new row, and no role can update or delete one.
An approval flow that records who approved each figure and refuses an approval by the figure's preparer.
Period locks, so a reported month can't change without a recorded reopening.
Reporting that reads only approved value.

A rough estimate for that portfolio, with six or seven spend sources at a company that already runs a data warehouse and a BI tool, is 12 to 16 person-weeks to build, spread over two to three months. Most of that goes into the cost pipelines and their de-duplication rules. Running it then takes about 0.3 to 0.5 of a full-time person. That covers gathering and approving figures each month across owners and finance, keeping the pipelines working, and repeating time studies once or twice a year.

Treat those numbers as estimates, not measurements. Yours depend mostly on how consistently your cloud spend is tagged and how clean your ERP's vendor data already is.

Where home-built trackers break

None of these is certain. They're the failures that tend to appear once a tracker is a year old and the person who built it has moved on.

Approver independence erodes. An owner approves their own figure "just this once" because the approver is on leave, or approval becomes a monthly batch nobody reads. Unless the tool refuses it, the rule only exists in a policy document.
Baselines get overwritten in place. Someone corrects a baseline cell, and every figure calculated from it changes, including last quarter's. A reported number that moves without a record is what makes a CFO stop trusting the rest.
Cost gets counted twice, or three times. A model provider's API bill, the same vendor's invoice in your ERP and a card charge for the same subscription can be one dollar recorded three ways. Cloud invoices are harder still: an AWS or Microsoft invoice mixes AI and non-AI services, so it can't be assigned to an initiative whole. De-duplication rules are the fiddliest part of a build, and a new vendor or card program can break them without raising an error.
Tags aren't retroactive. A cost-allocation tag applies to usage from the moment it was put on the resource. Spend from before then carries no tag, and it can only be split by estimate.
Key-person risk. A home-built tracker usually lives in one analyst's head. When that person leaves, the next one inherits pipelines, formulas and exceptions they didn't write.
Vendor APIs change. GitHub shut down its legacy Copilot Metrics API on April 2, 2026 (GitHub's notice), and the endpoints that replaced it report different fields. A pipeline built on the old API either failed, or, if it swallowed the error, went on reporting success while returning nothing. Every provider you pull from makes changes like this on its own schedule.
"Append-only" becomes a claim you have to prove. Insert-only tables and tight database grants make a sound record. An auditor will still ask you to show that no role can change a row, and that nobody used the one that can. That becomes a controls document you write and keep current.

What Roiva takes off your plate

Cost from the platforms it connects to, with double-counting handled. Where a vendor's name belongs to that vendor alone, its own bill is counted, and the copy on your books is left out in any month the vendor's bill is booked. Card charges aren't counted a second time from the card's account in your ledger. For AWS, Azure and Google Cloud, both copies are booked and the overlap is reported rather than guessed at. Anything Roiva can only suspect is listed, not dropped. Finance → Cost Coverage shows all of it. See How costs reach an initiative and What each platform books.
Metrics that a connected platform reports sync on their own, and baselines are calculated from the months before an initiative started where those months are available. The metrics reference lists which metrics a connection can feed.
Metrics you already model in a warehouse. A claims cycle time or a quote count that lives in Snowflake, Databricks or BigQuery is read by a metric query you write once. Roiva versions the query, keeps the rows each version returned, and runs it every night. See Metrics from your own data warehouse.
Formula versions and input snapshots. Every calculated figure keeps the version and inputs it was made with, and a later calculation leaves an approved month alone. Correcting a baseline next quarter doesn't rewrite a figure someone already approved. See What makes a figure auditable.
Approver independence, enforced by the app. By default nobody can approve a value entry they recorded or last edited. The rule steps aside only when nobody else could approve, and an Owner or Admin who turns it off under Organization Settings → Approvals leaves a record in the audit log. See Approving value and initiatives.
Period locks and journals, on every plan. A locked month refuses changes to its cost entries until someone reopens it with a reason. See Allocation rules and accounting periods.
Upkeep of the connections. When a provider changes its API, updating the integration is Roiva's work rather than yours, done once for every account instead of once per company.

What Roiva leaves with you

Time studies. Where no system records how long a task took before and after, somebody has to time it. Roiva stores the result and when it was measured, but it can't do the measuring.
Approvals. A person still reads each figure and decides whether to sign it off. Auto-approval exists and is off by default, and even when it's on it holds back any figure that rests on a default assumption, is above your approval threshold, or comes from a formula whose figures no person has approved before.
Metrics nothing holds yet. A figure that is in no connected system and no data warehouse is still recorded by hand or imported from a CSV. That is the same work a home-built tracker needs. Writing the metric query for a figure your warehouse does hold is yours too, though it's one SELECT per metric rather than a pipeline.
The attribution rule. How much of a change the AI gets credit for is your judgment. Roiva records the rule and applies it consistently. It doesn't test whether the change would have happened anyway, and no before-and-after comparison can.
Tagging at the source. Roiva can split cloud spend by tag, workspace or project, but only if those tags, workspaces and projects exist. Spend from before you set them up is as hard to split in Roiva as anywhere else.
Deciding suspected duplicates. When a typed cost and a synced bill might be the same money, Roiva lists the pair and a person decides which copy counts.
Your own vendor review. Roiva doesn't hold a SOC 2 report yet. Oneleet is conducting its SOC 2 Type 2 examination against the security criteria, which began on September 25, 2026 with a three-month observation period, along with an annual penetration test of the application. Until a report is issued, the security page says what's available for a vendor review.

Choosing

If your portfolio is small, your spend comes from two or three places and you have someone to keep the record honest, build it. Use the rules above, and revisit the decision when a fourth spend source appears or the person who built it moves on. If the pipelines, the de-duplication and the audit trail are the parts you'd rather not own, that's the part Roiva does. The judgment, the approvals and the time studies stay yours either way.

What makes a figure auditable — versioned formulas, frozen inputs, and approval before anything counts
How costs reach an initiative — where the same dollar can arrive twice, and what Roiva does about it
How Roiva calculates value — formulas, inputs and when they run
Metric keys, and where a value comes from — which figures sync and which a person records