> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensorcost.com/llms.txt > Use this file to discover all available pages before exploring further. # Cost explorer and allocation > Slice spend by team, service, provider, or model, save the views you use every week, and see how much of the bill is actually attributed. # Cost explorer and allocation Two different questions live under "Spend" in the console: **where did the money go** (Explorer), and **whose budget does it belong to** (allocation — Operations, Team scorecard, and eventually Chargeback). This page covers both, because the second question only means anything once the first one is answered. ## Explorer Explorer is the default landing page for the Spend surface — the hero number, the trend, and the breakdown a FinOps lead checks first. * A headline spend figure for the selected window, with day-over-day movement. * A trend chart and a per-dimension breakdown, grouped by **team**, **service**, **provider**, or **model** — pick one from the group-by strip. * A forecast-vs-budget rail comparing the trend against whichever tenant-level budget matches the selected period. * A pivot builder for multi-dimension slices — rows, columns, and a value aggregation, not just a single group-by chip. Useful when "spend by team" isn't enough and you need "spend by team, by model, for this quarter" in one table. Group-by and the pivot builder both read from the same underlying dimension list, so a saved view and a group-by chip never disagree about what "team" or "model" means. ### Saved views Any pivot configuration — the rows, columns, and value aggregation you built — can be saved by name and reloaded later, or deleted when it's no longer useful. This is what makes Explorer a reporting tool instead of a one-off query box: a FinOps lead builds "spend by team by model, this quarter" once and everyone on the team opens the same saved view going forward. ### Incomplete periods Cost data for the current day (or the current period, more broadly) is always partial — the day isn't over yet. Explorer's comparisons account for this: a day-over-day or period-over-period comparison lines up equivalent spans (the same number of elapsed days) rather than comparing a partial "today" against a full prior period, which would otherwise read as a false collapse in spend. ## How spend gets attributed Explorer answers "where did the money go" against your account/service/model structure. It does not, by itself, tell you which team or cost center is responsible for a given dollar — that's a separate step, called **allocation**, and it's the harder problem. ### Allocation coverage — the gating metric The FinOps discipline for this is well established: most cost-allocation programs start with **showback** (a read-only view of who's spending what) and only graduate to **chargeback** (billing teams for what they used) once **allocation coverage** — the percentage of spend that can actually be mapped to a team or cost center — crosses roughly 90%. Moving to chargeback before coverage is high enough is one of the most common ways a FinOps program loses credibility in its first year: an invoice that includes a large "unallocated" bucket gets disputed on arrival. TensorCost's **Operations** page (Spend · Operations) is built around this framing directly. Rather than a workflow checklist, it leads with one number: allocation coverage for the selected period, with the dollar amounts behind it and a plain-language interpretation banded at 90% ("ready to graduate to chargeback") and 70% ("getting there"). Below that is the one real action this page exists for: an allocation-rule editor (create, edit, delete rules) that raises coverage by mapping more of the unattributed spend to a team or cost center. A tenant with real spend but no allocation rules yet is not treated as an empty state — 0% coverage is itself the useful number Operations exists to show. The zero-data case is reserved for genuinely nothing-to-show situations: no cloud account connected at all, or connected with zero spend in the selected window. ### Team scorecard Team scorecard (Spend · Team scorecard) is the weekly companion to Operations — a per-team view of how spend moved over the current ISO week, meant for a Monday-morning check rather than a running total to act on by itself. It carries the same coverage band as Operations and Chargeback (one gating metric, shown consistently across all three pages) because a per-team number built on low allocation coverage invites a comparison the underlying data can't support. The comparison is explicitly non-judgmental: a team spending more this week than last is reported as a fact ("up 12.4% vs. the same span last week"), not flagged as good or bad — a legitimate ramp in usage looks identical to waste from this page's data alone. This page's period is fixed to the current week server-side; there's no selector for other weeks today; a real cross-week view needs a period parameter the backend doesn't accept yet. ### Once coverage is high enough When allocation coverage is high enough to trust, the next step is **Chargeback** — turning that allocated spend into per-team records finance can use. See [Chargeback and showback](/chargeback-and-showback) for what that actually produces (and, importantly, what it doesn't). ## Industry benchmark Spend · Benchmark compares your own cost efficiency against an anonymized peer band for your industry, opt-in only: * **Not opted in**: you see only your own value, with a prompt to turn on data sharing in Settings. * **Opted in, enough peers**: you see your value, its band (e.g. "top quartile"), and the p25/p50/p75/p90 markers for the metric and period. * **Opted in, not enough peers yet**: percentiles are withheld until enough tenants in your industry have joined — you see a preview notice and your own value only, never a fabricated distribution. Benchmark is read-only; there's no action to take from this page directly beyond opting in.