In NetSuite, you may see that the GL impact of a transaction has changed, sometimes weeks after a transaction posted. When reviewing the System Notes of the transaction, there will not be a user indicated; the system is.
Figure 1. System Notes of an assembly build transaction where the system updated the GL Impact
Note that Figure 1 shows GL impact updates to the transactions that are not from a user. In this case, the system posted a Cost of Sales Adjustment. In this article, we'll discuss what a Cost of Sales Adjustment is, how to identify it, and potentially how to cure it.
Where the Cost of Sales Adjustment Originates
The adjustment occurs when there is a negative inventory situation. Remember that NetSuite reflects reality. Let's say I have 10 units of inventory On hand. The warehouse operator then fulfills 50 units in an order. What happened?
We know the warehouse operator didn't generate the 40 extra units from thin air. The issue was that the original 10-unit quantity was incorrect.
NetSuite performs costing in a specific order, and if those numbers do not add up, the system will make an estimate for the GL impact of that transaction. Once transactions occur to provide an accurate number, the system will perform an adjustment.
The way that NetSuite determines the orders to calculate is outlined in this article.
The estimate done by NetSuite follows your inventory costing preferences. See Figure 2.
Figure 2. Inventory Costing Preferences found under Setup > Accounting > Inventory Costing Preferences
Implication of the Cost of Sales Adjustment
Example 1: Minimal Impact
For many transactions, there are little to no implications.
Say from Inventory Item X there was 0 On hand originally
- May 1: 10 were Fulfilled as part of a Sales Order
- May 2: Inventory Adjustment occurs to set the original inventory balance of 100 @ $10/unit, setting the inventory value to $1000
The system would automatically adjust the GL impact of that Inventory Adjustment from $1000 to $900 because, in reality, you have 90 remaining, which were costed at $10/unit.
This is good! NetSuite saved you the work of fixing inventory values.
Example 2: Errors Through the System
For other transactions, say if multiple occurred, that error can propagate through the system.
Assembly Item Y is transferred and then built. Say There are 0 units of Assembly Item Y at Location A and 10 Units at Location B (Total Value at B is $100).
- May 1: 10 units of Assembly item Y are transferred from Location A to B. The system shows no value of Y at location A, so 10 are transferred at 0 cost. This means the value of all 20 units at location B remains at $100! Your unit cost dropped from $10/unit to $5/unit.
- May 2: Assembly Build of 10 of Item Y occurs at location A ($10/unit).
The assembly build will initially show the value at A to be $100.
The system will correct that assembly later because the transfer put the inventory into the negative – the build corrected it, so the Cost of Sales Adjustment will correctly update to show 0 value.
However, the inventory at Location B will not be updated.
Examples like the second case may have to be corrected.
How to Find the Initial Error in NetSuite
The best way to find this is to go to the NS standard report "Inventory Valuation Detail".
Here, you can isolate the location to determine what went wrong with the transactions.
Figure 3. Inventory Valuation Detail showing assembly item 0036-P50 over a few days
Figure 3 shows how, on 9/6, the Inventory Transfer brings the quantity on hand below 0 while the assembly build restores it. It appears that the assembly build occurs first; however, when reviewing the system notes, the transfer occurred minutes prior to the assembly.
Working to Resolve the Underlying Issue
First, the people working with the process must be made aware of the systemic issue they are causing. Proper training and controls must be set up. Items should rarely go negative. Additionally, if someone closed the periods in NetSuite, then the negative inventory must be addressed.
Second, you must gauge how specific the cure must be for your use case. Some companies may require everything to be fixed, while others (if there was minimal impact) may be okay with going forward as long as the issue is fixed in the long run.
In the case of Figure 3, Multiple items went underwater (negative) when IT4867 was created. Many assembly items will be incorrectly costed, and multiple assembly builds have Cost of Sales Adjustments.
Figure 4 shows the GL Impact for this 8-line Inventory transfer.
Figure 4. Only 1 assembly item in the transfer was not put underwater during IT4867, so only one entry posts.
I then recreated the transfer (such that it occurs on the same date but later in the day), and Figure 5 shows the updated GL impact.
Figure 5. All assembly item values are transferred to the appropriate location because the transfer occurs systematically after the assembly builds.
For each case, the root cause must be identified. The Inventory Valuation Detail will assist in spotting the issue. It may be that the item receipt posted a few days later than the fulfillment or that the company has poor warehouse management practices, and many counts of inventory are incorrect. This highlights the need to follow system best practices.
Prevent underwater inventory and close the period!
Got stuck in a step during this article?
That's all for now! We like to update our blogs and articles to make sure they help resolve any troubleshooting difficulties you are having. Sometimes there is a related feature to enable or a field to fill out that we miss during the instructions. If this article didn't resolve the issue, please use the chat and let us know so that we can update this article!