Extract discovery insights

Findings: reconciliation discovery

Eight 40-minute calls with finance leads, August

Bottom line

These calls support further validation of a targeted reconciliation product, not yet a broad build decision. Several participants described substantial manual work, but “reconciliation” covers different problems. Adoption will depend on handling messy data and reducing switching effort—not just offering automated matching.

What we learned

1. Reconciliation is a material problem for some, not all. Five participants described current reconciliation pain: - Logistics: three or more days of an eight-day close, with missing bank-feed transactions checked against statements in Excel. - Retail: manual re-keying of card-statement PDFs and a shared spreadsheet used by four people; £14k of duplicates found last quarter. - Agency: intercompany balances take a day and a half to resolve. - Hospitality: processor payouts net of fees and refunds require manual reconciliation and hold up close. - Construction: reconciliation accounts for roughly 40% of close, driven by repetitive matching volume.

Two participants—SaaS and charity—said close was fine. The SaaS participant’s remaining frustration was receipt chasing, not reconciliation. The manufacturing participant primarily described a failed tool migration rather than quantifying current close pain.

2. There is no single, validated product scope yet. The examples span incomplete bank feeds, card-statement ingestion, intercompany balances, processor payouts and high-volume matching. These may require different integrations and workflows. Card reconciliation is plausibly adjacent to our spend-management product, but its evidence here comes from one call; we should not assume it represents the wider opportunity.

3. Trust and implementation are central adoption requirements. The construction controller wanted proof using their own messy data. The logistics controller expressed scepticism about promised time savings. The manufacturing CFO reported a four-month migration, lost matching rules and a return to spreadsheets; he would not switch again without migration support.

Together, these suggest that realistic-data trials, continuity of existing rules and migration assistance may matter as much as matching capability.

4. Willingness to pay remains unproven. One participant said saving two days would make a solution worthwhile, but gave no price or commitment. Another explicitly ruled out new spending this year. The duplicate-loss example indicates potential financial value, but does not establish recoverable savings or a purchasing budget.

How confident can we be?

• Moderate confidence that manual reconciliation creates meaningful pain for a subset of companies like these, and that trust and switching friction deserve early attention.
• Low confidence in market prevalence, the best initial segment, willingness to pay, achievable automation rates or expected close-time savings.

This is a small qualitative sample; recruitment and representativeness are unspecified. Evidence is self-reported, not verified through workflow observation or transaction data. The calls establish neither demand for one common solution nor demand specifically from our existing customers.

Recommended next step

Choose a narrow use case to test—not a general reconciliation platform. Observe workflows and trial matching on real, messy data with several similar customers. Measure manual effort removed, exceptions remaining and implementation burden, then test a priced pilot. Advance to a build decision only with repeatable evidence of value and credible adoption commitments.

Reconciliation discovery: findings from 8 finance-lead calls (August 2026)³

Bottom line: Most of the finance leads we spoke to have real reconciliation pain. But it shows up as several different problems, not one, and the biggest barrier to adoption is distrust and switching cost. We have almost no evidence on willingness to pay. This justifies more targeted discovery. It doesn't yet justify a decision to build.

What we learned

1. The pain is common but not universal. Six of eight say reconciliation is a significant part of close (Calls 1, 3, 4, 5, 7, 8).¹ The two who said close is fine (2, 6) run the smallest companies, at 95 and 70 staff, and one of them has a modern ERP. That hints at a size threshold around 100+ staff, but it rests on two data points.

2. Where people gave numbers, the cost is large. - About 3 of 8 close days (1) - 1.5 days a month (5) - About 40% of close (8) - £14k of duplicates found in one quarter (3)

All of these are self-reported.

3. "Reconciliation" is at least five separate problems. Each call with pain named a different source: - Bank feed dropping transactions (1) - Card statements arriving as PDFs and re-keyed into a shared spreadsheet (3) - Intercompany balances that don't agree across entities (5) - Payment-processor payouts that net off fees and refunds, so nothing matches the bank line (7) - Sheer volume of repetitive matching (8)

No two calls named the same source. One "reconciliation product" would have to handle different matching logic for different segments. Card spend (3) sits closest to what we already do and could be a natural starting point, but it came up in only one call.

4. Switching cost and skepticism are the main barrier.² - Call 4 switched reconciliation tools last year. Migration took four months, they lost their matching rules, and half the team drifted back to spreadsheets. He won't switch again unless someone else does the migration. - Call 8 won't believe a tool works until it handles their messy data, because demos always use clean data. - Call 1 has "heard that before."

That's three of eight, including people with heavy pain. Done-for-you migration and proof on the customer's own data look like requirements, not differentiators.

1. One adjacent signal. Call 2's only complaint was chasing people for receipts. That's our existing spend-management territory, not reconciliation.

How confident can we be?

Moderate confidence: - Reconciliation takes a meaningful share of close time for mid-sized finance teams. - The underlying causes vary widely between companies. - Buyers are wary of switching tools and of vendor demos.

Low or no confidence: - Willingness to pay. Only one person answered the question, and only conditionally. One has a budget freeze. - Which problem to build for. Each pain source appears exactly once. - Size threshold. It rests on two calls. - Prevalence. We don't know how these eight were recruited, whether they're customers, or how representative they are.

Method limitations: - Eight calls, one interviewer, one month. - We're working from excerpts chosen as "relevant," so the full transcripts may shift the emphasis. - The pay question was open-ended and hypothetical.

What would raise confidence before a build decision

• Recruit 8–10 more finance leads at companies with 150–400 staff. Screen them by pain source so we learn which problem repeats.
• Test the card-spend starting point with existing customers. Ask how they reconcile card spend today. We may already hold the data needed to solve it.
• Test willingness to pay concretely. Use price anchors or offer a paid pilot rather than asking an open question.
• Run a matching test on one prospect's real, messy data. Call 8 set that bar, and it's the test that would convince the skeptics.