Premium Collection: The Money You Billed and Never Actually Collected

An insurer writes the policy, bills the premium, and books the revenue. Somewhere between that and the bank account, a proportion quietly fails to arrive. A direct debit bounces, a card expires, an instalment is missed, a broker's account doesn't reconcile. Individually these are small operational events handled by a collections process. In aggregate they're a persistent leak, and at a lot of insurers nobody can say precisely how big it is — because the data needed to answer that question is spread across billing, banking, and policy administration and never gets joined.

Why collection failure hides

Billing systems know what was invoiced. Bank feeds know what was received. Policy systems know whether cover lapsed. The interesting question — which customers are failing to pay, why, and what happened to their policy as a result — sits across all three, and the join is often incomplete. So collection is managed as a queue of individual failures to chase rather than as a measurable business problem with patterns, causes, and a cost you could quantify and reduce.

Where it breaks down

  • Billed and received aren't reconciled at customer level. Totals may balance while individual failures go unexamined.
  • Failure reasons aren't captured as data. Expired card, insufficient funds, disputed amount — all get handled, none get analysed.
  • Lapse isn't connected to payment. A policy cancels for non-payment without the customer's payment history informing whether that was avoidable.
  • Broker accounts settle in bulk. Aggregated settlements make it hard to see which underlying policies were actually paid.

Why it's a data-foundation problem

Collections improves when you can see it, and seeing it means joining billing, banking and policy data at customer level with failure reasons captured as structured data. Do that and patterns emerge: which payment methods fail most, which segments recover after a retry, which lapses were a payment problem rather than a decision to leave. That turns chasing into targeting, and turns avoidable lapse into retained customers. It's the same join-and-measure foundation behind premium leakage and quote conversion, pointed at the cash you already earned.

What good looks like

  1. Billed, received and lapsed joined at customer and policy level, not just in totals.
  2. Structured failure reasons so collection problems can be analysed rather than only worked.
  3. Payment history informing retention so an avoidable lapse is recognised as avoidable.
  4. Broker settlements reconciled down to the policies they cover.

Premium you billed and didn't collect is the cheapest revenue in the business to recover, because you already won the customer and priced the risk. Building the data foundation that makes the leak visible is exactly the kind of work we do with insurers at IntelliBooks.

Written premium is a promise. Collected premium is the business. It's worth being able to measure the gap.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more

Insurance Knowledge Graphs: The Foundation AI Needs Before It Can Think

Every insurer wants enterprise AI. Few realise they're missing something much more fundamental. Knowledge. Not data. Knowledge. Insurance companies already possess enormous amounts of information. Policy systems contain customer records. Claims platforms hold loss histories. CRM systems track interactions. Document repositories store underwriting reports. Data warehouses consolidate analytics. Yet AI still struggles to answer surprisingly simple questions. Not because the information doesn't exist. Because the relationships between that information remain invisible. Data tells you what exists A customer database tells you who someone is. A policy database tells you what they bought. A claims system tells you what happened. An accounting platform tells you what was paid. Each system is internally consistent. Together they rarely behave like a connected enterprise. Humans mentally assemble those relationships every day. Computers usually canno...
Read more