All work
Purse · 2024 — 6 months

Payment reconciliation

A reconciliation workspace for finance teams who were matching bank transfers to transactions by hand, file by file.

Purse — payment reconciliation workspace
Role
Sole Product Designer: research, flows, UI, design system, API co-design
Team
1 PM, backend, a data engineer
Users
Merchants’ accountants and finance teams
Scope
Web app, API contract, high-density tables
In short

Every week, accountants rebuilt the link between payouts and transactions in spreadsheets. The PM had put the topic on the roadmap with a solution he had already built elsewhere. My interviews revealed a different need: first see the reconciliation rate, and where it gets stuck. I designed the workspace, and co-designed the API behind it, around that need.

  • ~6 hsaved per week per finance team
  • 100%of clients adopted the tool
  • 0reconciliations still done outside the product
Context

Reconciliation was living outside the product

Purse handled the payments but stopped at the payout. Everything after that, proving that a bank transfer corresponded to a given set of transactions, happened in the client’s own spreadsheets. Finance teams told us plainly that it was the most tedious part of their month.

The problem

Finance teams had to collect files from several sources, then guess which bank transfer matched which transactions.

  • Data split across bank statements, exports and the dashboard, with no shared identifier.
  • Manual matching, so errors surfaced weeks later during closing.
  • No audit trail: nobody could explain how a past match had been decided.
How I worked

Start from real files, not from a known solution

  1. Interviews

    With accountants and finance leads, going through their actual month-end files. Their first question was never “does this transfer match?” but “how much is left to reconcile?”.

  2. Journey mapping

    Reconciliation broke at the payment partners, each sending payouts in its own format. Hence the idea of a per-partner view.

  3. Prototype and tests

    The planned solution and mine, tested with the same users. The results became the argument with the PM.

  4. API co-design

    Matching rules and payload defined with the engineers, so the UI and the API shipped together.

Trade-offs

The calls that shaped the product

What should an accountant see first?

The reconciliation rate, right in the table

I put the reconciliation rate in the ledger, with the breakdown by payment partner up front. Accountants see where things are stuck at a glance, before opening a single row.

What settled it: the interviews. Every finance team started its day with the same question: how much is left to reconcile, and with which partner?

Not this: The solution the PM had built in a previous job: a list of transfers to process one by one, with no overview.

How far should we automate?

Suggest the match, never decide it

The system proposes a match with a confidence level and its reasons; the accountant confirms.

What settled it: an error found at closing costs hours, a confirmation costs one click. Trust came from showing the reasoning, not hiding it.

Not this: Fully automatic matching, faster on paper.

One row at a time, or many?

A dense ledger rather than card-by-card review

Many rows at once, with sorting and totals in view, rather than one item per screen.

What settled it: finance users compare rows with each other. In tests, daily users rejected the card-by-card review.

Not this: A card-based review queue, liked by new users only.

Convince

Changing a solution that was already decided

The PM had put reconciliation on the roadmap with a precise idea: reuse the feature he had built in a previous job. It answered another product’s needs, not our clients’.

Rather than pit my opinion against his, I brought evidence: interview quotes, then a prototype tested next to his version. The topic stayed on his roadmap, and the research-led version is the one that shipped.

What I heard in interviews

  • In the morning I want to know how much I have left to reconcile. I look at the detail later.

    Accountant, e-commerce merchant

  • When it gets stuck, it’s almost always with the same partner. I want to see that straight away.

    Finance lead

  • I spend almost a day a week in my files working out who paid what.

    Accountant

Outcome: the planned feature stayed on the roadmap, redesigned around the reconciliation rate and the per-partner view.

Impact

Every client moved reconciliation into the product

The workspace fully replaced the spreadsheet step. The whole client base adopted it, and finance teams got back about 6 hours a week that used to go into row-by-row matching.

Time measured with finance teams during interviews, before and after launch; figures rounded and anonymised.

  • Time saved per week per finance team~6 h
  • Client adoption100%
  • Reconciliations done outside the product0
What I took away

Finance users don’t want automation. They want a tool that shows its work and lets them take responsibility for the last step.

What I would do differently: bring the data engineer into the interviews from week one. Half of our design constraints were data constraints we discovered late.