The title of this post might have you expecting an assault on accounting systems. Well, I guess that’s one interpretation — but it’s not the purpose I’m aiming for.
I’ve spent many years working to resolve the data challenges that client reporting teams are faced with when compiling client reports and factsheets. Along the way, their struggle has become my purpose. So today’s post sets out to highlight the most important data problems clients face. As they say, forewarned is forearmed! First, however, lets lay out exactly why this topic deserves some airtime.
Data from accounting systems is vital for reporting
The fact that data from investment accounting systems represent something between 60–80% of the content of an average client report tells you something about the relative importance of these systems in the client reporting ecosystem (the remainder of the data is made up of a combination of performance stats, commentary, footnote/disclaimer and client static data).
So the hard reality is that investment accounting systems are not only essential for their own purpose but they also have a huge role to play in downstream systems like client reporting. Whatever way we look at it, we need to integrate with investment accounting systems and alleviate some of the data or architectural issues we face when dealing with them.
Are separate reporting solutions and accounting systems even necessary?
The debate remains wide open as to whether accounting systems can be extended or enhanced to include client reporting functionality or if there will always be a need for a separate, albeit integrated, reporting solution.
Kurtosys firmly believes in the latter, informed by the work we do with clients in this area, but I will leave that debate for another post. Today, I want to highlight some of the issues that I have come across when integrating investment accounting systems into a client reporting process:
1. Classification Structures
It is often the downstream systems duty to apply client specific classification structures. Accounting platforms are often unable to associate more than one classification hierarchy to a set of positions held within an account. These days, end clients, particularly institutional clients, require custom security taxonomies. Managing these becomes a headache for many.
2. Accounting System Life Cycle
Client Reporting processes often surface the need for specific types of data, some of which may not currently be available in the incumbent accounting system but are, nonetheless, potentially derivable. Accounting Systems [should] typically operate under tight version control and vendors/customers guard this carefully. Therefore, minor changes that are important for reporting but less so for accounting tend to get pushed/delayed down the release cycle introducing delays in downstream client reporting projects.
3. Data Validation
Some of the largest accounting providers and outsourcers today are still supplying data full of issues that go unidentified — that is, until the downstream applications process, load and check data. The introduction of data validation, post extraction (or during it), would help identify issues upfront and save time and money. The further downstream these issues get, the more time, resources and money are required to resolve them.
4. Multi-Currency
Even “multi-currency” investment accounting systems cannot necessarily accommodate the currency reporting needs of client reporting. These are two very different concepts. In reporting, client portfolios need to be available in a range of currencies depending on external factors such as relative benchmarks and sectors.
5. Data Storage
Some older or less versatile accounting platforms only hold prior-day data, making the extraction process to amend errors, found later, a real challenge. Data may need to be copied, restored, and then transmitted for corrections to be applied, all requiring time and resources.
6. Legacy Systems
Through mergers and acquisitions multiple accounting platforms may be used at a single firm, and these rarely “speak” to each other easily. Even the structure/set-up of Accounts and Portfolios may be handled differently making it hard to aggregate data.
7. Manual Processing
Human errors occur more frequently than might be assumed on platforms that are not intuitive, or require extensive training. One example is when transactions are not reversed properly, leading to data errors feeding down into reports, and issues only being spotted once the end-reports are visible.
8. Inability to Do Intra-day Extracts
Without being able to extract data again within the same day, investors may have to wait until the next business day to receive data corrections or see updated positions. These days, particularly online, clients are more than happy to receive intra-day, provisional figures. It’s the insight and speed they seek which is often incongruent with legacy accounting approaches.
9. Database Field Limitations
One example is with text fields such as Memo Events. A key field for client reporting notes! The main problem is that the memo text field is often limited to a certain number of characters that isn’t sufficient for the business details required. Less flexible systems, or those managed with limited resources, may mean that customers wait several weeks or months before they are able to change to a more suitable field length.
10. Spurious Data Fields
Due to the pre-defined structure of certain accounting platforms, data such as control fields or staging fields may be passed through even though it is not required for reporting. These additional fields make troubleshooting issues harder, and add to the unnecessary storage requirements of downstream applications that do not “throw them out” before processing.
11. Data Amendments that Do Not Ripple Through
At the onset of client reporting projects the “mapping” process ensures the right accounting data fields are associated with the correct client reporting properties; however, if at some point in the future a change is made, the accounting platform has to apply changes to all required places. If this isn’t done, it’s possible that the ‘used’ field becomes outdated. This can lead to reconciliations that are very difficult to isolate and trace.
So there it is. 11 observations I have encountered many times on multiple client engagements.
So what are the answers to these problems?
Well, the simple answer lies in your externalized data repository (data from your accounting systems).
And what I am stressing here is the need for a common repository designed with your business in mind — “data warehouses” or custom “client reporting databases” don’t qualify I’m afraid.
What we @kurtosys want to see is our customers looking to create a high-speed, web-ready, flexible data repository that accommodates and resolves not just the 11 issues highlighted in this post but many others. These are issues that client reporting and internal reporting teams encounter day-in, day-out because the initial client reporting project never addressed these issues strategically.
More to come in subsequent posts — and advanced notice— our Unified Data Model will feature!
