Data Reconciliation

The Problem

This was my first exposure to reconciliation as a domain, and the volume and complexity of data involved went well past a typical feature scope. Before I could design anything credible, I had to actually understand it: how reconciliation worked, what other ERP systems in the space could and couldn’t do, and where our product’s data model diverged from expectations shaped by those other tools.

Research & Approach

I mapped specific flows through the reconciliation process and annotated them with research notes instead of working from assumptions. The domain surfaced enough edge cases that user interviews alone weren’t going to cut it, so I tested and confirmed my understanding directly with subject matter experts. This feature spanned multiple sprints, quarters, and teams, so I built documentation as I went, specifically so ownership could move between people and phases without losing consistency along the way.

Constraints

The product’s existing data model was itself a constraint: it had already diverged from what other ERP tools assumed, so the design couldn’t be the textbook reconciliation flow in the abstract. It had to reconcile against what the product already stored and how it was already structured.

The Solution

The final design let users work accurately within the reconciliation flow and adjust records so data stayed consistent across systems: the core requirement, given that most of the friction came from systems disagreeing with each other in the first place.

Outcome

Shipped and in use today. Feedback has been informally positive.

Reflection

Ramping into ERP systems from zero, and learning to document for a long, multi-team timeline, turned out to matter well beyond this one project. When a related reconciliation problem showed up again later, I moved faster and pushed further, because I already knew to look one layer beneath the stated problem.