How costs reach an initiative

An initiative's cost is the sum of its cost entries. Every one of those is one row, and every row goes through the same door — whether a sync wrote it, a recurring schedule wrote it, or a person typed it — so a currency, a cost category and a period mean the same thing whatever recorded them.

This page is about where those rows come from, and about the question a finance team asks second: if spend can reach an initiative from several directions, how do you know it hasn't been counted twice?

The ways spend becomes a cost

A cost source link on a connection. The provider's own bill, narrowed to the part the initiative runs on. What narrows it depends on the platform — the vendors you pick on a finance or card system, the services or usage types on a cloud, the projects or workspaces a model provider's link claims, a cost-allocation tag on AWS or Azure. What each platform books has a row per platform; Linking connections to initiatives walks through setting one up.
A vendor mapping on a finance or card connection. The vendor's bills on your books become the initiative's cost, at the share you set.
An allocation rule on a finance or card platform. A rule splits a platform's bills across initiatives on an approved basis, with journals behind it. See Allocation rules and accounting periods.
A recurring cost on the initiative — a subscription or a retainer no integration reports. See Vendors, shares and recurring costs.
A cost entry somebody records, imports from a CSV, or accepts from a document Roiva read. See Adding costs and value entries.

Spend that arrives from an integration is booked net of tax, because what an initiative cost the business is the amount, not the amount plus the VAT you reclaim.

Why the same dollar can arrive twice

Because a vendor's spend does not only appear on that vendor's bill.

Anthropic charges you, and the charge also lands on your books as a bill from "Anthropic, PBC" and on a card statement from your card platform. Databricks charges you, and the same usage appears as an "Azure Databricks" line on your Azure bill. Each of those is a real record of the same dollar, held by a different system, spelled differently by each.

Roiva connects to all of them on purpose — that is what makes the total complete — so every one of those pairs is somewhere a cost could be counted twice. There are three honest answers to that, and Roiva gives all three rather than claiming the problem away.

What Roiva leaves out

Where a vendor's name is one no other company's bill carries, Roiva leaves that vendor's bill to the vendor's own link and does not book it. "Anthropic", "OpenAI", "GitHub", "Snowflake" and "Databricks" each name one company and nothing else, so a bill on your books whose vendor name contains one of them is given up in any month that vendor's link books.

Two things take the bill back, and the link books nothing that month:

An allocation rule for that vendor, because a rule is an approved split with journals behind it, and an approval outranks a heuristic.
A locked accounting period, which no sync may change — journal entries and auditor packets already reference those numbers.

Months before the link has data still book from the mapping, at the share you set. The same rule runs on a cloud's bill: an "Azure Databricks" line is left to the Databricks link in any month that link books.

Card charges work the same way in the other direction. Where a card platform is connected, its charges are counted from the card platform, and the copies of them posted from that card's account in your books are left out.

What Roiva counts twice on purpose, and says so

AWS, Azure and Google Cloud do not have a name that belongs to them alone. Azure bills as Microsoft, beside your Microsoft 365 invoice from the same name. Google Cloud invoices come from "Google Cloud EMEA Limited", so an exact match fails the other way.

A wrong match there would not double a cost — it would silently drop a real one, and a dropped cost is worse than a doubled one, because a doubled cost is at least visible in the total. So for those three Roiva suppresses nothing. Both copies are booked, the mapping form warns you, and you set the share for the part the link does not already count.

Roiva knows the size of that overlap and reports it rather than leaving you to find it. The figure is the smaller of the two copies, never the invoice.

What Roiva only suspects

A person's typed cost and a synced bill for the same vendor and the same month may be the same money or may not, and nothing in the data settles it. The same is true of one invoice reaching Roiva through two books systems.

Roiva matches those on vendor name and month and reports them as candidates. It never picks a winner: nothing is authoritative enough to decide between a person's entry and a bill, and quietly deleting one would be the kind of silent correction this product exists to avoid.

Where your account's own answer is

Finance → Cost Coverage is the list, for your account, all-time:

what is counted twice on purpose, and by how much;
what Roiva suspects is counted more than once, labeled as a guess;
what was already settled, and which copy counts.

It is all-time rather than windowed, because "is anything counted twice" is a question about everything recorded, and a reporting period that happened to exclude the double count would answer it wrongly.

It is a list rather than a tick on purpose. "Nothing is double counted" is unfalsifiable, and a green check invites the question again instead of settling it. The enumeration is the part a CFO can audit.

What this does not cover

One connection linked to two initiatives, where both links map the same bill, the same service or the same deal, books that item in full for each of them. The syncs fan out, so the portfolio counts it twice.

Roiva finds that in the rows themselves and shows it on the connection's Initiatives tab, but it does not prevent it: which initiative a shared bill belongs to is a judgment about your business, not a fact in the data. Splitting it is what shares and mappings are for.

Linking connections to initiatives — what each connection books, and the vendor-on-both-sides rule in detail
Allocation rules and accounting periods — approved splits, journals, and what a locked period refuses
Vendors, shares and recurring costs — setting a share, and costs no integration reports