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.

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.

Month-end close discovery: findings summary

Bottom line

Reconciliation is a real, recurring pain for mid-sized finance teams, but these eight calls don't yet show which product to build or whether anyone will pay for it. I'd treat this as grounds for a further, more targeted round of research, not a build decision.

What we learned

1. Five of eight leads have a real reconciliation problem (calls 1, 3, 5, 7, 8). Two said close is fine (calls 2 and 6), and one has a tool and regrets it (call 4).

2. They describe different problems, not one. - Bank feeds dropping transactions, matched by hand in Excel (call 1) - Card statements arriving as PDFs and re-keyed, with £14k of duplicates in a quarter (call 3) - Intercompany balances that never agree, costing about 1.5 days (call 5) - Payment processor payouts that net off fees and refunds, and are always the last thing holding up close (call 7) - Sheer matching volume, about 40% of one controller's close (call 8)

No problem appears in more than one call, so we can't yet say which is most common or most valuable.

3. The time cost is meaningful but self-reported. Estimates ranged from 1.5 days to 3 of 8 days. These are recollections, not measurements.

4. Those who are fine tend to be smaller or better equipped. The two "close is fine" leads are the smallest companies in the sample (70 and 95 staff), and one already has a modern ERP. This is suggestive at best with eight calls. The pain sits mostly in the 180–400 staff range.

5. Adoption barriers are as prominent as the pain. - Call 4's failed migration (four months, lost matching rules, team back on spreadsheets) is a warning about switching costs. He would only switch again if someone else did the migration. - Call 8 won't believe automation works until he sees it handle messy data: "Every demo uses clean data." - Call 1 is sceptical: "I've heard that before."

6. Willingness to pay is essentially untested. Only call 1 gave a conditional answer ("if it gave me two days back, it pays for itself"), and she hedged it. Call 6 has a budget freeze. No one expressed urgency or asked about pricing.

7. An adjacent finding: call 2's only complaint was chasing receipts, which sits closer to our existing spend-management product than reconciliation does.

How confident can we be?

Other limitations: - Eight calls is a small sample, and we don't know how participants were recruited, so existing customers or those already interested may be overrepresented. - The excerpts are edited and one interviewer ran all the calls. - Hypothetical questions ("would you pay?") overstate real intent.

Suggested next steps

1. Pick a wedge. Card reconciliation (call 3) is closest to our current product. Follow up with calls 3, 5 and 7 to size how often each problem occurs and what it costs.
2. Test with real data. Ask call 8 and similar leads for anonymised, messy samples to see whether matching is feasible.
3. Design for migration. Call 4 suggests onboarding and preserving matching rules may decide adoption. Treat this as a product requirement, not an afterthought.
4. Test price and urgency. Use concrete pricing or a paid pilot, not hypotheticals.
5. Widen the sample. Include firms of 150–500 staff and a mix of ERP and non-ERP setups, and record how each participant was recruited.