This article will explain what a System Posted Cost of Sales Adjustment is in NetSuite, how to recognize it, and potential solutions.
Within NetSuite, you might find that the General Ledger (GL) impact of a transaction has changed, sometimes even weeks after the transaction has been recorded. When you check the System Notes for that transaction, you'll notice there is no user indicated; it’s solely the system making the change.
Figure 1. System Notes of an assembly build transaction showing the GL impact update made by the system.
As shown in Figure 1, updates to the GL impact of transactions occur without any user involvement. In this situation, the system has posted a Cost of Sales Adjustment. In the following sections, we will dive into what a Cost of Sales Adjustment is, how to identify it, and ways to resolve it.
Origins of the Cost of Sales Adjustment
This adjustment arises during instances of negative inventory. It’s important to remember that NetSuite reflects actual inventory conditions. Consider this scenario: if I have 10 units of inventory on hand, and the warehouse operator fulfills an order for 50 units, what’s going on?
Clearly, the warehouse operator didn’t create 40 extra units from nowhere. The problem lies in the fact that the initial quantity of 10 was inaccurate.
NetSuite processes costing in a specific sequence; when those numbers do not align, the system will estimate the GL impact of that transaction accordingly. When subsequent transactions correct the quantity, the system then applies an adjustment.
The method NetSuite uses to determine which orders to calculate is detailed in this article.
The estimates provided by NetSuite align with your inventory costing preferences. Refer to Figure 2.
Figure 2. The Inventory Costing Preferences can be found under Setup > Accounting > Inventory Costing Preferences.
Consequences of the Cost of Sales Adjustment
Example 1: Negligible Impact
For a number of transactions, there are few to no consequences.
Imagine from Inventory Item X, there were originally 0 on hand:
May 1: 10 units were fulfilled as part of a Sales Order.
May 2: An Inventory Adjustment occurs to establish the original inventory balance of 100 at $10/unit, setting the inventory value to $1000.
As a result, the system would automatically adjust the GL impact of that Inventory Adjustment from $1000 to $900 because you genuinely have 90 remaining, which were valued at $10 per unit.
This is beneficial! NetSuite has saved you the effort of correcting the inventory values.
Example 2: System Errors
However, in other cases, particularly with multiple transactions, a mistake can cascade through the system.
For instance, if Assembly Item Y is transferred and subsequently built, consider the following scenario: there are 0 units of Assembly Item Y at Location A and 10 units at Location B (with a total value of $100).
May 1: 10 units of Assembly Item Y are transferred from Location A to B. Since there’s no value of Y at location A, the transfer shows a cost of 0. This results in the total value of all 20 units at Location B staying at $100, causing your unit cost to drop from $10/unit to $5/unit.
May 2: An assembly build of 10 units of Item Y occurs at Location A ($10/unit).
Initially, the assembly’s value at A will be shown as $100.
The system will later correct that assembly because the transfer resulted in negative inventory, and the build adjustment will show a Cost of Sales Adjustment reflecting a 0 value.
Nevertheless, the inventory at Location B will not be updated.
Cases like this second example may necessitate corrections.
Locating the Root Cause of the Error in NetSuite
The most effective way to track down this issue is to utilize the NS standard report "Inventory Valuation Detail."
By referencing this report, you can narrow down specific locations to understand what went wrong with the transactions.
Figure 3. Inventory Valuation Detail showing assembly item 0036-P50 over several days.
In Figure 3, you can see that on 9/6, the Inventory Transfer drops the quantity on hand below zero while the assembly build restores it. While it may initially appear that the assembly build occurs first, the system notes reveal that the transfer took place just moments before the assembly.
Steps to Resolve the Underlying Issue
First, it’s crucial to inform everyone involved in the process about the overarching issue they may be causing. Implementing proper training and controls is essential. Negative inventory occurrences should be rare. Additionally, if periods in NetSuite have been closed, then the negative inventory issue must be rectified.
Next, assess how precise the resolution needs to be for your organization. Some companies might demand thorough fixes, whereas others may be satisfied with a long-term solution if the immediate impact is minimal.
In the scenario depicted in Figure 3, several items went into negative balance when IT4867 was created. This could lead to incorrect costing of multiple assembly items, resulting in various Cost of Sales Adjustments.
Figure 4. Only one assembly item in the transfer remained unaffected during IT4867, resulting in just one entry being posted.
I recreated the transfer so that it occurred on the same day but later, as shown in Figure 5, with the updated GL impact.
Figure 5. All assembly item values are successfully transferred to the correct location due to the systematic timing of the transfer occurring after the assembly builds.
In every instance, identifying the root cause is critical. The Inventory Valuation Detail facilitates spotting the issue. It could be a case of an item receipt being recorded a few days after fulfillment or poor warehouse management practices, which led to numerous inaccuracies in inventory counts. This underscores the significance of following best practices in the system.
