How a P and C insurer built one claims truth with commercial property insurance data analytics

The numbers a general insurer can’t agree on

A property-and-casualty insurer runs on a handful of numbers, and the awkward truth is that the same number rarely matches across the business. How many claims came in last quarter. What they cost. Whether reserves are holding against the property book. Whether one suburb or one class of commercial building is carrying too much exposure. The data to answer all of this exists. It just lives in places that do not talk to each other.

In most general insurers the claims system holds one version, the finance ledger holds another, and the reserving work happens in a spreadsheet that pulls from both and then drifts. A claim looks like one figure to the claims manager, a slightly different figure to finance once payments and recoveries are netted, and a third figure in the actuary’s reserving model. None of them is wrong exactly. They are measured at different cut-offs, with different rules, by different people. The result is a month-end meeting that spends its first half arguing about whose total is right before anyone discusses what the numbers mean.

The obligations do not wait for that argument to settle. APRA expects general insurers to manage operational risk and data soundly, with the prudential standard CPS 230 putting weight on the controls behind critical operations. The actuary signs off reserving estimates that depend on consistent claims development data. And claims and policy records carry personal information governed by the Privacy Act 1988. “The number depends on which spreadsheet you opened” is not a position any of those parties can stand behind.

Why Microsoft Fabric, and what sits beneath it

The goal is one governed source of claims truth that reserving, finance and claims all read from. We headline these builds on Microsoft Fabric because it brings the storage, modelling and reporting into one platform instead of a chain of exports. Claims, policy and reserving data land in OneLake, the single store underneath Fabric, so there is one copy of the data with one set of access rules rather than a copy per spreadsheet. A single semantic model defines claim cost, frequency and severity once. Power BI reads from that model, so every report agrees by design.

Fabric earns the headline because the alternative is the problem. Scattered extracts and competing spreadsheets are how insurers end up with three versions of one claim. Landing claims, policy and reserving data into one governed platform replaces that with a single lineage you can trace and audit. Policy data supplies the exposure denominator, so frequency is claims against the right count of risks. Reserving estimates sit alongside the claims actuals, so adequacy can be read in the same place as development. Commercial-property exposure can be sliced by location, occupancy and peril without rebuilding a workbook each time.

The supporting stack stays deliberately plain. Microsoft Azure provides the surrounding cloud services and keeps the data in an Australian region. Power BI is the reporting surface the actuarial, finance and claims teams actually open. We kept the modelled semantic layer independent of any single dashboard on purpose, so the same governed numbers can feed reserving analysis, regulatory reporting and later forecasting, not just one screen.

Building it, and where it got hard

The hard part was never the reporting. It was reconciliation, and one issue stood in for the whole problem. The same claim did not equal itself across three systems.

Early in the build, claims totals from the claims system did not match the finance ledger, and neither matched the reserving spreadsheet. Tracing it back, the causes were ordinary and stubborn. Payments and recoveries were netted differently. Reserve movements were timed to different cut-offs. A handful of claims had been adjusted in the ledger but not the claims system. Each gap was small. Together they meant no two totals ever tied out, which is exactly why every meeting started with an argument instead of a decision.

The fix was structural, not a cleverer report. We landed all three sources into the one Fabric platform and built a single semantic model that defined claim cost, frequency and severity once, with explicit rules for gross, net and recoveries. Then we reconciled the modelled claims totals back to the finance ledger and surfaced the difference as a tracked figure rather than a surprise. Where a residual gap remained, the platform showed it and its cause instead of hiding it inside an average. Once the numbers tied to the ledger within a tight tolerance, the competing extracts had nothing left to argue about, and the trusted set replaced them.

Two constraints shaped the rest. Access was set by role so the move to one platform did not widen who could see sensitive claimant detail, keeping the build aligned with the Privacy Act 1988 and the insurer’s governance expectations under CPS 230. And we held a firm line on scope. The platform reports what claims and reserving data say. It does not price risk or make underwriting decisions, which stay with the people accountable for them.

What changed

In a representative build, claims totals reconciled to the finance ledger within a tight tolerance, so reserving, finance and claims worked from one agreed set of figures instead of three. The month-end assembly that had taken several days of stitching spreadsheets together became a refreshed report read from one governed platform, which gave the actuarial and finance teams their time back for analysis rather than reconciliation. Commercial-property exposure could be read consistently by location, occupancy and peril, surfacing concentrations that the scattered workbooks had never shown clearly.

These figures are illustrative. They describe the pattern we see rather than a published result for a named insurer. The shift is the point. When claims, policy and reserving data sit in one governed place and reconcile to the ledger, the argument over whose number is right disappears, and the people who manage reserves, exposure and cost spend their time on the question that matters instead of on the spreadsheet.

Where this fits

A claims-analytics platform on Microsoft Fabric is one application of our Data Insights and Analysis service, built for the realities of an Australian general insurer. It is a contained, high-return starting point, because the data already exists and the value comes from governing it properly and reconciling it once. It is also distinct from claims intake and claims workflow work. This is about the reporting truth, not extracting documents or orchestrating the process. If your reserving, finance and claims numbers never quite tie out, the place to start is to map those three sources and decide the handful of views that would settle the argument for good.