NetSuite has some great tools to help finance teams with month-end close. One of my favorites is the Amortization tool which automates expense recognition over time when a company has paid for (or been billed for) an expense in advance, but the expense needs to be recognized slowly over time.
However, like most out-of-box tools, the Amortization tool solves for a specific business pattern. The tool works well when a vendor sends a bill for the expense entirely in advance, the bill is paid for soon afterwards, and the prepaid expense needs to be booked subsequent to the billing and payment. However, when a company has billing and expense patterns that do not fit this model, the amortization tool is not really effective on its own.
Sample Accrual / Amortization
Consider the following common scenario: A company purchases a software license which needs to be renewed each year. The company needs to pay the contract amount in 3 installments – March, June, and December; and the vendor sends a bill for each installment when it is due. Yet, the expense must be recognized equally over the course of the year, starting January.
If we analyze the situation described, we can see that the expense recognition pattern does not match the billing and payment pattern (12 equal expense parts vs. 3 billing and payment parts) and therefore does not really fit the Amortization model, as the Expense recognition begins prior to the bill and payment, whereas NetSuite’s amortization tool needs to start subsequent to an initial transaction.
Another challenge that this use case presents is that the billing is taking place before the expense is completely accrued. In most accrual situations, the expense is eventually entirely accrued prior to the bill entry, which allows for simple monthly accruals using a reversing technique. Since in this example the bills arrive mid-stream, the reversing technique will result in incorrect expense amounts in the periods billed and in the final accrual period.
In situations like these, it is easy to get confused about the different parts to the business flow. Typically, companies will resort to spreadsheets to stay on top of accrual and prepayment balances, book manual journal entries, and then have to worry about spreadsheet versions and be sure that it is an accurate representation of the transactions booked in NetSuite.
Fortunately, NetSuite is flexible enough to tackle this sort of problem and get us out of the spreadsheet quagmire. The trick to solving this problem is to parse out the components into distinct parts. What we really have here are three separate flows going on concurrently:
- Expense Accrual Pattern
- Billing Pattern
- Payment Pattern
Next, we think about GL Accounts. Which GL accounts does each entry type need to hit? E.g:
- Expense Accrual: DR: Software Expense, CR Accrued Expenses
- Billing: CR Accounts Payable, DR Prepaid Expenses
- Payment: DR Accounts Payable, CR Cash
Now that we have an idea of how each transaction should look, we can think of a way to link these transactions together and automate as much as possible.
Step 1. Enter a PO for the expense
Using Purchase Orders for Expenses is good practice and allows for transparency in the Procure to Pay cycle, it also lends itself to good controls and approvals. In our example it can serve as a repository of all the different transaction types needed for the Accruals and Bills.
Step 2. Set up a Memorized Journal Entry and Link it to the PO
Memorized JE’s are fairly easy to set up. The way to link them to the related PO is to create a custom sublist on the PO record, and a custom field on the JE form to serve as a “key” to associate the JE’s to the correct PO. An underlying Saved Search will also be needed. See SuiteSolution articles 10120 and 48803 for help on this.
For even stronger capacity, instead of Journal Entries, you might consider using a Custom Transaction Type specifically for Accrual Journals. Custom Transaction Types are a great tool for a variety of purposes and I hope to expand on this more in a separate article.
The below images show how the transactions and sublist can appear. Note the “Scheduled” and “Posted” statuses, which are possible using the “Custom Transaction Type” approach.
Step 3. Bill against the PO, but use a GL Reclasser
Here’s the fun part of the process. We want to enter bills against the PO and allow users to understand what is being billed, yet the GL impact needs to hit a Prepayment Account in our model (see above). A great way to accomplish this is to use NetSuite’s GL Reclasser plugin which allows us to reroute the Bills to our Prepayment Account instead of to the normal Expense account on the PO.
Out of the box, this feature takes some scripting, but Prolecto has a great bundle that makes this tool easy to use, even for non-developers. See Marty Zigman’s article here. The key to making this efficient is to associate the GL reclass “profile” to the PO. Then, any bill created off of the PO will automatically get the right GL impact, while preserving the presentation we want – showing which expense the Bill ultimately relates to.
There’s even a simpler way, too. An item can be set up that can be routed to a Prepayment account, yet the item name can be descriptive enough to explain the nature of the charge. This method would work if Expenses of the type being accrued are only and always used in the same pattern of prepayment/accrual.
Step 4: Pay the bills
From here on this is native – the Bills will be paid as part of the normal bill payment process.
Step 5: Reconcile the Prepayment and Accrual Accounts
When we take a look at the GL impacts, we see that the transactions would result in a balance in the Accrued Expenses Account and the Prepaid Expenses Account. (Recall that the Accruals are hitting the Expense GL and our Bill hits Prepayments.) We want to offset the Accrued Expenses Account against the Prepaid Account. This can be done in a number of ways. Some companies prefer to keep things simple and use the same account for both Prepayments and Accruals, using the polarity of the account balance (Credit or Debit) to indicate a net Prepayment or net Accrual. However, since in our technique we are tagging the Accruals with a PO number, we can leverage this field in a saved search to summarize balances in the Prepayments and Accruals accounts and assess when to enter a Journal Entry to offset the balances and adjust a balance if necessary.
Conclusion
Once we clarify an approach such as the above suggestions, we can extend the solution with scripting as well – if appropriate. For example, I would consider automating the memorized Accrual Journal based on information on the PO, perhaps using some custom fields or a suitelet to hold the info needed to generate the Accrual Schedule.
Of course, the above is just one example of a use case – there can be many variations. For example, payments may occur in advance of billing, in which case I might consider using one of several Prepayment solutions in tandem with the above proposal (see related article here).
If you found this article interesting and would like to learn more about creative ways that NetSuite can be leveraged to improve your accounting practices, feel free to reach out to me at Prolecto. I’ll be happy to hear from you.