Or: what it actually means for a number to be governed.
You have probably been in this situation. Someone from Finance sends a slide deck with the company’s gross margin. Someone from Sales sends a different slide deck with a different number. Both people are confident. Both numbers came from NetSuite. The difference is somewhere in how they each decided what counts as revenue, whether to include a particular cost category, which subsidiary to include, whether to use the period-end date or the close date.
This is not a technology failure. It is a governance failure. Nobody agreed in advance on what the number means. So everybody computed their own version, and now you have a meeting to figure out whose version is right — which is really a meeting to figure out what you actually meant in the first place.
Tessera is built to prevent this meeting from happening.
Most reporting tools — including the ones built into NetSuite — are very good at answering the question “what does the data say?” They let you query transactions, build saved searches, create dashboards, and produce charts. They are flexible and powerful.
But flexibility is exactly the problem. When anyone can define a metric however they want, you end up with as many definitions of “gross margin” as you have people making spreadsheets. The tool did its job perfectly; the governance failed.
The tools are not wrong to be flexible. Flexibility is useful. But flexibility without governance produces the situation described above — confident people, different numbers, and a meeting.
What’s missing is a layer that sits between “the data” and “the dashboard” and asks: who agreed that this is what this number means, and when?
Tessera introduces the concept of a governed metric. A governed metric is not just a saved query. It is a defined, approved, versioned, and auditable business measurement — and it is the only kind of metric Tessera will display.
Here is what that means in practice.
Before a metric appears on any dashboard, it must be approved by a designated person — typically the Controller or CFO — who is identified by name, role, and timestamp. That approval is permanent. It cannot be edited retroactively. It is attached to every single result that metric ever produces.
When someone asks “where did this number come from?”, the answer is not “the system calculated it.” The answer is “Jennifer Walsh, Controller, approved this definition on March 14th, 2025.”
The Metric Wizard walks the Controller through a structured configuration process: which accounts to include, which to exclude, how to handle edge cases, what the period convention is, how to treat subsidiaries. Every decision is explicit and recorded. There is no ambiguity baked into the definition that will surface as a discrepancy later.
Before sign-off, the Controller goes through a pre-flight verification step: each component of the metric is tied to a specific line on a financial statement, and the Controller confirms that the computed value matches what she expects to see. If it doesn’t match, she can note the discrepancy — and that note is stored permanently alongside the approval record.
This is the difference between a Controller who approved a metric and a Controller who verified and then approved a metric.
When a metric definition needs to change — new accounts are added, a subsidiary is acquired, accounting treatment changes — Tessera does not silently update the definition. It creates a new version, with a mandatory note explaining what changed and why, and requires a new named approval.
Historical results are permanently associated with the version that produced them. If your gross margin was 41.3% in Q3 2024, and you later change the definition, Tessera does not retroactively recalculate Q3 2024. It shows Q3 2024 under the definition that was in effect at the time, and it shows a visible marker on the chart at the point where the definition changed.
This is not a technicality. This is what accounting requires. Restatements are material events with disclosure obligations. A tool that silently recalculates historical data is not a tool you can use for financial reporting.
Every metric result carries a timestamp showing when it was last computed. If a result is being refreshed, that is visible. If a result is unexpectedly old, that is visible. Tessera does not display a number without disclosing how current it is.
This sounds obvious. It is not how most dashboards work. Most dashboards show you a number and leave you to wonder whether it was computed five minutes ago or five days ago.
Tessera ships with a library of approximately 290 pre-defined metric components and composed metrics — covering the financial and operational measurements that Controllers and CFOs use most: revenue, gross profit, EBITDA, gross margin, operating margin, days sales outstanding, days payable outstanding, current ratio, quick ratio, and more.
These baseline definitions are immutable. They cannot be edited. If your company’s revenue calculation differs from the baseline — because you have a revenue recognition treatment that is specific to your industry, for example — you create a custom version. The custom version goes through the normal approval workflow. Both the baseline and your custom version are visible in the Metric Registry, with a clear record of what you changed and why.
The point of an immutable baseline is that it gives everyone a common reference point. “Our revenue” and “baseline revenue” are different things, and Tessera makes that difference explicit rather than allowing it to silently accumulate as undocumented divergence.
These are not settings. They are not policies you configure after installation. They are structural properties of how Tessera stores and computes data — enforced by the system’s design, not by the honor system.
When NetSuite closes an accounting period, that period is sealed. No new transactions can post. This is a fundamental accounting control, and Tessera treats it as one.
Once Tessera computes a metric result for a closed period, that result is stored permanently and never recalculated. Not when the metric definition changes. Not when new accounts are added to the chart of accounts. Not when a subsidiary is reorganized. The number that existed for Q3 2024 under the definition that was active at the time is the number that will always exist for Q3 2024 under that definition. The storage model makes retroactive recalculation structurally impossible under normal operations — there is no code path that overwrites a closed-period result without explicit named authorization, a mandatory documented reason, and a permanent audit record of both the prior and revised values. A Controller or second approver must explicitly sign off on any override of a closed-year result. The original value is never deleted — it is preserved permanently alongside the replacement, visible to auditors.
This is not a feature that could be turned off by a future software update or a configuration change. It is enforced at the data layer: closed-period results are written once and the write path has no update operation. A developer reading the source code would see immediately that there is no mechanism to overwrite a closed-period result. The governance is in the structure, not in a policy document.
In accounting, when you change a policy — say, a change in how you recognize revenue or how you capitalize expenses — you do not restate every prior period as if the new policy had always been in effect. You disclose the change, establish an effective date, and apply the new policy going forward. Prior periods are reported under the prior policy.
Tessera versions metric definitions the same way. When a definition changes, a new version is created with an effective date and a mandatory change note. Prior results remain associated with the version that produced them. On any chart showing a metric over time, version boundaries are marked visibly so anyone reading the chart can see exactly when the definition changed and look up what changed and why.
This mirrors how a Controller thinks about accounting policy changes — and it means Tessera’s historical data is always interpretable in the context of the rules that were in effect at the time, not silently revised to reflect current thinking.
Not every change to a metric definition is a restatement-level event. Correcting a field label, adjusting a display format, or adding a note to a definition does not change the computed result. Tessera distinguishes these two categories the same way auditors do: material changes (anything that affects the computed value) require a new version and a new named approval; minor changes are logged in a separate audit trail with the previous and new value, who made the change, and when — but do not trigger a new approval cycle.
Controllers already think this way. Tessera’s data model reflects it.
In accounting, every control requires a named responsible party. A control that says “someone should review this” is not a control — it is a suggestion. A control that says “Maria Chen, Controller, reviewed and approved this on April 3rd, 2025” is a control.
Tessera’s approval model is built on this principle. Approval Domains define areas of financial responsibility — one designated approver per domain, typically the Controller or CFO. No metric is active without a named approval from the appropriate domain owner. That approval record is immutable and attached to every result the metric ever produces. If the approver leaves the company, the historical approvals are preserved exactly as they were, and the domain requires a new designated approver before any new metrics in that domain can be activated.
This is not access control. Access control determines who can see data. This is accountability infrastructure — it determines who is responsible for what the data means.
Most governance failures in financial software are not caused by bugs. They are caused by people finding workarounds — a field that can be overwritten, a report that can be regenerated with different parameters, a dashboard that does not record what inputs were used to produce a number.
Tessera’s design philosophy is to make the correct path the only path. There is no “edit this result” button on a closed-period metric. There is no “recalculate history” option in the admin console. There is no way to approve a metric without going through the verification workflow. The system does not rely on users doing the right thing — it relies on the right thing being the only thing the system will do.
This is the difference between governance as a feature and governance as architecture. Features can be disabled. Architecture cannot.
If an external auditor asks to understand how a metric was calculated, Tessera can show:
This is not a report generated for the audit. This is the ordinary operation of the system. The audit trail is not a feature added on top — it is the architecture.
When a Controller joins a company that has been running Tessera, she does not inherit a collection of spreadsheets and saved searches whose provenance is unclear. She inherits a Metric Registry with documented definitions, approval histories, and version records.
She can see every metric the company tracks, who approved each one, what it includes, and when it was last reviewed. She can make an informed judgment about whether she agrees with the existing definitions or wants to change them. If she changes something, her approval is attached to the new version — and the prior version and its results are preserved.
This is what metric governance looks like when it is treated as a first-class concern rather than an afterthought.
Most dashboards tell you what the data says. Tessera tells you what the data means — because someone with authority and accountability decided that, explicitly, and put her name on it.
If you have ever had a meeting where two people had two different numbers from the same system, and spent the meeting trying to figure out why, Tessera is what prevents that meeting.
If you are a Controller who has been asked to stand behind a number that you did not define and cannot fully trace, Tessera is what gives you the traceability to stand behind it — or the visibility to know that you shouldn’t.
Truth, Composed.