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.
| What it counts | COUNT(*) of every order row in the Adobe Commerce orders index where created_at falls inside the period. The Adobe Commerce REST endpoint is GET /rest/V1/orders; one row per entity_id. |
| API field | The order document itself. There is no monetary aggregation, the count is on the document _id (mapped to Adobe Commerce entity_id). |
| VAT / tax treatment | n/a, this is a count of order documents, not a money figure. Tax inclusion is irrelevant. |
| Shipping | n/a. Shipping is a money concept; this is a count. |
| Discounts | n/a, but worth noting: a 100%-off promo order still counts here. A free-with-coupon order is one order. |
| Credit Memo refund treatment | NOT excluded. Adobe Commerce holds refunds on separate Credit Memo documents; the underlying order document still exists and is still counted here. A fully refunded order is still one order in this card. |
state machine inclusion | All states included by default. That covers new, processing, complete, closed, canceled, holded, pending_payment, and payment_review. The Adobe-specific quirk is pending_payment: orders sit there when the shopper hit Place Order but the gateway never returned a result. They count here even though no cash was collected. To get a “realised orders” count, filter state IN (processing, complete, closed). |
status distinction | state is the system-level lifecycle (8 fixed values). status is a configurable, user-facing label that maps onto state, merchants rename “processing” to “Order Confirmed” or add custom statuses. This card uses state-based logic only; merchant-renamed statuses don’t change the count. |
Multi-currency grand_total vs base_grand_total | n/a for the count itself. Worth calling out: a single B2B order at 4 sticker order both contribute one to this card. Pair with Total Revenue for the value view. |
Store View scope (store_id) | All Store Views summed by default. Orders from US, UK, DE, B2B portals, and any headless storefront are all counted together. Filter by store_id for a per-region view, or use Revenue by Store View for a value-weighted breakdown. |
| Time window | T/7D/30D vsP (default 30D vs the prior 30D) |
| Alert trigger | drop >20% vsP, driven by sentiment_key: order_count_trend |
| Roles | owner, marketing, operations |
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.store_id | Store View | Orders in window | Of which state = pending_payment | Of which state = canceled |
|---|---|---|---|---|
1 | US storefront | 1,840 | 62 | 41 |
2 | UK storefront | 612 | 18 | 9 |
3 | B2B wholesale portal | 41 | 0 | 1 |
| Total Orders (this card) | 2,493 | 80 | 51 |
- 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:| Card | Why pair it with Order Count |
|---|---|
| Total Revenue | The numerator partner. Together they answer “did revenue move on volume or basket size?”. Identical movement on both = volume change; revenue moves while orders flat = basket size change. |
| Average Order Value | Mathematical sibling: AOV = Total Revenue ÷ Order Count. If Order Count rose and AOV fell, you grew on lower-value baskets (often new-customer surge). |
| Cancellation Rate | The proportion of these orders that ended in state = canceled. A creeping cancellation rate hides inside a healthy-looking Order Count headline. |
| Refund Count | Number of orders that produced at least one Credit Memo. Pair as % of orders for refund rate. |
| Order State Distribution | Breaks this single number into processing, complete, canceled, holded, pending_payment. Surfaces the pending_payment quirk visually. |
| Revenue by Store View | Per-store_id revenue. Combine with a per-Store-View order count to spot which region drove a headline change. |
stripe.stripe_charge_count | Count of successful Stripe charges. Should sit at or below this card (Stripe never sees pending_payment, canceled, or non-Stripe-processed orders). |
google_analytics.ga_purchases_trend | GA4 purchase events. Typically 10, 25% lower than this card due to ad blockers and consent rejection. |
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.
| Reason | Direction of divergence |
|---|---|
| Time-zone. Adobe Commerce Admin renders the order grid in the Store View timezone configured under Stores > Configuration > General > Locale Options. Vortex IQ aggregates on UTC by default. Orders near midnight on the boundary days fall on different sides. | ±1 day’s orders at the boundary |
| Store View scope. The Adobe Commerce order grid filter typically defaults to the admin user’s assigned scope (e.g. only the UK Store View). Vortex IQ sums across every Store View unless filtered. Set the admin scope dropdown to All Store Views for a like-for-like read. | Vortex IQ higher than per-view admin filter |
canceled state. The order grid includes canceled rows by default (Status filter “All Orders”). Some merchants set their default filter to exclude canceled. This card always includes them. | Vortex IQ higher than filtered admin grids |
pending_payment. Included here, included in the admin grid by default. | Match (no divergence) |
Currency irrelevance. Order Count doesn’t depend on grand_total vs base_grand_total, so the two views agree on currency-multi stores. | No divergence on this axis |
| API rate-limit gaps during sync. Adobe Commerce REST has request quotas; if the indexer hit rate-limit during the most recent sync, the latest few minutes of orders may be missing. | Self-resolves at next sync, typically within 15 minutes |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_charge_count | Stripe ≤ Adobe Commerce Order Count | Stripe sees only successfully captured charges. Excludes Adobe Commerce pending_payment (gateway never returned), canceled, holded, and any orders routed through a non-Stripe processor (Authorize.Net, Braintree, PayPal, gift cards, manual payment). |
paypal.pp_transaction_count | PayPal ≤ Adobe Commerce Order Count | PayPal sees only PayPal-checkout orders. Subset by definition. |
google_analytics.ga_purchases_trend | GA4 typically ~75-90% of Adobe Commerce Order Count | GA4 misses purchase events from ad-blocked, consent-rejecting, or tag-fail browsers. Treat Adobe Commerce as the source of truth for order count. Use GA4 to understand traffic source, channel, and device, not to count orders. |
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.