Bordereaux software: test it on last quarter's files before you sign

Bordereaux software takes the bordereaux your MGAs and coverholders send, maps each delegate's layout to yours, checks every row against the binding authority and returns the rows that fail; the way to know whether a particular product does that well is to run it on files you have already closed. A replay of three past months, with your real binders and delegates, shows what the software finds, what it misses and what it flags wrongly, against a baseline you already know: what your own team found in those months. Botminds' Bordereaux Management is built to be tested that way, and the method below works for any system on a shortlist.

A demonstration on the vendor's sample data proves the screens work. It cannot show how the software behaves when one of your delegates renames a column, switches its date format or reports a risk from last year's binder. Your closed months contain all of those, and you already know the answers.

What does bordereaux software do on your own files?

On your own files, bordereaux software should do five things you can observe: read every delegate's file without a template built for it in advance, map its columns to your layout and say which ones it is unsure of, check every row against the binder in force on that row's inception date, explain every rejection with the clause behind it, and keep a record of every decision a person made. Each of the five can be measured in a replay.

The fifth is easy to forget and hard to fake. When the replay is over, you should be able to open any row from any of the three months and see what the software tested it against, what it concluded and who confirmed anything it could not settle. If that trail does not exist in the pilot, it will not exist when an auditor or an examiner asks for it.

Why a replay of closed months beats a demonstration

A replay is fair because the answers are known before the software runs. For each closed month you have the delegates' files as received, the rows your team rejected and why, the breaches referred and the corrections that came back. Run the same files through the software and the comparison is mechanical: what it found that you found, what it found that you missed, and what it rejected that was fine.

Three months is the useful minimum. One month shows the first mapping of each delegate, which is the slowest and least typical. The second shows whether the software remembered those decisions. The third usually contains a format change from at least one delegate, the event that separates a system that recognises columns from one that matches names. Pick the three most recent closed months so the binders are current and the people who did the work remember it.

A three-month bordereaux software pilot, week by week

The plan above fits in seven weeks if the carrier gathers the inputs before the clock starts. Week one is collection: binders, endorsements, field lists, the files and your team's exception lists. Week two is set-up: binders and the standard layout entered, thresholds agreed, and the first month's mappings made with a person, as they would be on a new delegate. Weeks three to five replay one month each, in order, so that each month benefits from the mapping decisions of the one before.

Week six plants errors in copies of real files, the subject of the next section, and re-runs them. Week seven scores everything against the sheet at the end of this guide. Running the timing log on the current live month in parallel gives the hours baseline: the replay tells you what the software catches, the log tells you what your process costs today.

What data do you need for a bordereaux pilot?

You need the documents the software checks against, the files it checks and the answers you already have. Without the third, a pilot can show only what the software found, not whether it found the right things.

Plant the errors the courts have already seen

Known exceptions test whether the software finds what you found; planted errors test whether it finds what you would have missed. Take copies of real files and change them in ways that match recorded failures. The most instructive is the pattern from Markel International v Surety Guarantee Consultants, where the court found that an underwriting agent had issued surety bonds above its binder's financial limits, shown them on the monthly bordereaux as exposures within the limits, and left some off altogether. Annex 1 to the judgment listed the 33 bonds focused on at trial, written above the financial limits between 11 February and 14 November 2005 ([2008] EWHC 1135 (Comm), paragraph 28).

Fourteen files chosen at random, a clean audit report, and every over-limit bond still on the books: that is the Markel audit, and the test a bordereaux pilot has to beat.

The court's account of that audit, with the auditor's own words, is quoted in audit sampling methods ([2008] EWHC 1135 (Comm), paragraph 56).

The judgment explains why: the original bonds had been replaced on the files with dummy bonds before the audit, and the employee directing the changes explained to a director that he was making the files agree with the bordereaux (paragraph 181; the exchange is quoted in continuous auditing tools). No bordereaux software would have caught that from the file. What a pilot can test is the part a file does show. Plant five kinds of error and count what comes back.

Add one more test that no file check should pass: under-declared premium. In XL Insurance Company SE v IPORS, the coverholder's own bordereaux understated the premium it had received, which only emerged from its bank statements ([2022] EWHC 2093 (Comm)). Ask the vendor what its software would have done. The honest answer is that a bordereau cannot show premium it leaves out, and that the declared figures have to be reconciled with cash elsewhere. A vendor who says otherwise has told you something useful about the vendor.

Sampling versus every row: the arithmetic of a missed breach

Sampling is a sound way to estimate an error rate and a poor way to find the rows that breach a binder. The audit standard used for financial statements states the reason precisely: a sample can lead the auditor to a different conclusion from the one testing every item would give, and the smaller the sample, the larger that risk (PCAOB AS 2315, Audit Sampling; its definitions are quoted in audit sampling methods). PCAOB writes for auditors of financial statements, not delegated authority teams, but the arithmetic is the same.

The chart's last bar carries a caveat the same standard makes: testing every transaction does not guarantee that a material misstatement is found, and its example fits bordereaux exactly: "confirming recorded receivables cannot be relied on to reveal unrecorded receivables". Checking every row of a bordereau removes sampling risk for the rows reported; it does nothing for the rows that were never reported. That is why the pilot scores the two separately.

How to score a bordereaux software pilot

Score the pilot on a few measures you can count, the same way for every product on the shortlist. The measures fall into three groups: what it found, what it got wrong, and what it cost in people's time.

Most pilots produce one uncomfortable number: new exceptions the team did not find at the time. Treat them as information, not embarrassment. A Florida location on a Gulf-states binder that was loaded in July is a breach that happened; finding it in a pilot is cheaper than finding it at the on-site review. Twelve questions before you buy turns the scores into a decision.

How long does a bordereaux software pilot take, and who must take part?

Seven weeks is realistic for three months of files from a handful of delegates, provided the inputs are gathered before it starts; more delegates mostly add set-up time in week two. The people matter more than the weeks. The bordereaux analyst who handled those months must take part, because only that person knows why each row was rejected. The head of delegated authority should decide the breach referrals the software raises, exactly as in live running. And the data and MI lead should own the standard layout, because a pilot that maps to the wrong target proves nothing.

Choose delegates for difficulty, not convenience. Include the one whose layout changes most, the one that is always late, and one with claims bordereaux if the software is meant to handle them. A pilot on the three cleanest delegates measures the vendor's demonstration again.

Running the replay with Bordereaux Management

In Bordereaux Management a replay starts the way a new delegate does: the closed month's files are loaded as they were received, and the first month's mapping of each delegate is made with the analyst; from then on each delegate's remembered mapping places its columns, and changes wait for a confirm. Every agent step and every human decision is recorded on the file's run with the time and the name.

Bordereaux Management's mapper: each file with its mapping, its checks and its run

One month across every delegate: what was checked, what changed and what is late

Botminds offers to run the solution on a month of your own delegates' files; ask for the quarter, and for the planted errors above. Start from Bordereaux Management.

Questions people ask

What is the best bordereaux software?

The one that scores best on your own closed months. Products differ most in how they handle changed layouts, whether they check every row against the right binder version, and how clearly they explain rejections, and a replay measures all three. Rankings that are not based on your delegates' files are rankings of demonstrations.

Is there free bordereaux software?

Spreadsheets and macros are free and are what many teams use for a few delegates. Their weakness is the renamed column: a macro that reads a column by name or position stops checking it without saying so. If you stay with spreadsheets, add a control that compares each month's headers and column profiles with last month's before any check runs.

How many delegates should a pilot include?

Enough to include your hardest cases: the delegate whose layout changes most, the one that is always late and one with claims bordereaux if they matter to you. Three to five delegates over three months is usually enough to see how the software handles change, and small enough to score by hand.

What if the software finds breaches our team missed?

Treat them as live findings. A risk bound outside a binder's territory or above its limit is a possible breach whether it was found in July or in a pilot in October, and it should go to the head of delegated authority for a decision. Record the finding in the pilot score as well.

What happens after a successful pilot?

The mappings and binder set-up from the pilot carry into live running, so the first live month starts with every pilot delegate already mapped. Add the remaining delegates in batches, each with its first file mapped with a person, and keep the timing log running to measure the change.