How to Attribute a Metric to the Right System of Record

The common failure is a system-level decision: "Stripe is the source of truth." That sentence breaks the first time you need to count trials, seats, or canceled subscriptions, none of which Stripe models the way your product does. The durable unit of governance is the metric.

Write a precedence rule as a table, one row per metric. Four columns are enough: the metric, the owning system, the fallback order across the remaining sources, and the time semantics (when the value is considered final).

Three decisions in that table are worth defending.

First, cash belongs to the processor because the processor is the only system that observed the money move. Gross bookings belong to the application database because it saw the customer's intent before the card was authorized, so it can represent failed and pending attempts. Recognized revenue belongs to the ledger because it is the only system applying accounting rules.

Second, the CRM owns relationship attributes, not financial ones. A CRM that reports revenue is reporting a number it copied from somewhere else, and copied numbers drift.

Third, "final at" matters as much as "owner." A number can be owned by Stripe and still be provisional until settlement. Stripe distinguishes pending from available balances and flips the status on the balance transaction as settlement completes according to the balance transaction types reference. If your rule does not say when a value stops changing, every dashboard argument becomes a timing argument in disguise.

For comparison and reporting metrics that investors will read (burn, runway, a single KPI shown consistently), the discipline is the same: name the metric, name who calculates it, and keep the definition fixed across periods, which is the pattern recommended in Carta's investor update guidance and in the Raisemoney update format.

A reconciliation done in a spreadsheet at close is a reconstruction. A reconciliation done in the pipeline is a record. The difference is whether the losing value still exists next quarter.

The rule: never let a merge or an upsert overwrite another source's value for the same metric and period. Write one row per source per metric per period, then a decision row that names the winner.

A minimal schema:

create table metric_observation (
  metric_key       text        not null,  -- 'cash_collected', 'active_subscriptions'
  period_start     date        not null,
  period_end       date        not null,
  source_system    text        not null,  -- 'stripe', 'app_db', 'crm', 'ledger'
  source_value     numeric     not null,
  currency         text,
  observed_at      timestamptz not null,  -- when this source's value was read
  source_watermark timestamptz,           -- latest event time included in this value
  primary key (metric_key, period_start, period_end, source_system, observed_at)
);

create table metric_resolution (
  metric_key       text        not null,
  period_start     date        not null,
  period_end       date        not null,
  rule_version     text        not null,  -- 'precedence-v7'
  winning_source   text        not null,
  reported_value   numeric     not null,
  compared_at      timestamptz not null,
  observation_ids  uuid[]      not null,  -- the rows that competed
  decided_by       text        not null,  -- 'rule' or 'rule+manual_override'
  override_reason  text,
  primary key (metric_key, period_start, period_end, compared_at)
);

Two design choices carry most of the value. source_watermark records how much of the source data the value included, so a comparison between a Stripe figure current through Tuesday and a warehouse figure current through Monday is visibly unfair rather than mysteriously wrong. rule_version turns the precedence table into a versioned object, so a value reported last quarter can be re-explained with the rule that was in force then, not today's rule.

The same idea appears in warehouse modeling as slowly changing dimensions: when an attribute's history matters for analysis, you keep multiple rows with effective dates rather than overwriting in place, which is the distinction between SCD Type 1 and Type 2 laid out in the slowly changing dimensions implementation guide and in Denodo's modeling notes. A precedence rule is a Type 2 attribute: it changes, and the old versions must survive.

Capturing the conflict depends on the ingest being trustworthy, and ingest is where most attribution programs quietly fail.

Stripe pushes events to an HTTPS endpoint, and events can be delivered more than once and out of order, which is why the production pattern inserts the event into a table with a unique constraint on the event identifier before running any business logic, and returns success only after the row is committed as described in the Stripe webhook idempotency pattern. Stripe's own documentation covers registering endpoints and receiving JSON payloads over HTTPS in the webhooks guide, and the catalog of event types your handler must expect is in the API reference.

If you derive metrics by re-fetching the current object rather than trusting the payload, you get correct state, but you lose what the object looked like when the event fired. Those are different needs, and a metric attribution program needs both. Keep the raw event for replay and refetch the object for truth.

Stripe also warns that fee credits are not uniform across time: credits issued before a cutoff date generate no balance transactions and appear only in dashboard exports, while later ones appear as transactions with a balance_type of fee_credits per the fee credit support note. Translation for the precedence rule: a source can change its reporting behavior for a population of transactions. If your rule version does not change when that happens, you will attribute a shift in reporting mechanics to a shift in the business.

A checklist for the ingest layer:

That last row is the one teams skip. If you only write rows when sources disagree, you cannot distinguish no conflict from the comparison never ran.

Say a subscription business closes a month and three systems report cash collected.

The application database says 1,000 successful charges with a gross total of 100,000. Stripe's payments view agrees: 1,000 charges. Stripe's balance transactions for the period include those charges plus a refund of 2,000, a partial capture adjustment, and a payout. The count of balance transactions is higher than 1,000 and the net balance impact is lower than 100,000. The ledger, receiving gross revenue of 100,000 and a fee expense of roughly 3,200, shows 100,000 in revenue and 96,800 net.

Nobody is wrong. The metric "cash collected" is owned by Stripe, so the reported figure is Stripe's net balance impact for the period, after fees and refunds. The application database's 100,000 is stored as a competing observation, flagged as gross, and labeled with the currency and the included charge count. The ledger's 96,800 is stored as recognized net. The resolution row says: metric cash_collected, winning source stripe, rule precedence-v7, compared at a specific timestamp, with the three observation identifiers attached.

Six months later, when the number is questioned, the auditor does not compare a number to a memory. They see the row: value, winner, rule, timestamp, and the losers preserved. Then they run the same comparison against the same observations and get the same answer. If the rule has changed since, they can see which version produced the figure and what changed in between.

Two more numbers make the failure mode concrete. If you overwrite rather than store, you keep one value per metric per period. If you store three sources, you keep three, and the cost is storage you can measure in kilobytes. The information difference is the entire audit trail. If a fee-credit cutoff shifts 400,000 of earlier credits from a balance transaction to a dashboard-only export, an overwrite design reports a 400,000 drop in fee activity with no way to explain it, while a stored-observation design shows the source's behavior changing under the same metric.

The data model only pays off if a human or a machine can query it without reading a wiki.

Three access patterns cover almost every question:

1. The value view, which returns one row per metric per period with reported_value, winning_source and rule_version. Every dashboard and every investor update reads this view, never the raw sources.
2. The conflict view, which returns periods where the spread between the highest and lowest observation exceeds a threshold you set, with the sources named. Review it weekly; it is a better use of an hour than arguing about a number in a meeting.
3. The replay query, which takes a metric, a period and a rule version, returns the observations as of the comparison timestamp, and re-applies the rule. If it disagrees with the stored resolution, something upstream changed without a rule change, which is exactly the thing you want flagged.

Two governance rules keep this honest. Any manual override must write to metric_resolution with a reason and an owner, never to metric_observation. And any change to the precedence table increments rule_version and is recorded with a date, so a question about why a number moved has two distinguishable answers: the business changed, or the rule changed.

For teams that need the reporting surface built around this model (an internal metrics view, an auditor-facing page, or an investor dashboard reading only the value view), that is the kind of build Quanta takes on with you, from the schema to the app.