Document processing
21 min read
—
A bordereau (plural: bordereaux, abbreviated BDX) is a periodic report submitted by a coverholder or managing general agent (MGA) to a carrier or reinsurer, listing the policies written or claims incurred during a reporting period. It is the primary data-sharing mechanism in delegated authority insurance arrangements. It gives the capacity provider transparent visibility into the business conducted in its name.
In the Lloyd's market, delegated authority accounts for approximately 40–45% of total premium volume. At that scale, bordereaux are not a back-office formality. They are the mechanism by which a syndicate knows what risks it has assumed, what claims it owes, and whether the programme is performing within the parameters set by the binding authority agreement. When bordereaux data is late, incomplete, or incorrectly formatted, the consequences ripple outward: reserve estimates go stale, regulatory submissions get delayed, and the managing agent loses the visibility it needs to manage exposure.
This guide is written for managing agents, reinsurance operations analysts, and MGA compliance officers who work with bordereaux directly. It covers the full operational picture: definition and etymology, the four principal types of bordereaux, the specific data fields required in premium and claims submissions, the Lloyd's Atlas submission standards, the structural reasons why manual processing fails at scale, and how AI in the insurance industry is changing the extraction and normalisation workflow for operations teams managing dozens of coverholder relationships.
In this article:
What a bordereau is, where the term comes from, and why the plural matters
The four types of bordereaux and what each one does operationally
Complete field inventories for premium and claims bordereaux
Why bordereau reporting breaks down at scale and what it costs
Lloyd's Atlas submission standards and the errors that trigger delegated authority reviews
How AI extraction works differently from template-based tools for bordereau data
Data extraction powered by AI
Automate data extraction
Get started today
What Is a Bordereau in Insurance?
The word comes from Old French. A bort was a border or margin; the notes written in the margins of a ledger were the bordereau. The term migrated into insurance practice as a shorthand for the supplementary schedules and statements that accompanied insurance transactions. In modern usage it refers specifically to the structured data reports exchanged between parties in delegated authority and reinsurance arrangements.
The BDX abbreviation is universal in the Lloyd's market. You will see it in submission portals, compliance correspondence, and binding authority terms. When a managing agent refers to the "BDX cycle", it means the recurring process of collecting, validating, and processing bordereaux from every coverholder on the book. When a coverholder is told its BDX is overdue, the submission deadline has passed.
The singular and plural distinction matters in practice. "A bordereau" is one specific document. "Bordereaux" is the class of documents. The plural follows French grammar, not English. Operations teams use the plural for the programme in general ("bordereaux processing", "bordereaux management") and the singular when referring to a specific submission ("the January premium bordereau"). Both forms are correct; what matters is using them consistently within the same communication.
Where Bordereau Reporting Is Used
Bordereau reporting appears in two principal contexts. In reinsurance, the ceding company submits bordereaux to the reinsurer to report the risks ceded and the claims developing under the treaty. In delegated authority insurance, the coverholder or MGA submits bordereaux to the managing agent or syndicate that provides the capacity under a binding authority agreement.
The delegated authority context is the more prevalent one today. In the Lloyd's market, delegated authority business accounts for approximately 40–45% of total premium income, with some estimates placing it higher. This share has grown steadily as MGAs have expanded their role: binding business, handling claims, and managing renewal cycles on behalf of syndicates that never see the underlying risks directly. The bordereau is what bridges that gap. The carrier bears the financial risk; the MGA makes the underwriting and claims decisions. Without bordereaux, the carrier is effectively blind to what is being written in its name.
The information asymmetry this creates is not incidental. It is structural to how delegated authority works. The bordereau is the instrument by which the syndicate exercises oversight without being present in every transaction. This is why late, incomplete, or incorrectly structured bordereaux are not merely an administrative inconvenience. They represent a failure of the governance mechanism that makes the delegated authority model viable.
An AI-driven underwriting workflow processes incoming documents through classification and extraction stages. The output is structured JSON data for risk analysis. The same pipeline applies to bordereau data, converting mixed-format submissions into consistent, usable records.
Types of Bordereaux
There are four principal types. Premium and claims bordereaux are universal to all delegated authority arrangements. The technical account bordereau and the risk bordereau appear in specific contexts. Each serves a distinct purpose, and a well-run programme requires all four to be consistent with one another.
Premium Bordereau
The premium bordereau documents every policy bound during the reporting period. Each row represents a single risk: the insured, the terms, the premium charged, and the net amount due to the syndicate after deduction of the coverholder's commission and any applicable brokerage. It is the primary mechanism by which the syndicate understands what risks it has assumed and verifies that premiums are being calculated correctly in accordance with the binding authority terms.
The distinction between a "written" bordereau and a "paid" bordereau matters here. A written bordereau records policies bound during the period, regardless of whether cash has changed hands. A paid bordereau records policies for which premium has actually been received by the coverholder. The two do not always align: binding and cash receipt can be separated by weeks or months, particularly in commercial lines. The binding authority agreement specifies which basis applies and the timing of remittance to the syndicate.
Claims Bordereau
The claims bordereau reports all claims activity during the period: new losses notified, movements in outstanding reserves, payments made, and claims closed. Each entry links to the corresponding policy in the premium bordereau via the Unique Market Reference (UMR) or the claim's own Unique Claims Reference (UCR). This linkage is operationally critical: the managing agent uses it to assess loss development against the expected claims experience for the book, and to identify policies where the incurred cost is approaching or exceeding the sum insured.
Claims bordereaux are operationally more demanding to produce than premium bordereaux. Premium data is relatively stable once a policy is bound. Claims data is in constant motion: reserves are revised as information develops, payments are made in tranches, and claims reopen after apparent settlement. The bordereau must capture the position as at the reporting date, with any movements since the previous submission clearly distinguished. A claims bordereau that lumps movements together without dating them is effectively unusable for reserve management.
For those evaluating automated insurance claims processing, the claims bordereau is often where automation delivers the most immediate value: it is the document type most prone to data quality failures, and the one where errors have the most direct financial consequences.
Technical Account Bordereau
The technical account bordereau, sometimes called the reinsurance technical account or RETACC, is the formal settlement document. It nets gross written premium against ceded losses, IBNR reserves, ceding commissions, brokerage, management expenses, and reinstatement premiums to arrive at the balance due between the cedant and the reinsurer for the period. In Lloyd's arrangements it is the document the syndicate's finance team scrutinises most closely: discrepancies between the technical account and the underlying premium and claims bordereaux are a common trigger for delegated authority reviews.
RETACC is also the bordereau type for which no genuine universal format standard has emerged. The UN/EDIFACT message type for reinsurance technical accounts never achieved broad adoption in the London market. Individual carriers and reinsurers impose their own templates, which means a coverholder managing relationships with multiple syndicates may be producing half a dozen different technical account formats for the same reporting period. This is not a problem technology has solved at the format level. It is a problem AI extraction solves at the data level.
Risk Bordereau
The risk bordereau describes the specific risks underwritten rather than the financial transactions. It is particularly common in property portfolios, where it allows the insurer to understand geographic exposure and verify that the MGA is not writing risks outside the agreed scope of the binding authority. A coverholder authorised to write residential property in England and Wales, for example, would submit a risk bordereau that lists individual properties by postcode, construction type, and sum insured. The managing agent uses this to aggregate exposure against its catastrophe model.
Risk bordereaux are not universal. Their inclusion in a programme is determined by the binding authority agreement and the class of business. They appear most frequently in property, engineering, and specialty programmes where geographic accumulation matters. In other classes, the information needed for exposure management is captured within the premium bordereau itself.
AI extraction pulls structured data from insurance documents, mapping fields like policy number, dates, and financial figures automatically. The same capability applied to bordereaux eliminates the manual rekeying that drives most data quality failures.
Key Data Fields: What Each Bordereau Contains
The specific fields required in a bordereau depend on the class of business, the carrier's requirements, and, for Lloyd's submissions, the Atlas data standards. The inventories below reflect the core fields common to most premium and claims bordereaux in the delegated authority market. Individual binding authority agreements will add to these depending on the programme's characteristics.
Premium Bordereau Fields
Unique Market Reference (UMR) or policy number: the primary key linking every row to the underlying risk. In Lloyd's submissions this is a standardised reference assigned at binding. Its consistency across premium bordereaux, claims bordereaux, and the technical account is what makes reconciliation possible.
Insured name and risk description: free-text fields that provide context for exposure analysis and audit trails. These are the fields most often truncated or reformatted by coverholders, which creates matching problems downstream.
Inception and expiry dates: drive earned premium calculations and determine treaty allocation for reinsurance. Date format inconsistency (DD/MM/YYYY versus MM/DD/YYYY) is one of the most persistent extraction failures in multi-MGA operations.
Gross written premium (GWP): the total premium charged to the insured, before any deductions. Always use the full form on first mention; GWP thereafter.
Commission rate and commission amount: the coverholder's compensation, expressed both as a percentage of GWP and as the resulting monetary amount. Both fields are required: the rate allows the managing agent to verify compliance with the binding authority; the amount feeds directly into reconciliation.
Brokerage: the broker's fee, separate from the coverholder's commission. Some bordereaux combine brokerage and commission into a single deduction; extraction logic must handle both patterns and flag which has been applied.
Tax amounts: vary by jurisdiction and must be extracted as discrete fields rather than aggregated into a single deduction line. Insurance Premium Tax in the UK, surplus lines tax in the US, and equivalent levies elsewhere all require separate treatment for regulatory reporting.
Net premium due: the settlement amount after deducting commission, brokerage, and tax from GWP. This is the figure that flows into the syndicate's accounts. It is also the figure most commonly affected by calculation errors in spreadsheet-based submissions.
Currency and exchange rate: critical for programmes written in multiple currencies. Some bordereaux embed the currency in the column header ("Premium (USD)"); others use a dedicated ISO code column; others carry currency information in footnotes. All three patterns must be handled correctly.
Risk location or territory codes: feed into exposure aggregation and catastrophe modelling. A misclassified territory code does not merely affect one row. It changes the nat-cat exposure picture for the entire portfolio that relies on that bordereau for its accumulation data.
Claims Bordereau Fields
Unique Claims Reference (UCR) or claim number: the primary identifier for the claim. Must be consistent across every submission in which the claim appears, from first notification through to closure.
Policy reference (UMR): connects the claim to the corresponding entry in the premium bordereau. This is the most common point of reconciliation failure when extraction quality is poor: a policy number that appears in one format in the premium bordereau and a slightly different format in the claims bordereau breaks the link entirely.
Date of loss: when the insured event occurred. This determines which treaty year the claim falls under for quota share and excess-of-loss programmes. An incorrect date of loss can misallocate a claim between treaty years, with direct financial consequences for both parties.
Date reported: when the claim was first notified to the coverholder or MGA. The gap between date of loss and date reported feeds IBNR (incurred but not reported) calculations; a compressed or missing date-reported field distorts the actuarial picture.
Paid amounts: split between indemnity payments and allocated loss adjustment expenses (ALAE). Combining these into a single figure prevents the managing agent from assessing whether claims handling costs are within expected parameters.
Outstanding reserves: the estimated future cost still expected on open claims. Reserve movements between reporting periods are tracked separately from cumulative reserves; a bordereau that reports only the cumulative position without disclosing movements is incomplete for reserve management purposes.
Incurred amount: the total claim exposure as at the reporting date, calculated as paid losses plus outstanding reserves. This is the figure the syndicate's actuary uses to assess loss development against expected.
Claim status: open, closed, or reopened. A closed claim must carry zero outstanding reserves. A reopened claim requires an explanation field in many binding authority arrangements. Status tracking failures are a recurring cause of reserve misstatement.
Claimant name and description of loss: narrative context for claims review, large-loss reporting, and audit documentation. These fields are often truncated in transmission from claims management systems, which creates problems when a claim requires manual review.
Why Bordereau Reporting Breaks Down at Scale
Format inconsistency in bordereaux is structural. It is not a problem any single MGA can solve, because the problem is not within any single MGA's control.
No universal bordereau format standard has been successfully adopted across the London market. The UN/EDIFACT message type for reinsurance technical accounts exists; it has existed for decades. It is used by almost nobody. Each carrier, each managing agent, each reinsurer imposes its own templates, field names, and column sequences. A coverholder managing 20 binding authority relationships may be producing 20 materially different bordereau layouts for the same reporting period, each one tailored to a different counterparty's requirements.
The documents themselves arrive in every format imaginable. PDFs, multi-tab Excel workbooks, flat CSVs, scanned reports from systems that do not produce electronic exports, and password-protected spreadsheets that require manual intervention before processing can begin. Formats change mid-programme without warning: a column renamed, a new sub-tab added for a specific class of business, a numeric premium field that starts carrying text qualifiers like "incl. IPT" mid-year. Each change breaks whatever mapping configuration the managing agent had previously built for that counterparty.
The cleansing burden falls on analysts. At 10 or 20 delegated authority relationships, this is manageable. At 50 or 100, analysts spend more time reformatting files than on the work those files are supposed to support: exposure analysis, premium adequacy review, loss trend monitoring. The reporting cycle becomes the overhead, not the analysis.
Delay compounds this. Manual processing introduces days or weeks of lag between when a coverholder binds a risk and when the carrier sees usable data in its systems. Pricing decisions, reserve estimates, and regulatory submissions all depend on exposure information that is already stale by the time it arrives. Deloitte's ceded reinsurance survey found that 71% of ceded reinsurance professionals cited late data as a driver of manual workarounds and downstream inaccuracies. This is not a technology problem disguised as a people problem. It is a structural feature of a process that was designed for a smaller, simpler market.
Then there are the errors. Manual rekeying between spreadsheets creates insertion points for mistakes that are difficult to detect without systematic validation. A class-of-business code transposed from one row to another. A reserve figure entered in the wrong currency. A net premium calculated against a commission rate that was updated in the binding authority but not in the extraction template. These errors often surface only during reconciliation or audit, by which point they have already contaminated downstream reports.
The V7 Go team sees this pattern consistently across the insurance operations teams that come to the platform: claims triage processes are blocked not by the complexity of the claims themselves, but by the time spent extracting usable data from inconsistently formatted source documents. Bordereaux are an acute version of the same problem.
V7 Go processing insurance operations documents, including submission intake and coverholder data. The same workflow that reduces submission processing from 30 minutes to 30 seconds applies directly to bordereau extraction across mixed-format coverholder submissions.
Lloyd's Reporting Standards and Regulatory Stakes
Lloyd's processes bordereaux through its Atlas platform, which consolidates the data standards previously managed under the DXC infrastructure. Atlas submissions must conform to Lloyd's prescribed data standards: required fields, acceptable formats, and validation rules for both premium and claims data. These standards are updated periodically; coverholders and managing agents must implement changes within defined transition windows.
The field counts involved are not trivial. Premium bordereaux for Lloyd's submissions typically require 40–60 or more fields depending on class of business. Claims bordereaux require 30–50 or more fields. Each field has a specified data type, an acceptable range of values, and a validation rule that the Atlas platform checks on receipt. A submission that fails validation is rejected; the coverholder must correct and resubmit within the reporting window.
Core required fields for a Lloyd's premium bordereau include: Unique Market Reference, original currency, premium in original currency, exchange rate, premium in GBP equivalent, coverholder commission rate, coverholder expenses, net premium due to syndicate, policy inception and expiry dates, insured name, risk postcode or territory, class of business code, and Lloyd's UMR where applicable. These are the minimum. Class-specific requirements add further fields: property programmes require construction type and risk location coordinates; liability programmes require jurisdiction and retroactive date; marine programmes require vessel type and voyage details.
Submission timing is fixed. Premium bordereaux are typically due 15–20 business days after the end of the reporting period. The clock starts when the period closes, not when the coverholder has finished compiling the data. A premium bordereau for January business may be due by 25 February regardless of how long the coverholder needs to prepare it. For quarterly reporters, this creates three periods of concentrated operational pressure per year. For monthly reporters, that pressure is continuous.
The move from quarterly to monthly reporting doubles the operational burden without a corresponding increase in team capacity. That is precisely why AI-assisted policy analysis and extraction automation have become operational necessities rather than optional upgrades for MGAs managing high-volume books.
Common Errors That Trigger Delegated Authority Reviews
A delegated authority review is not a routine check. It is initiated when the managing agent has reason to believe the coverholder is not meeting its obligations under the binding authority agreement. Bordereau quality failures are among the most common triggers.
Persistent late submission: the single most common trigger. A pattern of 3–10-day delays, even if each individual submission is eventually accepted, is treated as evidence of operational incapability. The binding authority agreement specifies submission deadlines; consistent non-compliance is a breach.
Inconsistent field mapping: class of business codes that change between submissions, currency fields that switch between ISO code and currency name mid-year, date formats that vary between DD/MM/YYYY and MM/DD/YYYY within the same file. Each inconsistency creates a reconciliation failure.
Missing or duplicate records: every policy bound and every active claim must appear in every submission. Missing records suggest incomplete extraction from source systems. Duplicate records suggest a merge failure between data sources. Both raise questions about data governance.
Premium-to-claims reconciliation failures: the technical account bordereau must reconcile arithmetically with both the premium and claims bordereaux. Timing differences introduced by manual processing are the typical cause: the premium bordereau is extracted on day one of the cycle, the claims bordereau on day three, and reserve movements in between are lost.
Calculation errors: commission applied to the wrong base, rounding differences on currency conversion, formula errors in spreadsheets that have been manually modified since the last reporting cycle. These errors propagate silently through subsequent submissions until a reconciliation check catches them.
AI extraction produces structured, validated data from insurance documents in any format. Applied to bordereaux, the same approach eliminates the manual mapping and rekeying that introduces errors between coverholder systems and managing agent platforms.
How AI Automates Bordereau Data Extraction
Template-based extraction tools have been the default approach for bordereau processing for years. The problem with templates is built into the assumption they rest on: that every document follows the same layout. Bordereaux do not.
When one MGA sends "Gross Written Premium" in column F of a 12-column spreadsheet and another sends "GWP" in column D of a 27-tab workbook, a template-based tool either fails or requires a dedicated configuration for each counterparty. At 20 counterparties, that means 20 configurations to build and maintain. At 100, it is operationally unsustainable. Each time a counterparty changes their format, the relevant template breaks and must be rebuilt before the next reporting cycle.
AI extraction works differently. It analyses document structure rather than memorising fixed column positions. The model reads headers, evaluates data types in adjacent cells, and identifies contextual relationships between fields. "Inception Date" next to a column of reference numbers is recognised as a date field regardless of its position in the spreadsheet, whether the document arrives as a PDF, an Excel export, or a scanned image processed through optical character recognition.
Header disambiguation is where this matters most in practice. "Premium", "GWP", "Gross Written Premium", and "Gross Premium Written" can all refer to the same field. "Sum Insured", "Total Insured Value", and "TSI" can describe the same exposure measure. "Commission", "Brokerage", and "Intermediary Fee" may or may not refer to the same deduction depending on the binding authority structure. AI extraction maps these to canonical field names using contextual reasoning guided by natural language extraction prompts. The prompts are defined once and reused across every reporting cycle. When a counterparty changes a column name, the prompt handles the variation without manual intervention.
Multi-currency normalisation is a specific version of the same problem. International reinsurance programmes generate bordereaux with currency information in different locations: dedicated ISO code columns ("Currency"), currency-specific amount columns ("Premium (USD)", "Premium (EUR)"), or footnotes that apply a rate across the entire document. AI extraction normalises these into a consistent output structure regardless of source format. Any row where currency information is ambiguous is flagged for review rather than silently assigned a default.
Batch processing extends this across an entire reporting cycle. A quarterly submission window means a stack of files from multiple counterparties arriving within days of each other: PDFs from one coverholder, multi-tab Excel workbooks from another, flat CSVs from a third, and occasionally a scanned print from a system that does not produce electronic exports. Batch AI extraction processes these in parallel and delivers unified structured output in Excel, CSV, or JSON format, with a source file reference on every row for audit traceability.
Post-extraction validation is where the extracted data becomes trustworthy rather than merely structured. Programmatic validation checks run on every row after extraction: net premium arithmetic (GWP minus commission minus brokerage minus tax equals net premium due, within acceptable rounding tolerance), claim-to-premium reference matching (every UCR links to a valid UMR in the premium bordereau), loss date range validation (date of loss falls within the policy period), duplicate detection, and currency code verification against a controlled ISO list. The review task shifts: instead of rebuilding data from scratch, analysts validate structured output against known rules. The analyst's attention goes to exceptions, not to data entry.
The integration payoff comes downstream. Validated, normalised bordereau data flows into reinsurance accounting platforms, actuarial reserving models, regulatory reporting tools, and the data warehouses that aggregate exposure across the whole delegated authority portfolio. With AI extraction, each additional MGA relationship requires updating the extraction prompts for that counterparty, not building another custom ETL pipeline. The marginal cost of adding a coverholder drops substantially. The managing agent's capacity to take on new delegated authority business is no longer constrained by the operational bandwidth of the data team.
For a practical look at how AI for insurance document processing compares across platforms and use cases, the linked guide covers the tooling landscape in detail. For the specific workflow of configuring extraction agents for insurance documents, the AI underwriting guide provides implementation context.
V7 Go's document extraction agents process insurance documents in any format using natural language prompts. There is no template to build and no pipeline to maintain when a counterparty changes their layout. The extraction configuration describes what to extract, not where to find it.
What Accurate Bordereau Data Actually Enables
The operational case for improving bordereau quality is straightforward: fewer reconciliation failures, fewer DA review triggers, fewer submission reruns. But the strategic case is larger than that.
Accurate, timely bordereau data is the foundation on which a managing agent manages its delegated authority portfolio intelligently. Premium adequacy review requires exposure data that is both complete and current. Reserve adequacy assessment requires claims data that reflects actual development, not a snapshot from three weeks ago that has been manually adjusted. Catastrophe exposure management requires accurate risk data that maps to real locations with real construction types. Regulatory capital calculations require premium and claims data that reconciles arithmetically across every submission in the programme.
None of this is achievable with a data process that runs on manual effort and spreadsheet-based extraction. The bottleneck is not analytical capability. It is the extraction and normalisation layer that sits between the raw bordereaux and the systems that use the data. Eliminate that bottleneck and the analytical work becomes the constraint, which is exactly where it should be.
Coverholders and MGAs that have moved to AI-assisted extraction report the same pattern: the first submission cycle after implementation produces more exceptions than the last manual cycle, because the validation layer catches errors that previously went undetected. After two or three cycles, the error rate drops substantially as extraction prompts are refined and counterparty-specific edge cases are handled. The operational overhead of the BDX cycle contracts. The analytical work expands to fill the recovered capacity.
For operations teams managing delegated authority at scale, that shift in where analytical capacity goes is the real return on automation investment. The bordereaux were always the data source for exposure management, loss trend monitoring, and pricing review. The question was always whether the team had enough time to use them properly, or whether the cycle consumed all available time just getting the data into a usable state.
To see how V7 Go handles insurance document extraction for delegated authority operations, including bordereaux in any format, visit the insurance document processing page.
What is a bordereau in insurance?
A bordereau is a structured data report submitted by a coverholder or managing general agent (MGA) to a carrier or reinsurer on a periodic basis, listing the policies written or claims incurred during a reporting period. It functions as the primary oversight mechanism in delegated authority insurance arrangements, where an MGA underwrites or handles claims on behalf of a carrier that is not directly involved in individual transactions. The carrier (whether a Lloyd's syndicate, a company market insurer, or a reinsurer) uses the bordereau to verify that business is being conducted in accordance with the binding authority agreement, to assess premium adequacy, to manage exposure, and to calculate settlement amounts. Without bordereaux, the capacity provider has no visibility into what has been written in its name. The bordereau makes the delegated authority model operationally viable by bridging the information gap between the party making underwriting decisions and the party bearing the financial risk.
+
What is the difference between bordereau and bordereaux?
Bordereau is the singular form; bordereaux is the plural. Both derive from Old French, where bort referred to a margin or border, and the notes written in the margins of ledgers were called the bordereau. The plural follows French grammar rather than standard English rules, which is why it does not take a simple -s suffix. In day-to-day usage, the plural is far more common: insurance professionals refer to 'bordereaux processing', 'bordereaux management', and 'the bordereaux cycle', treating the class of documents as a collective subject. The abbreviation BDX is used interchangeably with both forms, particularly in Lloyd's market communications, submission portals, and binding authority correspondence. It is also common to see 'bordereau' used as a modifier in compound nouns: 'bordereau reporting', 'bordereau data', and similar constructions where the word functions as an adjective describing the type of reporting or data involved. All of these usages are correct; the important thing is consistency within a document or communication.
+
What are the different types of bordereaux?
There are four main types. The premium bordereau documents all policies bound during the reporting period, listing insured details, coverage terms, gross written premium, commission, brokerage, and net premium due to the carrier. The claims bordereau reports all claims activity: new losses notified, reserve movements, payments made, and claims closed, with each entry linked to the corresponding policy via the Unique Market Reference. The technical account bordereau, also called the reinsurance technical account or RETACC, is the formal settlement document that nets premiums against losses, reserves, commissions, and expenses to arrive at the balance due between the parties. The risk bordereau describes the individual risks underwritten rather than the financial transactions, and is most common in property portfolios where the insurer needs to aggregate geographic exposure for catastrophe modelling. Premium and claims bordereaux are universal to all delegated authority arrangements; the technical account and risk bordereaux appear in specific programme structures as determined by the binding authority agreement.
+
What fields are required in a premium bordereau?
Core premium bordereau fields include the Unique Market Reference or policy number, insured name, risk description, inception and expiry dates, gross written premium (GWP), commission rate and commission amount, brokerage, tax amounts broken out by jurisdiction, net premium due, currency, exchange rate, and risk location or territory code. For Lloyd's submissions processed through Atlas, the required field count rises to 40–60 or more depending on class of business. Class-specific additions include construction type and location coordinates for property, jurisdiction and retroactive date for liability, and vessel type and voyage details for marine. The field names themselves vary by counterparty: 'Gross Written Premium', 'GWP', and 'Gross Premium Written' all refer to the same figure, which is one reason bordereau extraction at scale requires a system that can resolve header variations rather than assuming fixed column positions. Premium in original currency, exchange rate, and GBP equivalent must all be present separately for Lloyd's submissions.
+
What fields are required in a claims bordereau?
Yes, and the mechanism is meaningfully different from the template-based tools that have been the default approach. Template-based extraction memorises fixed column positions: when column F is labelled 'Gross Written Premium', it extracts from column F. When a counterparty renames or moves the column, the template breaks. AI extraction analyses document structure instead, reading headers, evaluating data types in adjacent cells, and identifying field relationships regardless of position. This means 'GWP', 'Gross Written Premium', and 'Gross Premium Written' are all correctly identified as the same field based on contextual signals rather than exact-match logic. Batch processing handles multiple counterparties in parallel across PDF, Excel, CSV, and scanned-image formats in a single extraction cycle. Post-extraction validation then runs programmatic checks on every row: net premium arithmetic, claim-to-policy reference matching, loss date range validation, duplicate detection. The review task shifts from rebuilding data to validating exceptions. The result is that the marginal cost of onboarding an additional coverholder drops substantially: the team updates extraction prompts rather than building a new template pipeline.
+
Can AI automate bordereau data extraction?
Go is more accurate and robust than calling a model provider directly. By breaking down complex tasks into reasoning steps with Index Knowledge, Go enables LLMs to query your data more accurately than an out of the box API call. Combining this with conditional logic, which can route high sensitivity data to a human review, Go builds robustness into your AI powered workflows.
+
Casimir is a seasoned tech journalist and content creator specializing in AI implementation and new technologies. His expertise lies in LLM orchestration, chatbots, generative AI applications, and computer vision.
