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.
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.
What’s interesting:
- 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
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.
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.
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.
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.