At KnowLedger, we sometimes have discussions with clients that begin: “When I process all of the transactions from my investment system, the total of the transactions does not equal what my statement shows. Why? What’s wrong?”
The first thing we tell those clients is: “Don’t panic.” While this may sound counterintuitive, the inconsistency does not mean that anything is wrong.
Why, then, is there a difference?
There are several possibilities. The difference could be attributable to non-transaction activity, timing, or tax lots not in sync.
In this brief article, we focus on the impact of non-transaction activity.
The impact of timing refers to situations in which an inconsistency is attributable to the difference between a trade date and a settlement date for a transaction, for example, or a situation in which a transaction is backdated after the data under review was pulled. As a result, the impact of timing is fairly self-explanatory.
We are not suggesting that discrepancies resulting from tax lots not being in sync are similarly self-explanatory. Instead, they could be the subject of a separate article.
To understand the impact of non-transaction activity, and how it can lead to discrepancies in your numbers, let’s consider the flow of your information.
Information flow and categorization
Private equity, direct investments, real assets, and other transaction information from custodians is commonly provided to portfolio accounting systems. These portfolio accounting systems provide transaction information to KnowLedger.
When we refer to “transactions,” we are including events like purchases, sales, deposits, withdrawals, and reorganizations, among others. If you focus exclusively on transactions, however, you are not necessarily capturing all of the available data. Certain adjustments, like amortization or “cost changes,” may not be categorized as transactions by a data source or a portfolio accounting system. If these adjustments are not categorized as transactions, then they are not included in the transaction data. One example of this is a fixed income amortization change.
When a bond is purchased, interest will be paid on it. The interest is generally reflected as a transaction. If the bond was purchased at a discount, however, then in addition to the calculation of interest, there is also an amortization that will take place – over the life of the bond – to bring it up to its face amount. That amortization is an example of the kind of cost adjustments that are provided by custodians. Custodians, however, may not pass this data out of their systems. In other cases, the custodian provides the data, but the changes may not be shown by a portfolio accounting system as a transaction. Sometimes, these adjustments are shown on the statement in the final balance, but are not shown as a transaction, making it very challenging to track them.
What does this mean? If information is not shown as a transaction, then importing and reviewing only transaction data will not capture the adjustment – leading to a potential discrepancy between your investment system totals and your statements.
What do I need to do?
What can you do to address this situation? An audit or reconciliation.
The logical next question is: “How frequently?” Should you audit monthly or quarterly? In practical terms, it makes sense to be guided by how frequently you produce reports using the data in question, or how frequently you need to use that data.
What kind of audit makes sense for you: High level? Low level? A combination of the two? How each firm performs an audit could be its own article topic, so we leave this to you to determine based on your business needs.
In addition to considering how frequently you will use the data, it is also helpful to consider how you will use the data in question. If you want to examine certain investments individually, for example, the most logical approach is to turn to your investment system. Your accounting system is simply not the best tool for examining individual investments.
When we refer to “transactions,” we are including events like purchases, sales, deposits, withdrawals, and reorganizations, among others. If you focus exclusively on transactions, however, you are not necessarily capturing all of the available data. Certain adjustments, like amortization or “cost changes,” may not be categorized as transactions by a data source or a portfolio accounting system. If these adjustments are not categorized as transactions, then they are not included in the transaction data. One example of this is a fixed income amortization change.
When a bond is purchased, interest will be paid on it. The interest is generally reflected as a transaction. If the bond was purchased at a discount, however, then in addition to the calculation of interest, there is also an amortization that will take place – over the life of the bond – to bring it up to its face amount. That amortization is an example of the kind of cost adjustments that are provided by custodians. Custodians, however, may not pass this data out of their systems. In other cases, the custodian provides the data, but the changes may not be shown by a portfolio accounting system as a transaction. Sometimes, these adjustments are shown on the statement in the final balance, but are not shown as a transaction, making it very challenging to track them.
What does this mean? If information is not shown as a transaction, then importing and reviewing only transaction data will not capture the adjustment – leading to a potential discrepancy between your investment system totals and your statements.
Two quick takeaways
At a basic level, this issue boils down to using the right tool for the job. One of the tools we mention excels at performance reporting, and the other one is optimal for accounting and tax reporting. Existing systems are not designed to be equally useful for both purposes, nor does the data in each system need the same audit process. For your GL, for example, it is important that the total be accurate, but you are generally not focusing on the details of each individual transaction in a particular category.
Finally, you want to make sure that your expectations for your tools are aligned with the benefits they are designed to provide. It has been our experience that family offices use KnowLedger to eliminate the need for the manual entry of data. To be consistent with best practices, though, they still need to audit the GL. This way, they get the benefit of the automation and access to detail offered by KnowLedger, and the security that comes with regular audits.