> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Total Revenue, Adobe Commerce > Total Revenue for Adobe Commerce stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) ## At a glance > Headline gross revenue across every Adobe Commerce (Magento) order placed in the period. The arithmetic sum of `grand_total` for every order created in the window, regardless of state, fulfilment, or refund status. | | | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `SUM(grand_total)` across every order in the window. `grand_total` is Adobe Commerce's authoritative customer-billed total, computed as `subtotal + shipping_amount + tax_amount − discount_amount`. | | **VAT / tax treatment** | **Tax-inclusive by definition.** `grand_total` already includes `tax_amount`. Pre-tax view sits in `subtotal` (or `base_subtotal` for the store's base currency). | | **Shipping** | **Included.** `grand_total` adds `shipping_amount` (post-discount). | | **Discounts** | Already deducted, this is the post-promotion, customer-paid figure. | | **Refunds** | **NOT deducted.** Adobe Commerce tracks refunds as separate Credit Memo entities. The order's `grand_total` does not change after a refund, the refund lives on the credit memo. A fully refunded $200 order still contributes $200 here. Use [Credit Memo Total](/nerve-centre/adobe_commerce/credit_memo_total) for the offset. | | **Order state vs status** | **Both unfiltered.** Adobe Commerce has a state machine (`new`, `processing`, `complete`, `closed`, `canceled`, `holded`, `pending_payment`, `payment_review`) AND a richer status overlay (configurable per merchant). This card includes every state, including `canceled` and `holded`. To see a "realised cash" view, filter to `state = complete OR closed`. | | **`pending_payment` orders** | Included. Adobe Commerce creates the order as soon as the shopper hits Place Order, even before the payment authorisation completes. If the gateway never returns success, the order can sit in `pending_payment` indefinitely. These contribute to Total Revenue but never collected cash. | | **Currency** | **Multi-currency arithmetic sum WITHOUT FX conversion.** Adobe Commerce stores both `grand_total` (in the order's display currency) and `base_grand_total` (in the store's base currency, FX-converted at order time). This card uses `grand_total`. For multi-store merchants with multiple base currencies, prefer `base_grand_total` views. | | **Channels / sources** | **Not filtered.** Adobe Commerce uses Store Views (`store_id`) to separate web storefronts, country sites, and B2B portals. POS, marketplace, and headless storefronts also tag a `store_id`. This card sums across every Store View. | | **Time window** | `T/7D/30D vsP` (default 30D) | | **Alert trigger** | `drop >15% vsP`, driven by `sentiment_key: revenue_trend` | | **Roles** | owner, marketing, operations | ## Calculation ``` SUM(grand_total) WHERE date BETWEEN [period_start, period_end] ``` ## Worked example A multi-region brand on Adobe Commerce 2.4 with three Store Views: US, UK, and a B2B portal. The 30-day window covers 14 Mar 26 to 12 Apr 26. | `store_id` | Store View | Orders | Avg `grand_total` | Channel revenue | | ----------------------------- | -------------------------------------------- | --------- | ----------------- | ---------------------------------------- | | `1` | US storefront (USD) | 1,840 | \$148 | \$272,320 | | `2` | UK storefront (GBP, summed without FX) | 612 | £132 | £80,784 | | `3` | B2B portal (USD, account-priced) | 41 | \$1,420 | \$58,220 | | (across) | `pending_payment` orders that never resolved | 78 | \$156 | \$12,168 (no cash taken) | | **Total Revenue (this card)** | | **2,571** | | **\$343,492 + £80,784 (mixed currency)** | What's interesting: 1. **The mixed-currency total is meaningless on its own.** The card sums `grand_total` directly without FX, so the headline mixes USD and GBP. A multi-store merchant should use `base_grand_total` views instead, or split per-Store-View. The roadmap includes a `currency_filtered_total_revenue` card. 2. **The B2B portal is 17% of US revenue from 2% of order volume.** Big wholesale orders skew Total Revenue. If the B2B portal goes quiet for a week the headline drops noticeably even if the DTC store is stable. Watch [BC Revenue by Store View](/nerve-centre/adobe_commerce/bc_revenue_by_store_id) for the breakdown. 3. **`pending_payment` orders are silently inflating the headline by \$12,168.** These are shoppers who hit Place Order but the gateway never returned. Adobe Commerce keeps the order skeleton; this card includes it. Subtract these (or filter `state != pending_payment`) for a realised-cash view. 4. **The 30-day prior window was \$358,400 + £79,200.** Total Revenue is down 4.2% on USD and up 2.0% on GBP, which is below the `drop >15% vsP` alert threshold for either currency stream. Vortex IQ Nerve Centre stays quiet, but the card itself shows the trend and a per-Store-View slice surfaces the divergence. ## Sibling cards merchants should reference together | Card | Why pair it with Total Revenue | | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Average Order Value](/nerve-centre/kpi-cards/adobe-commerce/average-order-value) | Total Revenue ÷ Order Count. Tells you whether revenue moved on volume or basket size. | | [Order Count](/nerve-centre/kpi-cards/adobe-commerce/total-orders) | The other half of the equation. If revenue moves but order count is flat, basket size changed. | | [Credit Memo Total](/nerve-centre/adobe_commerce/credit_memo_total) | This card is **gross** of refunds. Credit Memo Total tells you how much Adobe Commerce has actually credited back. Subtract for a net view. | | [`pending_payment` Order Value](/nerve-centre/adobe_commerce/pending_payment_value) | Headline includes orders that never collected cash. This card surfaces how big that gap is. | | [Discount % of Revenue](/nerve-centre/kpi-cards/adobe-commerce/discount-of-revenue) | Discounting always lifts Total Revenue mechanically. Watch them together. | | [Revenue by Store View](/nerve-centre/adobe_commerce/revenue_by_store_id) | Per-Store-View breakdown, essential for multi-region or B2B-plus-DTC merchants. | | [Order State Distribution](/nerve-centre/adobe_commerce/order_state_distribution) | Shows the mix of `processing`, `complete`, `canceled`, `holded`, `pending_payment`. A drift toward `holded` or `pending_payment` indicates payment-side trouble. | ## Reconciling against the vendor's own dashboard **Where to look in Adobe Commerce Admin:** Sales → Orders → Reports → Sales (or Reports → Sales → Orders, depending on Adobe Commerce version). Set the same window (default 30D), keep the *Status* filter on "All Orders", and look at the **Total Revenue** column. That figure should match this card to within a couple of dollars. Other Adobe Commerce Admin views that *look* like the same number but aren't: * **Reports → Sales → Orders**: this DOES match (assuming "All Orders" status, same window, same Store View scope). * **Reports → Sales → Invoiced**: this is invoiced amount only, post-Credit-Memo, so lower. * **Reports → Sales → Refunded**: this is the refund total, not revenue. * **Dashboard → Lifetime Sales**: all-time, not windowed. * **Dashboard → Last Orders**: last 5 orders only, not aggregated. **Why our number may legitimately differ from Adobe Commerce Admin:** | Reason | Direction of divergence | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | **Time-zone**. Adobe Commerce Admin uses store timezone (configured per Store View); Vortex IQ runs on UTC by default. Orders near midnight on the boundary days fall on different sides. | ±1 day's revenue at the boundary | | **Currency**. Multi-currency Adobe Commerce sites display `grand_total` in display currency in the order grid, but the Sales Report aggregates in `base_currency` (FX-converted). Vortex IQ sums `grand_total` without FX. | Material for international merchants | | **Store View scope**. Adobe Commerce reports run per Store View by default. Vortex IQ sums across every Store View unless filtered. The "All Store Views" report scope in Admin should match. | Vortex IQ higher than per-view report | | **`canceled` orders**. The default Sales Report status filter is "All Orders" which includes canceled; some merchants override the filter. This card always includes canceled. | Vortex IQ higher than filtered admin reports | | **API rate-limit gaps during sync**. If the Adobe Commerce REST API throttled during the most recent indexer run, the latest day's orders may be missing for a few minutes. | Self-resolves at next sync | **Cross-connector reconciliation (when the merchant has connected payment processors and analytics):** These connectors see *the same transactions through different lenses*. They should agree within known tracking gaps. Divergence is a data-quality signal worth investigating. | Card | Expected relationship | What causes legitimate divergence | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_total_revenue`](/nerve-centre/kpi-cards/stripe/total-charge-volume) | Stripe ≤ Adobe Commerce Total Revenue | Stripe sees only successfully captured charges. It excludes Adobe Commerce `pending_payment` (gateway never returned), `canceled`, `holded`, refunds (which sit on Credit Memos), and any orders routed through a non-Stripe processor (Authorize.Net, Braintree, PayPal, gift cards). | | [`paypal.pp_total_volume`](/nerve-centre/paypal/pp_total_volume) | PayPal ≤ Adobe Commerce Total Revenue | PayPal sees only PayPal-checkout orders. Subset by definition. | | [`google_analytics.ga_revenue_trend`](/nerve-centre/kpi-cards/google-analytics/revenue-trend) | GA4 ≈ Adobe Commerce Total Revenue × (1 − tracking gap) | GA4 typically misses 10, 25% of orders due to ad-blockers, cookie rejection, and tag-fire failures. **Treat Adobe Commerce as the source of truth for revenue.** Use GA4 for traffic and channel attribution, not for revenue figures. | **Net of all processors and pending payments:** if you sum *Stripe + PayPal + Authorize.Net + Braintree + manual + gift cards*, the total should sit close to *this card minus pending\_payment value minus canceled value*. A persistent gap > 2% means a payment processor is missing from your Vortex IQ workspace. ***
Same-metric documentation cross-reference (for agencies running multiple platforms) The same definition of Total Revenue lives on other commerce platforms. This is **not a reconciliation**, your Adobe Commerce store doesn't have a parallel store on Shopify or BigCommerce to compare numbers against. These cross-links exist so agencies running multi-platform client books can navigate between identical metrics across the docs. * [`shopify.total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) * [`bigcommerce.total_revenue`](/nerve-centre/kpi-cards/bigcommerce/total-revenue)
## Known limitations / merchant FAQs **Why does my Total Revenue look higher than my bank deposits?** Three reasons specific to Adobe Commerce: (1) `pending_payment` orders are included but never collected cash, (2) `canceled` orders are included even though they were voided, and (3) refunds live on Credit Memos and don't subtract from `grand_total`. To get a realised-cash floor, take this card minus *pending\_payment value* minus *canceled value* minus *Credit Memo Total*. **What's the difference between `state` and `status` on an Adobe Commerce order?** `state` is the system-level lifecycle (`new`, `processing`, `complete`, `closed`, `canceled`, `holded`, `pending_payment`, `payment_review`). It's a fixed enum used internally for what actions are valid. `status` is a configurable, user-facing label that maps onto `state`, merchants can rename "processing" to "Order Confirmed" or add custom statuses like "Awaiting Drop-Ship". This card uses `state` filtering for any state-based view; `status` is captured for display only. **What is `grand_total` vs `base_grand_total`?** `grand_total` is in the order's display currency (what the customer paid). `base_grand_total` is in the store's base currency (FX-converted at order time using the store's current FX rate). Multi-currency stores should use `base_grand_total` views for aggregate reporting, this card uses `grand_total` because it's the customer-paid figure. **Why doesn't the Adobe Commerce dashboard match this card?** Most commonly: (1) the dashboard scope is set to a single Store View while this card sums across all Store Views, or (2) the dashboard report filters out `canceled` while this card includes them, or (3) timezone difference (the dashboard uses Store View timezone, this card uses UTC). **Why is my Stripe / Authorize.Net number much smaller than this card?** Payment processors only see *successfully captured* charges. They exclude `pending_payment` (the gateway didn't return success), `canceled`, refunds (which subtract from the processor side), and any orders paid via a different processor (a typical Adobe Commerce store uses 2-4 payment methods). **My multi-store Adobe Commerce, how do I see per-Store-View revenue?** Use [Revenue by Store View](/nerve-centre/adobe_commerce/revenue_by_store_id). It groups by `store_id`. Useful for region-by-region performance reads (US vs UK vs DE) and for separating B2B portals from DTC. **Why doesn't Google Analytics match?** GA4 typically misses 10, 25% of orders due to ad blockers, cookie rejection, and tag-fire failures. The miss rate is *not* fixable; it's structural. **Treat Adobe Commerce as the source of truth for revenue.** Use GA4 for sessions, traffic source, and funnel behaviour, not revenue. **Why does today's number jump up and down so much?** Today is incomplete data. As the day progresses orders add into the bucket, and as the day rolls past midnight some orders flip date because of timezone effects. **Use the rolling 7-day or 30-day view for stable numbers**, that's why the alert window is `30D vsP` and not `1D`. *** ### Tracked live in Vortex IQ Nerve Centre *Total Revenue* is one of hundreds of KPI pulses Vortex IQ tracks across Adobe Commerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.