Kyle Maloney
September 20, 2023

A Guide to Financial Reconciliation, Part II: Reconciling a Product Ledger

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.

A primer on product ledgers

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: 

  • A product ledger - also known as a “core ledger” acts as a system of record for transaction data and end user balances. This type of ledger directly supports or supplements the direct end-user experience of the financial product. For early-stage fintechs, their core ledger is typically an amalgamation of their BaaS vendor, payments processors, and internal services (e.g. rewards, credit). Product ledgers tend to have technical traits like high availability, immutability, scalability, and speed. 
  • A shadow ledger - a ledger primarily used for balance & transaction reconciliation. Shadow ledgers are built for modeling money movement across sources of truth such as bank accounts & payment processors. At Proper, we consider shadow ledgers “follower ledgers” used for analytical processes and financial operations workflows. They typically sit downstream of various sources of financial data, including the product ledger. 
  • A general ledger - or GL, is a lower resolution ledger designed for tracking and reporting a company’s financial position. All companies have a GL, often managed in their core ERP, such as Netsuite or Quickbooks. 

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.

Challenges when reconciling a product ledger

New payment types and currencies

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. 

Mapping funds to the “real world” 

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. 

Black-box & biased logic  

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.

Aggregations, Timing differences, and snapshots

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. 

Best Practices when reconciling a product ledger

Adaptable and configurable reconciliation processes

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.

Translation between user-centric and accounting-centric views

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. 

Separation of duties & Transparency

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. 

Transaction level reconciliation

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.

Kyle Maloney
September 20, 2023

Some more posts

Changelog: January 2024

This month, we're focusing on providing you with more control and clarity over your data and processes.

February 7, 2024

Techniques in Financial Reconciliation, Part I: Data Acquisition & Transformation

In part 1 of our new series, we break down the key considerations for the first step of your financial reconciliation process: Data Acquisition and Transformation.

Kyle Maloney
February 3, 2024