What happens to the extra?
Compare four overreceipt policies by who does the work, where goods go, and how invoices match.
Four options. Different tradeoffs.
Expense items for an identified requester. Tags rate each option against the row’s goal—not overall system capability.
| Consideration | Option 01 Allow + deliver all | Option 02 Allow + hold the extra | Option 03 Block PO overreceipt | Option 04 Extra as non-PO receipt |
|---|
Preapproved extras
Requester wants the extra; quantity, price, and funding are approved.
A short decision window
Controlled space, a named buyer, and a firm disposition deadline.
Protect requester demand
Block unapproved excess; track any boxes already on site.
Documented exception
Use an approved receipt path; reconcile the extra separately.
Try a shipment
Compare quantities and policy fit. Illustrative only—not Oracle invoice validation.
Shipment assumptions
Calculator assumptions
Model: one quantity-based PO schedule, no prior receipts/invoices/returns, one UOM, identical unit prices, no tax/freight. Options 1–2 record all arrived quantity against the PO; 3–4 record only up to ordered quantity against the original PO. Option 4's excess remains unmatched to that PO. Percentage checks only; maximum quantity, amount, price, accepted quantity (4-way), cumulative activity, and other tolerances are excluded. Whether a particular hold is generated depends on the configured rules and match controls. Total billed quantity is assumed to be presented against the original PO for comparison.
Make the handoff explicit
Block unapproved PO excess. Track temporary custody. Assign supplier resolution to Procurement.
Count and capture
Capture PO, supplier, item, quantities, UOM, packing slip, photos, and applicable lot/serial/expiry.
Separate the extra
Deliver authorized units. Refuse excess if feasible; otherwise label and stage by exception ID. A system block is not a physical return.
Assign the buyer
Buyer owns the case, supplier contact, return instructions or approved terms. AP manages invoice holds.
Ask the user only for a decision
Ask whether extras are needed and funded. Buyer handles the supplier; involve the user only for technical or clinical input.
Execute and reconcile
Buyer authorizes disposition; warehouse executes it. Buyer/AP reconcile PO, receipt, invoice/credit, then close the case.
Decision ownership
Warehouse: physical count, custody, traceability, approved delivery/return.
Procurement: supplier communication, terms, purchase authorization coordination, disposition and case closure.
Requester / budget owner: usefulness, acceptance, funding approval.
AP: invoice matching, holds, credits and payment controls.
Inventory / WMS + Finance: supported hold design, allocation restrictions, integration and accounting treatment.
Workshop policy settings
Proposed targets, not Oracle defaults. Changes stay in this session. Copy the policy summary or print to retain your work. No data is sent to Oracle.
Oracle controls to keep separate
Oracle sources checked October 20, 2026. Expand for details; validate your release and integration.
1. Receipt permission ≠ invoice payment permission
Receiving can reject, warn, or permit excess. Direct routing combines receipt and delivery/putaway; a hold policy needs a route that separates them. Oracle 26D: Receipt Creation ↗
Payables checks ordered and received variances separately. Review match approval level, quantity/amount basis, supplier-site tolerances, and cumulative transactions. Receipt does not guarantee payment approval. Oracle 26D: Invoice Tolerances ↗
2. Expense destination ≠ warehouse stock
Design implication: shelving expense goods does not create inventory on-hand. Keep extras in controlled Receiving custody, or design an approved stock transaction with Finance.
Validate item setup, expense destination, routing, charges, accounting timing, and WMS support. Hold controls must prevent unintended picking and reconcile across systems.
3. What does “non-PO receipt” mean?
Fusion unordered receipt: temporary custody without an identified backing document. Match before inspection, putaway, or standard supplier return. Validate its suitability for a known PO overage; it is not an approval bypass. Oracle 25C: Unordered Receipts ↗
Matching restrictions include supplier, organization, item/category, approved shipment, and routing. PO controls still apply. Oracle 26D: Match Restrictions ↗
Miscellaneous inventory / WMS non-PO receipts: different paths with different controls. Validate item eligibility, valuation, ownership, traceability, and interfaces. Extra on-hand does not create an original-PO receipt match.
4. WMS enforcement and integration must agree
Oracle documents WMS line-level tolerances from 24B and predefined PO tolerance integration mappings in 25D. Test your mappings, warning/reject behavior, UOM conversions, partial receipts, and confirmations. Fusion and WMS controls may behave differently.
Oracle WMS 24B: Line-level tolerances ↗ · Oracle WMS 25D: Integration mappings ↗
5. Returns need a transaction and credit strategy
Standard receiving returns need a valid receipt; unordered receipts need matching first. Dock refusal differs from a recorded return. Coordinate pickup, receipt transactions, supplier credit, and any PO reopening. Oracle 26B: Returns ↗
Validate with one end-to-end test per option
Use 10 ordered, 12 arrived and 12 billed. Check physical custody, requester delivery, PO/receipt quantities, invoice holds, charges/accruals, return/credit, and WMS/Fusion reconciliation. Repeat the selected policy with a partial receipt, another UOM, a description-only expense item and an already delivered receipt where relevant.
Suggested test cases and operating recommendations are design judgments. Links support the documented Oracle mechanics, not a claim that every proposed workflow is available without configuration or process changes.