Architecting Financial Logic for the Web: Building an IOLTA 3-Way Reconciliation Tool

Sabrina Brown — Fri, 02 Oct 2026 22:32:12 +0000

When building web applications, developers spend a massive amount of time optimizing state management, reducing render cycles, and perfecting UI components. But when you start building software for the legal and accounting sectors, the priority completely shifts. A dropped frame on an animation is a minor bug; a dropped decimal in a trust account is a disbarment.

Transitioning from a career deeply rooted in corporate finance and transaction processing into software development gave me a unique perspective on how brittle typical web math can be. Recently, while building out the growth tools for Jazzy Management LLC, I decided to engineer a free IOLTA (Interest on Lawyers' Trust Accounts) 3-Way Reconciliation Calculator.

Here is a technical teardown of the financial logic required to build a compliant reconciliation tool, how to handle the data architecture, and how we tied it into a backend automation system to drive our core B2B SaaS, JazzySend.

The Stakes of IOLTA and the 3-Way Match

State Bar associations mandate that attorneys hold client funds (like retainers or settlement payouts) in specialized trust accounts. The compliance standard for these accounts isn't a simple bank-to-book match. It requires a strict 3-way reconciliation:

Adjusted Bank Balance: The ending bank statement balance, plus uncleared deposits, minus outstanding checks.

Book Balance: The total running balance in the firm’s internal accounting journal.

Sum of Individual Client Ledgers: The aggregated total of every individual client's trust sub-account.

For the firm to be compliant, all three of these numbers must match to the exact penny. If Adjusted Bank Balance != Book Balance or Book Balance != Sum of Client Ledgers, the firm is out of compliance and faces immediate audit risk.

The challenge in building this for the web is that you are asking a browser to handle strict financial transaction math—which brings us to the first major architectural hurdle.

Defeating the Floating-Point Problem

If you have spent any time writing JavaScript or Dart, you are likely familiar with the floating-point math issue where 0.1 + 0.2 === 0.30000000000000004. When dealing with hundreds of thousands of dollars in a trust account, relying on standard floating-point numbers for financial logic is catastrophic.

To ensure strict compliance in the calculator, all user inputs must be intercepted, sanitized, and converted into integers before any mathematical operations occur.

Instead of calculating $50,500.55 - $1,500.20, the architecture strips the decimals and calculates everything in cents: 5050055 - 150020.

Input Sanitization: Regex strips currency symbols, commas, and errant spaces from the user's input fields.

Integer Conversion: The sanitized string is parsed into a float, immediately multiplied by 100, and rounded to the nearest whole integer using Math.round() to eliminate trailing decimal artifacts.

Reconciliation Logic: The three-way match is calculated entirely using these integer values.

Presentation Layer: Only after the variance is calculated (e.g., finding a discrepancy of 5000 cents) is the value divided by 100 and formatted back into a localized currency string (e.g., $50.00) for the user interface.

This ensures that the strict zero-tolerance variance required by Bar associations is mathematically guaranteed by the tool's core logic.

State Management for Multi-Step Verification

An IOLTA reconciliation is not a single input-output equation. It requires holding multiple interdependent states. The calculator must manage:

bankStatementBalance

unclearedDeposits

outstandingChecks

bookBalance

clientLedgerSum

I architected the component to utilize a reactive state model. As the user inputs the first three variables, the adjustedBankBalance is dynamically computed in real-time. When the user clicks "Verify Compliance Status," the application evaluates the three core pillars.

If adjustedBankBalance === bookBalance === clientLedgerSum, the state updates to yield a "Compliant" success message. If any of those values diverge, the component calculates the exact variance amount, isolates which of the three pillars failed the match, and dynamically renders an error state warning the user of an audit risk.

Routing the Logic to Backend Automation

A free tool is only useful if it drives the core business forward. The entire purpose of this calculator is to highlight a law firm's administrative pain points and route them directly into JazzySend—our secure B2B email marketing platform.

When a firm finds a variance, the immediate next step is usually notifying clients of trust account replenishment requirements or missing funds. Doing this manually via standard BCC emails is a massive security risk for sensitive legal data.

To bridge this gap, the calculator acts as a contextual primer. While the calculator processes the logic on the client side, the surrounding page architecture is designed to capture the user's intent. Once they realize the complexity of their trust accounting, the page seamlessly introduces JazzySend's isolated-instance architecture.

By utilizing Make.com to handle our backend webhooks and Resend for transactional email delivery, we can automate the exact pain points the calculator brings to light. If a firm needs to request immediate trust replenishment, they don't draft a new email; they use JazzySend's dynamic tags to pull the exact variance data and route a secure, automated template to their client list via Firebase-backed infrastructure.

Building financial tools for the web requires a rigid adherence to mathematical precision, but when executed correctly, it serves as the ultimate proof of competence. You aren't just telling a highly analytical audience that your software is secure and accurate; you are mathematically proving it to them right inside their browser.

By utilizing Make.com to handle our backend webhooks and Resend for transactional email delivery, we can automate the exact pain points the calculator brings to light. If a firm needs to request immediate trust replenishment, they don't draft a new email; they use JazzySend's dynamic tags to pull the exact variance data and route a secure, automated template to their client list via Firebase-backed infrastructure.

How to Wire Up Firebase, Stripe Webhooks, and Resend API in a SaaS Backend

Sabrina Brown — Thu, 20 Aug 2026 23:12:51 +0000

Stop wrestling with backend infrastructure. Learn how to securely integrate Firebase Cloud Functions, Stripe Webhooks, and the Resend API for your next SaaS project.

Building a SaaS application usually follows a painfully predictable cycle: you have a great idea for a core feature, but before you can build it, you have to spend three weeks wrestling with authentication, database security, payment gateways, and transactional emails.
Wiring together Firebase for user management, Stripe for subscription handling, and Resend for email delivery is the gold standard for a modern backend, but the integration points can be incredibly tedious.
Here is a high-level breakdown of how to structure this architecture so your app is secure and scalable from day one.

Firebase Cloud Functions as the Command Center

Instead of exposing your database directly to the frontend, utilize Firebase Cloud Functions. This keeps your business logic entirely server-side. When a user creates an account, a trigger function should automatically generate their profile document in Firestore, establishing their baseline data structure before they even hit your onboarding screen.

Handling Stripe Webhooks Securely

The most common mistake when integrating Stripe is relying on client-side success messages to grant user access. If a user closes the browser too quickly, or if a payment is delayed, their account state breaks.

Instead, use Stripe Webhooks routed directly to a dedicated Firebase Cloud Function.

Your endpoint needs to:

Verify the Stripe signature to ensure the payload is authentic.
Listen specifically for checkout.session.completed and customer.subscription.deleted.
Update the user's active status and tier directly in Firestore based on these secure backend events.

Plugging in the Resend API for Transactional Emails

Deliverability is everything. Instead of using generic SMTP setups, integrate the Resend API directly into your Cloud Functions. You can set up event listeners in Firestore so that when a specific document changes (e.g., a "welcome email" flag is set to true during Stripe checkout), a function automatically fires an HTTP request to Resend, dispatching your beautifully coded welcome templates without any manual intervention.

The Developer Shortcut

Understanding this architecture is one thing; writing, testing, and debugging the hundreds of lines of code required to make Firebase, Stripe, and Resend talk to each other flawlessly is another.

If you are a developer looking to launch your next SaaS project this weekend instead of next month, you don't need to build this from scratch.

I’ve packaged my exact production-ready architecture into a Secure SaaS Backend Boilerplate. It includes the fully configured Firebase Cloud Functions, pre-mapped Stripe Webhook listeners, and the Resend API integration, all ready to deploy.

DEV Community: Sabrina Brown