Reconciliation automation tools are software that loads two or more sets of transactions, matches them by rules such as amount, date and reference, flags what does not match and routes the exceptions to a person, usually alongside a workflow for preparing, reviewing and certifying each balance sheet reconciliation. They work well where both sides record the same event in the same way, as with a bank statement and a cash account. An insurer's subledgers are different: one written premium becomes twelve installments and a cash receipt, a quarter-end puts tens of thousands of reserve changes on the wrong side of a cut-off, and statutory rules decide what an unmatched receivable costs. A tool that cannot handle those cases leaves the insurance work in spreadsheets around it. Botminds' Premium & Claims Reconciliation was built for the insurance ties specifically: its agents match, cluster what does not match by cause, trace the journals and draft the entries for approval.
The examples come from a fictional sample insurer, Larkspur Mutual Insurance Group, at its third-quarter 2026 close in the solution, and from NAIC statutory accounting papers, linked where they appear. The five tests are ours; use them on any tool, including this one.
Five insurance tests: generic transaction matching against insurance-aware matching
Generic matching: Matches one-to-one on amount; a policy written once and billed in twelve installments looks like eleven exceptions.
Insurance-aware matching: Matches one-to-many and many-to-one by policy, so written, billed and collected premium reconcile as one policy.
Generic matching: Pairs equal amounts near the same date, sometimes on the wrong claim.
Insurance-aware matching: Pairs reserve changes across the cut-off claim by claim and nets the cluster, so an error cannot hide in the timing.
Generic matching: Ages exceptions from the date they appeared in the tool.
Insurance-aware matching: Ages receivables from the effective date the statutory rule prescribes, and separates agency-billed from direct-billed.
Generic matching: Treats money sent to a third-party administrator as a paid claim.
Insurance-aware matching: Keeps TPA funding, claims paid by the TPA and the insurer’s liability as three different balances.
Generic matching: Flags a journal as an unmatched item.
Insurance-aware matching: Reads the journal’s preparer, approver and support, and says whether it is a documented top-side, a duplicate or a misposting.
What are reconciliation automation tools?
Reconciliation automation tools fall into three groups that are often sold together: matching engines that pair transactions by rules, balance sheet reconciliation workflows that track who prepared, reviewed and certified each account, and close managers that schedule the tasks around them. Most were designed around cash: bank statements, card settlements, payables and receivables, intercompany balances. Their strength is volume and consistency on transactions that both sides describe in the same terms.
For an insurer they are useful for exactly that work. The difficulty begins where the two sides do not describe the same thing in the same way, which is most of the insurance subledgers. A policy administration system records a policy; billing records installments; the general ledger records a daily summary. A claims system records reserve changes claim by claim; the general ledger records the net movement per batch. Matching those is not a question of fuzzier rules but of knowing what each line represents.
Do generic reconciliation tools work for insurers?
Generic reconciliation tools work for an insurer's cash, payables and intercompany accounts, and they work for the insurance subledgers only as well as they have been taught the insurance rules. Most can be configured with custom match keys and scripts; the evaluation question is how much of that configuration you will own, and whether it explains a break or only finds it.
A practical sign is where the work goes after the tool runs. If the exceptions from a premium or reserve tie are exported to a spreadsheet so someone can work out which are timing, which are mapping and which are real, the tool has automated the easy half. At the sample insurer the matcher paired 98.6% of 2,941,207 lines by 06:41; the useful work was in the 40,624 that it did not, and in particular in three of them.
Test 1: can it match one premium to many installments?
An insurance-aware tool must match one written premium to many billing and cash lines, because statutory accounting records them at different times. Under the NAIC's premium standard, written premium for most policies is recorded on the effective date, while workers' compensation premium may be recorded "on an installment basis to match the billing to the policyholder" (NAIC Issue Paper No. 53). The same policy can therefore appear once in one system and many times in another.
The NAIC's own worked example shows what that looks like. In interpretation INT 99-27, a workers' compensation policy written on January 1 for $120,000 and billed monthly carries, by April 30, $80,000 of installments booked but deferred and not yet due, $40,000 of premiums in course of collection and $40,000 of earned premium. The interpretation then states the consequence of no cash arriving: "If no collections have been made as of 4/30/X1 then paragraph 9.a. would stipulate that the entire balance of $40,000 residing in the premiums in course of collection account would be nonadmitted" (NAIC INT 99-27).
A one-to-one matcher sees one written line and four billed lines and calls four of them exceptions. A tool that matches by policy sees one policy, four installments due, none collected, and a statutory consequence. The guide to written premium vs earned premium follows one policy through all three systems month by month.
Test 2: can it net a case-reserve cut-off claim by claim?
An insurance-aware tool must pair reserve changes across a cut-off claim by claim, not amount by amount, because a reserve account can have thousands of identical amounts on different claims. At the sample insurer, 38,977 case reserve changes were entered after the 18:00 claims batch on September 30, so they sat in the claims system on the 30th and in the general ledger on the October 1 batch. Paired claim by claim, they net to $0.00.
The pairing key is the point. A tool that matches equal amounts within a date window will pair most of them correctly and some of them wrongly, and a wrong pair can hide a real error. A tool that pairs by claim number, amount and effective date, within a window set in advance (two days either side of the effective date at the sample insurer), produces a timing cluster that can be trusted because every line in it has a partner on the same claim.
Timing, mapping and manual journal: three clusters, three nets
Test 3: does it know the 90-day clock?
An insurance-aware tool must age receivables the way statutory accounting does, from the policy or endorsement effective date and the contractual due date of each installment, because that is the clock that decides what is nonadmitted at quarter-end. A tool that ages an exception from the day it appeared in the tool will report a sixty-day item that is already over ninety days due.
It also has to know which balances are which. NAIC Issue Paper No. 6, from which the agents' balance rules in SSAP No. 6 were written, says that the uncollected agent's receivable over ninety days due is nonadmitted "regardless of any offsetting amount (e.g., unearned premium)," while direct-billed premium is offset by its related unearned premium (NAIC Issue Paper No. 6). A tool that cannot tell an agency-billed policy from a direct-billed one cannot tell what an unmatched receivable will cost. The arithmetic is in the guide to non-admitted premium receivables.
Test 4: can it tell a TPA's funding from a paid claim?
An insurance-aware tool must keep three things apart when a third-party administrator pays claims: the cash the insurer sends the TPA, the claims the TPA has actually paid from it, and the liability the insurer still carries. Money in a TPA's claims account is not a paid loss until the claimant receives it, and the insurer's liability for loss adjustment expense does not shrink because it has paid the TPA a fee.
A generic matcher that pairs the insurer's wire to the TPA with the paid-losses account will show a clean tie on a month when the TPA has not yet paid half the claims. The insurance-aware version ties the TPA's bordereau to its funding requests and to the general ledger, and leaves the unspent balance visible. The TPA reconciliation guide sets out the three-way tie and the NAIC rules behind it.
Test 5: can it explain a manual journal, not just flag it?
An insurance-aware tool must read a manual journal's support and say what the journal is, because manual journals carry most of the money in an insurance break. At the sample insurer the whole −$2,131,418.62 case reserve break sat in three journals: a $1,750,000.00 top-side strengthening backed by the reserve committee's minutes, a $412,000.00 reversal that duplicated one already posted on September 3, and a $30,581.38 subrogation recoverable posted to case reserves instead of the recoverable account.
Flagging those three as unmatched is what any tool does. Saying that the first should be kept as a documented reconciling item, the second reversed and the third reclassified, each with its document, is the work that used to take the claims accountant until day four or five. In the solution the journal tracer reads each journal's header, preparer, approver and support, and flags duplicates, wrong accounts, journals without support, and journals whose preparer and approver are the same person; the entry drafter then drafts the fix.
The fixes drafted, with support and the effect on every tie
How do you evaluate reconciliation software? Match rate is the wrong first number
Evaluate reconciliation software by how much of a break it explains, with evidence, on a quarter you have already closed, not by its match rate. Match rate measures how many lines paired; it says nothing about whether the lines that did not pair are understood. The sample close shows the gap in one account.
98.6% matched, and the money was in three lines
A match rate tells you how many lines found a partner. It does not tell you where the money went.
Better measures are the share of each break explained with a source document by a set hour on day one, the number of breaks a person had to investigate from scratch, and whether the tool found what your own team found when it closed that quarter. All three can be measured on a replay of a closed quarter before you buy anything.
Eight things to test on a closed quarter of your own
- Replay a quarter your team has already closed
Compare the tool’s explanations with your own reconciliation file, break by break.
- Measure explained, not matched
What share of each break has a cause and a document by the time your controller arrives?
- One premium, many lines
Load a monthly-billed workers’ compensation policy and see whether it reconciles as one policy.
- A month-end cut-off
Check that timing lines pair claim by claim and net to zero within your window.
- The 90-day clock
Ask for the aging of an agency-billed receivable from its effective date, with unapplied cash shown.
- A TPA month
Load one month of bordereau, funding and general ledger and see what stays unspent.
- Three manual journals
Give it a top-side, a duplicate and a misposting, and see whether it tells them apart.
- Approvals and the audit trail
Confirm the tool cannot post, that approvers and limits are enforced, and that every step is recorded.
Where insurance-aware matching fits, and where a generic tool is enough
Insurance-aware matching fits the subledger ties that carry insurance rules: written and unearned premium, premiums receivable, paid losses and LAE, case reserves, salvage and subrogation and ceded balances. A generic tool is enough for cash and bank accounts, payables and most intercompany balances, and many insurers will run both. Two neighbouring jobs have their own specialist treatment: statements between a cedant, a broker and a reinsurer, compared in automated reconciliation software vs agents on one reinsurance account, and premium reported by managing general agents on bordereaux, handled by Premium Bordereaux Reconciliation.
Which accounts need which kind of matching
| Account family | Generic matching | Insurance-aware matching |
|---|---|---|
| Bank and cash | A good fit | Not needed |
| Premium written, unearned and receivable | Partial: one-to-one on billed lines | Needed: policy-level, effective dates, 90-day clock |
| Paid losses and LAE | Partial: payment to payment | Needed where TPAs pay, and for cost-code mapping |
| Case reserves and recoveries | Weak: equal amounts across claims | Needed: claim-level cut-off pairing and journal reading |
| Ceded balances | Partial | Needed for currency and settlement timing |
To run the five tests on a sample of your own extracts, start from Premium & Claims Reconciliation.
Questions people ask
What is many-to-many matching?
Many-to-many matching pairs a group of lines on one side with a group on the other when no single line matches, for example several installments and two partial payments against one policy's billed premium. It needs a shared key, such as a policy or claim number, to stay reliable; without one it can pair lines that only add up by coincidence.
What match rate should reconciliation automation achieve?
There is no meaningful industry benchmark, and match rate is a weak target on its own. At the sample insurer 98.6% of lines matched while the whole case reserve break sat in three unmatched lines. A better target is the share of each break explained with evidence by a fixed time on day one of the close.
What is the difference between bank reconciliation and claims reconciliation?
A bank reconciliation pairs the same cash movements seen by the bank and the insurer, usually one to one. A claims reconciliation ties claims system detail (payments, reserves, recoveries) to general ledger balances built from summaries and journals, across cut-offs and mapping tables, and includes balances, such as case reserves, that never pass through a bank.
Can reconciliation tools handle case reserves?
Only if they match at claim level and can read the journals posted to the reserve account. Case reserves change constantly, the general ledger sees only net movements, and top-side adjustments never enter the claims system, so a tool that compares totals or equal amounts will either report thousands of false breaks or hide real ones.
How do reconciliation tools handle TPA data?
They should load the TPA's bordereau and funding requests as separate sources and tie both to the general ledger, keeping funded-but-unpaid cash visible. Treating money sent to the TPA as paid losses produces a tie that looks clean while the claims behind it are still open.