At a glance
The raw count of order rows created in the period. Every Adobe Commerce order document with acreated_atinside the window contributes one, regardless ofstate, payment outcome, or whether the customer ever paid.
Calculation
Worked example
A multi-region apparel brand on Adobe Commerce 2.4.6 runs three Store Views: US (USD), UK (GBP), and a B2B wholesale portal (USD). The 30-day window covers 14 Mar 26 to 12 Apr 26.
The headline reads 2,493 orders. What’s interesting:
- Store View 1 contributes 74% of order volume but the B2B portal contributes 17% of revenue from 1.6% of orders. Order Count and Total Revenue tell different stories. Always read the two together. A drop in this card may be invisible in revenue if the B2B portal was steady, and vice versa.
- 80
pending_paymentorders are inflating the count by 3.2%. These shoppers hit Place Order, the gateway didn’t return success, and the order was never paid for. They count here. To see the “real” order count merchants typically use astate IN (processing, complete, closed)filter, which would land at 2,362 in this example. - 51
canceledorders also count. Adobe Commerce keeps the order document after cancellation; this card doesn’t filter them. If the warehouse refused 30 orders this week (out of stock, fraud, address invalid), they’re still in the headline. - The 30-day prior window had 2,612 orders. This window is down 4.6% vs prior, which is below the
drop >20% vsPalert threshold. Vortex IQ Nerve Centre stays quiet, but a per-Store-View slice would show the US store flat, UK down 8%, and B2B portal down 22%, an early warning that the wholesale pipeline is softening even though the headline looks fine.
Sibling cards merchants should reference together
Order Count is the denominator under nearly every per-order ratio in the dashboard. Pair it with these for context:Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin: The closest Adobe Commerce Admin view is:Sales > Orders (the order grid). Apply the same date range filter (“Purchase Date” betweenFor a windowed-aggregate view rather than a row list:period_startandperiod_end), set Status to All Orders, and the row count at the bottom of the grid should match this card.
Reports > Sales > Orders in older Adobe Commerce 2.x versions, or Reports > Sales with the Orders tab in 2.4.6+. Set the same window, scope to All Store Views, and read the Total Orders column.Other Adobe Commerce Admin views that look like the same number but aren’t:
- Reports > Sales > Invoiced: counts invoices, not orders. One order can produce zero, one, or several invoices (partial shipments).
- Reports > Sales > Refunded: counts Credit Memos, a subset.
- Dashboard > Last Orders: only the last 5 orders, not aggregated.
- Dashboard > Lifetime Sales: all-time count, not windowed.
- Customers > All Customers > Orders column: per-customer running totals, not a window.
Cross-connector reconciliation (when these connectors are connected for this merchant):
These connectors see the same orders through different lenses. They should agree within known tracking gaps; divergence is a data-quality signal worth investigating.
Known limitations / merchant FAQs
Why does the order count look higher than the number my finance team uses for revenue? Three Adobe-specific reasons stack: (1)pending_payment orders are counted but never collected cash, (2) canceled orders are counted even though they were voided, and (3) Credit-Memo-refunded orders are counted at full value (the refund lives on a separate document). Finance typically uses an invoiced count (one Adobe Commerce invoice per shipment, with refunds netted), which lands materially lower. Both numbers are correct for different jobs.
What’s the difference between state and status on an Adobe Commerce order?
state is the system-level lifecycle, an 8-value enum: new, pending_payment, processing, complete, closed, canceled, holded, payment_review. It governs what actions the system allows. status is a configurable, user-facing label that maps onto state, merchants rename “processing” to “Order Confirmed” or add custom labels like “Awaiting Drop-Ship”. This card uses state only; renamed statuses don’t change the count. If you want to slice by your custom workflow statuses, use Financial Status Distribution.
Why doesn’t the Adobe Commerce dashboard match this card?
Most commonly: the admin scope is set to a single Store View. The Sales > Orders grid filters by your admin user’s assigned scope by default (e.g. only the UK Store View). Vortex IQ sums every Store View. Set the scope dropdown at the top-left of admin to All Store Views and re-run, the numbers should match.
My multi-store Adobe Commerce, can I see per-Store-View order count?
Not on this card directly; it’s a single number summed across all store_id values. Use Order State Distribution for the lifecycle breakdown, or filter the source data by store_id for a per-region count. A per-Store-View order-count card is on the roadmap.
Why is my Stripe charge count smaller than this number?
Payment processors only see successfully captured charges. Stripe excludes Adobe Commerce pending_payment (gateway never returned), canceled, holded, and any orders paid via a different processor (Authorize.Net, Braintree, PayPal, gift cards, manual). A typical multi-payment Adobe Commerce store splits orders across 2-4 processors; no single processor sees the full picture.
Why doesn’t Google Analytics match?
GA4 typically misses 10, 25% of orders due to ad blockers, cookie consent rejection, and tag-fire failures. A typical UK Adobe Commerce store sees GA4’s purchase event count run 75-90% of this card. The miss rate is structural, not a configuration bug. Treat Adobe Commerce as the source of truth for order count. Use GA4 for traffic source, channel, and device attribution.
My multi-currency Adobe Commerce, does Order Count care?
No. Order Count is a count, not a money figure, so grand_total vs base_grand_total is irrelevant. A USD order and a GBP order each contribute one. Pair with Total Revenue (which uses grand_total, mixed-currency without FX) or base_grand_total views (FX-converted) for the value picture.
Why does today’s number jump up and down so much?
Today is incomplete data. As the day rolls forward, orders accumulate, and as it crosses midnight some orders flip date because of timezone differences between the Store View and UTC. Use the rolling 7-day or 30-day view for stable numbers; that’s why the alert window is 30D vsP and not 1D.