Key Facts:
• A growing real estate title company had outgrown the third-party accounting tool at the center of their closing workflow which was a system so complex and unguarded that users could easily knock a file out of balance, create escrow discrepancies, or trigger unexpected system behavior without realizing it until the damage was done.
• Over 2.5 years of research, design, and iteration, embedded with a product manager and engineering team through every stage, I helped design and build a replacement system that automated 80–90% of all line items and integrated accounting directly into the normal flow of working a file.
• In its first year, the system processed over $500 million in transactions with no major accounting errors or losses. A vendor audit found that out of ~75 flagged remittance errors, only one originated from the new system. Escrow losses dropped from roughly 10% to 2%.
The Problem
Real estate closings involve a lot of money moving between a lot of parties in a short window of time. Fees, payoffs, recording costs, policy premiums, lender disbursements — the accounting on a single file is dense, and the margin for error is essentially zero. When something goes wrong, it can mean escrow losses, failed fundings, or regulatory exposure.
The client's existing tool was a third-party product built for a broad range of transaction types, and it was never a great fit. It handled different kinds of line items in different ways, required users to take multiple repetitive steps to prepare a file for funding, and offered very few guardrails against mistakes. A user could easily create a balancing issue in escrow without knowing they'd done it. The system itself could interpret inputs in unexpected ways. And because the accounting work was largely separate from the day-to-day process of working a file, it was something users had to remember to manage on top of everything else rather than something that happened as a natural byproduct of their work.
Compounding all of this was the client's customer base. Unlike most title companies, they worked heavily with real estate investors: buyers with more complex financing structures, more frequent buyer changes mid-transaction, and a higher rate of non-standard closing scenarios. The third-party tool wasn't built for any of that, and the workarounds required to handle those cases were time-consuming and fragile.
The goal was to replace it entirely, with a system that was tightly integrated, heavily automated, and built specifically for how this team and their clients actually worked.
Defining the Solution
The project ran about 2.5 years from discovery through handoff, and the discovery phase was the largest single investment of time. That was intentional. Accounting for real estate closings isn't one task, it's an end-to-end process with distinct stages: balancing files, issuing payments, reconciling transactions, and auditing the books. Each stage has its own users, its own data needs, and its own outputs that feed into what comes next. Getting any one of those wrong would compromise everything downstream, leading to errors, reconciliation issues, and ultimately escrow losses.
I worked extensively with users and subject matter experts at every stage of that process, not just to understand what each stage required in isolation, but to map how information flowed between them and how each person along the way needed to see and interpret that information. That kind of end-to-end mapping is what made the eventual automation possible. You can't automate what you don't fully understand.
A few things came out of discovery that shaped the system in fundamental ways.
The first was the automation opportunity. The old tool required users to manually manage most line items. But in working through the process in detail, it became clear that the vast majority of those items — fees, payoffs, recording costs, policy premiums — were knowable from information already present in the file. That realization became the foundation of the system: rather than building a separate accounting interface that users had to maintain alongside their work, we built a system that built the statement and ledger through the normal process of working a file. By the time a file was ready to close, 80–90% of the statement was already complete.
The second was the multi-ledger architecture. Every competing product on the market operates on a 1:1 model, one ledger per file. For most standard transactions that's fine. But for a client base dealing regularly with multiple loans on a single property, or buyers who change mid-transaction, it creates a constant juggling act of opening new files, duplicating work, or starting over entirely. Working closely with the PM through the research process, we identified this as both a pain point and a competitive opportunity. The solution was a multi-ledger system in which a single file could hold an infinite number of ledgers, with each representing a separate loan, party, or accounting scenario, all tied to the same file. It handled the investor-heavy use cases cleanly, and as a structural innovation it turned out to have broader reach than we originally anticipated: it also enabled attorney-closing state workflows without requiring any additional feature-specific development.
Designs
An early testing version of the interface for creating and editing line items. The statement preview on the right was used to check the system against statements made in the third party system.
V1 of the accounting interface with a live preview of the statement on the right.
V2 of the accounting interface was redesigned to focus on speed and ease of input for users, with a focus on quick-add abilities and keyboard navigation
If a line item was a more complex edge case, users still had access to the full power of the line item editing and configuration
Outcomes
The system fully launched in 2025 and has since processed over $500 million in transactions without a major accounting error or loss.
The error rate improvement was visible almost immediately in the reconciliation work that followed. In a recent vendor audit of remittance errors, approximately 75 files were flagged. One came from the new system. The rest were errors from the old third-party tool that were still present in older files. Escrow losses dropped from roughly 10% to 2% over the same period, a result attributable to a combination of factors, but one in which the accounting system played a significant role.
The multi-ledger architecture, originally designed for investor-specific use cases, has proven to be a durable structural advantage. It continues to enable advanced accounting scenarios such as attorney-closing state workflows, without the need to build dedicated features for each new case. It has been on of the most impactful design choices made in discovery that keeps paying off years after handoff.
The project was completed and transitioned to another designer for long-term maintenance. The foundation it built continues to support the client's growth.