Solving Sell-Side Consignment in Oracle ERP

Oracle's consignment module, across EBS 11i, R12, and even Fusion Cloud, only covers the buy side. Here's how we designed a complete sell-side consignment process using standard EBS transactions. No customizations. No fake shipments.

If you've been looking for a way to handle sell-side consignment in Oracle EBS, where your company is the consignor placing samples at a customer's location, this post is for you. Oracle doesn't have a module for it. Not in 11.5.10, not in R12, and not fully in Fusion Cloud either.

This post documents how we designed and validated a complete sell-side consignment process using nothing but standard, out-of-the-box EBS transactions. No custom workflows, no modified PL/SQL, no form personalizations. I'm sharing it here because I couldn't find this solution documented anywhere when I needed it, and I suspect others are stuck on the same problem.

3 Key Takeaways ✍️

In case you are pressed for time, here are three key points I hope you take:

💡 Takeaway 1

Oracle's consignment module is buy-side only, across all versions. EBS 11.5.10, R12, and Fusion Cloud all provide consignment tracking for when your company is the consignee. None of them natively support the scenario where your company is the consignor.

💡 Takeaway 2

Separate billing from inventory movement. Bill Only Sales Orders handle invoicing (they don't touch inventory). Account Alias Issues handle inventory relief (they don't create invoices). Combined in the right sequence, you get both - without ever needing to pick, pack, or ship product that hasn't moved.

💡 Takeaway 3

Test with real numbers in a live instance. Our most surprising discovery, that the Account Alias must point to COGS, not back to the inventory account, only surfaced because we inspected GL entries line by line. The configuration looked correct. The results were silently wrong.

1. The Problem Statement

If you've ever searched Oracle's documentation for "consignment," you've found exactly one thing: supplier-side (buy-side) consignment tracking. That's the scenario where your company is the consignee: a supplier parks inventory at your warehouse, and you pay for it only when you consume it. This is true in EBS (11.5.10, R12), and even Fusion Cloud.

But what if your company is the consignor? You manufacture inventory or samples for customer evaluation, ship them to a customer's location, and the customer sits on them for 10, 30, or 60 days before deciding to buy? Until they commit, the product stays on your books.

That's sell-side consignment. And no version of Oracle ERP has a native workflow for it (yet).

💡 What Is Consignment?

In a consignment arrangement, goods are physically transferred to the customer (the "consignee"), but title and ownership remain with the vendor (the "consignor") until the customer decides to purchase. Until that point, the inventory stays on the vendor's balance sheet.

Here's the real-world scenario we faced: my client, a Canadian manufacturer, needed to place consignment samples with its French subsidiary's end customers across France. Canada needed to retain ownership until purchase, track inventory at each consigned location, and record the intercompany sale (Canada as supplier to the French entity) if and only when France's customer purchased.

2. The Business Pain Points

My client was shipping samples from Canada to its French entity using Oracle ERP's Intercompany Internal Requisition / Internal Sales Order (IR/ISO) workflow to move inventory between the two legal entities. Once a sample arrived in France, it was forwarded to the end customer for evaluation with no corresponding record in the ERP. Only if the customer decided to buy would the external sale be recorded. Here's what was going wrong:

Pain Point #1: Ownership Integrity

Intercompany orders (from CAN to FR) result in a shipment event, which trigger ownership transfer to the subsidiary. This contradicts the entire premise of consignment. Auditors would not be able to truly reconcile who owned what when.

Pain Point #2: Fake Logistics

If and when the customer decided to purchase, the external customer order process required pick, pack, and ship confirm for product that was already physically sitting at the customer's location. Warehouse operators were executing "phantom" shipping confirmations - generating meaningless move orders, packing slips, and BOLs for items that moved weeks ago.

Pain Point #3: No Consignment Visibility

There was no way to see, at a glance, which samples were sitting at which customer's location, how long they'd been there, or what their total inventory value was. Samples disappeared into a black hole between shipment and purchase.

3. Approaches We Evaluated (and Why Most Failed)

We didn't arrive at the final design on day one. Over two weeks of research, live Oracle testing, and iteration, we evaluated six different approaches:

4. The Solution: The Consignment Sale Model

💡 Here's the core insight we landed on: separate billing from inventory movement.

The design uses four standard EBS transaction types, combined in a specific sequence and zero code customization (except for generation of custom shipping documents to accompany samples during subinventory transfer 'shipments').

Why This Works

Subinventory Transfers keep inventory on the consignor's books while tracking physical location. The Material account on each subinventory drives the GL, so a transfer from Finished Goods subinventory to a customer-specific consignment subinventory simply reclassifies the balance sheet. This is perfect for consignment - no P&L impact and no ownership change.

Bill Only Sales Orders create the invoice and recognize revenue without triggering any inventory transaction. In other words, a Bill Only SO does not touch inventory. It fires Dr: Receivable / Cr: Revenue only.

To support the external customer sale, Account Alias Issues relieve inventory from the consignment subinventory and record COGS. The GL fires Dr: COGS / Cr: Inventory.

By designing the Bill Only SO and Account Alias in the proper sequence, you get both the financial transaction and the inventory movement without ever needing to pick, pack, or ship anything.

For the intercompany sale between the corporation's legal entities, a Miscellaneous Receipt brings inventory onto the subsidiary's books at the intercompany transfer price, hitting an IC Clearing account that offsets the parent's receivable at consolidation.

5. End-to-End Process Walk-through

Here's the complete flow for a sample that travels from the Canadian parent --> the French subsidiary --> the French customer's location, and is eventually purchased. I've included the GL entries at each step because getting the accounting right was our first priority.

Phase 1: Ship to Consignment

Phase 2: Customer Evaluates

Phase 3A: Customer Returns (No Sale)

Phase 3B: Customer Purchases

6. Consignment Model vs. Intercompany Process

Here's a side-by-side comparison. This table was key to getting stakeholder buy-in:

7. Subinventory Strategy: Per-Customer vs. Single Consignment Bucket

One design decision we spent time on: should you create a dedicated consignment subinventory for each customer, or use a single bucket for all consigned samples?

Here's why: With per-customer subinventories, each one gets its own Material account in the GL. That means the balance of consigned inventory at each customer is visible in your chart of accounts without any custom reporting. Oracle's standard on-hand reports work as-is - filter by subinventory and you see the customer. Partial returns stay traceable because product goes back to the customer-specific subinventory. And each subinventory maps naturally to a consignment agreement with that customer.

The single-bucket approach is simpler to set up (one subinventory for everyone), but you lose all native customer-level visibility. You'd need custom SQL joining MTL_MATERIAL_TRANSACTIONS, WIP, and SO tables just to figure out which customer has which sample.

The setup overhead for per-customer subinventories is tw steps: create the subinventory, assign a Material account, done. If your customer base is manageable (dozens, not thousands), per-customer is the clear winner.

8. The Gotchas That Burned Us During Testing 🔥

These are hard-won lessons from live Oracle testing. Every one of these caused real problems during our validation. I'm sharing them so you don't have to learn them the hard way.

1. Gotcha #1: Not Recognizing COGS

The Account Alias must point to the COGS account - not the consignment inventory account. If you point it back at the inventory account, the debit and credit net to zero. The inventory never leaves your books. COGS is never recognized. We caught this during live testing when the GL entries balanced perfectly - which was the sign something was wrong. This is the kind of "silently wrong" result you only catch by inspecting GL entries line by line. Be careful.

2. Gotcha #2: Bill Only SO Does NOT Relieve Inventory

This is by design (but misunderstood by many clients). If you book the Bill Only SO and forget to execute the Account Alias Issue, you'll have revenue on the P&L but the product will still be sitting in your consignment subinventory, indefinitely. COGS will be understated. Build an automated check (we use Oracle APEX to house the business logic and report errors) that flags any Bill Only invoice without a corresponding Account Alias Issue within a defined window.

3. Gotcha #3: Costing in your Subsidiary Organization

The Miscellaneous Receipt in the subsidiary organization requires an item cost for the item, even if the item is simply passing through the org. Without it, Oracle posts the receipt at $0, resulting with inventory on the books at zero cost. When the subsidiary sells it to the end customer, their margin looks like 100% - a major overstatement. Define a cost for every sample item in your subsidiary as part of the item setup process, before any Misc Receipt is executed. In our case, we automated the setup of an item cost, again with Oracle APEX.

9. Advice for the ERP Community

Here's what I'd pass along if you're solving this same problem:

1. Start with the GL, not the transactions. We ranked our design priorities with GL integrity as first, EBS transaction flow second and end-to-end walk-through third. Getting the accounting right forced us to pick the right transaction types, not the other way around. If you start by asking "what EBS transactions are available?" you could end up with a workflow that creates technically valid but inaccurate accounting entries.

2. Test with real numbers in a live instance. Our Account Alias discovery (Gotcha #1) only surfaced because we ran a transaction and inspected the GL entries line by line. The configuration looked correct. The accounting was wrong. Whiteboard designs don't catch this.

3. Separate physical movement from ownership transfer. This is the fundamental principle. Product moves in the system when it moves in the real world (subinventory transfers). Ownership changes only when the customer says "I'll buy it" (Bill Only SO + Account Alias). If your design couples these two events (physical movement and ownership change), you don't have consignment - you'll just have a regular sale with delayed shipping.

4. Don't fight the ERP - configure it. Every transaction in our design is a standard, out-of-the-box EBS function. No custom workflows, no modified PL/SQL, no form personalizations. We configured standard building blocks in a specific sequence to produce a behavior Oracle ERP doesn't natively support. This is the safest approach.

Conclusion

Sell-side consignment is a gap that spans Oracle EBS 11.5.10, R12, and even Fusion Cloud. But with a disciplined combination of subinventory transfers, Bill Only Sales Orders, Account Alias Issues, and Miscellaneous Receipts, executed in the right sequence, pointed at the right accounts, we were able to build a complete, auditable consignment process without writing a single line of custom code. The design principles apply regardless of which Oracle platform you're on.