Pre-discovery briefing
Presenting the build-versus-buy fork before anyone fell in love with building
A multi-entity holding wanted document AI across its finance operations. I designed the pipeline and then showed them the packaged alternative honestly, including where it would beat us.
- Capture, extract, validate, match and post, learn
- 5 stagesCapture, extract, validate, match and post, learn
- For invoices with no purchase order — the case that breaks automation
- 6 fallbacksFor invoices with no purchase order — the case that breaks automation
- Presented as a fork, with the packaged option argued fairly
- Build vs buyPresented as a fork, with the packaged option argued fairly
The client
A family-owned European investment holding with several operating entities across real estate, asset management and private equity — different enterprise systems, different purchase-order discipline, and a finance function absorbing the difference by hand.
The engagement
A pre-discovery briefing pack after a scoping call, sized as a six-to-eight-week discovery roadmap.
The problem
Multi-entity finance automation looks simple in a demo and fails in the exceptions: mixed purchase-order discipline across entities, several enterprise systems, and invoices that match nothing. Vendors in this space quote a cost per invoice that assumes the clean case. And a consultant who only knows how to build will always recommend building.
What I did
I designed the pipeline around the exception rather than the happy path — a six-level fallback chain for invoices with no purchase order, because that is where per-invoice economics are actually decided. Then I put the packaged-vendor route on the table as a genuine fork, with the conditions under which buying beats building stated plainly, because a recommendation that never says 'do not hire us' is not a recommendation. Published best-in-class benchmarks for cost per invoice, cycle time and first-year return were included as a yardstick the client could hold against any proposal, ours included. Visibility rules by entity and supplier were designed in from the start, since in a holding structure the wrong person seeing the wrong invoice is a governance incident rather than a bug.
What was built
A five-stage document pipeline — capture, extract with optical recognition plus a language model, validate, match and post, learn — with a six-level fallback chain for invoices arriving without a purchase order, which is the case that actually breaks automation, plus entity-level and supplier-level visibility rules so each entity sees only its own documents.
On the table at the end
- Pipeline design with the no-purchase-order fallback chain
- Build-versus-buy comparison against packaged vendors
- Benchmark set for cost per invoice and cycle time
- Second-track briefing on climate risk assessment
- Talk track and follow-up deck
What it changed
Gave a finance leadership team a decision they could actually make: a designed pipeline, an honest packaged-vendor comparison, and per-invoice benchmarks to test any vendor's claim against — including ours.
How it ran
- 01
Scope the mess, not the demo
Multiple entities, multiple enterprise systems, mixed purchase-order discipline — stated as the starting condition rather than as a risk footnote.
- 02
Design for the exception
A six-level fallback chain for invoices that match nothing, because that is where automation rates and per-invoice cost are really decided.
- 03
Put the fork on the table
Hyperscaler build versus packaged vendor, with the conditions under which buying wins argued honestly.
- 04
Give them a yardstick
Benchmarks for cost per invoice, cycle time and first-year return, usable against any vendor including us.
- 05
Design the visibility rules early
Entity and supplier level access designed in, because in a holding structure invoice visibility is a governance question.
Other work
All case studies →- Manufacturing
Three AI pilots aimed at one line of the balance sheet
A building-products manufacturer had capital trapped in inventory and a digital team already delivering wins. I proposed three pilots tied to working capital rather than to a technology roadmap.
- Financial services
A proposal the client could click
Predictive models were running and nobody could see them. I shipped the assessment as a working prototype on synthetic data rather than a document, then survived the meeting that changed the cloud, the tool and the pilot customer.
- Insurance
Sequencing the data foundation before anyone bought an AI agent
A financial group wanted AI scoring across five affiliates. I proposed one affiliate, eighteen weeks, and a data readiness report before a single model — because the alternative is an agent trained on data nobody has reconciled.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.