> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Cancellation Rate, Salesforce Commerce Cloud > Cancellation Rate, the share of orders moved to CANCELLED status. A fast read on checkout, payment, and fulfilment friction. How to read it, why it matters, and how to act on it. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Share of orders moved to CANCELLED status. A fast read on checkout, payment, and fulfilment friction. ## At a glance > The proportion of Salesforce Commerce Cloud (SFCC, formerly Demandware) orders that ended up in `CANCELLED` status during the period, computed as `COUNT(orders WHERE status = CANCELLED) ÷ COUNT(orders)`. Cancellations are not refunds: a cancellation voids an order before fulfilment completes, whereas a refund reverses money on a shipped order. Watch both, but treat them as separate signals. | | | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | `COUNT(orders WHERE status = CANCELLED) ÷ COUNT(orders)` over the window, pooled across every site (`siteId`) and locale in the realm. SFCC sets an order to `CANCELLED` when a shopper, a CS agent in Business Manager, or an automated job voids it before fulfilment. | | **Why it matters** | A rising cancellation rate is one of the earliest, cheapest signals of friction: a payment-authorisation problem, a fraud-screening rule that is too aggressive, a stock-sync error that oversells, or a pricing / promotion bug that customers spot at checkout. It moves before refunds do, because cancellation happens pre-fulfilment. | | **Reading the value** | A gauge from 0% upward. Lower is better. The realm-wide rate is dominated by the highest-volume site, so per-site reads are the right operational granularity. | | **Cancellation vs refund** | A cancellation voids an order in the order workflow (`status = CANCELLED`); a refund reverses payment on an order that was fulfilled, tracked on separate Return / Credit Memo objects. Use [Refund Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/refund-rate) for the post-fulfilment leakage layer. The two rarely move together. | | **What counts as cancelled** | Any order SFCC marks `CANCELLED`, whether triggered by the shopper, a CS agent, a fraud-screening LINK cartridge, or a scheduled job that voids unpaid `CREATED` orders. `FAILED` orders (payment-gateway hard failures) are a separate status and are not counted here, see [Failed Orders (24h)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/failed-orders-24h). | | **Currency** | n/a, this is an order-count ratio. The denominator pools orders across every currency and locale on the realm. | | **Channels / sources** | **Multi-site by design.** B2B trade portals (typically very low cancellation) and DTC sites (higher, especially where COD or manual-review fraud rules apply) pool together. Per-site filtering is the right operational view. | | **Unit** | Percent | | **Time window** | `30D vsP` (default 30 days vs the prior 30 days) | | **Alert trigger** | `>3%`, driven by `sentiment_key: scc_cancellation_rate` | | **Sentiment key** | `scc_cancellation_rate` | | **Roles** | owner, operations | ## Calculation Calculated automatically from your Salesforce Commerce Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A Fortune-500 fashion retailer running on Salesforce Commerce Cloud B2C, four DTC sites and one B2B portal. The 30-day window covers 14 Mar 26 to 12 Apr 26. Order data read via SCAPI / OCAPI; statuses confirmed in Business Manager Order Search. | `siteId` | Site / locale | Orders | Orders `CANCELLED` | Cancellation Rate | vs prior 30D | | -------------------------------- | ---------------- | ----------- | ------------------ | ----------------- | --------------- | | `RefArch-US` | US DTC, en\_US | 184,200 | 3,130 | 1.7% | 1.6% (up 0.1pp) | | `RefArch-UK` | UK DTC, en\_GB | 62,400 | 1,310 | 2.1% | 2.0% (flat) | | `RefArch-DE` | DE DTC, de\_DE | 41,800 | 1,090 | 2.6% | 2.5% (flat) | | `RefArch-JP` | JP DTC, ja\_JP | 28,600 | 1,830 | 6.4% | 3.1% (up 3.3pp) | | `RefArch-B2B` | B2B trade portal | 1,420 | 6 | 0.4% | 0.4% (flat) | | **Realm-wide (volume-weighted)** | | **318,420** | **7,366** | **2.3%** | **1.9%** | Three things to notice: 1. **The realm headline (2.3%) sits below the `>3%` alert, but JP is the story.** The Japan site jumped from 3.1% to 6.4% in 30 days, a 3.3pp move that the volume-weighted realm reading almost completely hides. This is the recurring lesson on SFCC: the realm-wide gauge is dominated by the highest-volume site (`RefArch-US`), so per-site panels are where the operational signal lives. Pin JP as its own panel. 2. **A cancellation spike on one site usually has one of three causes.** (a) **Payment-authorisation friction**, a PSP rule change or a new 3-D Secure flow in CyberSource / Adyen that drops shoppers at the auth step, leaving `CREATED` orders that a scheduled job later voids. (b) **Oversell from a stock-sync gap**, the inventory record showed available-to-sell but the warehouse could not fulfil, so CS cancels. (c) **A fraud-screening rule** in a LINK cartridge tuned too aggressively for a specific locale. For JP, the COD-heavy market and stricter fraud rules make (a) and (c) the usual suspects. 3. **B2B cancellation (0.4%) is structurally low and should stay there.** Trade orders are buying-team-vetted, scheduled, and often contractually non-cancellable. A B2B cancellation rate climbing above 1% points at a process failure (wrong account pricing, a broken approval workflow), not shopper behaviour. 4. **Cancellation and refund are different leaks.** This realm runs a 12.9% refund rate (see [Refund Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/refund-rate)) and a 2.3% cancellation rate. They do not move together: refunds spike on quality / sizing issues after delivery; cancellations spike on payment / stock / fraud friction before fulfilment. Reading them as one number masks both. ## Sibling cards merchants should reference together | Card | Why pair it with Cancellation Rate | | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Refund Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/refund-rate) | The post-fulfilment counterpart. Cancellations void before shipping; refunds reverse after. A site with low cancellation but high refund has a quality / sizing problem, not a checkout problem. | | [Failed Orders (24h)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/failed-orders-24h) | `FAILED` and `CANCELLED` are adjacent failure modes. A payment-gateway issue often shows first as failed orders, then as a wave of cancellations when scheduled jobs void the stuck `CREATED` orders. | | [Pending Orders (created/new/open)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/pending-orders-creatednewopen) | Cancellations frequently come out of the pending pool. A backlog of `CREATED` orders that never get paid converts to cancellations downstream. | | [Payment Status Distribution](/nerve-centre/kpi-cards/salesforce-commerce-cloud/payment-status-distribution) | If cancellation is climbing because of payment friction, the not-paid / authorised share moves first. Read them together to confirm the root cause is payment. | | [Total Orders](/nerve-centre/kpi-cards/salesforce-commerce-cloud/total-orders) | The denominator. A cancellation-rate move is only meaningful against the order base; the same percentage on a 200k-order realm is a very different absolute number from a 2k-order one. | | [Conversion Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/conversion-rate) | A fraud rule or auth flow tightened to cut cancellations can also cut conversion at checkout. Watch the pair after any payment or fraud change. | ## Reconciling against Salesforce Commerce Cloud **Where to look in Business Manager:** SFCC's admin tool is **Business Manager**, reached at a per-realm URL like `https://.business.demandware.net`. The most direct way to verify this card is **Merchant Tools, Ordering, Order Search**, filter **Status = Cancelled** for a single site and the same date range, then divide by total orders in that window. For a reporting view, **Merchant Tools, Site, Reports & Dashboards, Operations** breaks orders down by status. Other Business Manager views that *look* like the same number but aren't: * **Order Search filtered to `FAILED`**: payment hard-failures, a different status, counted by [Failed Orders (24h)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/failed-orders-24h), not here. * **Reports & Dashboards, Returns**: returns / refunds, the post-fulfilment leak, not cancellations. * **Custom order-status workflows**: some realms add custom statuses on top of the standard set; confirm a custom "cancelled-equivalent" status is mapped before comparing. **Why our number may legitimately differ from Business Manager:** | Reason | Direction of divergence | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | **Time-zone**. Business Manager Order Search and reports run in the site's configured time zone; Vortex IQ runs on UTC by default. Boundary days shift. | ±1 day at boundary | | **Site filter scope**. Business Manager defaults to the currently-selected site; Vortex IQ pools every site unless filtered. | Direction depends on per-site mix | | **Custom status mapping**. Realms with custom order-status workflows may label a cancellation under a non-standard status that Business Manager reports separately. | Vortex IQ may read lower until the custom status is mapped | | **`FAILED` vs `CANCELLED`**. Some merchants treat payment-failed orders as cancellations in their mental model; this card keeps them separate per SFCC's status field. | Vortex IQ lower than a "failed + cancelled" hand count | | **Window anchor**. This card anchors the numerator on the order's cancellation event date and the denominator on confirmation date, a slight lag after a cancellation spike. | Either, small except right after a spike | | **Order export lag**. SFCC's Reports & Dashboards warehouse runs 5 to 30 minutes behind real-time; SCAPI / OCAPI is near-real-time. | Vortex IQ slightly higher for current-day data |
Same-metric documentation cross-reference (for agencies running multiple platforms) The same Cancellation Rate definition lives on other commerce platforms. This is **not a reconciliation**, your SFCC realm does not have a parallel store elsewhere to compare against. These cross-links exist so agencies running multi-platform client books can navigate between identical metrics across the docs. * [`adobe_commerce.cancellation_rate`](/nerve-centre/kpi-cards/adobe-commerce/cancellation-rate), closest enterprise-tier peer * [`shopify.cancellation_rate`](/nerve-centre/kpi-cards/shopify/cancellation-rate) * [`bigcommerce.cancellation_rate`](/nerve-centre/kpi-cards/bigcommerce/cancellation-rate)
## Known limitations / merchant FAQs **What is the difference between a cancellation and a refund on SFCC?** A cancellation voids an order before fulfilment completes and sets `status = CANCELLED`. A refund reverses money on an order that was fulfilled and is tracked on separate Return / Credit Memo objects. They are different layers and rarely move together: cancellations spike on payment, stock, or fraud friction at or just after checkout; refunds spike on quality and sizing issues after delivery. This card measures only the cancellation layer; use [Refund Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/refund-rate) for the other. **Why is my cancellation rate climbing this month?** Three usual causes in order. (1) **Payment-authorisation friction**, a PSP rule change, a new 3-D Secure flow, or an expired credential in a CyberSource / Adyen LINK cartridge leaving `CREATED` orders unpaid until a scheduled job voids them. (2) **Oversell from a stock-sync gap**, the inventory record showed available-to-sell but the warehouse could not fulfil, so CS cancels. (3) **A fraud-screening rule** tuned too aggressively for a locale. Check [Payment Status Distribution](/nerve-centre/kpi-cards/salesforce-commerce-cloud/payment-status-distribution) first to confirm or rule out payment. **Does this include `FAILED` orders?** No. `FAILED` is a distinct SFCC status for hard payment-gateway or fraud-screening failures, counted by [Failed Orders (24h)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/failed-orders-24h). This card counts only `CANCELLED`. The two are adjacent, a gateway outage often shows first as failed orders and then as a wave of cancellations when jobs void the stuck orders, so read them together. **Does this include B2B cancellations?** Yes. B2B and DTC orders share the same Order object and status field, so B2B cancellations are pooled in. B2B cancellation rates are structurally very low (trade orders are vetted and often contractually non-cancellable), so they pull the realm rate down. Filter out the B2B `siteId` for a DTC-only view. **What is a "good" cancellation rate on SFCC?** Category and market dependent, but useful rough benchmarks: DTC sites in card-paying Western markets typically run 1 to 3%; markets with cash-on-delivery or stricter fraud rules can run materially higher; B2B trade portals usually sit well below 1%. The `>3%` alert is a reasonable cross-category default; tune per-site for markets where COD or fraud rules push the baseline up. **Why does Business Manager show a different cancellation rate?** Usually one of three reasons. (1) **Site-scope**, Business Manager defaults to one site while this card pools the realm. (2) **Time-zone**, Business Manager uses site-local time while the card uses UTC, so boundary days shift. (3) **Custom status mapping**, realms with custom order workflows may file cancellations under a non-standard status. Confirm all three before treating a gap as an error. **My cancellation rate dropped suddenly. Is that always good?** Not always. A sudden drop can mean a fraud rule was relaxed too far (watch chargebacks and [Refund Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/refund-rate) downstream), or that a scheduled job which voids unpaid `CREATED` orders stopped running, in which case the cancellations are simply piling up as pending orders instead. Pair this card with [Pending Orders (created/new/open)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/pending-orders-creatednewopen) to tell the two apart. **Can a customer-initiated cancellation and a CS-agent cancellation be told apart?** Both end up as `CANCELLED` in the status field, so this card pools them. SFCC records the actor and reason on the order's modification history in Business Manager, which is where you go to diagnose a spike: a wave of self-service cancellations from one locale points at checkout or pricing friction; a wave of CS cancellations points at stock or fulfilment. *** ### Tracked live in Vortex IQ Nerve Centre *Cancellation Rate* is one of hundreds of KPI pulses Vortex IQ tracks across Salesforce Commerce Cloud 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.