Workday recasts the chart of accounts as sexy

by admin on March 9, 2012

in Industry

Is it possible that after over 600 years of debit and credit that you could make the chart of accounts sexy? That might be going a bit too far but that’s the direction Mark Nittler, VP financial products at Workday [recent product client] would like you to go. Talking up the recent Guggenheim Partners LLC deployment, he says:

The chart of accounts in traditional financial software often mutates into an unmanageable behemoth requiring additional custom software just to interpret it for data entry or unwind it for reporting, due to the limitations and rigidity of 30-year-old system architectures. And fixing something so deeply embedded is not only hard and unglamorous, it is also practically impossible, short of starting completely from scratch. So the chart of accounts doesn’t get fixed, and users of traditional financial software make do with clunky systems and workarounds.

However, if you do start over and rethink, redesign, and rebuild as we did at Workday, the results can be revolutionary. Our customer Guggenheim Partners LLC was able to dramatically reduce general ledger complexity with its deployment of Workday, which we talk a bit more about in a news release.

In Workday Financial Management, the rigid code block structures of traditional financial software don’t exist. Instead, Workday captures transactions as business events in order to create a comprehensive financial and operational view of a customer’s business. Customer-defined Worktags are tagged to transactional data and used to identify the key dimensions of the business that management would like to track and analyze, such as customer, product, region, and project. As a result, customers can vastly simplify their chart of accounts structure without losing critical business visibility.

OK – so it’s a bit of a pitch but this is a really big deal. Last year, as I evaluated the strengths and weaknesses of the financials solution, the notion of getting rid of the code block and replacing (most) of it with tags was such a brain dead obvious idea to me I was surprised no-one had thought of it before. Of course Workday can’t get rid of the whole code block hierarchy but it keeps it to a minimum.

The net result is as Nittler describes. But does it work in the real world? One of the exercises we went through was a re-organisation. We were in a live demo run over the internet and I asked the company to make some structural changes to the way in which the test system was set up. This was done by establishing new tags and then re-organising around the new tag structure. It took no time at all. Once the new tags were established and the analysis rules tweaked to take account of the way I wanted them to appear, the financial analysis was automatically updated. No rewriting of reports. It was just ‘done.’

From a line of business perspective, this opens up all sorts of new opportunities to develop analysis needed to run the business. Users are no longer constrained by what they’re given. Subject to security controls, they can create their own tagging systems to reflect what they need. Think about it for a moment: it no longer matters what the accounts function deem as appropriate tags or account codes. LOB people can define their own.

In the real world, nothing is quite that simple and organisations will have to think through how they choose to organise tagging systens. The difference is that if one system doesn’t work for whatever reason you can always scrap it and start over. Try doing that with a 72-character code block. It’s a non-starter yet one of the key reasons that organisations remain locked into old systems. I say that’s an opportunity to rethink the system of financial record not just as a static entity but something that forms the basis of bringing numbers to life.

Nittler closes out with:

Hot new technology is always cool, but re-thinking the basics can be sexy, too.

I never thought I would hear that said about anything to do with financial management software but then nothing surprises these days. Net-net: the code block is dead, long live tags.

Comments on this entry are closed.

Joe DeFilippo (@SaaSAccounting) March 9, 2012 at 5:52 am

Workday recasts the chart of accounts as sexy: Is it possible that after over 600 years of debit and credit that…

roddrury March 9, 2012 at 6:12 am

Interesting, we looked hard at Tags in @Xero when we designed our accounting engine and found that they weren’t ‘certain’ enough for financial reporting.  We do use them in Xero Personal though where they are ideal.  Tags are less formal and the problem we found was tags lead to double counting or incomplete allocations.
The problem we saw with Charts is that businesses try to stack reporting into a hierarchical structure and end up with repeating codes and complex structures.  Some schools I’ve seen have m,any hundreds of chart items and the administrators end up needing special knowledge to know what goes where.
So instead we took a relational approach for reporting with what we call Tracking Categories.  This means the Chart of Accounts can be much smaller and reporting is pushed into other relational dimensions. This also has the advantage of being able to pull P&L’s and other reports by Tracking Category.  It is also useful for allocations.
Tags certainly can be an additional categorization on top of a relational chart and very useful but Tags as a replacement for Chart of Accounts structure we’re not so sure about.
Great discussion to have though and I’d love to hear others thoughts and experiences. 

dahowlett March 9, 2012 at 6:32 am

 @roddrury  @Xero The environments that Workday operates in don’t require formal reporting. You can still establish a system that allows for standard summarised P&L, B/S and cash flow statements. That’s not difficult the way they’ve done it. 
But then any system that provides an easier way to do reporting has to be welcome.
I like what I’ve seen and in flight, WD has no problem handling millions of line items and hundreds of tags. 

Jason Currill (@ospero_JasonC) March 9, 2012 at 6:35 am

Workday recasts the chart of accounts as sexy – Is it possible that after over 600 years of debit and credit that yo…

(@jonerpnewsfeed) (@jonerpnewsfeed) March 9, 2012 at 6:36 am

Workday recasts the chart of accounts as sexy – by @dahowlett #ensw (via @jonerp)

anwenrobinson March 9, 2012 at 12:42 pm

This has been a fundamental concept with Agresso from day 1 whereby with a simple COA code structure, reporting relationships can be derived from account attributes where each transaction type can have different associated attributes if required.
This is the backbone behind our strapline ‘the system for businesses living in change’ as attributes and relations can be readily amended as the orgnaisiation changes without having to recode or bulk move transactions. Also as the organisation changes, reporting streams are therefore automatically updated with no additional overhead.

dahowlett March 9, 2012 at 2:03 pm

 @anwenrobinson  – in the WD world, there is no need for balance tables as such and you can do the whole thing while ‘in flight’ – very little by way of hierarchy needed although at the back end and hidden away from the user, WD does that heavy lifting in order to present the info needed. This presents other challenges but that’s a different topic. 

(@SAP_Jarret) (@SAP_Jarret) March 9, 2012 at 2:03 pm

Speaking of “sexy” @dahowlett & @NathanGenez talk about #Workday & FI (COA)

(@SAP_Jarret) (@SAP_Jarret) March 9, 2012 at 2:14 pm

#Workday recasts the chart of accounts as sexy by @dahowlett ->Usability & design sounds VG.

greg_not_so March 9, 2012 at 2:33 pm

@SAP_Jarret not clear about ‘code block’, but (XBRL) tags are here to stay

Naomi Bloom (@InFullBloomUS) March 9, 2012 at 3:18 pm

RT @dahowlett: Fresh content: Workday recasts the chart of accounts as sexy #industry

Cody Nelson (@NelsonlakeO) March 9, 2012 at 5:58 pm

RT @dahowlett: Fresh content: Workday recasts the chart of accounts as sexy #industry

Mark Phillips (@markcphillips) March 10, 2012 at 7:22 am

Post Sarbanes Oxley #Financial systems must enable effective analytical reporting. How #Workday delivers.

Irene Becker (@justcoachit) March 10, 2012 at 7:59 pm

RT @SAP_Jarret: Speaking of “sexy” @dahowlett & @NathanGenez talk about #Workday & FI (COA) #hr

tconnolly March 12, 2012 at 12:12 pm

I agree wholeheartedly with you on this Dennis. I have often felt the use of the Chart of Accounts to represent the basis for all analysis of business results as being hugely restrictive and limiting in terms of ability to amend as an organisation develops and grows. Any structural changes require a major revamp of the General Ledger and usually means all comparatives are lost as a whole new Chart of Accounts needs to be implemented.
This is why we designed a separate user definable business analysis structure to augment the Chart of Accounts in accountsIQ (, You can start with a simple Chart of Accounts and build the analysis structure as the business develops. You can also amend the analysis code structure and start coding new period transactions to the new structure without changing the Chart of Accounts or the historical figures attached to that Chart of Accounts. Linking history from the previous analysis structure is also possible.
Flexibility is the key as organisations develop and change. You need to be able to decide which GL codes you want to analyse further so you can gradually build it over time to cover revenues initially, then direct costs and then more and more costs that can be apportioned appropriately. The other clear advantage is not needing to create a tonne of GL codes with all the possible combinations of GL accounts and analysis codes. Combinations are created either by setting up a budget for the combination, or coding a relevant transaction to the combination, unless you decide to restrict users from coding to combinations that do not have a budget.
Flexibility in designing the analysis structure is paramount allowing top-down (ie: define the analysis elements you need and then auto creating relevant code/tag combinations of those elements) or bottom up (ie: create the tags and point them to the analysis elements to which they relate). This allows for easier reporting. It is also critical in using an analysis structure in consolidated results for a group that some element of control over analysis structures can be imposed at group level, while also allowing for groups with disparate activities that require their own analysis structure.

Workday (@Workday) March 12, 2012 at 2:26 pm

“Workday recasts the chart of accounts as sexy” >new blog from analyst @dahowlett #EnSW #finance #cfo

CloudERP (@CloudERP) March 12, 2012 at 2:33 pm

RT @Workday: “Workday recasts the chart of accounts as sexy” >new blog from analyst @dahowlett #EnSW #finance #cfo

CloudERP (@CloudERP) March 12, 2012 at 2:38 pm
Eric Perry (@chiefmarketmakr) March 12, 2012 at 5:47 pm

RT @Workday: “Workday recasts the chart of accounts as sexy” >new blog from analyst @dahowlett #EnSW #finance #cfo

Workday (@Workday) March 13, 2012 at 2:27 pm

Dennis Howlett blogs on Mark Nittler’s view that financial management software can be sexy via @dahowlett #CFO #EnSW

rayskyy March 13, 2012 at 3:37 pm

In my experience tags are really a product of more modern ERP and their easier approach.  Using generated accounting codes based on segment definitions is very 90′s.  That whole idea makes things (from a GL standpoint) very complex and inflexible since these have to be defined up front – essentially predicting the future. 
Tags work well and if structured and validated right – do not create an allocation issue.  It does create maximum flexibility of course and makes reporting a breeze. 
Actually – this is one way you can tell whether the ERP SaaS product is fake SaaS or not -  because no one in their right mind would do a segmented (or coded) GL structure today. :-)  

Chris Spivey (@ChrisSpivey) March 13, 2012 at 8:38 pm

RT @Workday: Dennis Howlett blogs on Mark Nittler’s view that financial management software can be sexy via @dahowlett #CFO #EnSW

Previous post:

Next post: