Skip to main content

I am prototyping the use of subaccounts for the chart of accounts/general ledger. As I am starting to play with this, I am getting flashbacks of previous experiences attempting to use Inventory subitems with Acumatica, which I considered to be a mess. It seemed like the general consensus when I brought up inventory subitems a couple years ago was that inventory subitems were anachronistic and had been useful when the software was at a less mature stage, but now were not considered best practice and shouldn’t be used for a system setup from scratch (they were still there to enable legacy upgrades, etc).

Does anyone have any similar experiences with general ledger subaccounts? I recognize the old “subitem 0”, which was the same as for the inventory subitems. With inventory subitems, if you didn’t want to use a subitem, you couldn’t just have item number 43434. It had to be 43434, subitem 0. Which makes for a lot of extra fields and database entries in the system for no perceivable benefit and is kind of confusing for the users.

Can anyone give some advice on general ledger subaccounts, yes or not? I recognize there is some benefit in keeping the chart of accounts smaller at the top level, as well as allowing for drill-down in the financials, but I also wonder whether these things can be achieved through other means now?

Hello,

The first thing I do when turning on subaccounts is change 0 to something else like 0000.  We do this by overtyping and saving.

I’d like to know the purpose of the subaccounts in your specific situation. Usually we want to record details in GL, for the purpose of GL financial reports, in more detail than just the GL account number provides. Examples are Sales Regions, Stores, or departments. Many times we have more than one segment, such as Sales Region then Store.  NOT branches or companies; branches & companies are separate fields already & you don’t want to duplicate data entry for them.

The subaccount doesn’t cause extra data entry, per se.  There is a checkbox in Chart of Accounts where you can say “Use default sub” with any particular account, then specify a default sub (0000?) in GL Preferences. The user would then be presented with a blank for data entry in the accounts where the extra details need to be selected with thought, such as Revenue & Expenses. It’s common to use 0000 (or whatever format you need) with balance sheet accounts and other subaccounts with revenue and expense.

HTH

Laura


Hi @laura01 -

The debate sort of boils down to this. Do we use “branches no balancing entries” or “no branches”. If we use no branches, we can still segregate financial information by subaccount to keep of inventory transactions by branch, and we can still have multiple warehouses in order to segregate inventory by branch location.

I’m trying to understand what ends up being simpler in the end. For example, if you use “branches no balancing”, then the sales order form always has a branch selection and a warehouse selection for every line item. The branch selection can be auto-filled based on the user, but it is kind of extraneous for our purposes. We want to know what warehouse the inventory is coming from, and be able to transfer inventory between warehouses, but we don't really need to assign orders to a specific branch per se. So in this example, using branches adds some additional overhead to the sales order process that would go away if we didn't use branches.

Another example is that you could transfer inventory between branches in a little more straightforward way if we can use one-step transfers instead of two to do inventory moves (with probably an in-transit warehouse as an intermediary).

I’m not sure of all the tradeoffs between doing it one way versus the other, so I’m looking for some feedback on potential pitfalls.

 

Thanks,

 

Jonathan

 

 


Hello Jonathan,

To make sure I understand you: your company doesn’t actually have Branches/locations.  You have multiple warehouses. You need to report out of the GL by warehouse. 

Subaccounts as warehouses might look like this:

  • 0000 - General/Administrative (no warehouse)
  • 1000 - Warehouse 1
  • 2000 - Warehouse 2
  • 3000 - Warehouse 3

For every account that is not inventory-related, you can check ON ‘Use Default account’ in the Chart of Accounts screen, and enter 0000 as the default account. This configuration cuts down on both data entry and mistakes in transactions that are not inventory-related.

In the Warehouse screen, you can default the subaccount properly for inventory-related transactions, thus cutting down on data entry and mistakes in inventory-related transactions:

 

Next, there are places in Acumatica where we choose the source subaccount for transactions. I’m showing Sales Order Types.  You’ll want to set these settings to Warehouse for inventory-related transactions, wherever possible:

Finally, I recommend setting up a test tenant where you can configure a handful of customers, items, and subaccounts and then enter inventory transactions. Receive, transfer, sell items, and then run GL reports to make sure you are getting the desired result on the data entry screens and also GL reports. 

Hopefully others will contribute more ideas and opinions for you. 

Best regards,


Hi Laura-

We do have branches. They are in separate cities. It is just that for financial purposes, we don’t have separate books for each branch. So we would use branches with no balancing entries.

This is where the flexibility of a system like Acumatica can also be a bit daunting. There are different ways to achieve the same thing. It isn’t always obvious upfront what tradeoffs you’re making by potentially simplifying certain things in the system (i.e. not having formal branches in the system), but perhaps losing some functionality in the process (i.e. perhaps certain branch specific functionality would simplify data flow through the system, and this would not be avaialble if we do away with the formal concept of branches entirely? Also...maybe branch functionality becomes better in future releases, and we’re making it harder to implement this in the future by commiting to this subaccount structure now?

 

Thanks,

 

Jonathan


Reply