What fifty demos have in common

Every demo works. Here is what the demo never shows you and how to script one on your own data.

Vendors Marc McCarthy, November 2026

Between us we have sat through well over fifty reconciliation vendor demonstrations, from the enterprise suites to the point solutions and the tools a bank built for itself and decided to sell. They are all different. They all have one thing in common. The demo works.

Of course it does. The data was loaded last week. The matching rules were tuned by the person presenting. The break that appears on screen is the one the tool resolves best, and it resolves it in four seconds to a round of nods. Nothing in that hour is dishonest. It is simply not your reconciliation.

What the demo never shows you

It never shows you the break that sits on the rec for eleven weeks because nobody owns it. It never shows you what happens when a feed arrives late, in a different format, with a column missing. It never shows you how a tolerance rule behaves on a many-to-many match across three currencies at month end. It never shows you the audit trail an external auditor can pull without asking your team to build a report first. And it never shows you the configuration screen where your team will spend the next three years.

Those are the things that decide whether a reconciliation platform earns its keep. None of them fit in a demo built on the vendor's data.

Script the demo yourself

The fix is not to stop watching demos. It is to write them. Before you invite a vendor in, build a script and send it to every shortlisted vendor a fortnight ahead. The script has five parts.

  1. Your data. Two days of real files from both sides of two of your reconciliations, anonymised if they must be, with the ugly bits left in: the duplicates, the late items, the reference that is formatted three ways. The vendor loads these, not their own.
  2. Your breaks. Ten real exceptions from the last quarter, including the two that took longest to close. Ask the vendor to show how each would be identified, routed, aged and resolved, and who would see it at each step.
  3. Your rules. Three matching rules your team actually uses, including the tolerance logic. Watch the vendor build them live rather than load them from a template. The time this takes tells you more about the implementation than any proposal.
  4. Your auditor. Ask for the evidence pack an auditor would receive for one closed break: who did what, when, and with what approval. If it takes a developer to produce it, you have learned something.
  5. Your Friday. Describe a bad day: a feed fails, a resend arrives with duplicates, and the control deadline is 4pm. Ask the vendor to walk through it on your data.

Score every vendor against the same script with the same people in the room. Keep the slides for the end, if there is time.

What this does

A scripted demo on your own data removes the polish and leaves the product. Vendors who are confident in their platform welcome it, because it shortens the sales cycle. Vendors who are not will ask for more time, and that is an answer too. Either way you finish the process with a decision you can explain to your board and your regulator, which is the whole point.

If building the script feels like a job in itself, it is the second half of what we produce in a Data Diagnostic. The first half is understanding your reconciliations well enough to write it.

Back to the Knowledge Centre

Start with one day. Finish with a decision.

Book a call