Why Do My Ecommerce Reports Not Match?

Why ecommerce reports do not match: the direct answer

Your ecommerce reports do not match because each system is usually answering a different question. Your store platform may count placed orders. Your accounting export may count booked revenue. Your ad platform may count attributed conversions inside its own attribution window. Your analytics tool may count tracked website purchases. Your marketplace report may count settlements after fees and payout timing. Your spreadsheet may apply another layer of filters, joins, formulas, or manual edits.

That means one dashboard is not automatically wrong. The mismatch often comes from different rules for date basis, revenue recognition, attribution, refunds, discounts, tax, shipping, order status, marketplace settlement, POS syncs, SKU mapping, currency, timezone, or spreadsheet transformations.

If you are deciding whether yesterday’s sales were down, start with raw commerce orders. If you are closing the month, use finance or accounting-recognized revenue. If you are tuning Meta or Google campaigns, review platform-attributed campaign data but do not treat it as total store revenue. If you are investigating refunds, separate refund date from original order date. If you are analyzing products, reconcile SKU, variant, bundle, and return logic before trusting the product table.

Which ecommerce report should you trust?

The report to trust depends on the decision. A single “master dashboard” can still mislead you if it blends incompatible definitions of revenue, orders, refunds, AOV, ROAS, and customer value.

The safest rule is to keep metric families together. Reconcile revenue from one definition, orders from one status policy, refunds from one timing rule, and ROAS from one attribution model. Mixing definitions creates false precision.

Report mismatch map: where ecommerce numbers usually diverge

Use this map to locate the mismatch before rebuilding your entire reporting stack.

A practical workflow for reconciling ecommerce reports

Do not reconcile every metric at once. Start from the symptom and follow the shortest path to the likely definition mismatch.

Start here if total revenue differs

1. Freeze one date range and one timezone.
2. Export raw orders for that exact range from the commerce platform or order database.
3. Separate gross revenue, discounts, shipping, tax, refunds, fees, and net revenue into different columns.
4. Check whether each report uses order date, payment date, fulfillment date, refund date, or payout date.
5. Compare revenue before refunds and revenue after refunds separately.

If order count is the same but revenue differs, the issue is usually revenue basis. If revenue matches over a longer period but not by day, the issue is usually timing.

Start here if order counts differ

1. List the order statuses included in each report.
2. Check whether cancelled, unpaid, partially paid, draft, test, fraud, exchanged, subscription, POS, and marketplace orders are included.
3. Compare total orders, paid orders, fulfilled orders, and refunded orders separately.
4. Look for duplicate order IDs created by exports, joins, or subscription renewals.

Do not use ad conversions or analytics purchases as the source of truth for order count. They are tracking outputs, not the order ledger.

Start here if ROAS differs

1. Write down the attribution window for each platform.
2. Separate click-attributed, view-attributed, modeled, and tracked purchases where possible.
3. Compare platform-attributed revenue to total store revenue, not as a replacement for it.
4. Check whether returns, cancellations, taxes, shipping, and discounts are included in the revenue used for ROAS.
5. Use blended measures alongside platform ROAS when budget decisions affect the whole store.

Ad platforms are useful for campaign diagnostics, but they should not be treated as the only source for company-level revenue or profit decisions.

Start here if product performance differs

1. Export order line items, not only product summary rows.
2. Map product ID, variant ID, SKU, product name, bundle parent, and bundle component.
3. Check whether renamed SKUs or merged products changed historical reporting.
4. Separate revenue sold from revenue kept after refunds and returns.
5. Look at contribution margin if product decisions involve profitability, not just sales volume.

Product reports often disagree because one system reports what was sold, another reports what was fulfilled, and another reports what was retained after refunds.

Start here if refund totals differ

1. Separate refund amount from return status.
2. Compare refunds by original order date and refunds by refund processed date.
3. Check for partial refunds, shipping refunds, tax refunds, exchanges, store credit, and chargebacks.
4. Confirm whether refunded orders are removed from revenue or shown as negative transactions.

A refund report can be correct and still not match a revenue report if one uses the refund date and the other adjusts the original order date.

Start here if marketplace numbers differ

1. Keep marketplace order revenue separate from marketplace payouts.
2. Reconcile fees, reserves, holds, shipping adjustments, returns, chargebacks, and payout date.
3. Compare order date revenue to settlement date cash movement.
4. Document marketplace-specific caveats instead of forcing them into the same formula as direct-to-consumer orders.

Marketplace settlement reports are cash and payout tools. They are not always clean substitutes for order-level revenue reports.

Metric definition matrix: revenue, orders, refunds, AOV, ROAS, and LTV

Before you compare dashboards, define the metric. Most reporting fights are definition fights disguised as data problems.

Common mismatch scenarios and what to audit first

Shopify or WooCommerce revenue does not match GA4

The likely explanation is that your commerce platform is reporting order records while GA4 is reporting tracked website events. GA4 can be affected by consent settings, tracking gaps, session rules, attribution, duplicate event handling, and transaction ID collection.

Check first: transaction IDs, purchase event firing, timezone, refunds, tax, shipping, discounts, and whether the same order date range is used. Do not use: GA4 as the sole ledger for order revenue.

Meta Ads or Google Ads revenue does not match analytics

The likely explanation is attribution. Ad platforms, analytics tools, and your store apply different rules for click credit, view credit, conversion windows, modeled conversions, deduplication, and channel assignment.

Check first: attribution window, conversion action, purchase event, revenue value passed, and whether returns or cancellations are adjusted. Do not use: one platform’s attributed revenue as total business revenue.

Order exports do not match dashboard orders

The likely explanation is a filter mismatch. The dashboard may exclude cancelled, test, unpaid, or archived orders while the export includes them, or the export may include POS, marketplace, subscription, draft, or duplicate rows from line items.

Check first: order status, payment status, sales channel, test orders, and whether each row is an order or a line item. Do not use: row count as order count unless each row is one order.

Refund totals do not match revenue reports

The likely explanation is timing. One report may apply the refund to the original order date, while another shows the refund on the date money was returned. Partial refunds, store credit, tax refunds, shipping refunds, chargebacks, and exchanges can also cause gaps.

Check first: refund date, original order date, refund amount, refund reason, payment processor record, and return status. Do not use: returns requested as a proxy for refunded revenue.

AOV changes depending on the report

AOV changes when the numerator or denominator changes. One tool may use gross sales divided by all orders. Another may use net revenue divided by paid orders. Another may exclude tax, shipping, refunds, discounts, or cancelled orders.

Check first: revenue numerator and order denominator. Do not use: AOV from mixed revenue and order definitions when evaluating pricing, bundles, or promotions.

Product reports disagree with sales reports

The likely explanation is product mapping. Product dashboards often group by current product name, while order exports may preserve historical SKU, variant, bundle, or line-item details. Refund and return handling can also move product performance after the sale.

Check first: SKU, variant ID, bundle logic, renamed products, deleted products, and refunded line items. Do not use: product name alone as the product key.

Marketplace payouts do not match order revenue

The likely explanation is that order revenue and payout cash are different concepts. Marketplace payouts may include fees, reserves, advertising charges, shipping adjustments, tax handling, chargebacks, and settlement delays.

Check first: settlement date, payout report, fees, holds, returns, and marketplace-specific adjustments. Do not use: payout amount as clean product revenue.

Manual spreadsheets disagree with dashboards

The likely explanation is spreadsheet logic. A stale export, hidden filter, broken lookup, duplicate join, pivot-table setting, overwritten formula, or manual exclusion can change the result even when the original data was correct.

Check first: raw row count, unique order IDs, formula ranges, lookup keys, pivot filters, export timestamp, and any manual edits. Do not use: a spreadsheet total until it reconciles back to raw source rows.

How to assign a source of truth by decision type

A source of truth is not just a tool. It is a documented rule that says which system, metric definition, date window, and filter policy your team will use for a specific decision.

For each important metric, document these fields:

• Metric name and business use.
• Primary source system.
• Date basis: order date, payment date, fulfillment date, refund date, settlement date, or cohort date.
• Reporting timezone.
• Included and excluded order statuses.
• Revenue basis: gross, net, total sales, booked revenue, or contribution margin.
• Tax, shipping, discount, refund, fee, and chargeback treatment.
• Attribution window and conversion source, if marketing-related.
• Customer identity rule for retention, repeat purchase, and LTV.
• SKU, variant, bundle, and product mapping rules.
• Marketplace, POS, subscription, and wholesale caveats.
• Metric owner and refresh cadence.

Once this is documented, reporting disagreements become easier to resolve. Instead of debating which dashboard “feels right,” the team can ask whether the report follows the approved rule for that decision.

Operator audit script: how to prevent mismatches from recurring

Run this script before major budget changes, merchandising decisions, monthly reporting, retention planning, or refund analysis.

1. Freeze the date range. Use exact start and end dates, one timezone, and one refresh timestamp.
2. Export raw orders. Pull order-level and line-item-level data before relying on summaries.
3. Compare gross and net revenue separately. Do not reconcile one blended revenue number until discounts, refunds, tax, shipping, and fees are separated.
4. Separate refunds by two dates. Build one view by original order date and another by refund processed date.
5. Verify order statuses. Document whether cancelled, unpaid, partially paid, test, fraud, exchanged, subscription, POS, and marketplace orders are included.
6. Check attribution windows. Record the conversion source, attribution window, click/view rules, and modeled conversion settings for each ad or analytics report.
7. Reconcile SKU aliases and bundles. Map SKU, variant ID, product ID, bundle parent, bundle component, and historical product names.
8. Compare marketplace settlements separately. Reconcile order revenue to payout reports only after fees, holds, reserves, returns, and settlement timing are identified.
9. Inspect spreadsheet transformations. Check row counts, unique order IDs, lookup keys, pivot filters, formula ranges, and manual edits.
10. Document the source-of-truth rule. For every metric used in a decision, write down the approved source, formula, timing rule, and owner.

The goal is not to make every platform show the same number. The goal is to know why the numbers differ, which one fits the decision, and where mismatches may be hiding a revenue leak.