Modern Treasury

Ledgers Categories

Ledgers Categories

Ledgers Categories

Designing a scalable hierarchy layer for Modern Treasury’s core ledger, enabling enterprise reporting without rewriting the underlying system.

Designing a scalable hierarchy layer for Modern Treasury’s core ledger, enabling enterprise reporting without rewriting the underlying system.

Designing a scalable hierarchy layer for Modern Treasury’s core ledger, enabling enterprise reporting without rewriting the underlying system.

Riders
Riders
Riders
Riders

Role

Design Lead

Timeline

Q3 2022

Sector

Payment Operations

Scope

CORE LEDGER FEATURE

01

SUMMARY

SUMMARY

IMPLEMENTING HIERARCHY WITHOUT REWRITING THE LEDGER

BACKGROUND
BACKGROUND
BACKGROUND

As customers relied on Modern Treasury’s ledger as their source of truth, flat account structures made it difficult to reason about balances at scale. Without hierarchy, finance teams struggled to reconcile, audit, and report accurately as complexity grew.

OUTCOME
OUTCOME
OUTCOME

Introduced a flexible hierarchy layer that allowed customers to group ledger accounts without altering underlying data — preserving financial integrity while enabling scalable reporting and future platform expansion.


My background in finance and platform design shaped the approach — prioritizing financial correctness, scalability, and enterprise workflows over surface-level hierarchy.

THANKS TO
THANKS TO
THANKS TO

Koji Murase (PM), Jason Jong (Eng Lead), Sahil Altekar (Full Stack Eng), Leon Dai (Full Stack Eng), Sajeel Malik (CSM)

Koji Murase (PM), Jason Jong (Eng Lead), Sahil Altekar (Full Stack Eng), Leon Dai (Full Stack Eng), Sajeel Malik (CSM)

Koji Murase (PM), Jason Jong (Eng Lead), Sahil Altekar (Full Stack Eng), Leon Dai (Full Stack Eng), Sajeel Malik (CSM)

02

PROBLEM

PROBLEM

FLAT LEDGERS DIDN'T SCALE TO ENTERPRISE FINANCE

The core issue wasn’t missing data. It was missing structure.


As ledgers scaled to hundreds of accounts, finance teams struggled to summarize, audit, and explain balances across increasingly complex financial structures. Basic questions required spreadsheets, manual mappings, or custom queries — introducing risk, delays, and duplicated effort.


To simulate hierarchy, teams repurposed metadata fields to tag related accounts and relied on engineers to manually stitch balances together for reporting. This workaround was fragile, inconsistent, and couldn’t support accurate or timely financial reporting at enterprise scale.


The ledger remained financially correct, but structurally flat. It didn’t reflect how businesses actually organized money — creating growing reconciliation overhead as customers scaled.

Rainy Ride
Rainy Ride
Rainy Ride

03

Constraints

Constraints

Shaped by Real Enterprise Workflows

Ledger Categories wasn’t designed in isolation. The shape of the solution was driven by a small set of enterprise customers whose financial workflows exposed clear constraints around hierarchy, aggregation, and correctness.

Ledger Categories wasn’t designed in isolation. The shape of the solution was driven by a small set of enterprise customers whose financial workflows exposed clear constraints around hierarchy, aggregation, and correctness.

Ledger Categories wasn’t designed in isolation. The shape of the solution was driven by a small set of enterprise customers whose financial workflows exposed clear constraints around hierarchy, aggregation, and correctness.

Procore
Procore
Procore

Needed to represent how funds flowed between General Contractors and Subcontractors across large, multi-party projects.
This required hierarchy that reflected real organizational relationships, not just reporting labels.

Needed to represent how funds flowed between General Contractors and Subcontractors across large, multi-party projects.
This required hierarchy that reflected real organizational relationships, not just reporting labels.

Needed to represent how funds flowed between General Contractors and Subcontractors across large, multi-party projects.
This required hierarchy that reflected real organizational relationships, not just reporting labels.

Ramp
Ramp
Ramp

Needed hierarchy at the vendor and transaction level to support payments, accounting, and downstream reporting.
This constrained the system to support deep nesting without sacrificing performance or financial accuracy.

Needed hierarchy at the vendor and transaction level to support payments, accounting, and downstream reporting.
This constrained the system to support deep nesting without sacrificing performance or financial accuracy.

Needed hierarchy at the vendor and transaction level to support payments, accounting, and downstream reporting.
This constrained the system to support deep nesting without sacrificing performance or financial accuracy.

MainStreet
MainStreet
MainStreet

Needed to roll up interest payables into a single account to pay customers while preserving underlying ledger data.
This required aggregation to be structural and reversible, not destructive.

Needed to roll up interest payables into a single account to pay customers while preserving underlying ledger data.
This required aggregation to be structural and reversible, not destructive.

Needed to roll up interest payables into a single account to pay customers while preserving underlying ledger data.
This required aggregation to be structural and reversible, not destructive.

04

Solution

Solution

MAKING HIERARCHY USABLE AT SCALE

At its core, Categories was about introducing hierarchy without compromising financial correctness, performance, or existing workflows.


These are the three decisions that made hierarchy usable at enterprise scale:

At its core, Categories was about introducing hierarchy without compromising financial correctness, performance, or existing workflows.


These are the three decisions that made hierarchy usable at enterprise scale:

At its core, Categories was about introducing hierarchy without compromising financial correctness, performance, or existing workflows.


These are the three decisions that made hierarchy usable at enterprise scale:

AGGREGATED BALANCE VIEWS
AGGREGATED BALANCE VIEWS
AGGREGATED BALANCE VIEWS

Surface rollups inline to preserve context and reduce reconciliation overhead

Surface rollups inline to preserve context and reduce reconciliation overhead

Surface rollups inline to preserve context and reduce reconciliation overhead

HIERARCHY SUPPORT
HIERARCHY SUPPORT
HIERARCHY SUPPORT

Make account relationships legible without adding cognitive or visual complexity

Make account relationships legible without adding cognitive or visual complexity

Make account relationships legible without adding cognitive or visual complexity

Category Assignment
Category Assignment
Category Assignment

Introduce structure without disrupting existing account creation workflows

Introduce structure without disrupting existing account creation workflows

Introduce structure without disrupting existing account creation workflows

05

Outcome

Outcome

INLINE ROLLUPS AT SCALE

Aggregated balances are surfaced inline, allowing teams to scan rollups and drill into detail without losing context or switching views.

Aggregated balances are surfaced inline, allowing teams to scan rollups and drill into detail without losing context or switching views.

Aggregated balances are surfaced inline, allowing teams to scan rollups and drill into detail without losing context or switching views.

Category-level balances surfaced alongside accounts

Category-level balances surfaced alongside accounts

Category-level balances surfaced alongside accounts

Category details consolidate balance logic in one place

Category details consolidate balance logic in one place

Category details consolidate balance logic in one place

A dedicated Categories view for faster navigation and review

A dedicated Categories view for faster navigation and review

A dedicated Categories view for faster navigation and review

HIERARCHY WITHOUT VISUAL OVERHEAD

Account hierarchy is revealed inline through expandable rows, making complex financial structures legible without visual noise.

Account hierarchy is revealed inline through expandable rows, making complex financial structures legible without visual noise.

Account hierarchy is revealed inline through expandable rows, making complex financial structures legible without visual noise.

Long category lists collapsed to reduce cognitive load

Long category lists collapsed to reduce cognitive load

Long category lists collapsed to reduce cognitive load

Nested categories reveal structure only when needed

Nested categories reveal structure only when needed

Nested categories reveal structure only when needed

A complete, bird’s-eye view of category structure

A complete, bird’s-eye view of category structure

A complete, bird’s-eye view of category structure

STRUCTURE BUILT INTO EXISTING SETUP

Categories are assigned directly within existing account workflows, avoiding the need for a separate management surface while preserving setup speed.

Categories are assigned directly within existing account workflows, avoiding the need for a separate management surface while preserving setup speed.

Categories are assigned directly within existing account workflows, avoiding the need for a separate management surface while preserving setup speed.

Categories assigned inline during account creation

Categories assigned inline during account creation

Categories assigned inline during account creation

Accounts can belong to multiple categories

Accounts can belong to multiple categories

Accounts can belong to multiple categories

Category structure integrated into existing account workflows

Category structure integrated into existing account workflows

Category structure integrated into existing account workflows

06

Impact

06

Impact

06

Impact

06

Impact

IMPACT AT SCALE

Ledger Categories turned a flat ledger into a scalable financial model — unlocking faster reporting, enterprise adoption, and revenue growth.

ARR added

$255K

New customers

3

Custom SQL Reports

0

Request a

Case study

Want to go deeper?
I’m happy to walk through tradeoffs, constraints, and what I’d do differently.

Request a

Case study

Want to go deeper?
I’m happy to walk through tradeoffs, constraints,
and what I’d do differently.

Request a

Case study

Want to go deeper?
I’m happy to walk through tradeoffs, constraints, and what I’d do differently.

Request a

Case study

Want to go deeper?
I’m happy to walk through tradeoffs, constraints, and what I’d do differently.