The reinsurer’s statement comes in as a PDF or a spreadsheet: their references, their amounts, their total. Ours comes out of the ledger. The two totals differ by a figure that means nothing on its own — it is the sum of three or four unrelated things netted together. Someone puts both lists side by side in a workbook, ticks off the lines that agree, and is left with a handful that do not. Then the real work starts: is that a payment they made that we have not booked, a claim they reserved that we have not paid, a typo in a claim number, or a share applied wrongly?
The ticking is mechanical and the last step is not. InsightCede gives the ticking to an agent and keeps the last step for the analyst.
What the agent compares
The reconciliation agent is the one agent in the settlement step that does not run on a schedule, because it needs an input the ledger does not hold: the counterparty’s statement. It is run for one reinsurer with that statement supplied as a list of lines, each a reference and an amount. On our side it takes every recoverable for that reinsurer that has been billed or still has something outstanding, at its outstanding amount, with the claim number as its reference.
It then walks their statement line by line:
flowchart TD
A["Each line of theirs"] --> B{"Same reference,
within tolerance?"}
B -- yes --> M["Matched
proposed offset"]
B -- no --> C{"Any of ours within
tolerance on amount?"}
C -- yes --> M
C -- no --> T["Theirs only
proposed query"]
M --> E["After their last line:
ours left over, proposed chase"]
T --> E
E --> D["Net difference
theirs unmatched less ours"]
What comes out is a decision record with three groups of evidence — Matched, On their statement only and On ours only — and a proposal: an offset for each matched pair; for each line only they show, a query (“not on our ledger”); for each line only we show, a chase (“missing from their statement”); and the net difference, their unmatched total less ours. The money at stake on the decision is the size of that difference, so it sorts into the queue alongside everything else by what it is worth.
If a model is reachable it writes the title and the explanation from those groups, and may word the proposal; its catalogue entry says it may never invent a match below the tolerance, and the matching itself is done before it is asked anything. If the model is not reachable the record says how many lines matched within the tolerance and what the net difference is, and nothing more.
Dry first, then live
Because the run is by hand, it has two modes. A dry run is open to anyone signed in: the whole graph runs — gather, match, the model’s words, the proposal — and the result comes back, but nothing persists except the run record, so no decision lands in anyone’s queue. It is the way to check that a statement has been keyed in the shape the agent expects, or to see how a half-finished reconciliation looks before the reinsurer’s last remittance arrives. A live run needs a manager, and it writes the decision record that the analyst then answers. Both are recorded with the identity they ran as, the prompt version they read and what the model call cost, so a reconciliation that someone ran twice with different statements is visible as exactly that.
Use case details
| Reconciliation | |
|---|---|
| Trigger | Manual: run for one reinsurer with its statement lines supplied. A live run by hand needs a manager; a dry run is open to anyone signed in |
| Actor(s) | Ceded analyst; the reinsurer’s technical accounts team on the other side of each query |
| Agent | reconciliation_agent, action propose_offsets |
| Grounded in | cede_recoverable for the reinsurer, and the counterparty statement supplied with the run |
| Prepares | Matched pairs, lines on their statement only, lines on ours only, proposed offsets and take-ups, the net difference |
| Checkpoint & default level | reconciliation_review at L1 Draft |
| What a person decides | Which differences are timing, which are a booking we owe, which go back to the reinsurer, and whether any amount-only match is the right pair |
| What is recorded | The run with its identity, prompt version and cost; the decision with every line as evidence; the answer as feedback. Any collection is recorded separately, by a person |
Why the net difference is the least useful number
Every statement reconciliation ends in one figure, and it is the figure least worth acting on. A $56,250 difference can be a $70,000 payment we have not booked, a $212,500 reserve they are carrying that we have not paid, and an $86,250 bill they have not received yet, all at once. The agent reports the net because people ask for it; the decision puts the lines first because they are what you act on. The worked example below is exactly that case.
Notice that the net difference went up after the one real correction. A process that chases the net to zero would have been working against Sara here. A process that chases each line to an explanation gets her to the end of the statement in one sitting.
What accepting does, and does not do
The record is at L1, which means it is a draft for a person to work from. Accepting records that you agree with how the lines were paired and what was proposed; that answer is feedback, like every other. It does not book anything. There is no offset entry in the ledger to book: what moves a balance is a collection recorded on Recoverables, a payment or recovery event from the claims system, or a new bill. Changing the proposal — for example, saying that an amount-only match is the wrong pair — is the answer that teaches the agreement rate the most.
The reinsurer’s own view of the relationship is on the Reinsurers page: what it owes, what it has paid to date, how many items are overdue or disputed, the treaties it sits on and the notes thread. That is where the outcome of each query belongs once the reinsurer answers it.
What it does not do
- There is no screen to load their statement. The statement is supplied with the run, as lines of reference and amount, through the agents API. Reading it out of a PDF or a spreadsheet is not part of this agent today.
- It reconciles the recoverables side only. Our lines are recoverables. Premium, ceding commission and reinstatement premium on their technical account are not matched; a statement that nets premium against claims has to be split before it is supplied.
- An amount-only match can be the wrong pair. When a reference does not match, the first remaining line of ours within the tolerance is taken. Two claims ceding the same round figure — common on a layer, where a full limit is the same for every loss that exhausts it — can be paired the wrong way round. The evidence shows which pairs matched on amount alone; read those.
- The tolerance is absolute. $1.00 per line by default, whatever the size of the line. It absorbs rounding, not a currency conversion or a share applied to a different base.
- Its words are blunt. Every unmatched line of theirs is proposed as “not on our ledger”, including one whose claim we hold at a different amount. The evidence groups say which is which; the wording does not.
- The offsets are words, not entries. On screen the decision draws the evidence groups and the explanation; the full offset and take-up list is in the decision record the API returns.
Why a person keeps the last step
Every unmatched line has at least three possible causes — timing, a booking one side has not made, or a genuine disagreement about the contract — and the ledger cannot tell them apart. Only the third is a dispute, and calling something a dispute changes how the relationship is managed for months. That is not a sentence an agent should be able to write on its own.
If your statement reconciliations still end with a net difference carried forward to next quarter, send us one quarter’s statements and we will run them against a demo ledger built from your recoverables.