Reference · built on requestOperator by FibricReporting & analysis

Metric Reconciliation

Compares one figure across two systems of record, flags disagreement beyond tolerance, and proposes a reconciliation note.

Request accessPricing ↗

About

Revenue in the store, revenue in the ledger, and revenue in the warehouse are three numbers that should be one. Metric Reconciliation reads each pair you define: net sales in Shopify against the sales account in NetSuite, Stripe's balance transactions against the payouts booked in Xero, an analyst view in BigQuery against the table it was built from.

For each pair it computes the difference over the same period, compares it to the tolerance you set, and when the gap exceeds it, proposes a note. The note lists both figures, the period, the definition each system uses, and the rows that most explain the gap. A person approves the note and decides what to do with it.

This is a reference listing. It documents what Fibric would read from Metric Reconciliation and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders and their totals through the Shopify Admin GraphQL orders query, filtered by created date and financial status
  • Balance transactions from Stripe with amount, fee, net, type, and available_on, listed by created interval or payout
  • Ledger and transaction rows from NetSuite through SuiteQL, and ProfitAndLoss report lines from Xero by date range
  • Tables and views in BigQuery through jobs.query, and in Snowflake through the SQL API, for the derived side of a pair
  • The tolerance and period definitions you set per pair, and prior notes so a known, explained gap is not raised twice

Proposed actions

  • Target capability: propose a reconciliation note in Slack showing both figures, the gap, the tolerance, and the rows that explain most of it
  • Target capability: propose a Jira issue for a gap that needs a fix in one system, with the pair definition and period attached
  • Target capability: propose a line in the reconciliation log sheet through spreadsheets.values.update, one row per pair per period
  • Target capability: propose marking a gap as explained, with the reason, so the same difference is not raised again next period

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Store sales against the ledger

    Net sales from Shopify orders for the month are set against the sales account from NetSuite through SuiteQL. When the gap passes tolerance, the note lists the orders with no matching ledger line.

    With Shopify, NetSuite, Slack

  • Stripe payouts against the bank entries in Xero

    Balance transactions of type payout from Stripe are summed by available_on and compared with the payouts booked in Xero for the same days. Fees are shown separately so a fee-only gap is not mistaken for a missing payout.

    With Stripe, Xero, Google Sheets

  • Analyst view against its source table

    A BigQuery view of daily revenue drifts from the raw table it reads. The operator proposes a Jira issue to the data team with the days that differ and the query on each side.

    With BigQuery, Jira

Requirements

  • At least one pair defined: the two sources, the query or report on each side, the period, and the tolerance
  • Read access on both sides of each pair, such as read_orders in Shopify and a restricted Stripe key that can list balance transactions
  • A Slack channel for notes and, if you want tickets, a Jira project the connector can create issues in
Authentication
Metric Reconciliation reads through the Shopify, Stripe, NetSuite, Xero, BigQuery, and Snowflake connectors you connect. It writes notes through Slack, issues through Jira, and log rows through Google Sheets, each after approval.

Limits

  • It compares what each system reports. It does not decide which system is right, and it never edits a figure on either side.
  • Timing explains many gaps. Stripe records when funds become available; a ledger records when the entry is posted. The note shows both dates.
  • Shopify's read_orders scope reaches sixty days back. Reconciling older periods needs read_all_orders.
  • A pair without a shared period definition cannot be compared. The operator reports it as undefined rather than guess.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Metric Reconciliation ↗

Questions and answers

What does a person approve?
The note, and any ticket or log row that follows it. Each proposal shows the two figures, the period, the tolerance, and the rows that explain the gap. Approving a note posts it. Marking a gap as explained is its own proposal, with the reason recorded.
What record does it leave?
One entry per pair per period: both figures as read, the time of each read, the gap, the tolerance, whether it was raised, the note as approved, and any explanation attached later. Nothing is overwritten. A restated figure appears as a new entry.
Will it correct the wrong system?
No. It reads Shopify, Stripe, NetSuite, Xero, BigQuery, and Snowflake and writes only to Slack, Jira, and a log sheet, after approval. Fixing a figure is a decision a person makes in the system that owns it.
Ask about Metric Reconciliation

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy