Activity-Based Costing Software Top 3 ‘Must Haves’ – Part 1

Activity-Based Costing Software Top 3 ‘Must Haves’ – Part 1

I did some work for a client this month that I think was a little unusual in today’s world of technology, internet and the need to do things ‘now, now, now’.

Like the majority of our clients, this one was looking at developing an activity based costing (ABC) model.  But unlike most of our clients, they wanted to start with training.  Not training on how to use ABC software but basic training on what ABC was, what it could be used for, and most refreshing of all to me, what type of functionality and methodology should they pursue in their software platform to get the results that they were after.

I’ve been designing, implementing and maintaining ABC models for over 15 years and one of the more common trends that I’ve seen is that a lot of organisations tend to procure their software first and then try and ‘mash’ their requirements into the functionality that the software provides.  While a good proportion of organisations ‘list’ their software requirements in a RFP/RFT or similar, most of these requirements are quite generic in nature and unless the author(s) of the RFP/RFT are aware of some of the more sophisticated and complex functionality out there, they may not realise just what an impact a few of these may have on results that can be obtained from their finished model.

So back to the training I did this month.  After a full day of workshopping their requirements and obtaining a better understanding of what they actually wanted, I recommended Microsoft Excel.  Why?  They were small (both in budget and in personnel), this was their first attempt at ABC, and they wanted something simple.  And most importantly of all, they knew that their model would evolve once they started to understand more about the results, and therefore they didn’t want to be locked into software that, although it would satisfy their current requirements, may not satisfy them as their model methodology matured and grew more complex.

As part of the workshop that day, the client and I briefly spoke about my views on the top three ‘must haves’ when looking at procuring activity based costing software.  So here they are, in no particular order (because I think they are equally essential ):

  • the ability to report on not only the beginning and end of your model (the inputs and outputs), but all stages in-between;
  • the ability to track multiple cost types through the model; and
  • the ability to automate as much of the model allocation and maintenance as possible.

Now, I’m not going to go through all of these today, but I thought I would delve into the first one and then follow up on the others over the next few weeks.

So why I have listed reporting, and more specifically, being able to report on all stages of your model as one of my top three ‘must haves’?  Well, I think it’s quite logical – why build a complex model that has numerous allocations in it, each representing phases or stages in your business if you can only report on the beginning and end, and maybe a couple of points in the middle.

Let me give you an example:  most typical ‘top –down’ ABC models (as opposed to standard cost ‘bottom up’ models) will involve an extract of the general ledger for a given period (month, quarter, year etc).

But depending on the size of your organisation, you may wish to then allocate employee related expenditure through to personnel or positions (which in turn get allocated through to activities) and depreciation through to assets.

Because most software restricts you to three modules (Resources, Activities and Cost Objects (Products / Services etc)), you would be required to maintain a number of ‘resource’ structures within your resource module as shown here:

You would then need to allocate salaries and wages to personnel objects and depreciation to asset objects, all within the one module.

Technically this works well – your costs are flowing through the model and will continue on to the next stage of activities.  But there are a number of limitations to this type of solution:

  • What happens if you want to allocate facilities maintenance activities to the assets and have that cost ‘follow’ the asset cost through the model?  Very few ABC software products allow you to send costs backwards from the activity module to the resources module and even if it does, there are normally issues with reciprocal allocations being resolved properly.
  • What happens if you want to allocate other GL costs to your personnel using their respective salary costs as the driver?  Some software products allow you to ‘phase’ or ‘sequence’ your drivers, but even if they do, you wouldn’t be able to report on salary costs by personnel as nearly all software restricts reporting by module to ‘Start Process’ costs (that is, the starting cost of each object prior to allocations’ or the ‘End Process’ costs (that is, the finishing cost of each object).  In this instance, you would be after the ‘mid point’ cost for personnel, that is, the cost after the first phase of allocations, but prior to the second phase.
  • What happens if you want some users to be able to view the General Ledger component but not the Personnel allocations (due to privacy concerns)?  In this case, users would have access to the entire module and would be able to see everything.
  • And let’s look at the other end of the model.  What happens if you want to cost both products and customers?  Or services and customers?  The same limitations apply.  Although it is possible to do these in the one module, it really limits the reporting available to you.

My solution?  Insist on software that enables you to have as many modules as you want – it will provide you with the utmost flexibility from both a modeling point of view as well as a reporting point of view.  So, using the example above, this would be how I would set up my model:

Alternatively, I could have the assets module as my third module followed by activities – it all comes down to how you plan to allocate your resources and activities.

From a reporting point of view, this structure not only allows me to report on each module separately, but also the specific allocations from that module to the individual products and customers – nothing is hidden or lost in inter-modular allocations.

So, as I mentioned earlier, don’t be constrained by three modules and don’t let the software dictate how your model works.  Instead, make sure that the software you select can model your business how you want to see it.  For me, unlimited modules are a must!