At a glance
Distribution of orders by fulfillment state (new, processing, complete, closed, holded, etc.). The operational dashboard for warehouse managers and ops leads. Adobe Commerce’sstatemachine is the canonical lifecycle; this card decomposes it. The B2B-mixed nature of typical Adobe Commerce stores meanspending_paymentis often a large bucket (net-30 PO pipeline) rather than a problem signal.
Calculation
Worked example
A B2B-heavy industrial supply distributor on Adobe Commerce 2.4.6. 30-day window ending Monday 4 May 26. State distribution:
What this is telling operations:
- 31% of revenue ($310k) sits in
pending_payment. On a B2B-heavy store this is normal: net-30 POs and B2B-sales-approved orders awaiting AP processing. Cross-check the running average; if it’s stable at 28-32%, healthy. - 18.6% in
processingis the warehouse pipeline (paid, not yet shipped). - 8.2% in
payment_review($82k of revenue value) is fraud-review queue. This is unusually high; typical baseline is 1-3%. Investigate: is the fraud-rule sensitivity tuned too tightly? - 4.4% in
holdedis operations-paused orders (credit checks, custom-make awaiting approval). - 4.2% in
closedat $42k is post-RMA fully-refunded orders or specially-handled small orders. - 1.2% in
canceledis in the healthy range. - The
payment_reviewflag is the most actionable surprise. A fraud rule pause-rate of 8% means the rule is rejecting ~7% more orders than benchmark. Either the rule is over-sensitive (reduce sensitivity to recover legitimate orders) or the merchant is genuinely seeing a fraud campaign (validate via per-IP and per-card-BIN review). - Cross-checking Cancellation Rate: 1.2% is fine. If the
payment_reviewfraction was being auto-cancelled, cancellation rate would be 9%+. The merchant currently leaves them in review (manual ops review), which is conservative but adds operational load.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:Sales > Orders with the Status filter shows per-status counts; the State filter (Adobe Commerce 2.4.6+) shows canonical-state counts.
Reports > Sales > Orders with state grouping (newer Adobe versions).
Stores > Order Status to see the configured status-to-state mapping.For specific state subsets:
Sales > Orders with state = pending_payment filter for the AP/gateway pipeline.
Sales > Orders with state = holded for the credit-check queue.
Sales > Orders with state = payment_review for the fraud review queue.
Why our number may legitimately differ from Admin:
Cross-connector reconciliation (when these connectors are connected for this merchant):
Known limitations / merchant FAQs
Why ispending_payment so big on my store?
On B2B-heavy stores, net-30 POs sit in pending_payment until AP processes the invoice. 20-35% pending is typical. On consumer-only stores, pending_payment should be transient (gateway pre-authorisation lasting seconds-to-minutes); a high pending count there indicates webhook callback failures or net-30/wire-transfer routes the merchant should investigate.
Adobe Commerce vs Magento Open Source: difference?
None at the calculation. Both editions use the same 8-value state enum. Adobe Commerce paid edition’s B2B Companies module adds approval-flow lifecycle on top, but the state field itself is identical.
What’s the difference between this and Order State Breakdown?
Same underlying data. This card surfaces it primarily as count and revenue distribution; Order State Distribution often adds time-in-state analysis. Use the one that matches your question.
Why is payment_review separate from processing?
payment_review is Adobe’s fraud-review state; orders sit there awaiting manual review or fraud-rule decision. processing is paid-and-greenlit. The distinction matters operationally: warehouse picks processing orders; fraud-team handles payment_review.
My multi-store, can I see per-Store-View distribution?
Yes, configure per-Store-View variants. Useful when one Store View has different fraud rules or B2B-routing.
Why does closed show meaningful revenue?
Closed orders include refunded orders, post-RMA orders, and orders the merchant manually closed (typically because of refund or special handling). 2-5% revenue share in closed is normal.
The holded state has $44k of revenue, is that money at risk?
Possibly. holded means operations paused the order. If the hold is for credit-check (B2B), the revenue typically converts after AP review (low risk). If for fraud or supplier-stall, the order may eventually cancel. Audit hold reasons by clicking into individual orders.
Why does this card include cancelled orders?
Because it’s a workflow-distribution view. Other cards (Total Revenue, AOV) exclude cancellations because they’re not real revenue, but the workflow card is auditing the lifecycle and cancelled orders are part of it.