What the customer said on the call. Checked against what was submitted.
A customer discloses something on the call — a change of job, a habit they mention in passing — and by the time the application reaches the insurer, the form says something else, or nothing at all. Reconciliation compares the two automatically, once the insurer's application PDF reaches the sale, and flags what doesn't line up for your team to check. Pro plan
See what's included on the Pro plan, or ask us about upgrading.
The call and the form are supposed to agree. Reconciliation flags where they don't.
A fact find gets tidied on the way onto the application. A box gets ticked from memory rather than the recording. Whatever the reason, the insurer only ever sees the form — and if it doesn't match what the customer actually said, that gap surfaces at a claim, not before.
A file review, after the sale
The suitability letter gets checked against the form, not the call. It relies on the adviser's own summary of what was said, and a mismatch is only caught if someone happens to read both closely — days or weeks after the customer has committed.
Reconciliation, from the call itself
The call transcript is checked against each submitted answer, once the application PDF reaches the sale in your CRM. A mismatch is flagged for your team to raise with the insurer, with a passage of the call where the question was found, where there is one. An application format we don't recognise is parked for a person, not guessed at.
Read against the call. Rules find and compare; a model reads each answer.
Once Reconciliation is switched on for your firm and the insurer's application PDF is attached to the sale in your CRM, each submitted answer is checked against what the customer said across the calls in that sale. A flag against an adviser is, in effect, an allegation that they mis-recorded a customer's disclosure, so finding each question and comparing the answers are fixed rules. Rules find whether each question was put to the customer at all, and a question is only reported as never asked when its words are absent from a call where they could have been found. A model then reads the customer's answer from the passage around each question, because "about seventeen and a half stone" needs reading, not matching. It sees those passages, not the whole call. Rules compare that answer with the application, and a model is asked only where they genuinely can't tell, with its answer kept as reasoning for a person to weigh, not treated as the final word.
Health details a customer names, such as a condition, test or treatment, are redacted from transcripts by default, so an answer that depends on them usually cannot be read and is marked "Could not verify", not a match. Plain yes or no answers are still compared. Keeping health details readable is something we set up with a firm, with a DPIA.
A mismatch is flagged for your team to raise with the insurer, and later amendments are classified so a routine correction made during the call isn't treated the same as a disclosure quietly taken back. Where an application declares more than the customer said on a question where more means more risk, that's recorded separately too — over-declaring is not a non-disclosure.
Built to flag, not to decide on its own.
Reconciliation is deliberately cautious about what it will assert. Where it can't check something, it says so rather than guessing.
An application format we haven't read before
The sale is parked rather than guessed at. It's queued for a person on our side to read the document and either match it to a format already in use or teach the system a new one — which a person then reviews before it's used to check any sale.
Insurer applications, not lender applications
Reconciliation reads the application an insurer returns for a fully underwritten protection product, question by question. It doesn't read a mortgage lender's application.
A flag, not a verdict
A mismatch is something for your team to raise with the insurer, not an automatic fail. A passage of the call where the question was found sits alongside it, where there is one, so a reviewer checks it against the recording rather than taking it on trust.
No accuracy figure, yet
We don't publish one. An earlier set of figures has gone stale, and a fresh measurement against production data is owed before we publish again.
Questions about Reconciliation, answered.
Which plan is Reconciliation on?
Reconciliation is part of the Pro plan. See what else Pro includes, and what's on Starter and Growth, on the plans page.
What happens with an insurer's application format CallGuard hasn't seen before?
The sale is parked rather than guessed at. It's queued for a person on our side to read the document, either matching it to a format we already know or teaching the system a new one, which a person then reviews before it's used to check any sale. Reconciliation picks that sale back up, and every later one from that insurer, once that's done.
Can I see an accuracy figure for how well it catches mismatches?
Not one we can stand behind yet. Figures we published before this review turned out to be stale, and we owe a fresh measurement against production data before we publish one again. Each finding shows a passage of the call where the question was found, where there is one, so your team checks it against the recording rather than taking a score on trust. A finding is something for your team to raise with the insurer, not an automatic verdict.
Does Reconciliation cover mortgage lender applications too?
Not currently. It reads the application format an insurer returns for a fully underwritten protection product, question by question. Where a mortgage case also includes a protection sale, the insurer side of that sale can be checked the same way; the mortgage lender's own paperwork is not.
Further reading: why non-disclosure starts on the call, and the protection consent-gate checklist for the disclosures a call needs on record.