Skip to main content
Metrics type: Key Metrics • Category: Ecommerce Platform
A cross-platform 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-platform 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.

​
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. 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-platform 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) to find the failing flow.
  3. This is unrecognised revenue. The $239,600 was earned but never booked, so Revenue Booked into GL understates by that amount and the gap shows up on 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.

​
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-platform 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:

​
Known limitations / merchant FAQs

Why is this a cross-platform 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 or book a demo to see this metric running on your own data.