Why matching is hard
Nothing ever
matches exactly.
Brokers quote last year’s policy number. Pay short by six dollars. Send the wrong commission. Name the insured five different ways across five systems.
Seven real examples of what comes through our pipeline — and what we do with them.
First, it’s really hard to get the data out of remittances.
Every broker management system spits out a different shape of PDF. Six real samples — same week, six different formats:
Second, the data on the remittance rarely matches the data in your underwriting systems.
Only 1 in 7 receipts arrived clean. The other six needed the AI to bridge a gap somewhere — a stale policy number, a name variant, an off-by-a-few-dollars amount. Here is what those look like.
When everything lines up.
Every field agrees. About 1 in 7 incoming receipts looks like this — they resolve in milliseconds without ever touching a person. The rest are below.
No policy yet — just “TBA”.
The broker bound the policy yesterday and paid for it today — before they had a policy number to quote. We matched on the insured name and the exact amount. The policy number on file gets attached to the receipt automatically.
One payment, two policies.
The insured carries professional indemnity and cyber under two policy numbers, and the broker pays for both in one line — quoting only the PI policy. The two invoice amounts sum exactly to what has been paid, so the system splits the allocation across both.
Six dollars short on five thousand.
Six dollars and twenty-four cents short on a five-thousand-dollar receipt. Inside the ten-dollar write-off threshold, so the variance is written off and the receipt clears straight through. The threshold is set by you, not by us.
Three open invoices, one match.
One payment, three open invoices for the same insured. Without an effective date the matcher would have to guess between them. With one, the right invoice falls out — same date, same amount to the cent. Auto-matched.
The invoice doesn’t exist yet.
The payment arrived before the underwriter bound the policy. The system flags the underwriter to bind it — and the moment the invoice appears, the receipt auto-matches against it. Today it sits in the queue; in a day or two it resolves itself with no human keystroke. We call this an eventual match.
The 2.4 % — when a human looks at it
So what isn’t auto-matched?
Mostly over- and under-payments that fall outside the write-off threshold your finance team set. They hold for human review — and from the same screen the operator can query the broker or notify the underwriter in a single click.
The broker over-paid by twenty-two dollars.
The broker withheld less commission than expected, so they over-paid by twenty-two dollars. That is above the ten-dollar write-off threshold your finance team set, so the receipt holds for a human to decide rather than be over-allocated to the wrong policy.
This is what AI matching actually has to do.
Not pattern recognition. Judgement under ambiguity — knowing when to match, when to write off, and when to refuse to guess.
See how it works