Incorrect on-hand quantity in Fusion Inventory is nearly always a transaction that did not complete rather than a balance that drifted. Transactions fail in the interface on validation — item, subinventory, locator, lot or serial control — and remain in error until corrected. On-hand reflects completed transactions only, so an error queue produces a quantity that looks wrong.
What problem does this solve?
On-hand quantities that disagree with the physical count usually trace to transactions sitting in error rather than to a system fault. The interface holds them, and nobody is watching the queue.
Transactions stuck in error typically fail on control attributes: lot or serial not supplied where required, an invalid locator, or a subinventory that does not permit the transaction type.
Costing differences arise where the cost method and the transaction sequence interact — receipts and issues processed out of order produce valuations that look wrong but are arithmetically correct.
How the solution works
We start with the error queue, not the balance. Clearing pending and errored transactions usually resolves the apparent discrepancy without any adjustment.
Where adjustments are genuinely needed, they are made with a documented reason and reconciled to the physical count, so the audit trail explains the change.
- 1List pending and errored inventory transactions before investigating the balance itself.
- 2Identify the validation that failed — item, subinventory, locator, lot or serial control.
- 3Fix the transaction attributes and resubmit rather than adjusting the balance to compensate.
- 4Compare corrected on-hand to the physical count and quantify any genuine difference.
- 5Where a real difference remains, adjust with a reason code and approval.
- 6Alert on errored transactions so the queue is worked continuously rather than at count time.
Limitations & prerequisites
- On-hand is a derived figure; correcting it without correcting the underlying transactions produces a balance that disagrees with the transaction history.
- Lot and serial control cannot be changed once transactions exist for an item, so a control error found late requires a different remediation than reconfiguration.
- Costing differences may be arithmetically correct given the transaction sequence; investigating them as errors wastes time unless the sequence is examined.
- Where a warehouse system owns stock movement, Fusion reflects what it is told, and persistent differences are an interface or process problem.
- Adjustments have accounting consequences in the period they are made, which may not be the period in which the discrepancy arose.
FAQ
Usually because transactions have not completed. Check the pending and errored transaction queue before investigating the balance — in most cases clearing the queue resolves the difference without any adjustment.
A validation failed: a lot or serial number missing where control requires it, an invalid locator, an item not enabled in that organisation, or a subinventory that does not allow the transaction type. The error record names the specific failure.
Cost method and transaction sequence interact. Receipts and issues processed in an unexpected order produce valuations that are arithmetically correct but counter-intuitive. Examine the transaction sequence before treating it as an error.
Only after clearing errored transactions, because most apparent discrepancies disappear at that point. Genuine differences should be adjusted with a reason code and approval so the audit trail explains them.
Almost always an unmonitored interface. Where a warehouse system feeds Fusion, failures accumulate silently between counts. Alerting on errored transactions turns a quarterly surprise into a daily task.
Not once transactions exist for the item. Discovering the wrong control setting after go-live usually means creating a new item and migrating, which is why control attributes deserve attention during implementation.
Tell us the module, the release and the exact symptom.
Send the module in scope, your Fusion release or EBS version, and the exact error text or symptom with a screenshot where you have one. We reply with a written assessment: the likely cause, what we would check first, and whether it is a configuration fix, a data fix, or a defect that needs an Oracle service request. When Swedish Technology can help, we scope the remediation with effort and sequence before you commit to anything.
Request an Oracle AssessmentSources & evidence
- Oracle Help Center — Cloud Applications documentation — module setup, subledger accounting and period-close reference
- Oracle Help Center — all product documentation — database, middleware and infrastructure reference used for error diagnosis
- My Oracle Support — patches, known-issue notes and service requests; Oracle account required
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.