Commerce orders that never created a NetSuite Sales Order. Each row is a revenue-leak investigation.
At a glance
Alert table: every commerce-platform order older than 24 hours that has no corresponding NetSuite Sales Order. Each row is a revenue-leak investigation. The merchant fulfilled the customer (probably), the customer paid (definitely, since the gateway took the money), but NetSuite never received the SO and therefore never recognised the revenue, never created the AR, and probably never depleted the inventory. This is the single most useful alert for finance teams onboarding NetSuite to Vortex IQ; first-period investigation typically surfaces 20 to 200 orders worth £20k to £500k that the merchant had no idea were missing from their books.
| What it counts | LEFT JOIN(commerce.orders, netsuite.salesorders ON external_order_id) WHERE netsuite.id IS NULL AND commerce.order_age > 24h AND commerce.status NOT IN ('cancelled','draft'). Each row is one orphaned commerce order. |
| VAT / tax treatment | n/a; this is an order-level reconciliation. The dollar impact reported per row is the commerce order total (gross, customer-paid figure). |
| Shipping | Shipping is included in the dollar impact (since the customer paid for it and the GL doesn’t yet recognise it). |
| Discounts | Discounts already deducted (commerce-side post-discount total). |
| Refunds | Orders that were refunded on the commerce side don’t appear (they shouldn’t have a NS SO either). |
| Cancelled / voided orders | Excluded. The list is “active orders that should have an SO”. |
| Currency | Per-order in transaction currency, dollar-impact column in consolidation currency. |
| Channels / sources | Web by default (Shopify, BigCommerce, Adobe). POS, marketplace, and B2B portal can be included via manifest configuration. |
| 24h grace window | The 24-hour exclusion exists because most sync flows take 5 to 60 minutes; orders <24h old may simply be in-flight rather than failed. Configurable per merchant (some prefer 6h grace for tighter alerting). |
| Time window | RT (live snapshot of currently unmapped orders). |
| Alert trigger | >0 unmapped orders. Any non-zero count is meaningful. Healthy stores run zero or low single-digits. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your NetSuite 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 US wholesale distributor on NetSuite OneWorld + BigCommerce on the front-end. Snapshot 04 May 26. Headline: 142 unmapped orders, total dollar value $284,200. Top causes (Vortex IQ auto-categorisation):| Cause | Order count | Dollar value | Sample of underlying issue |
|---|---|---|---|
| Customer mapping failure | 78 | $182,400 | BigCommerce customer email doesn’t match any NS Customer record |
| SKU not in NetSuite | 32 | $48,200 | New product launched on BC before being mirrored to NS |
| Tax rate mapping error | 18 | $26,800 | New California zip code not mapped to NS tax code |
| Auth token expired | 8 | $14,200 | NetSuite TBA token rotated, sync silent-failed for 4 days |
| Multi-currency edge | 4 | $9,400 | EUR-priced order on US BC instance lost mapping |
| Other / manual review | 2 | $3,200 | Custom SKU on B2B account |
| Total | 142 | $284,200 |
- The 8 auth-token expired orders are the highest-priority urgent fix. Without resolution, the sync fails silently for ALL future orders too, not just these 8. Cause: the merchant’s NetSuite Token-Based Authentication credential rotated on 30 Apr 26 (annual rotation policy); the BC integration cached the old token and silently 401’d on every order since. First action: rotate the BC integration’s NS credential, then retry-create the 8 SOs. Recovers $14,200 + prevents future leakage.
- The 78 customer-mapping failures are the largest dollar group ($182,400). Investigation: the merchant uses email as the customer-mapping key. 78 orders have an email that does not match any active NS Customer record. Of those:
- 38 are net-new B2B accounts that were created on BC but never mirrored to NS (sales rep skipped the NS-side customer creation step for the BC self-signup flow). Action: create the 38 NS Customer records, retroactively map, retry-create SOs. Recovers $98,400.
- 28 are existing NS customers with a typo in the email (e.g. customer registered with
john at altipro dot com, NS hasjohn at alfipro dot com). Action: fuzzy-match cleanup, manually map. Recovers $62,200. - 12 are guest checkouts on BC where no email mapping was ever expected. Action: create one-off NS customer records labelled “Guest” with order-specific identifiers. Recovers $21,800.
- **The 32 missing-SKU orders (48,200.
- The 18 tax-rate mapping errors trace to a California zip code that was created in 2025 (San Diego split). NetSuite’s tax-rate table never received the new zip code. Action: add the zip-to-tax-rate mapping in NS, retry the SOs. Recovers $26,800.
- The 4 multi-currency edges and 2 other are 1-2% and need manual review. Recover $12,600.
- **Total recovery: 284,200 short of actual fulfilled revenue.
- Episodic spikes (50+ unmapped orders appear suddenly) signal a regression: a deployment, credential rotation, or NS workflow customisation broke the sync.
- Persistent low counts (5 to 15 sustained) signal structural process gaps that aren’t going away without an integration audit.
- Persistent high counts (>50 sustained) signal a fundamental sync architecture problem; consider re-architecting via middleware (Celigo, Boomi) rather than direct integration.
Sibling cards merchants should reference together
| Card | Why pair it with Commerce Orders Without NetSuite SO |
|---|---|
| Revenue Gap, Detailed Breakdown | The total cross-channel revenue gap; this card drills into the largest cause. |
| Revenue Gap vs Commerce | The dollar gap; this card is the operational drill. |
| Inventory Sync Drift | When orders don’t sync, inventory deduction also doesn’t sync; the two cards co-occur. |
| Open Sales Orders | The healthy SOs; this card is what should have been on that list. |
| Revenue Gap Spike Alert | Fires when this card’s count suddenly increases. |
shopify.order_count | The numerator of the cross-platform comparison. |
bigcommerce.order_count | Same for BigCommerce. |
adobe_commerce.order_count | Same for Adobe Commerce. |
Reconciling against the vendor’s own dashboard
Where to look in NetSuite’s own dashboard: NetSuite cannot show this card. By definition it lists orders that don’t exist in NetSuite. The closest you can do in NS alone:- Pull the list of NS Sales Orders for the period.
- Pull the list of commerce orders for the same period from the commerce platform.
- Diff manually.
| Reason | Direction | Why |
|---|---|---|
| 24h grace window | Vortex IQ shows fewer | Orders <24h old are excluded as “in-flight”. Manual check at any timestamp will include them. |
| Cancelled commerce orders | Vortex IQ excludes | Cancelled orders shouldn’t have a NS SO; manual diff would surface them as false positives. |
| Mapping key | Material | Vortex IQ uses commerce-order-ID as the join key by default; some merchants use a custom external ID. Configurable. |
| Multi-store / multi-channel | Either | Multiple commerce instances mapping to one NS tenant need explicit scope; otherwise legitimate orders from instance B may falsely appear unmapped against instance A’s filter. |
Known limitations / merchant FAQs
One unmapped order: how worried should I be? Investigate, don’t panic. A single order can be a transient sync issue (gateway-timeout retry that didn’t complete). If it persists for 48+ hours, it’s a real failure. Resolve it; if the cause is identifiable (auth, mapping, SKU), fix the cause to prevent recurrence. 100+ unmapped orders appeared overnight. What just happened? Almost always a regression: an auth-token rotation that broke sync, an NS workflow customisation that started rejecting SO creates, a Shopify store-front change that altered the webhook payload. Open the Revenue Gap Spike Alert for the timestamp; cross-reference deployments and configuration changes around that time. Can I auto-create the SOs from this list? Yes for some causes. Vortex IQ supports a “retry-create SO” action via Ask Viq for orders where the cause is non-data (auth fixed, SKU now exists). For data-cause orders (customer mapping, tax mapping), the underlying mapping must be fixed first; retry without fix re-fails. My commerce platform shows the order as fulfilled. How can NS not have it? Because the fulfilment flow is independent of the SO-create flow on most integrations. The shipping label was printed, the carrier picked it up, the customer received the goods, but the integration never created the SO in NS. NS shows neither revenue nor inventory deduction; the merchant is operating on Shopify’s view of inventory but writing in NS’s view in the GL. Why can’t NetSuite tell me this on its own? Because NS only sees what NS receives. An order that never reached NS is invisible to NS reports. Cross-platform visibility requires both sides; that’s the value of the join. My middleware (Celigo, Boomi, MuleSoft) said it synced everything. Why does this card show 50 unmapped? Middleware vendors track “did the API call succeed?”, not “is the SO actually in NS?”. A middleware can succeed at calling NS while NS rejects the SO downstream (validation failure, workflow rejection, lock condition). The middleware’s logs will show success; NS will not have the SO. Trust the data, not the logs. The 24h grace window means I always miss yesterday’s orders. Can I shorten it? Yes, configurable per merchant. Some merchants use 6h or even 1h grace for tight alerting, accepting the noise of catching genuine in-flight orders. Default 24h reflects the typical sync window for most integrations; tighten if your sync is faster. Per-channel split: I want B2B portal separately. Configurable. Most merchants want web-Shopify and B2B-Shopify-Plus-B2B in separate buckets because the sync flows are different. Per-channel manifest entries handle this. Why do I see new unmapped orders even after I fixed the underlying issue? The fix only affects new orders going forward. Orders that failed before the fix remain unmapped until you retry-create them (Vortex IQ provides a bulk-retry action). Run the retry once after each fix to clear the backlog. My OneWorld account: do I see per-subsidiary? Yes. Each commerce instance maps to one NS subsidiary by default (configurable). The card splits by subsidiary so the controller can route the alert to the right regional finance team. The dollars on this card don’t match the dollars on the Revenue Gap card. Why? Because Revenue Gap is a period-bounded comparison and this card is real-time. They reconcile within a day’s drift. Use Revenue Gap for finance reporting; use this card for operational triage. A single order shows up here repeatedly even after I fixed it. What’s wrong? Most likely the retry-create posted a duplicate SO with a different external ID. Vortex IQ can’t match the new SO back to the original commerce order. Fix the mapping by editing the new SO’sexternalid field to match the commerce order ID.