When Shopify, Finance and Marketing Report Different Revenue

Three teams, three revenue numbers for the same month. Usually none of them is wrong. They answer different questions and nobody wrote down which.

The short answer

Shopify, finance, and marketing disagree because they count different things on different dates: Shopify reports sales activity, finance reports revenue under its accounting policy, and marketing reports revenue credited to its channels. The fix is not one number but a metric dictionary that gives each number a name, a date rule, a time zone, and an owner, with every metric tied to a source total.

Sound familiar?

  • Last month's revenue has a different answer depending on who you ask.
  • Adding up ad platform reports gives more revenue than Shopify shows.
  • A refund processed this month lowers revenue for an order placed last month.
  • Meetings start with an argument about which number is right.

Why it happens

Refunds and recognition use different dates
Shopify's sales reports show a sale on the day it was made and a reversal on the day it was processed. Tie the refund back to the order instead and the month changes. Finance may also move revenue to the date goods shipped.
Time zones move orders between months
An order placed at 11:30 PM on October 31 in New York is November 1 in UTC. Shopify warns that finance reports and payout exports may use different date ranges or time zones than its payments activity report.
Attribution credit is not revenue
Ad and email platforms report the orders they claim, so two platforms can credit the same order. Summing their reports overshoots real sales and is never a valid company revenue number.

How we fix it

  1. 1

    Pick the numbers people argue about

    Start with the five or so numbers leadership disputes, and tie each one to a source total, such as a Shopify report or a closed month in the books.

  2. 2

    Write and sign off the definitions

    Give each metric a definition, a grain, a date rule, a time zone, and an owner. Name the versions separately, such as booked net sales, recognized revenue, and attributed revenue, and settle edge cases like gift cards and test orders up front.

  3. 3

    Build once and show the definition

    Build the metrics in the tool you already use, whether Snowflake semantic views, dbt, or your BI model. Point one dashboard at them, retire duplicate calculations, show the definition next to each number, and check totals every month.

What you end up with

  • A metric dictionary with each revenue version named
  • A tie-out month that every number must match
  • Dashboards that show the definition beside each metric
  • A monthly check of totals against source reports

10,105

overlapping order-line records reconciled before a Shopify connector change reached production

Read the case study

Common questions

Which revenue number is the correct one?

Each can be correct for its own job. Booked net sales ties to Shopify, recognized revenue ties to the close, and order-cohort net sales shows what an order ended up worth. Decide which one answers when someone just says "revenue", and label the others.

Why do our ad platforms report more revenue than Shopify?

Platforms credit the orders they claim, and more than one platform can claim the same order. Attributed revenue is useful for comparing channels, but it is not deduplicated company revenue.

Will a semantic layer fix bad source data?

No. If a cost is missing or a connector drops refunds, the semantic layer will calculate the wrong answer consistently. Check totals against source reports every month, because a definition can be right while a source breaks.

Do AI tools need the same definitions?

Yes, or they will guess. If someone asks for "revenue" and you have four revenue metrics, the tool still has to pick one, so say in each description which metric is the default and when to ask.

Bring the numbers that don't add up

We'll trace them to the source with you and say where we'd start. No pitch deck.

Book a Call