Background
While NetSuite is strong as a general-purpose ERP platform for distributors, there are some business flows where the system out-of-the-box does not have ready-to-go algorithms. One such practice is called Consignment Sales. Instead of the dropship model where a seller does not possess the good but then instructs a supplier to ship directly to the customer, this model assumes that the selling organization takes possession of items (but not property rights; in essence, an agency relationship) to sell them direct to the customer. This model is more common in retail situations where the customer interacts physically with the item.
You often see this consignment retail model used in high-priced items. Consider art and jewelry type goods where the artist produces the piece but needs it to be promoted and sold by parties that have relationships with likely interested customers. Retailers can avoid inventory risk and working capital demands by not purchasing items but instead using its physical space and brand to promote goods and attract customers.
There can be many ways to conduct consignment sales. In this discussion, we will look at the practice from the perspective of the NetSuite organization that holds other parties (suppliers’) goods and then uses its selling capacities to “sell-through” the item. When the item is sold, an obligation is recognized to pay the supplier.
General Consignment Considerations
In this model, the key considerations are as follows:
- Receiving: How will the inventory arrive in the place for which it will be sold? Typically, we rely on purchase order planning and operations to inbound inventory.
- Inventory Ledger: even though we don’t own the inventory, we should track it as if we do. Using a “Consignment Location” as a sub-location to a real warehouse/store allows accounting to distinguish inventory that is not really owned but is in possession.
- Obligation Management: when inventory is sold, how do you record the obligations incurred in the deal?
- Recognizing Revenue: what is the revenue recognition policy? How will this be expressed on the financial statements?
These fundamental questions need to be answered before you can design your program.
A Consignment Application for Serialized Items
In a recent implementation, we assisted the client to automate a relatively simple consignment program that had the following features:
- Purchase Order / Receipts: the client used purchase orders and receipts for normal inventory operations. Upon receipts, the Inventory account is debited and the Inventory Received, Not Billed (sometimes considered accrued purchases) is credited. Accounting can reclass these amounts at the end of the accounting period as the inventory is not really owned by the organization.
- Serialized Inventory: each item had a unique serial number allowing for specific identification. This made it easier to identify the original acquisition transaction. Meaning, it was easy to join the revenue transaction (sales order/item fulfillment/invoice) with the disbursement transaction (purchase order/item receipt/vendor bill).
- Separated Inventory: inventory was held in a separate location making it easy to identify what was considered consignment.
- Obligation Due Upon Sale: the supplier obligation was due upon the sale. In this case, a vendor bill needs to be constituted at the time of the sale which sets up the payable.
- Differences in Purchase Order Price and Deal Parameters: an agreement was reached between the supplier and the client. Purchase orders will be used for traditional prices. But a delta price was held on the item master to help distinguish the “profit” earned on the sale.
In my mind, the deal parameters are the most interesting. Here, we need to consider the “commission” earned on the sell-through transaction. There are different ways to express this; as such, we can get creative with our accounting via transaction management. In addition, if the items are not serialized, we may have assumptions about how revenue is earned in the model.