Ask the reinsurance manager at a small commercial-lines carrier how treaty cession works in their shop, and the answer almost always involves a spreadsheet. Specifically, it involves a quarterly exercise where someone extracts policy data from the policy-admin system, maps each in-force policy to its applicable treaty, calculates ceded premium for the period, and assembles that data into a bordereau that goes to the reinsurer or the reinsurance intermediary. The process takes three to five days per quarter, requires manual reconciliation when policy endorsements have changed mid-period, and produces a bordereau that the reinsurer will sometimes dispute on specific line items.
This is not a failure of the people doing the work. It is a structural failure of how the policy-admin system and the reinsurance function are separated in most small-carrier IT environments. Policy data lives in one system (or spreadsheet). Treaty terms live in a document in someone's shared drive. The cession calculation lives in neither place — it is created fresh each quarter by someone who knows how to do it. When that person leaves, the institutional knowledge leaves with them.
What Treaty Reinsurance Actually Requires of a Policy System
A treaty reinsurance program — whether quota share, excess of loss (XOL), or a combination — has a defined scope. That scope is typically expressed in terms of the lines of business covered by the treaty, the geographic territory, the policy inception date range that falls within the treaty period, and any exclusions (certain SIC codes, certain coverage types, attachment points for XOL layers). Every policy the carrier writes needs to be evaluated against those treaty parameters at the time of binding, not at the end of the quarter.
This evaluation at binding is where most small-carrier systems fail. The policy-admin system captures the coverage and premium but has no awareness of treaty parameters. The underwriter binds the policy, and the policy is in force. Whether it falls inside the quota share treaty, the XOL Layer 1 treaty, or is excluded from cession because the GL class code is on the treaty exclusion list — none of that is determined until the quarterly bordereau exercise, when it is too late to correct a misclassification without issuing an endorsement or filing a treaty submission exception with the reinsurer.
A policy-admin system that integrates treaty management evaluates cession eligibility at binding. The system holds the treaty terms as structured data: the LOB scope (mapped to ISO LOB codes), the effective date range, the attachment point and limit layer for XOL treaties, the cession percentage for quota share. When a policy is bound, the system checks it against the applicable treaties, determines the ceded portion, and writes the cession record to the policy ledger at inception — not three months later.
Quota Share vs. XOL: Different Cession Logic
The two most common commercial-lines treaty structures for smaller carriers require different cession logic, and a policy-admin system needs to handle both.
Under a quota share treaty, the carrier cedes a fixed percentage of every eligible policy's premium and losses. If the quota share cedes 40% of gross premium written on all commercial GL policies with inception dates in the treaty period, the cession calculation for any given policy is: Ceded Premium = Gross Premium × 40%, with a matching cession of expected losses at the same percentage. The bordereau simply reports all in-force policies in the treaty scope with their gross premium and the calculated ceded amount. The reinsurer receives ceded premium net of a ceding commission — typically expressed as a percentage of ceded premium — which flows back to the carrier.
XOL treaties are structurally different. The carrier retains all losses up to the attachment point (the retention) and cedes losses in excess of the attachment up to the treaty limit. A carrier with a $500,000 per-occurrence retention and an XOL Layer 1 that covers $500,000 in excess of $500,000 (written as $500K xs $500K) pays any single loss fully until it exceeds $500K; losses between $500K and $1M are split between carrier and reinsurer per the treaty. The reinsurer charges a rate-on-line (ROL) premium for the XOL cover, which is typically calculated as a percentage of the subject premium — the gross premium for all policies in the XOL treaty scope.
Most small carriers operate with both structures simultaneously: a quota share on a portion of the book that cedes premium and loss, and an XOL layer (or multiple layers) that protects against severity. The bordereau for a quota share treaty and the premium reporting for an XOL treaty are different documents with different data requirements. Assembling them from the same policy data source quarterly, by hand, is where reconciliation errors accumulate.
The Bordereau Data Model Problem
A bordereau — the periodic report of ceded business sent to the reinsurer — has a specific data structure that the reinsurer's treaty administration team uses to book the assumed business. The required fields typically include: policy number, insured name, inception date, expiration date, gross premium, ceded premium, effective cession date, LOB code, and state of domicile. For Lloyd's syndicates and London market reinsurers, the bordereau format often follows the London Market Principles (LMP) data standards. For US treaty reinsurers, the format is typically specified in the treaty agreement itself.
The challenge for a carrier producing a bordereau from a spreadsheet is field-level accuracy. Policy inception dates, mid-term endorsement premium changes, and cancellation pro-rations all affect the ceded premium for a given quarter. A policy that was endorsed in month two of the quarter — adding a location, which increased the gross premium — needs the cession record updated to reflect the endorsement premium. If the policy system and the cession spreadsheet are separate, that endorsement update requires a manual reconciliation step.
Consider a specialty surplus-lines MGA in the process of becoming an admitted carrier, writing commercial habitational GL in three Gulf Coast states. Their quarterly bordereau exercise takes four days. Two days are spent extracting policy data from their policy system and matching it to the treaty scope. One day is spent reconciling endorsement changes made during the quarter — added locations, increased limits, reduced limits on cancellations. One day is spent formatting the bordereau for the reinsurer's required template. The four-day exercise happens once every 90 days but occupies the reinsurance manager fully for those four days, and errors discovered by the reinsurer in subsequent quarter statements require retroactive adjustments.
When treaty management is integrated into the policy-admin system, that four-day exercise becomes a report generation step. The cession records are written as policies are bound and updated as endorsements are processed. The bordereau is generated from structured policy data at the end of the quarter, not assembled manually from extracted reports.
Treaty Limit Monitoring and the Aggregation Problem
XOL treaties have aggregate annual limits — a cap on the total amount the reinsurer will pay across all occurrences in a treaty year. When a carrier has multiple XOL layers (Layer 1, Layer 2, aggregate protection), monitoring the aggregate utilization of each layer requires tracking cumulative losses against the layer's annual limit across all paid and reserved claims in the treaty period.
In a spreadsheet environment, this monitoring is typically done manually and infrequently. The carrier may review aggregate XOL utilization once a quarter or when a large loss triggers a manual check. By the time the check is done, the carrier may be approaching the aggregate annual limit on a layer without realizing it — which means the next large loss above the retention will be unprotected if the aggregate is exhausted.
We are not claiming that this happens frequently — most small carriers do not exhaust XOL aggregate limits in normal loss years. The issue is that the carrier has no early-warning mechanism when adverse loss development is accumulating. A policy-admin system that integrates both treaty management and FNOL claims can surface that warning in real time: as paid losses and incurred reserves accumulate against policies in the XOL treaty scope, the system can display aggregate layer utilization as a dashboard metric rather than a quarterly calculation.
Facultative Submissions and Their Own Workflow
Treaty reinsurance covers the bulk of a carrier's book, but individual large or unusual risks often require facultative reinsurance — a separate negotiated cession for a specific policy, placed with one or more reinsurers outside the treaty. Facultative submissions are common for commercial property risks above the treaty's maximum cession per risk, for unusual GL classes excluded from the treaty, and for umbrella or excess policies where the carrier's retained exposure warrants outside support.
Facultative reinsurance has its own workflow: submission preparation, negotiation with reinsurers, conditional binding subject to reinsurance placement, and ongoing premium and loss reporting on the facultative certificate. Managing facultative cessions in a spreadsheet separate from the policy system means that the facultative certificate — the reinsurer's acceptance of the cession — is not connected to the policy record. If the policy is endorsed, the facultative reinsurer's exposure changes, and the carrier needs to notify the reinsurer. In a disconnected system, that notification depends on the underwriter remembering to do it.
Integrating facultative cession tracking into the policy-admin workflow means the facultative certificate is attached to the policy record, and any endorsement that changes the gross premium or the covered exposure automatically flags the need for a facultative endorsement notification. That flag is not a guarantee that the notification happens — the underwriter still has to act on it — but it is far more reliable than expecting the underwriter to track it independently.
The Practical Migration Path
For carriers currently managing treaty cession in a spreadsheet, the migration path to integrated treaty management does not require replacing the entire policy system on day one. The most tractable starting point is building the treaty data model — encoding the treaty terms as structured parameters — and running the cession calculation in parallel with the existing bordereau exercise for one or two quarters. The parallel run will identify any differences between the system-calculated cession and the manual calculation; those differences are almost always attributable to endorsement processing gaps in the policy record that the manual process was papering over.
After the parallel run confirms alignment, the bordereau generation moves fully into the system. The quarterly exercise shrinks from days to hours. And the treaty limit monitoring and aggregate tracking move from a reactive check to a live view.
Irys builds treaty management into the same workflow as policy binding, endorsement, and FNOL. The treaty terms are configured as structured parameters — LOB scope by ISO code, effective date range, quota share percentage or XOL attachment and limit — and the cession record is written at policy inception. Bordereau generation is a report, not an exercise. If you are approaching a renewal cycle on your reinsurance treaty and the quarterly bordereau is still a manual process, this is the moment to change that.