Questions answered by the experts:

3:06 – What is a thick or thin General Ledger?
4:36 – If you go for a thin GL, where do you put all the detail?
5:55 – Could you discuss the pros and cons of each of those three approaches?
9:32 – How do you get there? Is it easier to have a data warehouse and a general ledger?
12:26 – If you’ve already got thousands of accounting rules, do you throw that work away or is there a way to migrate over?
15:29 – Is a data warehouse strategy, and a subledger strategy, mutually exclusive?
17:13 – Why does the subledger give more independence to finance?
21:04 – Many finance teams spend a lot of time on reconciliation. What advantages could you achieve from a thick or thin general ledger in this area?

Transcription of the session:

Nicolas:
Good morning. Good afternoon and good evening to everyone. Pleased to welcome you to this month’s Meet the Experts live event. I’m joined today by Elizabeth Sipiere, our Chief Revenue Officer at Legerity, an insightsoftware company. Hi Elizabeth, how are you doing today?

Elizabeth:
Morning Nicolas, looking forward to the discussion.

Nicolas:
Great, thank you. So yes, for today’s discussion, we will discuss thick and thin general ledgers and the benefits of a subledger. So, the question is are you putting too much pressure on your general ledger? A subledger can really deliver granular and transactional based accounting, daily in real time, for multi GAAP, multi entity, multi-currency, multi time zone processing, and so on. And with the highly flexible segment definition, users unlock a significant business value with rapid, on-demand reporting. And that, really, will be the topic of today.
So as a reminder, you can ask all your questions on our website, at info@legerityfinancials.com, or you can just drop a comment on LinkedIn, and we’ll make sure to address all your questions during the live event, and if we can’t, we’ll make sure to come back to you after via email.
So let’s get right into it. Elizabeth the first question, maybe you can tell us a little bit more about what is a Thick and a Thin general ledger?

Elizabeth:
Yes. I think the first question is really what is a general ledger? So you know, the general ledger is the books and records of your organisation and it is the place where you do your financial statements, your reported financials, they are the home of that source – that source of hopefully truth. And generally, a thick ledger does that. It does what it says on the tin, and that’s about all it does. So, it has your assets cash, accounts receivable, land equipment, liabilities, you know, loans payable, accounts payable, operating revenues, sales, all of those things and operating expense. So, it generates financial statements. Often these have to get consolidated across many, many entities.
A thin ledger tries to go further. It particularly tries to create dimensions that reflect the business, maybe product, channel, different aspects of each business. And that starts to magnify up what you’re putting in your general ledger. And historically, for many people, that was what they did. There’s definitely been a trend to sort of thin ledgers now with a subledger accompanying it, or alternative solution for getting at that kind of granular detail.

Nicolas:
Okay, okay. So as you know, a lot of people still have a thick ledger. If you go for a thin ledger, where do you put all the details?

Elizabeth:
If you go for a thin ledger, right, if you’re moving from a thick to a thin ledger, you have to think about where to put that detail. And the first most common move I think people really saw was a move to put a lot of stuff in a data warehouse. And you know, data warehouses are brilliant for some things; they’re flexible, dynamic, often cloud-based, but they have their own challenges. So, one of the places people started putting stuff was in the data warehouse.
The second, actually, was many businesses have sort of core systems for each product or line of business. So quite often, if you are in insurance, the policy admin system might do your accounting for you. If you’re in banking, you might have a core banking system that does your accounting for you, and another one for your treasury and another one for your trading, and maybe another one for leasing. But sometimes you would find the accounting in there.
So, one choice is to use a data warehouse. The second choice is to use a product-based system or line of business system. And the third choice is really to think about having a subledger, which is what we would always advocate.

Nicolas:
So now, if we think about the pros and cons of those three approaches, or subledger, or the operational ledger and the oppression tools or the data warehouse – what are the pros and cons of those three approaches?

Elizabeth:
You started out saying a lot of the benefits of a subledger. A subledger is like a general ledger – it’s a double entry, bookkeeping, full audit trail, controlled environment, probably managed by finance. So, a subledger has the controls that typically are associated with the accounting department. If you look at a data warehouse, it doesn’t have that. And that’s probably the biggest difference, you know, as you can put the same data in both.
But the data warehouse won’t have usually that level of audit and control. And also, it can be difficult to trace. If you put stuff in a subledger, you can probably look at any balance and work out what the debits and credits are, and what reference data was used, what rules were applied, and in a modern subledger that should all be very transparent. In a data warehouse, there is a tendency to use more opaque calculations, perhaps sequel or other things. And often, data gets in there through various types of ETL. So you tend to lose a lot of that traceability. But the data warehouse does things that a subledger isn’t designed for; it enables you to dynamically change stuff. If you’re looking at changing risk metrics, if you want to run lots of scenarios, if you want to sort of play with what would influence customer profitability, things like that, then data warehouses are the right tool for that.
So you know, there are pros and cons of each. The product subledger is a difficult one, that historically has often been the case. And sometimes it’s probably cheaper, if you’re buying a core system, you might well find the accounting sort of thrown in for free. But generally, there’s a lot of issues with it. It tends to be that each product line, if they have their own, will have a different set of accounting. Given they’re not usually created by accountants for accountants, they’re not always following the standards as the standards migrate. So, they tend to start falling behind. And generally, if you’re in banking, you might have different accounting treatment of exactly the same derivative in a different product system.
So there’s quite a lot of challenges with a product system, the positive is that often they will, to the people running the business, they’ll give them a P&L that those people own and possibly can influence, possibly can adjust. And that brings all host of challenges, if that gets its way through to your actual audited financials.

Nicolas:
Yeah. And I think also, if you think about the application subledger, it’s no longer owned really by finance, it is owned by the operating team who are purchasing the tool. At the end of finance transformation, one of the key challenges is to bring the ownership to the finance team of all the finance processes. But, like you said, to use something around the subledger, could really be the way to go. So, how do you get there and is it easier to have a data warehouse and a general ledger? What will be the journey?

Elizabeth:
I don’t think it’s easier to have a data warehouse and a thin general ledger. The journey is probably about the same. And a subledger can probably offer you features you don’t have in a data warehouse. So generally, every customer chooses its journey to get there. If they’ve got accounting in lots of different places, and they really want to move it towards finance, you know, you’ve got Sox controls, there’s lots of issues now around manual adjustments that might be made in lots of different places, and then your risk and reg reporting starts to be significantly different from your financial reporting. And then you get into the whole world of reconciliations. So there’s a lot of different ways to go about it.
Generally, in my experience, most people go about it depending on where the biggest pain point is, and they move fastest if they’ve got an audit point, or a regulatory point, you know, that generally moves things along. Because finance rarely gets the budget first, so then the other way to move is to look at where you’ve got a lot of dynamic change in a core system. And when you’re doing that, start cleaning up the accounting, and then as soon as you do that for one part of the business, you’re probably beginning to think, ‘okay, well, that’s adjacent to this part of the business’ and you create yourself a roadmap.
Sometimes you’ll find as well, for example, we’ve got one prospect we’ve been talking to where the sort of biggest offices, they happen to be a Swiss entity, so their Swiss office and their New York office and, and their UK office, and probably their Singapore office, they’ve all got cleaned-up accounting. So then what they’ve got is they’ve got lots of small entities that nobody’s tidied up.
So sometimes you can have two different strategies and approach them in different ways, and find something for smaller entities that’s more cost efficient, and more achievable than perhaps some great big massive rollout. Because historically, SAP and Oracle did not have subledgers. Generally, sort of 10-15 years ago you were talking about a thick GL, but both of them now, of course, offer a subledger themselves.
So if you’re very big, you may well have chosen one of those alternatives. We would argue that there are benefits from something a little bit more agile and flexible, and probably slightly lower cost.

Nicolas:
Yeah, no, definitely. And actually, it brings me to the to the next question I wanted to ask you about the accounting rules, because a subledger is one part of really this kind of transformation. There’s also all the accounting rules that you’ve built, and if you look at the banking industry for example with thousands of accounting rules, how do you avoid throwing away all this work that has been done, probably historically in the data warehouse or in very hard-coded type of environments? And how do you migrate over this type of massive history of accounting rules?

Elizabeth:
It varies, it varies. And one of the other big challenges: the people who wrote the rules probably left years ago. So there is a transparency problem. However, there have been quite a few tools over the years that people have preferred for accounting rules. And generally, I think most of the modern subledgers that anticipate receiving business transactions, and then applying accounting rules are able to import in various formats. So, if you’ve got some transparency into the rules, and you can see what’s going on, and you can get it into a format that can actually be imported, then you can probably do 80% of them.
The other thing is that historically, typically, a rule would be written sequentially. So you’d get a rule that says ‘Post this debit here’. And then actually, you’d say, well, actually, two years later, you’ve made a variation. So therefore, it goes to somewhere slightly different. If you look at all those rules, now, you can probably say ‘Okay, I’ve got, I don’t know, 2000 rules, but actually seven or eight of them are nearly identical. Therefore, I can write one rule, and then have some logic within the rule.’
We use something called the Legerity expression language, which is very like Excel logic, but you can see it on screen and the finance people have full transparency into it. So you can actually start to consolidate an awful lot of rules into something a bit more succinct, and much more manageable.

Nicolas:
Okay, and that’s quite interesting, because, you know, everybody’s trying to do a little bit of the clean-up in this kind of process. And it’s very often difficult to know where to start. So this idea of being able to transfer all the rules and then looking at the ones that are necessary, is quite important. Thank you.

Elizabeth:
And Nicolas can I make another comment. One of the things that I’ve seen as well is it’s quite important to separate out what is an accounting rule and what is ETL. You know, quite often I think what happens is the data is being cleaned at the same time as somebody’s writing the logic for accounting. And actually, separating out those also creates a whole lot of efficiency, because ultimately, you’re looking for automated finance transformation that reduces the load on finance.

Nicolas:
Yeah. And that’s actually a very, very good point. And, you know, I wanted to get back on the data warehouse strategy, and what you just said about the difference between the accounting rules and the ETL. So, is a data warehouse strategy and a subledger strategy mutually exclusive? I would think no, but how would you approach that?

Elizabeth:
We would always recommend both, partly because of the ETL problems. So it’s good to have a staging area and to let subledgers and accounting hubs do their job, and make sure that any data transformation is done somewhere else, or, if it is done, then you know, for example our product has a certain level of transformation, but you can separate it from the actual accounting.
But the other thing is that what you’re providing in a subledger is auditability, and traceability at a really granular level of your financials and of the performance, and so every aspect, every client contract, every retail customer can look at that, for your recorded financials. When you get that data into a data warehouse with all the other data, you have so many more reporting possibilities. You can start profiling, you can start analysing, if you can take finance data with all the reference data needed to create the finance data and marry that up with all the other customer behaviour data, you then have something far more powerful than the two completely separated and not aligned.

Nicolas:
Yeah, and that makes it makes a lot of sense. At the same time, also there is the aspect of ownership of certain aspects and certain processes without excluding the other team. So, yeah, that makes sense. Makes a lot of sense. So actually, now, why does the subledger give more independence to the finance team? You just spoke about how the data warehouse gives controls to IT and people don’t need to do more things with data, and you spoke about the value of the subledger before, but why does it give more independence to the finance team?

Elizabeth:
I think that’s tied to finance tending to come last. So if finance wants something changed in a product system, the chances ,especially if it’s a dynamic side of the business that’s got a roadmap of things they’re trying to do to build more digital services for their clients, finance are probably not going to get priority. The revenue earning businesses tend to come first. So then what happens is, finance is going to have to solve the problem anyway. And so then what they’ve got is they’re dependent on whatever is in the product system that is not compatible with how they need to do their accounting. And then they actually have to start doing what we call end-user computing.
You know, you’re back in the land of spreadsheets, and access databases and other tools that finance people know really, really well. But they have errors in them, they’re manual. And so finance lose not only their independence, but they lose an element of control, and they lose a piece of automation. And then you’re at your month end, and your whole close process takes longer. So they lose a lot more than just independence when the accounting is actually done in a system.
And one of the other challenges, particularly in banking, where we have a lot of focus, is product systems. Often you might buy something that was designed for equities, and then it gets a few bonds shoved in and then a few commodities. And actually, the data doesn’t fit. So then you’ve started to use fields for lots of different things. And then you’ve got accounting treatments that don’t match.
So you know, the problem, it’s not the end user’s fault. It just happens that way, because of the way historically systems have tended to grow up.

Nicolas:
Yeah. And you know, you also mentioned earlier the Legerity expression language when we spoke about the accounting rules. And I would imagine there is also a certain aspect of the subledger or this accounting rules platform to give a control, as you were saying, to the finance team in the way that they can do things with less coding. And in a way that’s much more visual and therefore experts in accounting can actually have a discussion around the process, around the control and what has been done instead of the coding and something that’s written in a language that nobody understands and trying to justify it to the auditors.

Elizabeth:
Yes. And that’s the whole benefit, isn’t it, of migrating rules. Because many, many of these legacy rules, you know, we have somebody we’ve been talking to, I think they had something like 28,000, COBOL rules. I mean there’s a lot of work to be done, actually, for the very, very large players. I also think that giving finance ownership makes finance accountable. And I think it must be very frustrating to be accountable for stuff and actually not have ownership. I think that creates challenges in any organisation.

Nicolas:
Yeah no, that’s very, very true. I have one last question. It’s opening Pandora’s box to a lot of other questions, but let’s get this one into today, maybe. Many finance teams spent a lot of time on reconciliation. What advantages could you achieve from a thick or thin general ledger in this area? So really, the reconciliation challenge.

Elizabeth:
Nirvana, really, is to send a balance to the general ledger. And that balance has what you sent to your general ledger, from your subledger, and that balance is in the GL, and you can see that. And you’ve got a protocol between the two that tells you everything was sent correctly, received correctly, and you’ve got your check. So you know what’s in the general ledger is correct.
And then, the Nirvana is what I call reconciliation by design – that process of you’ve got a balance, you know exactly what journals were in it, you know exactly what business data was provided to generate it, and you know exactly which rules were applied. So you have that sort of traceability.
However, most finance people still will do lots of reconciliations. And actually, in a subledger, you have other ways of addressing things you’re worried about. We had one client, where they had some issues with their cash, they were doing top-ups for lots of managing agents and loss fund top-ups, and we put in some control accounts. So it’s not just recs that you can do, you can also, as soon as you get a discrepancy in your control accounts, you can begin to see, okay, this is an issue that needs some analysis.
But to be honest, if you need to do a reconciliation, and you’ve got a detailed, granular subledger, with lots of dimensions, and very good tools, certainly with products like ours, you can generate a picture of balances and their journals and events and you can download it to Excel. That’s not excel in the operational process, but it is a way of having a clear finance-favourite tool way of looking at exactly what’s going on with any balance and then reconciling it.

Nicolas:
Yeah, that that’s very, very true. So, thank you very much. Actually, this is bringing us to the end of today’s Meet the Experts session. So Elizabeth a really big thank you for all your insight, maybe do you have any concluding thoughts that you would like to share with people online?

Elizabeth:
I think it’s an interesting journey. And because we largely work in financial services, I think that we all know that there is actually a huge trend for regulation for better alignment of risk finance reg reporting. And we are at a point in time where you can actually hold this level of granularity at a reasonable cost.
You know, in days gone by, it was difficult. We didn’t have the cloud in the same way, we didn’t have low-cost databases. But now we can store seven years data at a granular level for a much lower cost than ever before. So the potential is there.

Nicolas:
That’s brilliant. And actually just a quick word now about Legerity FastPost, so people understand who we are. FastPost is the next-generation accounting rules platform and subledger, as we discussed, and it’s designed and developed for large volumes of complicated data, and as you just mentioned, end to end processes. We differentiate ourselves by being cloud native, ultra high-speed performance, and we’re built with the latest open-source technology. All of that to enable the finance team to take control of the accounting process.
If you feel like you have weaknesses in the back office and your processes and automation, we really encourage you to come on our website, check some of the recordings that we have, the Meet the Experts or Webinars, or a lot of the white papers. You can always reach out to our sales organisation by either clicking the links on the website or sending us an email at info@legerityfinancials.com. I will make sure to get back to you.
So on that note, I just want to thank you again, Elizabeth, for all your insight and wish everybody a very good rest of the week.

Elizabeth:
Thank you, Nicolas.