Nester
2025
Bank Reconciliation
Moving reconciliation from spreadsheets to Nester — connecting bank accounts, matching movements against invoices, and laying the groundwork for automated matching built on real transaction data.
Context
Nester clients managed their finances in fragments — reconciled by hand, one spreadsheet at a time.
Comparing bank movements against invoices was slow and error-prone, and left managers without a real, up-to-date view of their cash flow. Without it, clients were exporting data or leaning on third-party tools just to close their books. We integrated with WealthReader to bring account aggregation directly into Nester.
Challenge
A feature big enough to break into three.
Automating without any real data
The end goal was automatic reconciliation, but designing that matching logic before seeing a single real transaction meant building rules on assumptions — what a "typical" payment description looked like, how often edge cases occurred — instead of on actual patterns.
Three phases, not one big bet
Instead of shipping automation as one large, uncertain block, the team split the build: connect and view first, manual matching second, automation last — once there was real transaction data to design it from.
Approach
Let real usage teach the system, before asking it to think for itself.
Designing for data you don't have yet
The phased rollout doubled as a research strategy. Shipping read-only bank connection first meant Nester could observe real transaction typology before Phase 3's automated rules were ever defined.
The roadmap in Notion — three phases, tracked from kickoff to what's still in progress.
A match that has to be exact, not close
Manual reconciliation was designed as a two-table, master-detail workspace: bank movements on the left, unmatched Nester records on the right. A live summary calculates the gap between the two selected amounts — the "Conciliar" button only activates when that gap is exactly €0.00, so an approximate match can't quietly corrupt the books.
The reconciliation workspace — bank movements on the left, unmatched Nester records on the right.
The case nobody had modeled yet
Partway through, we designed for what happens when a bank deposit is larger than the invoice it's matched against. The system detects the surplus automatically and lets the manager resolve it as tenant credit — auto-applied to the next invoice — or a rounding adjustment.
Solution
Three phases, each shipping something usable on its own.
Phase 1 — Connect and view
Bank linking through the WealthReader widget, a consolidated Treasury › Banks view with a 12-month cash flow chart, and a bank detail view with a searchable, filterable movements table.
The Treasury › Banks overview — consolidated balance, cash flow, and every connected account.
Phase 2 — Manual reconciliation
A reconciliation status card (pending vs. reconciled, with a progress bar) as the entry point, the matching workspace itself, and a shortcut to create a missing expense or invoice directly from an unmatched movement — pre-filled and auto-reconciled on save.
From the reconciliation status card to the matching workspace, in one click.
Phase 3 — Automation, designed but not yet built
Suggested matches based on amount, date, and description; configurable rules; automatic 1:1 reconciliation for high-confidence matches; and advanced reconciliation reporting.
Early concepts for Phase 3 — suggested matches and configurable rules, not yet built.
Impact
141 bank accounts connected
Linked via WealthReader across 87 connections, led by CaixaBank, Sabadell, and BBVA.
3,412 movements reconciled
Matched through the reconciliation workspace since Phase 2 launched, peaking at 763 in a single month.
34 businesses, multiple banks
Over a third of connected businesses track two or more accounts from one place.
Reflection & what's next
Shipping under real pressure, without cutting the corner that mattered.
Holding the line on quality
Days before the planned Phase 2 release, the team flagged the payments logic wasn't fully derisked and pushed the date back a week rather than ship something uncertain — the deploy that followed was recognized internally as a genuinely hard one, done well.
What the live product surfaced
Reviewing Phase 2 in production surfaced gaps design review missed — the connected-bank cards were missing the same reconciled/pending counts already shown inside each bank's detail view. Logged for the next release, not a redesign.
What's still open
No defined flow yet for un-reconciling a payment when a bank charge is returned; permissions are Admin-only for the MVP, with a flexible roles system still to design; matching one payment against multiple invoices isn't scoped yet; and the confidence thresholds behind Phase 3's suggestions are still an open question.
Key Takeaway
Sequencing is a design decision, not just a scoping one.
Splitting the build into three phases wasn't about doing less — it was about refusing to design the hardest part, automation, from assumptions when real usage data was one phase away.