Skip to main content
Card class: Non-HeroCategory: Ecommerce Platform

At a glance

Distribution of orders by financial status (status field). Adobe Commerce uses configurable status labels layered on top of the state machine; merchants commonly extend the default list with custom statuses (e.g. “Awaiting Wire Transfer”, “Net-30 Pending”, “Sales Approved”). The card surfaces the active distribution so finance and operations can audit the workflow.
What it countsCOUNT(orders) GROUP BY status over the trailing 30 days, with revenue (SUM(grand_total)) per status. Returns the status distribution as count and dollar share.
API fieldstatus (configurable label) and state (canonical lifecycle) from GET /rest/V1/orders.
VAT / tax treatmentn/a for the count; revenue series uses grand_total (tax-inclusive on B2C).
Shipping inclusionIncluded via grand_total.
DiscountsDeducted via grand_total.
Credit Memo refund treatmentAn order can have a custom status like “Partially Refunded” if the merchant configured it; the card sees whatever label is current.
state machine inclusionAll states. The card distinguishes status from state explicitly, surfacing the mapping.
pending_payment quirkA pending_payment state may have a custom status like “Awaiting Bank Wire” or “Net-30 PO Submitted”; the card preserves the custom label.
Multi-currency grand_total vs base_grand_totalRevenue uses base_grand_total.
Store View scope (store_id)All Store Views; per-Store-View variants useful when status workflows differ by region.
Time window30D
Alert triggerNone by default.
Rolesowner, operations

Calculation

GROUP BY status
  WHERE date BETWEEN [period_start, period_end]

Worked example

A B2B-heavy industrial supply distributor on Adobe Commerce 2.4.6. Custom statuses configured per the merchant’s workflow. 30-day window ending Monday 4 May 26. Status distribution:
Status (custom)State (canonical)Order countRevenue% of revenue
Sales Approvedprocessing412$310,00031%
Awaiting Wire Transferpending_payment168$124,00012.4%
Net-30 Pendingpending_payment72$186,00018.6%
Shippedcomplete1,820$282,00028.2%
Closedclosed246$42,0004.2%
Canceledcanceled88$12,0001.2%
Holded for Credit Checkholded32$44,0004.4%
Total2,838$1,000,000100%
What this is telling operations and finance:
  1. Custom workflow visibility. This merchant has 7 active status labels mapped onto 5 canonical states. The card surfaces both, so operations can audit which custom labels are in use.
  2. 31% of revenue is in “Sales Approved” but not yet shipped. This is the operational pipeline; warehouse should prioritise.
  3. 12.4% in “Awaiting Wire Transfer” + 18.6% in “Net-30 Pending” = 31% of revenue waiting on payment. For B2B distribution this is normal (net-30 invoicing); the merchant’s cash-flow forecasts depend on aging this pipeline.
  4. 4.4% “Holded for Credit Check” ($44k) is the credit-review queue. A back-office task; operations should ensure this doesn’t accumulate.
  5. 1.2% “Canceled” is in the healthy range; cross-check Cancellation Rate for the trend.
  6. Cross-checking Order State Distribution which shows canonical states only: the same data appears as 4 buckets there (processing, pending_payment, complete/closed combined, canceled, holded). The 7-status custom view here is more useful for operations workflow tracking; the canonical view is more useful for cross-platform comparison.

Sibling cards merchants should reference together

CardWhy pair it with Financial Status
Order State DistributionThe canonical-state companion.
Cancellation RateThe cancellation slice tracked over time.
Total RevenueThe aggregate.
Total OrdersThe aggregate count.
B2B Revenue ShareB2B-specific statuses (Net-30) drive much of the distribution.
Unfulfilled OrdersOperational pipeline subset.
shopify.financial_statusCross-platform peer (Shopify uses paid/pending/refunded etc.).

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 grid total updates as filters apply.
Stores > Configuration > Sales > Sales > Order Status lists all configured statuses and their state mappings.
Reports > Sales > Orders with date range and grouping by status (Adobe Commerce 2.4.4+).
For workflow audit:
Stores > Order Status lists every status, custom label, and which state it maps to.
Why our number may legitimately differ from Admin:
ReasonDirection of divergence
Status vs State. Card surfaces both; Admin grid filter is by status. If a custom status was renamed, the card sees the new label; saved filters or reports may reference the old.Material if rename is recent
Time-zone. Admin in Store View timezone; card UTC.Boundary effects
Currency. Card uses base_grand_total for revenue. Admin uses Store View base.Material on multi-currency
Sync lag. Card uses OpenSearch sync (5-15 min); Admin live.Negligible
Cross-connector reconciliation (when these connectors are connected for this merchant):
PairExpected relationshipWhat divergence tells you
ERP / accounting statusERP statuses often less granular than Adobe custom statusesMap Adobe custom status to ERP at sync time; track which Adobe statuses don’t have ERP equivalents.
stripe.stripe_chargesStripe-paid orders should be in processing or later stateMaterial gap means Stripe-captured but Adobe shows pending; webhook callback issue.

Known limitations / merchant FAQs

What’s the difference between status and state in Adobe Commerce? state is the canonical 8-value lifecycle (new, pending_payment, processing, complete, closed, canceled, holded, payment_review). status is a configurable label that maps to a state. A merchant can have 20 custom statuses (“Sales Approved”, “Awaiting Wire”, “Pick Started”, “Quality Check”) all mapped to state = processing. The card surfaces both. Adobe Commerce vs Magento Open Source: difference? Both editions have configurable status. Open Source merchants typically have fewer custom statuses (no built-in B2B workflows); Adobe Commerce paid edition’s B2B Companies module may add approval-flow statuses (Awaiting Approval, Approved, Rejected). My status names look weird, why? The card preserves whatever the merchant has configured in Stores > Configuration > Sales > Order Status. Custom names persist; abbreviations and historical labels appear here. Why are pending_payment orders worth tracking? On B2B-heavy stores they represent net-30 PO pipeline (genuine future revenue). On consumer stores they may indicate gateway issues. The financial_status card lets you distinguish: a B2B-tagged custom status like “Net-30 Pending” is healthy pipeline; a status like “Stripe Failed” sitting in pending_payment is a gateway problem. My multi-store, can statuses differ per Store View? Adobe Commerce statuses are global, not per-Store-View. A status defined for the consumer Store View applies on all. For per-Store-View routing, use Customer Group filtering on rules instead. A custom status was renamed; do historical records update? Adobe Commerce status changes apply going forward. Historical orders keep the label they had at order time. The card sees current labels, so a rename creates a brief “two labels for the same state” period. Most stabilises within 7-14 days. Why do complete and closed look similar? complete = order shipped and invoiced; closed = the merchant has closed the order (typically because it’s fully refunded or no further action expected). On many stores they look similar; on stores using Adobe RMA module, closed may dominate post-RMA. Why does the card include cancelled orders in the distribution but other cards exclude? This card is auditing the workflow distribution; cancellations are part of that. Other cards (Total Revenue, AOV) exclude cancellations because they’re not real revenue.

Tracked live in Vortex IQ Nerve Centre

Financial Status Breakdown is one of hundreds of KPI pulses Vortex IQ tracks across Adobe Commerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.