Journal|||Payments Primers

How and Why Homegrown Ledgers Break

Image of Lucas Rocha and Sarah Speights
Lucas Rocha and Sarah SpeightsMarketing

Introduction

Due to the nature of our product, we at Modern Treasury often deal with complex payment infrastructure problems. Beyond payment rails, dealing with banking products, and regulation, there is a class of problems that often go unacknowledged: ledgering issues. Every high-growth company that moves money—fintechs, marketplaces, vertical SaaS—needs a ledger, even if they don’t think of it as one.

A ledger database is the underlying infrastructure that logs every single transaction in a fintech marketplace or vertical SaaS product or platform. It tracks and surfaces relevant balances and acts as a source of truth for transaction history, user balances, payout decisions, authorization workflows, and the overall cash flowing through a product. If your product deals with money, all of that information sits on a database somewhere—this is your ledger.

As such, this piece of software should be bulletproof. Or, at minimum, clean and consistent, scalable and performant, fault-tolerant and auditable—at least as much as other large-scale application databases we use to power our modern life.

The problem is, for too many of the fintech experts we know, the idea of a clean source of truth for their data sounds, at best, idealized.

What Happens When Ledgers Break?

Often, companies will set up a ledgering system when they’re still young. Over time, whether it’s increased transaction volume and company size, a change in product offerings, or a jumble of patched-together solutions that slow down a company’s ledger database, those initial ledgers are usually not designed in a way that will allow them to scale as the company scales.

Homegrown ledgering systems can struggle to keep up with the needs of companies that are focused on moving money—at scale—efficiently. The results of ineffective homegrown ledgers can look like:

  • Inconsistency and issues with data integrity call into question the reliability of the company as a whole. Inaccurate aggregation of balances can lead to incorrect payouts, incorrect user balances, missing funds, or money created out of nothing.
  • Non-performant systems lead to deteriorated user experience. Fetching a user balance in more than a few milliseconds is unlikely to cause big problems when it happens in isolation. But millions of users going through time-sensitive workflows— like adding money to a digital wallet or dealing with card payments—can stress poorly-built systems to the point of collapse.
  • A web of patches on top of initial ledger designs leads to problems around maintainability and increased technical debt. As with most tech debt, engineers do not want to work on legacy ledgering issues and often choose to build parallel systems from scratch instead.
  • Reconciliation becomes a challenge. Too often, ledgering systems fail to adopt double-entry successfully. Failing to ensure debits = credits means engineers need to spend valuable time reconciling balances and clearing out inconsistencies on behalf of internal business teams.

The longer a company goes without a ledger that can act as a single source of truth for their data, the more discrepancies, errors, and inconsistencies within that data compound. This usually leads to long, complicated workarounds for accounting and engineering teams. From missing funds to compliance challenges, trying to find, parse and fix issues in a homegrown ledger can lead to wasted time and lost revenue.

To illustrate how these issues come to be, let’s look at the anatomy of how ledgering breaks at a typical fintech company. The anecdotes we share here come from our experience working with hundreds of fintechs, marketplaces, and vertical SaaS companies, as well as the public cases of Uber, Square, and Airbnb.

Why Do Ledgers Break?

Let's look in more detail at some of the most common problems we’ve seen with homegrown ledgers.

Evolvability

Homegrown ledgers are often focused too rigidly on a company’s first product offering. Ledgers are often initially set up as single-entry tables on Postgres. This might work fine for a while, but as the company grows or offers new products, it’ll also be forced to add new infrastructure to its ledger, which is where many companies run into trouble.

For example, Uber has written about the challenges of making updates to its custom payment platform. With their initial offering of ride-sharing services, they had one table for tracking rider fares and another for tracking payments to drivers.

As they scaled and began to offer services like food delivery in addition to ride-sharing, payouts to restaurants, and delivery drivers. This added another layer of complexity to their ledgering system: not only did they have to track rider fares and rideshare driver payments, but also delivery driver payments, restaurant disbursements, tips added onto a delivery purchase, restaurant commissions, and how all of those transactions affected user wallets within their app.

Ultimately, this prevented them from being able to scale faster. The complexity of what Uber was already managing prevented them from focusing on new user features. To build the improved custom payments tracking system they use today (called Gulfstream), it took Uber two years’ worth of work from over 40 engineers.

Changes became necessary because they noticed deep underlying problems in their ledger design. Businesses are often focused on getting to market as soon as possible, and future-proofing their ledger is one thing that is often overlooked. Testing and building features like double-entry and immutability takes time and resources—two things that new companies often don’t have, or want to spend, in bulk. While this type of “we can fix it when it breaks” mindset feels like the right choice initially, it frequently catches up with businesses in the long run.

Consistency

An even more pressing issue is consistency. Lacking consistency in aggregating and accurately surfacing information from transaction data calls into question the integrity of your entire data stack.

With a homegrown ledger, adding a new product means adding a new ledger to track the data around that new offering. Scaling a ledger can be hard, especially as the number of transactions increases exponentially. And as we saw with Uber, over time, this can impact a company’s ability to continue to grow or offer different products because the system becomes too convoluted to manage reliably.

Most homegrown ledgers will become a patchwork: lots of different rules and priorities to try and keep data consistent. These cobbled-together ledgering solutions can often negatively affect latency and require a lot of manual steps to reconcile the information in bank statements. This simply isn’t maintainable for most companies over any significant period of time.

What are the Alternatives to a Homegrown Ledger?

If your business is already struggling with the constraints of your homegrown ledger, one option is to address the tech debt and spend the time and resources necessary to custom-build a ledger from scratch.

Aside from resource allocation, a potential downside to this option is that, with growth, you will likely need to continually employ resources to adapt your ledger. This means new rules, new exception handling logic, and inevitably, issues with consistency and maintainability. Problems like these are unlikely to go away on their own.

There are also software options in Enterprise Resource Planning systems (ERPs). While these software options work for many businesses, their APIs can be challenging to work with, their data can be stagnant, and the resolution of their chart of accounts may not be sufficient. Your accounting team will still need to take extra steps to ensure that your transactions are recorded and the data is reliable.

Another solution is to utilize a ledger-specific API to safeguard against or recover from the issues of a homegrown ledger. A well-built ledger API will allow a business to track financial and user data as they grow–regardless of transaction volume–and should include features that ensure reliable, consistent, maintainable data for all aspects of a business.

How Modern Treasury Can Help

At Modern Treasury, we built our ledgers product to include: 

  • Double-entry accounting to help ensure against losing track of funds.
  • Immutability to maintain the integrity of your ledger and make auditing your data straightforward and simple.
  • Idempotency to prevent errors like accidentally double charging a customer.
  • Concurrency controls to allow simultaneous transactions to be run consistently.
  • Compatibility with our payments product to tie payment activity directly to information on your ledger.
  • A user interface that can be easily utilized by finance teams and business stakeholders.
  • Support for working with multiple currencies.
  • A quick, scalable implementation, so we can support your business from day one—whether you’re running only a few transactions or hundreds of thousands.

If you’re curious about how Modern Treasury can help your business build a better ledger, reach out to us.

Share

Copied!