Chapter 13: Financial Transactions and Period Closes

The bookkeepers, accountants, and financial managers within any organization will learn to love the flexibility that NetSuite provides them with to work with Journal Entries, Period Closes, and more. You need to learn how to make sure your client's financial experts and accountants are satisfied so that they'll be able to complete their tasks every day, including at the end of their financial periods, with NetSuite.

In this chapter, we will cover the following topics:

• Setting up and using the General Ledger
• Implementing Currency Management
• Setting up and using banking features
• Using Journal Entries
• Performing and managing Period Closes

Your client's financial managers, bookkeepers, and accountants will be your main contacts for the topics covered in this chapter. They should have already completed the NetSuite Foundations training before you begin training them further on the system's accounting features. By the time you walk the client through these topics, the users will be able to navigate and use the finance and accounting features themselves.

Setting up and using the General Ledger

As we discussed in Chapter 6, Understanding the Organization's Accounting and Finance, most clients will know what they want their Chart of Accounts (COA) to consist of when they transition into the cloud. NetSuite does come with a COA list in every new account, just in case you ever work with a brand-new company, but in most cases, we remove those accounts early in the project and replace them with the company's list. Most established businesses will have accounts they need to import and use right away. We typically help each client import their COA from a CSV file since this is relatively simple to do (and this helps the financial users become familiar with using the CSV Import feature). The good news here is that the system offers a wide variety of account types (expense, income, credit card, and so on), which should satisfy most business accounting needs.

Important Note

Remember that when a business has a OneWorld account and uses multiple subsidiaries, everything about their finances and accounting is more complicated. Each of the features explained in this chapter can handle this requirement when needed, but doing so makes everything from transactions to closes to reporting more powerful, and so more complex.

The COA can become a topic we spend considerable time on when there are multiple subsidiaries in a OneWorld account – for instance, if the client's business is broken up into multiple main legal entities, and they each have a hierarchy of subsidiaries within them. We can model the list of Subsidiaries within one NetSuite account easily enough, but setting up and getting that hierarchy just right, including being able to eliminate subsidiaries and accounts, is key here since all other General Ledger (GL)-related activities in the account will depend on this being done correctly. In rare cases, we need to take that a step further and set up Multi-Book Accounting.

Note

We won't have enough space to cover this topic in this book, but you can start to learn more about this within the NetSuite Help pages – read the Accounting heading for more on all of this chapter's topics.

The next step in this process is typical for helping users become used to NetSuite's approach to posting into the GL. Since other applications have different names for some transactions or are lacking some of NetSuite's transactions, it helps the users know which transactions are posting and which are not. Some accounting users might start an implementation project with the expectation that their Sales Orders should post to the GL, for instance, but a quick explanation of why NetSuite considers these to be non-posting transactions usually sets them straight. (The answer is that the items on a sales order might change or be removed before they are fulfilled/billed to the customer.)

There are many other related NetSuite features within this financial/GL heading, but not every client company will need to use them. If your client has multiple subsidiaries that do business with each other, you'll want to research what NetSuite calls intercompany accounting more. If the business needs to track non-monetary data about the financial reports, they should check out the NetSuite Statistical Accounts feature and its possible uses.

For companies who only ever conduct their transactions in one currency, accounting management is relatively simple. Let's explore what it looks like when multiple currencies are in play.

Implementing currency management

NetSuite is available globally now, which means that it must support everything businesses in various regions around the world require. That includes things such as language translations and data storage rules for the EU versus the US, for instance, and this also means we need a set of features related to currency management. When a business tracks all of their work in just one currency, they can set that as the default and then use that one currency for all transactions and reports and so on. But many companies today work in regions where multiple currencies are required, and NetSuite has them covered – for the most part.

The Multiple Currencies feature can be enabled by going to Setup | Company | Enable Features. At this point, the business must select a base currency to act as their default (that is, most common) currency for transactions and reports. Every other currency they enable will be referred to as a foreign currency. For example, if Ottawa Soaps is a manufacturer in Canada, they might need to buy and sell things in both CAD and USD (Canadian and US Dollars). CAD will be their base currency and USD will be a foreign currency for them. Note that NetSuite sets the default for the base currency based on the country the business is primarily set up in, and you can only change that value before any transactions (of any type) are created in a new account.

Once you've established the currencies that will be used within the account, you can start applying those to entities such as customers and vendors, and on every transaction with currency amounts (for example, Item Fulfillment doesn't have any currency-specific amount fields).

In addition to helping the client get this set up, there are a few other topics you should cover with a client who has this requirement. We'll check them out in the following sections.

Customer and vendor currency lists

Each customer and vendor record in the system can be associated with one or more of the account's enabled currencies. In most cases, most clients are OK to set up the list in advance for their account and then allow all customers and all vendors to use that list. If the client wants, though, they can remove entries from the currencies list on a per-customer/vendor basis. For instance, maybe your client's company has a US business and a worldwide business, and the US customers are only allowed to transact in USD, but the worldwide customers can use USD, euros, or pesos.

This is what the Currencies list of a typical customer record might look like:

Figure 13.1 – The Currencies list, on a customer, on the Financials subtab

We can add currencies to this list and remove them as needed, on a per-customer or per-vendor basis, as needed. NetSuite automatically tracks the BALANCE and UNBILLED ORDERS amounts in those lists for us.

Exchange rates for multiple currencies

Once a company starts tracking its transactions using more than one currency, it usually becomes important to plan how it will handle exchange rates between those currencies. For reporting reasons, the business needs to know how much they bought and sold in any period, and it's usually easiest to do this by converting those so-called foreign currencies into the account's base currency. Some reports are defined to show both the foreign currency amount and the converted base currency amount, but this all relies on a well-managed exchange rate solution within the account.

Out of the box, the system has a screen we can visit to set up the initial exchanges rates when we're first starting. Go to Lists | Accounting | Exchange Rates. You'll see the currencies that are enabled there and a row in the list showing the exchange rate for converting from each of the foreign currencies into the account's base currency. You can set up new rows in this list whenever you need, for instance, to define the exchange rate for a new currency you just set up, but the base currency is always chosen first for any exchange rate entry. We can set an effective date at this time as well.

As part of getting the client live, though, they will most likely want to enable an exchange rate syncing service, such as the one NetSuite offers. To enable this, visit the Enable Features screen, and then the Company tab. When enabling the Exchange Rate Integration feature, you'll need to visit the Accounting Preferences screen (Setup | Accounting | Preferences) to select from the list of available exchange integration providers. NetSuite contracts with these companies and the list can change over time.

Currency reporting is another level of complexity we learn to handle when we use the currency features in an account. You may be asked to help the users with formatting for numbers and currency symbols, which the system can help you with. Some accountants will have interesting ideas about how their reports need to arrange the data or which numbers to show from each transaction (the base currency or foreign currency amounts, for instance). Just work with them and the features of the system to accommodate each request.

Next up, let's talk about the banking features NetSuite provides out of the box since this is always an important topic for the accounting users we work with.

Setting up and using banking features

NetSuite offers a variety of features around banking (deposits, checking, credit card handling, and reconciliations). Many of those features can be automated in some sense (depending on the countries involved) via imports and exports.

Important Note

Always remember that there are special permissions for most of the banking features, so unless you access NetSuite with the Administrator role (which only a few people should do), you will need someone to grant your role these permissions before you can access the features. Read the Help page titled Permissions for Banking Features for more information.

Your job in helping the client set up these features will be to know them well and to know how to tweak them if that's needed. For instance, features such as Deposits and Write Checks are easy enough to learn, but your client might want to adjust the deposit slip or check the templates the system uses when printing those things (if they still print them to paper, of course). The automated payment and reconciliation and bank feed features all require some fairly technical assistance to set up correctly. There is a multitude of bank data formats in use today. Selecting the right format from the list NetSuite offers is a good start, but we frequently need to make tweaks to formats to get to 100% compatibility. Or, your client may work with a financial institution that NetSuite doesn't already know about, and in those cases, you'll be setting up a format, and the related data, from scratch.

The system has a good number of features built into it for handling basic bank data, but you can also check out the SuiteApp Marketplace via any account to learn about and install tools from NetSuite for a bank statement and feed imports. There are third-party tools there as well for companies outside the US with region-specific banking requirements or situations that require other, more advanced features.

Once you have the basics in place for the business' COA, currencies, and banking, we can move on to working with the accounting team on how they will use Journal Entries throughout their business, when they need to make adjustments to GL balances directly.

Using Journal Entries

There are many reasons we end up with entries in the GL within an active NetSuite account. Some of those are user-initiated and some are system-generated. For instance, users create GL-posting transactions such as Invoices, Payments, and Journal Entries and in some companies, users will need to create Advanced Intercompany Journals (AIJs) as well. The system auto-generates a variety of journals as well, for things such as Fixed Asset Management and Revenue Recognition. In most cases, we want the accounting team to know about the system-generated journals so that they can anticipate their impact on the business (and tweak them in the rare cases that this is needed). When a client requires a custom solution for things such as journals or the GL impact of other transactions (via SuiteScript), we want to be very careful both when delivering such customization (with ample testing, for instance) and afterward, as we also need someone to actively monitor the customization once it's in place.

I have been involved in many projects where we developed and tested a solution that customized the GL impact of transactions, or posted new journals to change the GL balances as the customer required, and in one of those cases, the customer reported much later that the scripts had been causing the wrong accounts to be debited and credited for the wrong amounts. Always remember that messing up a sales order is bad (the customer will not be happy if they don't receive the right items, for instance) but messing up thousands of journals could conceivably ruin a business completely if they cannot complete an audit, or worse. If you're the functional consultant on a project, make sure you either have the right experience to handle a task like this, or work with someone who does.

Let's look at some uses I've come across for (user- and system-generated) Journal Entries in the system that you might not already be aware of or that might just require some additional explanation.

Reversals

There will be times in many businesses where a journal is created for one GL impact but you must reverse that impact later. You can handle this with a standard journal entry transaction by entering a reversal date on the forms. These reversals are automatically linked to the original journal they reverse. Here's what this looks like:

Figure 13.2 – Entering a journal with a reversal date

The system defaults the Reversal date on these transactions to the current date, but you can change that if you need to.

Advanced versus normal ICJs

When your client's business has more than one subsidiary and they buy and/or sell goods or services between them, we frequently use ICJs to record the details. Before NetSuite version 2017.1, we just had ICJs for this, but then Advanced Intercompany Journals (AICJs) were introduced. The advanced version is now the default and the non-advanced version is available only as a legacy feature. The AICJ transaction allows us to specify both a From subsidiary and one or more To subsidiaries, allowing for more complex transactions when they're needed.

Revenue recognition

Companies such as software and services companies frequently need to control when and how they recognize their revenue since they don't primarily deal with goods in physical form. There are complex rules for accounting around revenue recognition (rev rec) in each country, but the system enables them via its Advanced Revenue Management (ARM) module. This set of features will automatically include system-generated journals to record and adjust revenue based on the transactions being entered and their details. Setting up and training users on this module requires additional skills and experience, but you can learn more about this via the ARM Help pages in the system.

Elimination

Businesses with a parent company and subsidiaries frequently need to track the profit or loss involved in doing business between these entities. NetSuite makes this relatively easy with elimination journal entries. This is typically very important for these companies since, without these journals, their financial reports will not be correct. An elimination journal in the application is the same transaction we use for other purposes, but it is associated with an elimination subsidiary.

Here is an example of a simple subsidiary hierarchy showing how Elimination Subsidiary fits in:

Figure 13.3 – A typical subsidiary hierarchy with a parent company

Placing Elimination Subsidiary in this position, below Parent Company, allows the users to create elimination journals for any of the subsidiaries at the same level or lower in the hierarchy.

Statistical journals

All the previous journals record monetary values the business needs to track as it goes about its day-to-day or month-end processes, but there might be times when your client needs to record journals for amounts other than money. For example, if your client provides cloud-based computing services and it wants to track the total number of terabytes of storage offered, it can do so with statistical journals. Once this feature has been enabled in an account, these transactions can be created in the same way we create financial journals, except we track a specified unit of measure (for example, terabytes or square feet of floor space) on the journals instead of currency amounts. These records can be edited, deleted, approved, reversed, and imported as needed.

Once your client is comfortable with using the various types of journals within the system, you can help them plan and practice performing their Period Closes. We'll check this out next.

Performing and managing Period Closes

A Period Close in NetSuite is a flexible thing, and many companies find it's a little too loose out of the box. This depends on the business though and what they're used to from their legacy ERP system. Some companies need to keep transactions editable from one period to the next in case edits are needed as working conditions change over time. These companies will do well to use the Period Close feature's minimal settings. However, many other businesses would be horrified at that thought, so they need to have the system lock down each period as they close it, to keep their reporting accurate over time. These NetSuite clients will need to understand how the Period Close feature can be used to lock their transactions and reports in place. They almost always already have a process in place and policies for this, so now they just need to understand how to implement those policies with NetSuite's various features. The Period Close Checklist screen is a very handy feature for users who will perform these activities in their accounts.

This is what the native Checklist screen looks like for closing a period:

Figure 13.4 – The Period Close Checklist screen, partially completed

Here, you can see that NetSuite will try to help the accountants with the steps in the close, including things such as resolving date/period mismatches and consolidating exchange rate calculations.

You should have already set up periods in the account that match as closely as possible those the business currently uses. In a brand-new account, you'll find that the system has already created 12 periods for the current year, one per month. We can replace those periods with any of the supported alternative options. For instance, a client might want to use the 4-4-5 weeks option to change the duration of their periods. We can always create new periods for the future, but we can only replace the current periods when no transactions have been assigned to the period yet.

For businesses using the Period Close feature to lock their account down within each period, you can help them understand the additional permissions that affect closed periods. Let's see which ones.

Manage Accounting Period

This permission allows the user to work with accounting periods, create them, change them, and so on. This is separate from the permission needed to perform Period Closes.

Override Period Restrictions

Closed periods can be reopened (in rare cases, only when necessary) by any user with this special permission associated with their role. This permission also allows the user with this role to add and make GL-impacting changes to posting transactions in periods that have been locked for transactions. For example, if the business closes the April 2020 period but then realizes they incorrectly reported a liability, they might want a senior accountant to make a change to a transaction to correct this. A user can only do this if they have this "Override" permission. This can be key for certain users who very rarely need to make changes that would otherwise be locked down in their accounts.

Period Closes within the system can be performed on any day, and that should work well with most of your clients' schedules. A typical accounting department doesn't close the previous month on the first day of the following month, for instance. Learn to use the close features yourself, and then work with the accountants to practice closes at least a couple of times during the implementation, before going live, to make sure there will be no issues after that date.

Most accountants believe a successful Period Close is the most important thing they can do in the system. Getting the financial reports to be 100% accurate and complete is critical if the company is publicly traded, but this is very important to privately held companies too. Practicing this with these users and getting any issues handled before going live is yet another key to the project's success.

Summary

There are so many accounting and finance-related features in NetSuite that we couldn't possibly cover them all in this book. We learned about the general ledger, currencies, banking, and Journal Entries in this chapter. You will almost certainly learn more while implementing your clients, but hopefully, this chapter has gotten you started and given you some pointers in the right direction. To become more familiar with these features, read the Help pages and SuiteAnswers under the Accounting heading and stay up to date with new features as they are rolled out twice a year. And as always, there are lots of resources outside of NetSuite now as well.

In the next chapter, we will focus on the Procure to Pay transactions, such as purchases and receipts, vendor bills, and payments.

Self-assessment

Think about these questions in terms of your client work and consider how you would handle these requests on your own:

1. You are beginning to work with a new company when they ask you whether they will need separate NetSuite accounts for each of their legal entities. They are somehow convinced this will be necessary, based on a conversation they had at a convention with another company's CEO. How will you guide them to the right solution?
2. Your client has asked you to set up their account so that currency exchange rates are only evaluated and updated once per year. Is that an option within NetSuite and if so, how would you help them set that up? (Hint: You won't be using the native exchange rate syncing feature.)
3. You are helping The Toy Company implement NetSuite, and they've asked you how they can control the GL impact for their item fulfillments and invoices so that one type of income is applied in a way that NetSuite doesn't support out of the box. What type of customization might help them achieve what they need?
4. When a company uses a bank that is not in NetSuite's supported financial institutions list, we have to set up custom bank file formats for them. Do you know where to go in the Help pages to learn more about this?
5. The company you are working with tells you that they must lock down their accounting periods regularly as the accuracy of their financial reports is key. But they also insist that two users need to be able to change any data on transactions, even after their period has been fully closed, going back any amount of time. Can you help them achieve both of these requirements somehow, and if so, how will that affect their financial reports for a period where amounts have been modified?