Real-time alert when sales marks a deal won but no matching commerce transaction posts. Either a CRM data-entry error or ecom integration drift, and a revenue-recognition gap either way.
At a glance
Deal Close-Won Without Matching Ecom Order is a real-time anomaly alert. It fires when a HubSpot deal moves to closed-won but no corresponding commerce order is found for the same contact within a short following window. That mismatch is a revenue-recognition gap with two common causes: a salesperson marked the deal won prematurely or by mistake (CRM data-entry error), or the deal genuinely closed but the commerce-side order never synced back into the system (integration drift). Either way, the books say one thing and the store says another, and finance needs to know before the period closes.
| What it counts | The count of HubSpot deals that entered closed-won in the trailing 24 hours for which no matching commerce-platform order exists from the same contact within the following 7 days. Each alert row carries the deal name, amount, owner, close date, associated contact, and the match-search result. |
| Match logic | A deal is matched to a commerce order by the associated contact’s email against the order’s customer email. Where a deal carries a company association, company-domain matching is used as a secondary check. No match on either means the deal is flagged. |
| Why the 7-day grace | Commerce orders sometimes post a few days after a deal is marked won (invoice paid later, fulfilment-triggered order creation). The 7-day look-forward avoids false alarms on legitimately-delayed orders while still catching genuine gaps quickly. |
| Deal scope | Closed-won deals only. Open deals, closed-lost deals, and deals in non-revenue pipelines (for example a support or onboarding pipeline) are excluded; configure which pipelines count as revenue in the profile. |
| Commerce sources | Matches against connected commerce platforms (Shopify, BigCommerce, Adobe Commerce) and against Stripe charges or paid invoices where the merchant bills through Stripe. |
| Currency | currency for the deal amount displayed; the alert itself is a count. |
| Time window | RT (real time). Re-evaluated as deals close and as orders sync. |
| Alert trigger | More than zero deals closed-won in the last 24 hours with no matching commerce order from the same contact within 7 days. |
| Roles | owner, finance, operations. Finance owns revenue recognition; operations owns the integration that should be syncing orders; the owner needs the number for an accurate revenue read. |
Calculation
Calculated automatically from your HubSpot 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 B2B coffee-equipment supplier running Sales Hub for wholesale deals and a BigCommerce storefront for self-serve reorders. Most wholesale deals close as a manual order keyed into BigCommerce by the account manager. Reading on 21 Apr 26 over the trailing 24 hours. Four deals went closed-won yesterday. The card flags two of them:| Deal | Amount | Owner | Matching ecom order within 7d? | Flagged? |
|---|---|---|---|---|
| Cafe Rosso reorder | $4,200 | A. Patel | Yes, BigCommerce order placed same day | No |
| Northside Roasters Q2 | $11,800 | J. Lee | No order found | Yes |
| Harbour Beans starter kit | $2,650 | A. Patel | No order found | Yes |
| Tideline Coffee top-up | $1,900 | S. Okoro | Yes, order posted 2 days later | No |
- Northside Roasters Q2 ($11,800) is integration drift. The account manager did key the order into BigCommerce, but the contact’s email on the HubSpot deal (a personal Gmail) does not match the email on the BigCommerce order (the company’s accounts inbox). The order exists; the match failed. The fix is to align the contact email or add the accounts inbox as a secondary email on the contact.
- Harbour Beans starter kit ($2,650) is a data-entry error. The deal was marked won by mistake during a pipeline cleanup; the customer never actually paid. There is no order because there is no sale. The deal should be moved back to its real stage. This is exactly the kind of phantom revenue that inflates a forecast.
- The two clean deals show the grace window working. Tideline’s order posted 2 days after the deal closed; without the 7-day look-forward it would have been a false alarm on the close day.
- The dollar amounts matter for triage. The 2,650 phantom is a smaller correction but still phantom revenue.
- Two different teams own the two fixes. The email-mismatch flag is an operations and data-hygiene fix; the phantom-win flag is a sales-process fix. The card surfaces both under one signal, which is why finance, operations, and the owner are all on the roles list.
Sibling cards merchants should reference together
This alert is the revenue-integrity guard between the CRM and the store. Pair it with these to close the loop:| Card | Why pair it with Deal Close-Won Without Matching Ecom Order |
|---|---|
| Pipeline-vs-Realised Revenue Gap | The aggregate version of this alert. This card flags individual mismatched deals; that card shows the total gap between booked and realised revenue. |
| Lifecycle Stage vs Ecom Revenue | The contact-level mirror. A closed-won deal with no order often sits on a contact whose lifecycle says “customer” but whose ecom revenue is zero. |
| Top Customers Without HubSpot Contact | The opposite drift: orders that exist with no CRM record. Together the two cards bound the sync-quality problem from both sides. |
| Top 10 Deals by Amount | Context for severity. If a flagged deal is also a top-10 deal by amount, the revenue-recognition risk is material. |
| Deal Win Rate (30d) | Phantom wins inflate win rate. A run of unmatched closed-won deals can make win rate look better than the cash reality. |
| Total Revenue | The reconciliation anchor. Unmatched deals are the line items that explain why CRM-reported and store-reported revenue diverge. |
Reconciling against HubSpot
Where to look in HubSpot: HubSpot knows when a deal closed-won but has no native view of whether a commerce order followed, because order data lives in the store, not the CRM. The closest individual views:HubSpot → Sales → Deals filtered to Deal stage is Closed won and Close date is in the last 24 hours. HubSpot → CRM → Contacts to open the associated contact and confirm the email used for matching. Store admin (Shopify Admin → Orders, BigCommerce → Orders, Adobe Commerce → Sales → Orders) or Stripe Dashboard → Payments to confirm whether an order or charge actually posted.The merchant traditionally reconciles by exporting closed-won deals and exporting orders, then joining on email by hand at month-end. This card runs that join continuously and flags the gaps as they appear. Why a flag may be a false alarm rather than a real gap:
| Reason | Direction | Why |
|---|---|---|
| Email mismatch | False flag | The deal’s contact email differs from the order’s customer email (personal vs accounts inbox, alias, typo). The order exists; the match failed. Align the emails to clear it. |
| Order posted after the grace window | Late-clearing flag | An invoice paid 8+ days after the deal closed posts outside the 7-day look-forward and flags until the next evaluation catches it. |
| Non-revenue pipeline misconfigured | False flag | A deal in a pipeline that should not expect an order (onboarding, renewal-without-charge) flags if that pipeline is not excluded in the profile. |
| Manual order keyed under a different contact | False flag | The account manager created the order against a different store customer than the one on the deal. The revenue is real; the link is wrong. |
| Genuine phantom win | True flag | The deal was marked won in error and no payment exists. This is the case the card is built to catch. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
| Shopify Total Revenue | The sum of matched closed-won deal amounts should reconcile against store revenue for the same contacts. | Self-serve store orders with no deal at all are revenue Shopify counts and the CRM never booked; that is expected and not flagged by this card. |
| Pipeline-vs-Realised Revenue Gap | The total dollar value of flagged deals should roughly equal the unexplained portion of the realised-revenue gap. | Timing differences (orders posting just outside the grace window) shift small amounts between the two reads. |
Known limitations / merchant FAQs
A deal got flagged but the order definitely exists. Why? Almost always an email mismatch. The card matches a deal’s contact email to the order’s customer email. If the customer placed the order under a personal address but the CRM contact uses the company accounts inbox, the join fails even though both records are real. Add the second email to the contact or correct the order’s email and the flag clears on the next evaluation. Why a 7-day window? Some of our orders post later than that. Seven days catches the overwhelming majority of legitimately-delayed orders while still surfacing genuine gaps quickly. If your business routinely invoices on net-14 or net-30 terms where the paid order posts much later, raise the grace window in the profile so slow-but-real payments do not flag. Does this card move my deals or change any data? No. Every Nerve Centre card is read-only. It detects the mismatch and surfaces it; correcting the deal stage or the contact email is a manual action you take in HubSpot or in the store. We mark deals won before payment on purpose, as a forecasting convention. Will this just flag everything? It will flag those deals until the matching order posts within the grace window. If your convention is to mark won well ahead of payment, either widen the grace window or exclude that pipeline from the revenue-matching profile so the card only watches pipelines where won should mean paid. How is this different from the Pipeline-vs-Realised Revenue Gap card? This is the line-item alert; that is the aggregate. This card names the specific deals that do not reconcile so someone can fix each one. That card shows the total dollar gap so finance can size the problem. Use this to act, that to measure. Could the gap be on the store side rather than the CRM side? Yes, and that is the integration-drift case. If the deal is correct and paid but the store order never synced into the system, the fix is on the integration, not the CRM. Operations is on the roles list precisely because some flags are sync failures, not sales errors. Action playbook when this fires:- Sort flagged deals by amount; start with the largest, since they distort the period most.
- For each, open the associated contact and check whether a store order exists under a different email or customer record.
- If the order exists, fix the link (align emails or re-associate the order) and the flag clears.
- If no order exists and no payment was taken, move the deal back to its true stage; it was a phantom win.
- If a pattern emerges (many flags from one source or one rep), treat it as a process or integration issue, not a one-off.