Station 5 of 10
Order to cash in Oracle Fusion
What you leave this station with
Running a full sales cycle or simulating it, reading what delivery does to revenue and cost, and diagnosing a wrong customer balance from its structural cause.
Station four followed money on its way out. This one follows it on the way in, and the difference is not direction. A purchase cycle ends in a payment whose timing you control; a sales cycle ends in a collection whose timing you do not. Which is why all of this cycle’s complexity is built around one moment: when what you did becomes revenue.
The documents and their journals
| # | Document | The accounting entry |
|---|---|---|
| 1 | Quote | None |
| 2 | Sales order | None — a commercial commitment |
| 3 | Shipment and delivery | Cost of goods sold debit, inventory credit |
| 4 | Customer invoice | Customer debit, revenue and tax credit |
| 5 | Receipt | Bank debit, customer credit |
Rows three and four are deliberately separate, and that is the most important thing on this page.
Cost is recognised at delivery and revenue at invoicing. Deliver on 29 September and invoice on 3 October and September carries a cost without its revenue, so the month’s margin is distorted in both directions. That is the real answer to “why did the margin drop this month for no reason”, and it is an answer about timing rather than about pricing.
The principle the interview tests: everything delivered in a period is invoiced in it, or the revenue is explicitly accrued. The gap between delivery and invoicing is not an administrative detail. It is an error in the financial statements.
Automatic invoicing, and the interface that fails quietly
In a healthy configuration, invoices here are not typed by hand. They flow in from their sources — shipping, contracts, projects, subscriptions — through an automatic invoicing interface that turns what was delivered into a customer invoice.
And this is where the quietest failure in the cycle happens: a line enters the interface, is rejected, no invoice is created, and nobody notices. The goods left the warehouse, the cost was recognised, the customer never received an invoice, and the revenue does not exist.
Four causes dominate:
- An undefined transaction source or type for this scenario.
- No revenue account derivable for that item and business unit combination.
- Incomplete customer data: a missing bill-to site or payment term.
- A closed period at the transaction date.
The discipline that prevents the disaster is simple and always neglected: the interface error report is reviewed daily, not at the close. Review it at month end and you find a hundred rejected lines with four causes, and spend the night fixing what would have taken two minutes on the day.
Unapplied receipts — the reason the customer balance is wrong
A customer transfers a million against seven invoices. The collector records the receipt and does not apply it.
The result: the customer’s total balance is right, and the ageing is entirely wrong. The seven invoices show unpaid and ageing, and the million shows as a floating amount. Then the ageing report reaches the finance director, who concludes that collections are deteriorating. They are not.
This is the commonest shape of the sentence “the system’s reports are wrong” on projects at this tier. The system is right; the last step was never taken.
There is automatic matching that proposes the application from reference and amount, and its real value is removing a human from something that repeats hundreds of times a month. The control rule: no month closes with a non-zero unapplied receipts balance and no written explanation.
What this product ships in the sales cycle, and where it needs a separately priced line, is in the Oracle Fusion Cloud ERP guide.
When revenue is not revenue
Three cases that catch people arriving from simple systems.
- An advance payment is not revenue. It is a liability until delivery.
- An annual maintenance contract is spread over twelve months rather than recognised in full at invoicing.
- A sale conditional on inspection or installation is not recognised before the condition is met.
All three are handled with deferred revenue released over periods. Recognising revenue at invoicing in these cases shows a profit this month borrowed from the months ahead — which is the clearest note an auditor writes.
What you actually do in this station
- Run a full sales cycle — order, delivery, invoice, receipt — or simulate it with the journals.
- Run the hard case: delivery at month end, invoice in the next, and calculate the effect on both margins.
- Break an invoicing interface line deliberately, then fix it from its cause.
- Record a receipt without applying it, produce the ageing, and watch the report lie with your own eyes.
- Write the treatment of an annual maintenance contract invoiced in advance, month by month.
- Reread order to cash to separate the general principle from this product.
The three commonest mistakes
One: ignoring the invoicing interface error report. Missing revenue that nobody complains about, because it does not exist — found only when a customer calls to say no invoice arrived.
Two: leaving receipts unapplied. Then making credit decisions on an ageing report that is wrong.
Three: recognising advance payments as revenue at invoicing. It surfaces at the first audit and is corrected by adjustments that disturb three months.
The acceptance test for this station
- Name the five documents and their journals, and which carries cost and which carries revenue.
- Explain the effect of the delivery-to-invoice gap on two consecutive months’ margins.
- Give four reasons a line is rejected by the invoicing interface, and how the backlog is prevented.
- Explain how a customer balance is right and its ageing wrong at the same time.
- Show the treatment of an annual maintenance contract invoiced in advance.
What comes next
You know where money enters and leaves. The next station explains the number that settles your profit before you sell anything: inventory and costing — cost books, receipt accounting, and why the same item’s margin differs between two entities in one group.
