Reconciliation

Context

I’d tackled reconciliation before, at a much larger scale (see: Data Reconciliation, Vertex). That domain knowledge is what let me push past the surface-level ask here instead of starting from zero again.

The Problem and the Reframe

The brief was to improve reconciliation. Research said otherwise. The real problem sat one layer down: transaction-level issues were what made accurate reconciliation impossible in the first place. Fix reconciliation directly, and you’re just designing a nicer experience around inputs that were never reliable to begin with. That’s a losing bet.

The Business

Studio Designer positioned itself to customers as a one-stop shop, comprehensive enough that a bookkeeper wouldn’t need to leave the platform to reconcile their books. Reconciliation was the clearest place that promise didn’t hold: audit issues surfaced, people burned hours just tracking down the source of a discrepancy, and for many users, the real answer to “how do you reconcile” turned out to be some ad hoc configuration of Excel, not anything in the product. That gap between the one-stop-shop pitch and what people actually did outside the product was the business case for fixing this.

Research

I built the research plan and interview scripts myself, and ran both synchronous and asynchronous interviews. Competitive research showed how other tools approached similar transaction-and-reconciliation problems. Throughout, the goal was narrow and specific: confirm that transactions, not reconciliation, were the right place to intervene, before committing to a direction.

Every interview ended with the same open prompt, a “magic wand” question: if you had a magic wand that could instantly change one part of the product, what would you change? Letting people name the fix themselves, unprompted, was one more way to confirm the reframe rather than lead them toward it. Individual answers varied, but taken together they revealed the same general trends and desires, and asking it that way got people thinking more creatively than a flatter question like “what’s your number one priority” would have.

The Solution

The design starts at the bank account level:

• Logic builders let users define matching rules and conditions, building on rule-building patterns already validated in a prior project (see: Rule Builder Engine)
• Transaction matching surfaces as a task-based flow against incoming bank data
• Comparison views put bank transactions side by side with internal records

Constraints

This also wasn’t a clean slate: reusing the logic-building pattern already validated in the Rule Builder Engine project meant engineering wasn’t building a second logic-builder from scratch, which mattered given how early-stage this concept still is.

Flexibility itself was a constraint, not just a feature: some accounting teams needed far more latitude than others, but more flexibility for the user also meant more liability for the product if someone configured something incorrectly. Every point of flexibility raised the same question: what should stay locked down, and should the interface trust the user’s judgment, block the action outright, or just warn hard before letting it through?

Current Status & Early Signal

Still in development. Early stakeholder and user reaction to the concept has been strong, though it hasn’t shipped yet.

Reflection

The most valuable part of this project wasn’t the interface. It was catching that the stated problem and the real problem weren’t the same thing, and having the research discipline, plus the domain experience, to catch it before committing to a design.