.svg)
In this post, we cover common challenges and best practices for reconciling a product ledger.
Welcome back to our series A Guide to Financial Reconciliation. In our prior post (Part I), we cover the basics of financial reconciliation and why it's important.
In Part II, we discuss common challenges and best practices when reconciling a product ledger.
This is probably worth a series itself, but most simply, a ledger is a tool for tracking and giving meaning to money. It includes a financial journal and a ledger. The journal logs transactions, and the ledger books those transactions as credits or debits to accounts.
Every company uses some form of a ledger to track their money movement. But in fintech companies, the concept of a ledger takes on multiple forms and implementations. Generally, fintechs will run multiple ledgers for different purposes:
And as fintechs grow and mature, their ledgering systems become complex. Companies add new providers to their stack, layer on custom business logic based on first & third party data and begin decisioning funds availability theirselves. And as these features are added, their source of truth becomes distributed across internal and external sources.
And as technical complexity grows, so does the gap between product teams moving money & finance teams accounting for that money. While the ledger acts as a source of truth for transaction data, reconciliation ensures the agreement of time, amount and direction of that data.
Reconciliation becomes the critical function required for fintechs to manage their ledgers.
Fintech product ledgers change quickly as new financial products are delivered to end users. And often, this means that lots of accounting-specific logic is layered into application code as new payment types and currencies are introduced. Often, the original implementation of the fintech’s core ledger was not designed to flex to these new payment types or currencies, leading to inevitable challenges with reconciliation. As new payment processors and banks are introduced, new types of exceptions arise related to that payment method - but this has knock-on effects that cause reconciliation challenges for existing payment types as well. So with each new payment type, account feature, or currency, potential issues grow exponentially.
Product ledgers are often designed to be a “user-centric” view of money, with accounts modeled relative to the end user. But translating a user account centric product ledger to a view consistent with your payment processors and real world bank accounts is a challenge. Ideally, all funds modeled on the product ledger should be able to be mapped and reconciled to their real world bank accounts, but this translation is often not done in a way that can be tracked or reconciled.
Many fintechs bury their reconciliation logic in code or SQL that is inaccessible to non-technical members of the team like finance & payment operations. And the reconciliation logic being written can be highly biased, often leveraging the same processing code or parsing logic as is used for processing transactions on the fintech’s product ledger. But using the same logic to check yourself means that errors are perpetuated when reconciling transactions on the ledger. This often leads to silent errors and becomes a root cause for regulatory and compliance issues.
Most companies begin reconciling their product ledger using aggregations - and not 1:1 transaction level reconciliation. This usually starts by summing transactions over a time period (like a day / week) and comparing the aggregation to an aggregation of another source. But timing differences immediately introduce false positives and issues. Additionally, many reconciliation processes are not able to model the differences between snapshots over time, meaning that teams have to be responsible for understanding how false positives resolve over each reconciliation for the specific transaction type.
As fintechs grow, new products will be launched, new integrations will be added, and new account offerings will be created. It is critical that internal reconciliation processes can grow and flex with the changing needs of the business. When adding new transaction types and currencies to the product ledger, it is important to ensure that shadow ledgers and reconciliation processes can quickly adapt. Reconciliation processes should be designed to be configurable, ideally by non-technical team members, so that processes can be updated without engineering intervention.
Shadow ledger systems should sit downstream of product ledgers to model money across real world bank accounts. Often this system is designed to take on an accounting-centric view of managed funds and answer analytical questions related to the reconciliation process. Shadow ledgers are designed to generate curated views for specific types of reconciliation processes, ensuring that balances can be reconciled and that funds settlements map to the expected amounts across payment processors and bank accounts.
Reconciliation processes should enforce clear separation of duties between services: the payment initiator (or initiating service) should not also be the reconciler of that financial transaction. By reusing internal system logic for both payment initiation and reconciliation, companies expose themselves to the risk of repeating errors across systems, resulting in silent exceptions.
Reconciliation processes should be transparent, so that they can be repeatable and auditable. Reconciliation is often part of a larger financial controls process that companies must enforce and adhere to.
True 1:1 transaction reconciliation often involves a heuristic & rules based matching logic for tying out transactions across sources over time. Ideally, it will enable a single transaction object to participate in multiple reconciliations - each time a transaction changes state or has an impact on funds movement or availability. For example, transaction reconciliation should be able to tie out a card payment in each of its states across its lifecycle: the authorization, the clearing (any any balance adjustments), and settlement.
There is a lot to unpack when it comes to reconciliation and financial operations. In this post, we covered the common challenges and best practices when reconciling product ledgers. In future posts, we’ll discuss the different types of reconciliation in detail.
If you are looking to improve your reconciliation processes, Proper provides financial data infrastructure, purpose-built for fintech. We help stitch together sources of financial data into a single platform and provide tools for reconciliation and financial operations. Back office infrastructure is critical to financial services, and with Proper, companies can spend less time on financial ops tools and more time focused on their end-users.
We’re modernizing the systems that many innovative fintechs are forced to build in-house and providing services that you can integrate quickly to expedite your financial operations stack.
