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.
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.
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.
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.