> ## 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. # Ecom Customers Absent from Fusion Party, Oracle ERP Cloud > Ecom Customers Absent from Fusion Party. Count of ecommerce buyers who have no matching customer record in the Oracle Fusion Party model, the customer-master drift that breaks invoicing and revenue posting. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Count of ecommerce buyers with no matching customer record in the Oracle Fusion Party model. Customer-master drift that quietly breaks invoicing. ## At a glance > Ecom Customers Absent from Fusion Party counts ecommerce buyers who have transacted on your storefront but have no matching customer record in the Oracle Fusion Trading Community (Party) model. This is a cross-channel integrity signal. Every order placed by an absent customer cannot AutoInvoice cleanly, cannot post to Receivables, and so cannot become recognised GL revenue. When the count rises with active orders attached, you have revenue stuck at the customer-master layer, not the order layer. | | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The number of distinct ecommerce customers seen on the connected storefront(s) over the window that have no corresponding Account or Party record in Oracle Fusion's Trading Community model. A buyer is matched on the customer identifiers shared between the commerce platform and Fusion (account number, email, or tax identifier, depending on how your integration maps them). Anything that fails to resolve to a Fusion Party is counted as absent. The hero view weights customers who have active or recent orders, because those are the ones actively losing revenue to the gap. | | **Why it matters** | Oracle Fusion will not raise a Receivables Transaction against a customer it does not know. An absent Party means AutoInvoice has nothing to bill, the Subledger Accounting entry never forms, and the order never reaches the General Ledger. The buyer paid on the storefront, but the revenue cannot be recognised under ASC 606 or IFRS 15 until the customer master is reconciled. | | **Currency** | n/a. This is a count metric. The dollars at risk surface on [Ecom Orders Missing Matching Fusion Receivables Transaction](/nerve-centre/kpi-cards/oracle-erp/ecom-orders-missing-matching-fusion-receivables-transaction). | | **Business Unit scope** | Respects the dashboard's selected Business Unit filter. By default rolls up every Business Unit and connected storefront the role can see. | | **Common causes** | An Oracle Integration Cloud (OIC) customer-sync flow that failed silently, a new storefront or marketplace channel onboarded before its customer feed was wired into Fusion, guest-checkout buyers never promoted to a Party, or a matching key mismatch (the storefront stores an email, Fusion keys on account number). | | **Time window** | `7D` (last 7 days of customer activity) | | **Alert trigger** | `>10`, and on the cross-channel hero view `>10 with active orders absent`, driven by the customer-master integrity sentiment | | **Roles** | owner, finance, marketing, operations | ## Calculation Calculated automatically from your Oracle ERP 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 large-enterprise omnichannel retailer runs Oracle ERP Cloud behind a Shopify Plus DTC storefront and an Adobe Commerce B2B portal, with customer records flowing into the Oracle Fusion Party model via an OIC integration. The 7-day window covers 16 Jun 26 to 22 Jun 26. | Source channel | Distinct buyers in window | Matched to a Fusion Party | Absent from Fusion Party | | ------------------------------------- | ------------------------- | ------------------------- | ------------------------ | | Shopify Plus DTC | 4,820 | 4,789 | 31 | | Adobe Commerce B2B | 612 | 598 | 14 | | Marketplace (new channel) | 207 | 0 | 207 | | **Total** | **5,639** | **5,387** | **252** | | of which with active or recent orders | | | **47** | Five things to notice: 1. **The headline count is 252, but the alert fires on the 47 with active orders.** The Nerve Centre weights the cross-channel hero view toward buyers who are actively transacting, because those are the ones whose revenue is stuck right now. The remaining 205 are mostly the new marketplace channel that has not yet had its customer feed connected to Fusion at all. 2. **The marketplace channel is the obvious finding.** 207 of 207 buyers are absent because the channel was onboarded on 14 Jun 26 and its customer-sync OIC flow is not live yet. This is a configuration gap, not a data-quality problem, and it resolves the moment the flow is wired in. 3. **The 31 Shopify and 14 Adobe absentees are the subtle finding.** These are buyers on channels that do sync. The likely cause is a matching-key mismatch (guest checkout under a new email, or a B2B buyer whose account number was never written back to the storefront) or an OIC flow that errored on individual records. These are the ones worth a manual reconcile. 4. **Each absent buyer with an order is a revenue-recognition gap, not just a CRM gap.** Without a Fusion Party, AutoInvoice has no customer to bill, so the order cannot post to Receivables or the General Ledger. The dollar value of that stuck revenue is quantified on the companion [Ecom Orders Missing Matching Fusion Receivables Transaction](/nerve-centre/kpi-cards/oracle-erp/ecom-orders-missing-matching-fusion-receivables-transaction) card. 5. **Last period the count was 38.** The jump to 252 is driven almost entirely by the new marketplace channel. Filtering that channel out, the underlying drift is 45, broadly flat versus the prior week, which tells the finance team the existing integrations are healthy and the spike is a known onboarding event. ## Sibling cards merchants should reference together Customer-master drift is the upstream cause of several downstream revenue and reconciliation gaps. Pair this card with these to see the full chain. | Card | Why pair it with Ecom Customers Absent from Fusion Party | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Ecom Orders Missing Matching Fusion Receivables Transaction](/nerve-centre/kpi-cards/oracle-erp/ecom-orders-missing-matching-fusion-receivables-transaction) | The dollar consequence. An absent customer master is the most common reason an order has no Receivables Transaction. This card quantifies the revenue at risk. | | [OIC Integration Flow Failures (24h)](/nerve-centre/kpi-cards/oracle-erp/oic-integration-flow-failures-24h) | The mechanical cause. A failed customer-sync flow in Oracle Integration Cloud is the usual reason buyers fail to appear as a Fusion Party. | | [New Party Records (30d)](/nerve-centre/kpi-cards/oracle-erp/new-party-records-30d) | The healthy counterpart. New Party creation should track new-customer volume. If New Party Records stalls while storefront signups climb, drift is building. | | [Customers with TaxRegistrationNumber Mismatch (B2B)](/nerve-centre/kpi-cards/oracle-erp/customers-with-taxregistrationnumber-mismatch-b2b) | The other half of customer-master integrity. Absent customers cannot be billed at all; mismatched tax IDs are billed wrongly. Together they cover the B2B onboarding risk surface. | | [Commerce Orders Without Oracle ERP Cloud Sales Order](/nerve-centre/kpi-cards/oracle-erp/commerce-orders-without-oracle-erp-cloud-sales-order) | The order-layer twin of this customer-layer gap. Both surface storefront activity that has not made it into Fusion. | | [Revenue Gap vs Commerce](/nerve-centre/kpi-cards/oracle-erp/revenue-gap-vs-commerce) | The roll-up. Customer-master drift is one named contributor to the headline gap between commerce gross and Oracle GL booked revenue. | | [Active Customers](/nerve-centre/kpi-cards/oracle-erp/oerp-active-customers) | Context. The denominator against which absent-customer drift should be read. | ## Reconciling against Oracle ERP Cloud **Where to look in Oracle ERP Cloud:** The closest native views in the Oracle Fusion UI are: > **Navigator → Receivables → Customers → Manage Customers** (search for the buyer by name, email, or account number to confirm whether a Party exists) > **Navigator → Customer Data Management → Manage Persons / Manage Organizations** (the Trading Community Party model, the authoritative customer master) > **Reports and Analytics → OTBI → Customer Data Management Real Time Subject Area** (to list recently created Parties and spot sync gaps) To check a specific absentee, take the customer identifier from the storefront and search Manage Customers. If no Account or Party resolves, the buyer is genuinely absent. If a Party exists but on a different key (a different email or account number), this is a matching-key mismatch rather than a true absence, and the fix is in the integration mapping rather than the customer master. Common mistakes when comparing against Oracle's own views: * **Searching only the Account, not the Party.** A buyer can exist as a Party (Person or Organization) without an active Receivables Account. Both layers matter; AutoInvoice needs the Account, but the Party is the root record. * **Ignoring guest checkout.** Guest-checkout buyers often never get promoted to a named Party. They will show as absent here even though the order was fulfilled, which is expected behaviour, not an error, until your policy promotes them. * **Reading a stale OIC run.** If the customer-sync flow runs on a schedule, a buyer who signed up minutes ago is correctly absent until the next run. Check the OIC flow cadence before treating a low count as a problem. **Why our number may legitimately differ from Oracle's views:** | Reason | Direction | Why | | ---------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **OIC sync cadence** | Card higher | If the customer-sync flow is batched, recent signups are absent until the next run. The native UI catches up once the flow completes. | | **Matching-key choice** | Either | The card uses whichever identifier your integration maps on (email, account number, or tax ID). A buyer matched on email may look absent if Oracle is keyed on account number, and vice versa. | | **Business Unit scope** | Either | The card respects the dashboard Business Unit filter. A Party that exists under a Business Unit outside the current filter looks absent within the filter. | | **Guest vs named customers** | Card higher | Guest-checkout buyers with no promoted Party are counted absent by design. Your customer-master policy decides whether that is a gap to fix. | | **Merge and de-duplication** | Card lower | Oracle's Customer Data Management may have merged duplicate Parties. A buyer who appears under a merged master resolves correctly and drops off this card. | ## Known limitations / merchant FAQs **Is an absent customer always a problem?** No. Guest-checkout buyers who, by policy, are never promoted to a named Fusion Party will always count here, and that is expected. A brand-new storefront or marketplace channel whose customer feed has not been connected yet will also count, and that resolves once the integration goes live. The signal to act on is the subset with active or recent orders, which is what the cross-channel hero view weights toward and what the `>10 with active orders absent` alert fires on. **Why does this card matter to finance, not just to marketing?** Because Oracle Fusion will not raise a Receivables Transaction against a customer it does not know. An absent Party means the order cannot AutoInvoice, cannot post to Receivables, and cannot reach the General Ledger. The buyer paid, but the revenue cannot be recognised under ASC 606 or IFRS 15 until the customer master is reconciled. It is a revenue-recognition control issue, not just a CRM hygiene one. **How is this different from Ecom Orders Missing Matching Fusion Receivables Transaction?** This card is the customer-layer cause; that card is the order-layer and dollar-value effect. An absent customer master is the single most common reason an order has no Receivables Transaction. Read this card to find which customers are missing, and read the orders card to size the revenue at risk. **What usually causes a sudden spike?** Three patterns dominate. First, a new channel or storefront onboarded before its customer-sync flow was wired into Fusion, which produces a large one-off jump concentrated in that channel. Second, an Oracle Integration Cloud flow that failed silently, which produces a steady climb across existing channels. Third, a matching-key change on either side (the storefront or Fusion) that breaks resolution for a batch of customers at once. **How do I fix the absent customers?** For a channel-level gap, wire or re-enable the customer-sync OIC flow for that channel. For individual absentees on a healthy channel, confirm the matching key, then create or re-sync the Party in Oracle Customer Data Management so AutoInvoice can bill the open orders. The companion OIC and orders cards point to whether the cause is a flow failure or a per-record mismatch. **What is the data freshness?** Vortex IQ reads storefront customer activity and the Oracle Fusion Party model on a recurring sync window and compares them. The count reflects the state as of the last sync, so a buyer who signed up moments ago, or a Party created seconds ago, may take until the next window to resolve. For an instant check on a single buyer, the native Manage Customers search is always live. **Does this card replace Oracle Customer Data Management?** No. Customer Data Management is where you fix the master record; this card is the detection layer that tells you a fix is needed and which buyers are affected. Nerve Centre runs the detection, Vortex Mind investigates the cause, and Ask Viq lets you ask which customers are absent in plain English. The remediation still happens in Oracle. *** ### Tracked live in Vortex IQ Nerve Centre *Ecom Customers Absent from Fusion Party* is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP 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.