Extract discovery insights

Executive Summary

We interviewed eight finance leads across various industries (70–400 FTEs) to assess whether to build a reconciliation product.

The takeaway: A generic, standalone reconciliation tool is a high-risk bet with massive adoption hurdles. However, there is acute, high-value pain around messy, high-volume card and payment processor reconciliations—areas adjacent to our core spend-management platform.

---

What We Learned

#### 1. Pain is driven by transaction complexity, not company size * High-pain profiles (FTEs 180–400): Companies with complex transaction streams (retail cards, payment gateway net-offs, intercompany transfers, dropped bank feeds) spend 30–40% of their month-end close (1.5 to 3+ days) manually ticking spreadsheets. * Low-pain profiles (FTEs <120): Smaller teams or digitally native businesses with modern ERPs report manageable 4-to-5-day closes. Their bottlenecks lie in chasing receipts, not reconciling balances.

#### 2. Buyers are deeply skeptical and burned by past tools * Migration trauma: One CFO spent four months migrating to a dedicated reconciliation tool, lost matching rules, and saw the team revert to Excel. He will not switch again without full migration support. * “Clean data” cynicism: Buyers repeatedly noted that vendors promise automated matching but fail on real-world messy data (e.g., processor fees netted against payouts, missing bank feed lines).

#### 3. Clear synergy with core spend management Retail and hospitality leads cited corporate cards and payment payouts as their primary close bottlenecks (e.g., one retail chain discovered £14k in duplicate card transactions via shared spreadsheets). Reconciling card spend naturally fits our existing product footprint.

---

Confidence Assessment

Sample Limitations: Eight calls provide qualitative directional signals, but the sample spans very diverse business models (logistics, SaaS, retail, charity, construction). We lack statistical significance on pricing thresholds and specific ERP integrations.

---

Product Recommendation

1. Do not build a generic, horizontal reconciliation platform. Competing against established ERPs and broad reconciliation players carries extreme migration friction.
2. Double down on native spend reconciliation: Scope a feature set within our existing platform focused on automated card matching and statement ingestion (e.g., parsing PDF card statements, catching duplicate charges).
3. De-risk with a messy-data PoC: Before committing to a major build, run a technical pilot with 2–3 design partners (such as the retail chain or logistics firm) to prove our matching algorithm handles their dirtiest statement data without manual rule configuration.

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.

Findings summary

The pain is real, but it is not universal—and it is concentrated in specific reconciliation workflows. Five of the eight interviewees described reconciliation as a meaningful close burden. Their problems were concrete: dropped bank-feed transactions and manual matching (Call 1); high-volume card statements re-keyed from PDFs (Call 3); intercompany balances (Call 5); processor payouts obscured by fees and refunds (Call 7); and repetitive matching at scale (Call 8). One reported finding £14k in duplicate transactions. These examples suggest the opportunity may be less “speed up month-end close” and more “handle particular messy, high-volume matching jobs reliably.”

Company context seems to matter.¹ The clearest pain came from organisations with volume, multiple entities, many cards, or complex payment flows. Two interviewees said close was fine: one had a well-established ERP and mainly struggled with receipts; another was small, knew every transaction, and had frozen budgets. A reconciliation product is therefore unlikely to be equally valuable to every mid-sized company.

Trust and implementation are central adoption barriers. One finance leader regretted a tool switch after a four-month migration, lost matching rules, and a return to spreadsheets. Another would not trust automation until it worked on messy real data. A product that matches well in a demo may still fail if it cannot preserve existing rules, handle exceptions, and prove accuracy on customers’ own data.

Willingness to pay is unproven. One controller said saving two days could justify the cost, but explicitly expressed scepticism based on past promises. Another prospect would not buy this year. These calls reveal value hypotheses, not validated demand or pricing.

Implications for the product team

Explore a narrow, workflow-led wedge rather than assuming a broad reconciliation platform is needed. Card-spend reconciliation may fit our existing product particularly well; processor payouts and intercompany are other distinct opportunities, but may require different data and capabilities. Test which segment has both acute pain and access to usable data. Prioritise messy-data performance, explainable matches and exceptions, and low-friction migration or coexistence with spreadsheets.

Confidence

• Moderate confidence that reconciliation is a significant pain for some complex, high-volume finance teams: several independent, specific examples support this.
• Low-to-moderate confidence on which workflow or customer segment is the best product wedge: each use case appears in few calls.
• Low confidence on market-wide prevalence, willingness to pay, achievable time savings, or product feasibility: eight qualitative calls cannot establish these, and no prototype or pricing was tested.

Treat this as a reason to run targeted workflow and data-validation research—not yet as evidence to commit to a broad build.