Build vs Buy Insurance Statutory Reporting Software: Buy the Last Mile, Build the First

The half of this you should never build

Wolters Kluwer and Sovos Booke maintain the annual statement templates, absorb the instruction changes each year, run the cross check validations and carry the electronic filing path. That work reappears every single year, it is not differentiating, and no carrier has ever gained an advantage from owning it. Buy it, keep it current, and leave it alone.

A small carrier should stop there entirely. One legal entity, licensed in a handful of states, one or two lines of business, and a controller who assembles the annual statement in a week without drama: you do not have a problem worth six figures. Document the workbooks better, name a second person who understands the mappings, and spend the money on something that grows premium.

The same logic applies to your core systems. Policy administration and claims platforms are transaction systems, and replacing one because statutory reporting is painful is treating a headache with surgery. If February is difficult because the forms are difficult, you have a vendor problem rather than a build problem, and changing statement vendors is the cheaper answer.

Buying stays right for as long as the numbers going into the statement can be explained on demand. The moment nobody can say where a figure came from without convening a meeting, the tool has stopped being the issue and the pipeline behind it has become one.

Where the vendors stop and your February begins

Statutory accounting is a different basis, not a different format. Non admitted assets are written off rather than carried. Acquisition costs are expensed as incurred. Reinsurance credit depends on counterparty status and collateral, which is why the reinsurance schedule carries a penalty mechanism your GAAP ledger has never encountered. Each of those is an accounting judgement somebody made, and in most carriers that judgement sits in a mapping tab with no owner and no history.

Then it multiplies. Several legal entities. An intercompany pooling agreement where the lead cedes and members assume by fixed percentages, so entity statements must sum and eliminations must be right in every schedule. Licensure across many states, each reading its own state page. Risk based capital drawing on the same data with different groupings. And every schedule carrying prior year columns that must agree with what you actually filed, not with what today's pipeline would compute for last year.

Build when lineage has become the constraint. The loss development triangle assembled from a summarised claims extract will not reconcile cleanly to the ledger and cannot be re cut when the actuary asks for a different segmentation. The reinsurance recoverable ageing reconciled by hand cannot be defended line by line. When an examiner asks why net incurred loss for a line and accident year moved between filings, the honest current answer at most carriers is a two day investigation involving three people, and that is the cost the build removes.

Build also when the whole close depends on one person's workbook and only that person understands the mapping. That is the risk that ends careers rather than budgets, and it does not appear on any risk register.

What each side costs

Statement software licensing generally scales with entities and filing years, so a group adding a subsidiary adds a line rather than absorbing it. That is reasonable pricing for what it does, and it is also why entity count quietly drives your annual software spend more than premium volume does. The larger cost on the buy side is unmeasured: the controller, the reinsurance accountant, the business analyst and the actuarial contact each losing weeks to assembling and defending numbers, every quarter, forever.

A build prices predictably in this category. In Digital Heroes delivery experience, a first release covering a statutory data mart with transaction level lineage, versioned mapping rules, frozen filed snapshots and schedule ready output for a single entity runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full close platform adding multi entity and pooling logic, state premium allocation, risk based capital inputs, close task workflow with evidence attachment and variance reporting runs $180,000 to $400,000 across 6 to 12 months. Ongoing costs sit near 15 to 20 percent of build a year.

What moves the number: entity count and whether they pool, since eliminations are genuine work. The number of source systems, because most carriers run separate policy platforms by line and at least one legacy claims system. Life and property casualty in one group, which means two statement families. Whether investment detail arrives from the custodian in usable form. And how much history you load, because triangles built on ten years of claim transactions take longer than anyone expects and are what makes the output credible.

The costs that surprise the finance team

Freezing filed periods is not a cost so much as a decision that becomes catastrophically expensive if missed. Teams build a clean pipeline, improve a mapping rule in year two, and the pipeline recomputes history so prior year columns shift and the statement no longer agrees with itself across periods. Snapshot every schedule value at filing with the rule versions that produced it, read prior year columns from that snapshot always, and make restatements explicit dated events. This costs almost nothing at the start and is close to impossible to retrofit.

Historical claim transaction loading is the second. Sourcing triangles properly means accident date, transaction date, line, reinsurance treatment and expense type on every transaction, over many years, from systems that may have changed twice. Data quality problems surface as reconciliation differences against filings you have already made, and resolving them takes accounting judgement rather than engineering time.

Investment data is the third. Custodian files often arrive without the attributes statutory valuation requires, so enrichment against security reference data becomes a standing process with its own exceptions. Carriers scope it as a feed and find a workflow.

Fourth, the judgement backlog. Turning undocumented mapping tabs into versioned rules with named owners exposes decisions nobody has revisited in years. That is the point of the exercise, and it consumes your controller's attention rather than the developer's, so it belongs in the plan as a real commitment during a period that is already busy.

Two questions that decide it before March

First, pick a schedule line from last year's filing and trace it to the underlying transactions. Not a summary that happens to tie, an actual drill path to the claim transactions, premium transactions and journal entries behind it, with the mapping judgement and who made it. If you can do that inside an hour, your workbooks are better documented than most and you should invest in succession rather than software. If it takes days and three people, you already pay for this system in overtime and examination risk.

Second, compare a prior year column in this year's statement against the same figure as filed last year. If they differ and nobody can explain why, your pipeline is rewriting history quietly, and the next time it happens it will be an examiner who notices rather than you.

A third check takes an afternoon. Count the workbooks that feed the statement and name the owner of each. Then ask what happens to the close if any one of those people is unavailable in February. Carriers consistently discover that the answer is a single name appearing three or four times, and that concentration is a stronger argument for the build than any efficiency calculation.

How to sequence it and who to trust with it

Start with one entity and the schedules carrying the most defence risk, usually loss development and the reinsurance schedules, plus the state page allocation. Get lineage, versioned rules and frozen snapshots working there before extending to pooling and risk based capital. Run the new outputs in parallel with the existing workbooks for one full cycle, and treat the differences as findings rather than defects, because most of them will be undocumented judgements finally becoming visible.

When interviewing developers, ask them to draw it: source transaction, sub ledger, mapping rule with effective quarter and owner, schedule line, filed snapshot, validation result, variance. If they do not immediately ask how a filed period gets locked, they will build a pipeline that rewrites history. Ask whether they understand accident year, report year and calendar year as three distinct things. That takes five seconds and separates people who have worked in insurance finance from people who have not.

Ask what they intend to do about the statement vendor. The right answer is to feed it clean data. Anyone proposing to rebuild the annual statement forms is either inexperienced or selling hours.

Digital Heroes builds this category PRD first, with the mapping rules and freeze behaviour agreed in writing before code. Contracting runs through an India LLP, a US LLC or a UK LTD, whichever matches the domicile of the entity commissioning the work. Fifty plus people, 2,000 plus delivered projects, and a build process explained openly to 2.5 million subscribers on YouTube. Settle repository and cloud ownership before kickoff, because these mapping rules are your accounting judgement written down.

If you would rather scope this before committing budget, Digital Heroes starts every engagement with a signed specification covering the data model, permissions and acceptance criteria, which is what keeps a fixed price fixed. You keep the specification either way.