A Send bordereaux validation is not delegated-authority proof

Begin with the agreement and delegated population

Send's official page describes binder management, bordereaux ingestion, contract-term validation, and delegated underwriting. It also states that Duck Creek acquired Send. Those are official provider claims and current ownership context, not evidence of a configured end-to-end Duck Creek integration or of any insurer's control effectiveness. The controlling object for delegated authority remains the executed agreement and its effective terms, not the software's validation label.

Create an authority record for the insurer, MGA or coverholder, legal entities, agreement and version, effective and expiry dates, territories, products and lines, permitted risks, limits, pricing or referral rules, endorsements, claims or servicing authority where relevant, premium and commission terms, sanctions and compliance responsibilities, reporting cadence, data specification, correction window, audit rights, suspensions, exceptions, and authorized signatories. Link each reported transaction to the applicable version.

Make bordereaux validation field and rule specific

A bordereau may report quotes, bound risks, premiums, endorsements, cancellations, renewals, claims, cash, or another agreed population. Validation should identify the file and checksum, reporting period, schema and version, source system, extracted fields, transformations, currency and exchange-rate basis, effective and transaction dates, policy and risk identifiers, required-field rules, authority-term mappings, duplicate logic, totals, rejected rows, warnings, overrides, and reviewer.

Passing syntax or contract-rule checks does not prove source completeness or business truth. A record can conform while omitting a bound policy, using the wrong agreement version, carrying stale reference data, duplicating an endorsement, misclassifying a territory, or misstating premium. Preserve the source file, normalized record, validation output, corrections, resubmissions, and acceptance. Do not overwrite an earlier bordereau after the insurer has relied on it.

Reconcile post-bind handoffs without collapsing ownership

Send says bound policies can move to downstream systems or be packaged as bordereaux. The underwriting platform, policy core, billing system, claims platform, general ledger, data warehouse, and delegated-authority repository may each own different records. A successful export is not a confirmed policy transaction, premium receipt, commission settlement, claim authority, or accounting close. Each receiving system should acknowledge the exact object and version.

Test a late endorsement, canceled risk, backdated correction, currency conversion, duplicate policy, referral outside authority, changed agreement, missing premium, failed import, and accepted row later disputed. The workflow should quarantine exceptions, retain the original report, show who may override which rule, and identify downstream records affected by correction. Metrics need line, population, reporting period, maturity, denominator, exclusions, and source before comparison.

Run one agreement-to-core reconstruction

Use a synthetic delegated program to trace the signed agreement, authority version, bound risk, bordereau creation, ingestion, validation, referral, acceptance, downstream policy transaction, premium and commission records, correction, and reporting close. Ask an insurer reviewer outside the original workflow to reconstruct why the risk was within or outside authority and which system now owns each state. Repeat after suspending or amending the delegation.

Claims Core Ledger reviewed the registered Send page on September 5, 2026. It supports the documented product roles and Duck Creek ownership statement, but it does not establish configured integration, agreement interpretation, source completeness, validation accuracy, delegated compliance, policy-core acceptance, premium or commission accuracy, claim handling, accounting, consumer outcome, or financial result. This is clean current-source analysis, not a verified post-cutoff integration event.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Claims Core Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.