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 here. Use 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
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) |
- The mixed-currency total is meaningless on its own. The card sums
grand_totaldirectly without FX, so the headline mixes USD and GBP. A multi-store merchant should usebase_grand_totalviews instead, or split per-Store-View. The roadmap includes acurrency_filtered_total_revenuecard. - 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 for the breakdown.
pending_paymentorders 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 filterstate != pending_payment) for a realised-cash view.- 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% vsPalert 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 | Total Revenue ÷ Order Count. Tells you whether revenue moved on volume or basket size. |
| Order Count | The other half of the equation. If revenue moves but order count is flat, basket size changed. |
| 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 | Headline includes orders that never collected cash. This card surfaces how big that gap is. |
| Discount % of Revenue | Discounting always lifts Total Revenue mechanically. Watch them together. |
| Revenue by Store View | Per-Store-View breakdown, essential for multi-region or B2B-plus-DTC merchants. |
| 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.
| 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 |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_total_revenue | 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 | PayPal ≤ Adobe Commerce Total Revenue | PayPal sees only PayPal-checkout orders. Subset by definition. |
google_analytics.ga_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. |
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. 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.