> ## 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 Orders Missing Matching Fusion Receivables Transaction, Oracle ERP Cloud > Ecom Orders Missing Matching Fusion Receivables Transaction counts ecommerce orders with no matching Receivables Transaction in Oracle Fusion after 7 days, a revenue and SOX-audit gap. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > A cross-channel count joining two systems: ecommerce orders that still have no matching Receivables Transaction in Oracle Fusion seven days on. This is unrecognised revenue and a SOX-audit gap, not a timing wobble. ## At a glance > This is a cross-channel card. It matches every ecommerce order against the Receivables Transactions in Oracle Fusion and counts the orders that, seven days after they were placed, still have no Receivables counterpart. Within a normal AutoInvoice cadence an order becomes a Receivables Transaction in 1 to 3 days; a gap that survives seven days is not lag, it is a break. The most common cause is an Oracle Integration Cloud (OIC) flow that posts Receivables Transactions failing silently, so the order looks complete on the storefront while no invoice ever lands in Oracle. That is two problems at once: revenue that was earned but never recognised in the GL, and a SOX-audit gap where the system of record is missing transactions the storefront can prove happened. A reading of zero is the healthy state; anything above zero is orders whose revenue is stranded outside Oracle. | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | The number of ecommerce orders that have no matching Receivables Transaction in Oracle Fusion more than 7 days after the order date. The match is made on the order identifier carried into Oracle, so an order with no corresponding AutoInvoiced or manually created Receivables Transaction counts. | | **Cross-channel join** | The storefront's order feed (proof the sale happened) is matched to Oracle Receivables Transactions (proof it was invoiced). The card exists because the storefront cannot see Oracle and Oracle cannot see the storefront's unmatched orders. | | **Why 7 days** | Normal AutoInvoice lag is 1 to 3 days for DTC and longer for B2B terms, but any order should have a Receivables Transaction within a week. Beyond 7 days the cause is a break, not latency. | | **Why it matters twice** | It is missed or unrecognised revenue (the GL understates) and a SOX-audit gap (the system of record is missing transactions). Both make it a finance and audit priority, not just an operations one. | | **Business Unit scope** | Respects the dashboard's selected Business Unit filter. By default spans every Business Unit and storefront the connected role can see. | | **Time window** | `7D` (orders older than 7 days still unmatched) | | **Alert trigger** | `>0 unmatched after 7d` - any order with no Receivables Transaction after a week raises the count | | **Roles** | owner, finance, 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 Fortune 500 omnichannel retailer runs Oracle ERP Cloud for Receivables, with a Shopify Plus DTC channel and a BigCommerce B2B channel feeding Order Management through Oracle Integration Cloud (OIC). On 12 Apr 26 the card shows 38 orders placed on or before 05 Apr 26 that still have no matching Receivables Transaction. | Channel | Unmatched orders (>7d) | Order value | Likely cause | | ------------------------- | ---------------------- | ------------- | -------------------------------------------------------------------------- | | Shopify Plus DTC | 31 | \$84,200 | OIC Receivables-posting flow erroring silently on a payment-method mapping | | BigCommerce B2B | 5 | \$146,000 | Orders stuck pre-AutoInvoice; missing customer party link | | Marketplace (synced) | 2 | \$9,400 | Order never mapped into Oracle | | **Total unmatched (>7d)** | **38** | **\$239,600** | | Four things to notice: 1. **Two systems, one finding.** Shopify can prove 31 orders were placed and paid. Oracle Receivables has no transaction for any of them. Neither system raises a flag: Shopify thinks it did its job, Oracle never knew the orders existed. The cross-channel match is the only thing that surfaces the gap. 2. **The DTC cluster points at a broken OIC flow.** 31 orders failing the same way is a systemic break, not 31 coincidences. The OIC flow that posts Receivables Transactions is erroring silently, almost certainly on a single mapping. Pair this with [OIC Integration Flow Failures (24h)](/nerve-centre/kpi-cards/oracle-erp/oic-integration-flow-failures-24h) to find the failing flow. 3. **This is unrecognised revenue.** The \$239,600 was earned but never booked, so [Revenue Booked into GL](/nerve-centre/kpi-cards/oracle-erp/revenue-booked-into-gl) understates by that amount and the gap shows up on [Revenue Gap vs Commerce](/nerve-centre/kpi-cards/oracle-erp/revenue-gap-vs-commerce). Until the Receivables Transactions are created, the revenue does not exist in the system of record. 4. **It is also a SOX-audit gap.** A control environment expects the system of record to hold every revenue transaction. Orders that paid but never invoiced are exactly what an auditor probes. That is why finance is on the role list, not just operations: this is a control finding, and the longer it persists the harder it is to remediate cleanly. ## Sibling cards merchants should reference together This card sits at the join of the storefront and Oracle Receivables. Pair it with the integration, revenue, and order-reconciliation cards. | Card | Why pair it with Ecom Orders Missing Matching Fusion Receivables Transaction | | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | [OIC Integration Flow Failures (24h)](/nerve-centre/kpi-cards/oracle-erp/oic-integration-flow-failures-24h) | The most common root cause: the Receivables-posting flow erroring silently. | | [Commerce Orders without Oracle ERP Cloud Sales Order](/nerve-centre/kpi-cards/oracle-erp/commerce-orders-without-oracle-erp-cloud-sales-order) | The earlier break in the same chain: orders that never even became Sales Orders. | | [Revenue Gap vs Commerce](/nerve-centre/kpi-cards/oracle-erp/revenue-gap-vs-commerce) | The unmatched value is part of the gap between commerce and GL revenue. | | [Revenue Booked into GL](/nerve-centre/kpi-cards/oracle-erp/revenue-booked-into-gl) | The headline that understates while these orders sit uninvoiced. | | [Invoiced Revenue](/nerve-centre/kpi-cards/oracle-erp/invoiced-revenue) | The Receivables-invoice total these missing transactions should have lifted. | | [Subledger-to-GL Posting Failed (any source)](/nerve-centre/kpi-cards/oracle-erp/subledger-to-gl-posting-failed-any-source) | If a transaction was created but failed to post, it shows here instead. | | [Oracle Fusion Health Score](/nerve-centre/kpi-cards/oracle-erp/oracle-fusion-health-score) | The composite that a persistent revenue-recognition gap drags down. | ## Reconciling against Oracle ERP Cloud **Where to look in Oracle ERP Cloud:** The Oracle side of this card maps to standard Receivables views; the order side comes from your commerce connector, so the match needs both. > **Navigator → Receivables → Billing → Manage Transactions** (search for the order reference to confirm whether a Receivables Transaction exists) > **Scheduled Processes → Import AutoInvoice** (review the execution and reject report for orders that failed to import) > **Reports and Analytics → OTBI → Financials → Receivables - Transactions Real Time** For any order on this card, search Manage Transactions for its order reference. If no Receivables Transaction comes back, the order is genuinely unmatched. The AutoInvoice reject report is where partially imported orders surface; orders that never reached AutoInvoice at all will be absent from Oracle entirely, which is the cross-channel half the connector supplies. Common mistakes when comparing against Oracle's own reports: * **Searching Oracle alone.** Oracle cannot list orders it never received. The unmatched orders exist only on the storefront, so an Oracle-only search shows nothing missing, which is precisely the blind spot this card closes. * **Assuming AutoInvoice lag.** A 1 to 3 day lag is normal and is excluded by the 7-day window. Anything on this card is past the point where lag explains it. * **Order reference mismatch.** If the order identifier is transformed between systems, a manual search may miss a transaction that does exist. The card uses the mapped reference; confirm the same key when searching by hand. **Why our number may legitimately differ from Oracle's reports:** | Reason | Direction | Why | | --------------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Cross-channel by design** | Card has extra data | The unmatched orders exist only on the storefront, so no Oracle report lists them. The card's value is the absence in Oracle, which Oracle cannot self-report. | | **Order-reference mapping** | Either | If the order key is transformed in transit, a manual Oracle search may find a match the card's mapping did not, or vice versa. | | **7-day boundary** | Either | An order at the edge of the 7-day window may match in Oracle a few hours later; the card and a later query then disagree. | | **B2B terms vs DTC** | Card may include long-terms orders | Some B2B flows intentionally delay invoicing; confirm whether a long-terms order is a real break or a configured delay. | ## Known limitations / merchant FAQs **Why is this a cross-channel card?** Because the finding lives in the gap between two systems. The storefront can prove an order was placed and paid; Oracle Receivables can prove an invoice exists. The break is an order with the first and not the second. Neither system can surface it alone, because Oracle never knew about the order and the storefront assumes its job ended at checkout. The card matches the two and counts the misses. **Isn't this just AutoInvoice lag?** No. Normal lag is 1 to 3 days for DTC and somewhat longer for B2B terms. The 7-day window deliberately excludes that. Anything on this card has survived past the point where lag is a plausible explanation, which means the cause is a break: a failed integration, a missing party link, or an order that never mapped into Oracle. **Why is this both a revenue and a SOX problem?** Two reasons in one finding. Revenue: the order was earned but never booked, so the GL understates and the commerce-to-GL gap widens. SOX: a control environment requires the system of record to hold every revenue transaction, and orders that paid but never invoiced are a documented gap an auditor will probe. That is why finance, not only operations, owns it. **What is the single most common cause?** An OIC flow that posts Receivables Transactions failing silently, usually on one mapping such as a payment method or a customer party link. Because it fails quietly, the orders accumulate unnoticed until something joins the two systems. A cluster of same-channel misses is the signature of a broken flow rather than scattered one-off errors. **Does a count here mean the money is lost?** The cash may well have been collected by the payment processor; what is missing is the Receivables Transaction and therefore the recognised revenue in Oracle. The order is not lost, but until the transaction is created the revenue is not in the system of record. Once the flow is fixed and the transactions are created, the GL catches up. **Can Vortex IQ create the missing Receivables Transactions?** No. Creating Receivables Transactions and re-running AutoInvoice or OIC flows are controlled actions inside Oracle Fusion and your integration platform, under your change controls and SOX segregation of duties. Vortex IQ detects the unmatched orders, points at the likely failing flow, and notifies owner, finance, and operations. Your team remediates in Oracle and OIC. *** ### Tracked live in Vortex IQ Nerve Centre *Ecom Orders Missing Matching Fusion Receivables Transaction* 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.