Explaining NetSuite’s Inventory Received Not Billed Account

This article is relevant if you seeking to understanding the meaning and value of NetSuite’s Inventory Received Not Billed (or Vouchered) account.

Background

A number of clients have asked me to explain the balance in the NetSuite’s “Inventory Received Not Billed” (IRNB) account. To help, I usually offer the following:

“NetSuite maintains a real time perpetual inventory system. When tracking inventory using the Advanced Receiving feature, NetSuite produces a mechanism to handle the differences between the inventory ledger and related purchase liabilities.  The IRNB account is used to accumulate these differences.”

This explanation though doesn’t really get to their question. Instead, they are really asking to explain the reasonableness of the account balance. Accordingly, let’s discuss the nature of this account and an offer for a saved search to assist with inspection.

Inventory Received Not Billed Account Orientation

NetSuite uses a system designated general ledger account (you can change the name and number, but not the actual account reference) to track the differences between inventory purchase operations and accounting. If your day-to-day inventory practices are well-designed and your related accounting operations work closely with the inventory team, the IRNB account can help you understand your outstanding accrual for vendor bills that have yet to be received but for which you have already taken item possession. Ideally, if you stopped producing purchase orders and you let the related vendor bills arrive, the IRNB account will eventually become accounts payable and net to zero.

However, the reality of the situation for most is more complex. NetSuite does a very good job producing real-time information. But to do so, it needs to operate, at times, with imperfect information. We start with the purchase order and we indicate a rate for which the goods will be acquired. This purchase order rate then becomes the cost used to receive inventory. At that moment, the inventory ledger is updated for both quantity and value. These values become immediately available for subsequent fulfillment transactions and thus are used for cost of goods sold calculations. This is how NetSuite can produce real-time information.

Yet, the purchase order relative to vendor bill may be different. It’s at this point we start to have significant considerations which affect the IRNB account. The underlying assumption in an item receipt transaction is that a) the quantity and b) the item was indeed received. It’s important we can trust that our item receipt records are tracking physical reality. For some, this assumption may not be reliable. But I am going to assume we can trust it for our discussion.

Next, if we want to have good real-time information, we need to have our purchase order rate be a close as possible to price we will pay (not withstanding landed cost; a topic I have covered multiple times). Once our vendor bill comes, we may find differences from the purchase order:

  1. Price differences: the price difference from the purchase order rate and vendor bill is the most common problem I see.
  2. Quantity differences: a quantity difference is interesting because if we have good inventory receipt operations, we then can debate with the supplier why their vendor bill differs from our item receipt.
  3. Exchange rate differences: in purchasing goods in a foreign currency, we likely will have differences between the item receipt exchange rate and the vendor bill rate.

If we receive our vendor bills fast enough, and the accounting periods are still open, we have an opportunity to modify the item receipt to match the bill. Scripting can help if this is cumbersome. Yet, in general, since most well-run accounting departments seek to close the accounting books as quickly as possible, the likelihood of vendor bills coming in after the close is greater. Once we close the period, we are not allowed to modify the item receipt record as this will affect financial information.

Since item receipt records will credit IRNB and vendor bills will debit IRNB, then any differences between the accumulated item receipt and vendor bill records are going to show up as “noise” in the IRNB account. IRNB will not net to zero. NetSuite offers tools to support accounting for the noise. The topic is called posting vendor bill variances (see NetSuite Help). Here, you can route to specific general ledger accounts the differences discussed above. NetSuite has a function to help you post journal entries to account for the variances; the offset to these accounts is IRNB.   Most important, these journal entries do not affect the inventory cost.  On another note, I have seen clients produce journal entries in the IRNB account. In general, the only place I support using manual journal entries is to reclass the account via an automatic reversing journal entry — but not to “fix” the account balance.

Variances in Inventory Received Not Billed Account and Inventory Valuation

Management generally will have a philosophy for how it accounts for inventory costs. It’s important to understand that variance accounting is effectively an inventory capitalization strategy. Variance accounting works quite well in a real-time accounting system especially if the amounts are small and / or immaterial. However, if the variances are material, the inventory capitalization implications become more meaningful as it affects financial reporting. Financial reporting ultimately shapes the decision making of key actors: namely investors and executives. The challenge is the trade off between real-time information and imprecision accuracy. Since this is philosophy, and it is shaped by industry guidelines, senior management often works to establish their practices accordingly. I can’t say much more until I understand your philosophy — so I will stop here.

Saved Search to Explain Inventory Received Not Billed

To assist in evaluating the IRNB account analysis, I have created a saved search to help explain the balance sheet value. The key report assumption is that purchase orders which do not have related item receipt and vendor bill variances close out and disappear. The ones that remain should represent only two key things: a) true accruals — our desired explanation and b) the timing differences between the variances. To know you can trust the saved search, we make sure you can tie the summary amount to the balance sheet.

In practice, when I assist clients in getting in front of this account, we take the saved search and refine it further. The saved search represents a very good starting point for an accounting analysis. We have put the saved search into our Financial Saved Search Library,  If you are a NetSuite end customer, you are welcome to the bundle. With no obligation, send me a request with your account ID and I will make it available to download. If you are in a situation and need a professional that understands accounting and NetSuite advanced Saved Searches, let’s have a conversation.

Be Sociable, Share!

Marty Zigman

Holding all three official certifications, Marty is Southern California's NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 25 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to setup a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - Google Plus - YouTube

| Category: Accounting, NetSuite, Reporting | 2 Comments

2 Comments

  1. Nikunj
    Posted November 28, 2017 at 8:36 pm | Permalink

    Can we block PO Price and amount from editing in the Purchase order. It should always default from the item aster

  2. Posted December 9, 2017 at 3:40 pm | Permalink

    Sure, you need to use some script to control the line edit function.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>