Why you should separate your "project accounting" and "general ledger"

Why your general ledger should be handled separately from your project management practices

There was a time when a software solution that integrated all of your processes into a single package was the obvious choice. Technology has rendered that idea obsolete, and best-of-breed is now the way forward.

Businesses are increasingly having to face the decision to replace their all-in-one software package with multiple, best of breed solutions. We've already talked about the merits of the latter, but let's dig a little deeper into why your general ledger should be handled separately from your project management practices.

Then vs. Now

There was a time when the argument for an all-in-one system was compelling and logical. Before the advent of SaaS (Software-as-a-Service) products and the cloud revolution, managing multiple systems was a pretty painful affair.

The products were written on different codebases, meaning the databases didn’t map. And the evolution of API’s had yet to take place, so connecting them was no mean feat.

This left you with 2 options:

• Manual rekeying of information
• Bespoke middleware

Manual rekeying of information

No accountant would seriously entertain this unless they had no other option. Not only is it inefficient, it increases the opportunity for error—and why would they want to threaten the fluency of their reconciliations?

Bespoke middleware

Still not ideal, but an accountant would at least consider this. Middleware could take the data from one system, reformat it and push it into the other system, cutting out the redundant work.

However, we need to remember the time period we’re talking about. Middleware was expensive to build and prone to failure, as well as requiring substantial ongoing maintenance costs.

Ultimately, it wasn’t the choice between 1 or 2 systems. It was the choice between 1 or 3.

So back then, few would argue against the logic of implementing an all-in-one system.

Now, times have changed. They’ve evolved. And in the last decade technology has taken a quantum leap forward.

And if businesses are to remain effective, business culture should be leaping quantums right alongside it.

Technological Changes

So, what exactly are the key technological changes that have taken place?

• Cloud hosting
• SaaS
• API’s

Cloud hosting

Historically, a company had no option but to use on-premise servers to run their infrastructure. These were expensive to install and maintain, inflexible, hard to scale, and carried significant risks, e.g. from a freak flood or fire. That’s not to say there isn’t a place for on-premise in today’s world, but the downsides are well catalogued.

Today, the cloud offers companies newfound flexibility. Everything from saving time and reducing costs to improving agility and scalability. It does away with the burden of in-house server hardware, software licenses, integration capabilities and the need for a large team of IT employees on hand to support and manage potential issues that may arise.

SaaS

Traditionally, software was deployed in-house using on-premise servers. This meant all consumers had an individual install and, as such, providers struggled to release upgrades of their products. For example, if I have 500 clients, that’s 500 individual installs to push out every single time I release an upgrade. Not exactly a walk in the park.

The problem was further compounded by customizations. If you paid for your software to be customized, you’d get “version locked”. This essentially meant that unless you were a big fish with a marquee logo, you wouldn’t be eligible for future upgrades as your customization(s) wouldn’t be supported—and even then, you might struggle!

Ultimately, the larger and more established the provider, the slower their pace of change and the greater their level of difficulty in moving to the cloud.

Today, the cloud is where modern software products are deployed. This means there’s just one version of the software, and no need for individual installs. So, a SaaS provider may have 500 clients, but they have the equivalent of just 1­ installation.

If a client wants to pay for a customization, it’s built into the core product as standard functionality, or as a feature option. Crucially, this means no-one is version locked so they don’t get left behind unable to receive future upgrades.

Compared to the old way, the pace with which new upgrades can be developed and released to every single customer in the SaaS world is akin to comparing Usain Bolt to an exceptionally lethargic tortoise.

APIs

It used to be the case that separate software products were truly separate. They had different engineering teams, using different methodologies, in different languages. Getting the systems to talk to each other was expensive and frustrating.

Today, there’s been an explosion in connectivity between modern software products. Think of how you can now un-box a smartphone and effortlessly connect up your apps, even connecting apps-to-apps-to-apps.

The modern world has demanded it. And the combination of SaaS + API’s has delivered it.

SaaS products have driven API advancements and for good reason. You no longer have to be an all-in-one to get ahead. Instead, it’s possible to achieve hyper growth as a best-of-breed with deep functionality in your particular area of focus. The bumper revenues are achieved by making it super easy to connect your product with other best-of-breed products that serve their own niche.

These offerings combine to provide an integrated suite of products that outperform a “jack-of-all-trades, master-of-none” in almost every single way.

But surely integrations aren’t as strong between best of breeds? Let’s debunk that myth.

Most all-in-ones aren’t, in fact, true all-in-ones. Typically the vendor’s strategy has been to acquire smaller turnkey systems and incorporate that into their pre-exisiting suite by – you guessed it – integrating them.

It’s the same story. Products written on different code bases by different engineering teams with the mere illusion of true integration.

Ok. I get it. Time has moved on. The argument for cloud was won years ago. SaaS products get updated more frequently. API’s enable us to connect systems in ways that were never previously possible. That’s great. But why should I look to move away from my existing all-in-one and go for two best-of-breeds?

Ultimately, it boils down to the types of people we are and the experiences we require.

Appropriate Experience Equals Best Results

Let’s start by stating the obvious. Operations and finance are not alike.

If I’m a creative type in operations, I’m a right-side-of-the-brainer. I’m client-facing and want to turn their visions into reality—even if I know that doesn’t necessarily translate into making a profit.

If I’m an accountant in finance, it’s the left side of my brain that’s leading the charge. For me, the world needs to be ordered and logical, checked and balanced. The idea of not working or thinking this way is alien and irrational.

The hard truth is, operations aren’t interested in accounting. It’s viewed as being super complicated and jam-packed with nonsensical jargon. This sentiment prevails from lower levels all the way up to swathes of the senior management team.

Whilst accountants are comfortable with raw numbers in key financial reports as the story is spoken in a language they live and breathe, it’s essentially gobbledegook to operations.

Ultimately, this is why the savvy accountants find ways to simplify data from the balance sheet, cashflow, etc. and prettify it with graphs and charts. The reports don’t tell the story to non-accountants, and it’s difficult for ‘boring’ lists of numbers to hold a right-sider’s attention.

This reveals something deep. They are two completely different audiences requiring very different experiences. So why would you expect them to use the same system?

Project accounting is a system for operations to run their projects. It is not a system for accountants. Accountants may want a login, but that doesn’t make it their system.

Likewise, the general ledger is a system for accountants. Operations don’t - and won’t - want anything to do with it, and no accountant wants them anywhere near it. So for starters, keeping the two separate allows your finance team to retain absolute control of the general ledger. Music to their ears!

Not only are operational users largely allergic to accounting, they can also be rather fussy about what they use. If the system is unintuitive and ugly, you have next to no chance of the system being adopted – though that’s fairly understandable, all things considered.

That doesn’t mean an all-in-one is doomed to fail. It simply means their only means of success is when finance inevitably sweep in to save the day after operations buy-out. There’s nothing wrong with having a strong finance presence to the business. In fact, it’s to be encouraged. But if you want the best results, you must also provide operations with a system they’ll engage with – one that’s built for them and not an accountant.

Let’s put some numbers on this. Finance typically make up 5% of the workforce. This means 95% of your staff don’t need to be anywhere near the general ledger and have zero interest in it.

This 95% will not fully adopt the all-in-one, usually just using it to punch in a fee number, along with their time and expenses. Job costing, staffing—the reasons you bought the system in the first place—all fail to get off the ground.

Similarly, the 5% have been limited to using a general ledger from a choice of one. A system that isn’t the vendor’s priority, as they have their own core plates to keep spinning.

It would not be unfair to suggest, therefore, that it is unlikely to be the finance team’s general ledger of choice if they were free to select from any system on the market.

Conclusion

The conclusion is clear. A best-of-breed project accounting system combined with a best-of-breed general ledger system is the clear choice to benefit both audiences and get the top overall business results.

The project accounting system is used by operations for business development, job costing, resourcing and so on, while the general ledger system is used by finance for journaling, fixed assets and tax.

Two different systems with two different audiences and purposes, both the best in their particular area of focus.

Ultimately there are a handful of transactions types that need to be in both systems: sales invoices, purchase invoices and personal expenses. A robust integration through a modern API will take care of that and give 100% of your workforce the best possible experience, enabling them to achieve the best possible results.

‍