IntermediateSupply Chain · Order Management + Receivables

Order-to-Cash in Oracle Fusion

The end-to-end flow from a customer sales order through fulfillment to cash application.

End-to-End Process Flow

Click a stage for detail

Sales Order

A sales order is entered — manually, via integration, or via a storefront — with a business unit, customer, order type and one or more lines. Each line carries the item, quantity and requested schedule.

Tables Involved

DOO_HEADERS_ALL

Order header — customer, order type, business unit, order status.

DOO_LINES_ALL

Order line — item, quantity, requested schedule.

Overview

Order-to-Cash (O2C) covers a customer's sales order from capture through orchestrated fulfillment — scheduling, reservation, pick, ship — to Receivables invoicing and, ultimately, cash application against the customer's payment. Order Management orchestrates the line's lifecycle across Inventory, Shipping and Receivables using a configurable orchestration process.

Unlike P2P, where a single AP invoice usually maps to one purchase transaction, O2C often has a fan-out shape: one sales order line can ship in multiple deliveries, and each delivery can generate its own AR transaction — which is why the fulfillment line, not the order line, is the real unit of tracking.

Modules Involved

Order Management

Order capture and orchestration across the fulfillment lifecycle.

Inventory

On-hand availability, reservation, and transaction recording.

Shipping

Pick release, ship confirm, and delivery management.

Receivables

AutoInvoice billing, cash receipts, and application.

Costing

COGS recognition tied to the shipment transaction.

Subledger Accounting

Turns AR transaction and receipt events into GL journal entries.

Accounting Impact

When a shipment relieves inventory, Costing generates the COGS entry — debiting COGS and crediting inventory — based on the item's cost method (standard, average, FIFO/LIFO where applicable).

Separately, the AR transaction generates the revenue recognition entry — debiting AR and crediting revenue — once AutoInvoice creates the transaction from the shipped line. The two entries are generated independently but both trace back to the same fulfillment line.

Common Statuses

Order Created → Scheduled → Reserved

Early orchestration stages tracked on DOO_FULFILL_LINES_ALL.

Awaiting Shipping → Shipped

Pick release and ship confirm progress.

Invoiced

The line has been picked up by AutoInvoice and billed.

Common Issues

A line stuck at 'Awaiting Shipping' usually means reservation or pick release hasn't completed — check supply availability and any pick release criteria.
A line that shipped but never invoiced usually failed the AutoInvoice interface, often due to missing setup (transaction type, AR/tax rules) for the order type/item combination — check the AutoInvoice interface exception tables.
Duplicate or missing COGS entries typically point to a costing period that closed out of sync with the shipment date.
Orders that never leave 'Scheduled' often indicate global order promising can't find a valid supply source for the requested date.
Cash applied to the wrong transaction is usually a receipt application error — check AR_RECEIVABLE_APPLICATIONS_ALL for the APPLIED_CUSTOMER_TRX_ID.

EBS vs Fusion

EBS Order Management used a simpler header/line/workflow-activity model; Fusion's orchestration process is more explicitly configurable, with DOO_FULFILL_LINES_ALL as a dedicated status-tracking layer that didn't have a direct EBS equivalent.

Receivables changed the least — RA_CUSTOMER_TRX_ALL and RA_CUSTOMER_TRX_LINES_ALL carried over from EBS into Fusion with a largely compatible schema, so AR reporting SQL tends to port over with minimal changes.

Shipping's WSH_ tables (deliveries, delivery details) are also largely shared lineage between EBS and Fusion, unlike Order Management's header/line tables which were redesigned.

Useful SQL

Trace a sales order from header to fulfillment status

SELECT
  h.order_number,
  l.inventory_item_id,
  l.ordered_quantity,
  f.fulfillment_line_status_code
FROM doo_headers_all h
JOIN doo_lines_all l
  ON l.header_id = h.header_id
JOIN doo_fulfill_lines_all f
  ON f.line_id = l.line_id
WHERE h.order_number = :order_number;

AR transactions for a customer

SELECT
  customer_trx_id,
  trx_number,
  trx_date,
  bill_to_customer_id
FROM ra_customer_trx_all
WHERE bill_to_customer_id = :customer_id
ORDER BY trx_date DESC;

Cash receipt applications for a transaction

SELECT
  ra.receivable_application_id,
  ra.amount_applied,
  cr.receipt_number,
  cr.receipt_date
FROM ar_receivable_applications_all ra
JOIN ar_cash_receipts_all cr
  ON cr.cash_receipt_id = ra.cash_receipt_id
WHERE ra.applied_customer_trx_id = :customer_trx_id;

Interview Questions

Walk through O2C end to end — what happens at each stage?
What does DOO_FULFILL_LINES_ALL track, and how does it relate to DOO_LINES_ALL?
Why might a shipped order line never reach Receivables?
How does costing relate to a sales order shipment, and how does it differ from revenue recognition?
What's the difference between order orchestration in Fusion and order flow/workflow in EBS Order Management?
How would you trace a cash receipt back to the sales order it eventually paid for?

Next Steps

Try It: Create a Sales Order

A hands-on walkthrough of the first stage of this cycle, with real Fusion screens.

Compare with Procure-to-Pay

The mirror-image cycle on the buy side — requisition through reconciled payment.