Businesses that bill insurance companies sit in an unusual corner of accounts receivable. Every claim generates its own invoice, so the ledger fills up with large numbers of small invoices, and the insurer then settles on its own cycle, in bulk payments that cover weeks of work, with remittances organised around claim references rather than your invoice numbers. Insurers also part-pay invoices by design, send payments with no remittance at all, and pay the same invoice twice, which most other payers rarely do. This guide covers how to reconcile all of it in Xero.
It's written for the businesses on the receiving end of insurer payments, vehicle repairers and recovery operators, translation and interpreting agencies, healthcare and allied health providers, restoration contractors, and the bookkeepers who look after them. The examples describe UK practice, and the Xero mechanics are the same everywhere.
Why insurer payments look the way they do
An insurer's accounts payable process is built around claims rather than suppliers. Each invoice you send gets attached to a claim file, approved by whoever handles that claim, and released into a settlement run alongside hundreds of other approved payments. Two invoices you sent on the same day can be paid weeks apart because they sit in different claim files, and one bank credit can bundle invoices from dozens of unrelated claims.
That's why insurer reconciliation feels different from ordinary B2B debtors. The payer is reliable in aggregate and unpredictable per invoice, so there's no payment run to chase and no safe assumption that the oldest invoice gets paid first, which leaves the remittance as the only reliable record of what any given payment covers.
What arrives with an insurer payment
A typical insurer remittance lists one row per settled invoice, keyed by the insurer's own references first, claim number, policy number, sometimes the insured party's name, and then, if you're lucky, the invoice number you issued. Where your invoice number is missing, the claim reference is usually the value you quoted on the invoice, which is why the claim reference belongs in Xero at the point of invoicing rather than whenever someone gets round to it.
Format varies with size. The weekly or fortnightly settlement run tends to arrive as a PDF or spreadsheet running to many pages, and between runs, smaller payments often turn up with nothing more than a line or two in the body of an email and no attachment. Both count as remittances, and both need every line tied to an invoice before the bank credit is reconciled.
The three insurer behaviours that break reconciliation
Part-payments are routine, not errors
A short payment from an ordinary customer means something has gone wrong, but from an insurer it's usually the policy working as designed. There are two common reasons in UK practice. The policy excess gets deducted from the settlement because the policyholder owes it directly, and where the policyholder is VAT-registered and can recover VAT, the insurer commonly settles net of VAT and leaves the VAT element for the policyholder to pay. A repairer can therefore invoice £1,200 and correctly receive £700 from the insurer, with the balance owed by the customer.
In Xero, allocate the insurer's payment as a part-payment against the invoice and leave the remainder open, since it's still owed, just by someone else. Teams that credit the shortfall away lose track of the excess and VAT balances they should be collecting from policyholders.
The same invoice, paid twice
Duplicate payments are a recognised pattern with insurer payers. Two claims handlers approve the same invoice from different claim files, or a resubmitted invoice gets processed alongside the original, and the second payment lands weeks after the first. On a bulk remittance the duplicate is easy to miss, one line among two hundred, referencing an invoice that no longer appears in your open invoice list precisely because it's already been paid.
Forcing the allocation onto a different open invoice so the numbers balance corrupts the ledger twice over, because the forced invoice then shows paid when its own payment hasn't arrived, and the duplicate is invisible when the insurer later asks for the money back, which they do. Record it instead as an overpayment held on the insurer's account.
Payments with no remittance at all
Some insurer payments arrive as a bare bank credit with a reference like a fragment of a claim number, or nothing recognisable at all. What saves these is upstream work, quoting the claim reference on every invoice and recording it in the invoice reference field in Xero so it's searchable. A bank line that matches nothing then becomes a query to the insurer's payments team quoting the amount and date, rather than an afternoon of guesswork.
Recording a duplicate insurance payment in Xero
Xero handles this with an overpayment transaction, created during bank reconciliation:
- On the reconciliation screen, find the bank line containing the duplicate. If the payment bundles other invoices, use Find & Match to allocate the legitimate lines first.
- For the duplicated amount, create a Receive Money transaction, change the type from Direct Payment to Overpayment, and make sure the contact is the insurer.
- Put the original invoice number in the reference, for example duplicate payment of INV-2041, so that the insurer's statement of account explains the credit on its own without anyone reconstructing the history.
- The overpayment sits as credit on the insurer's account until you either allocate it against a future invoice or refund it when the insurer reclaims the money.
Whether you hold the credit or refund it without being asked is a business decision, and insurers reclaim duplicates on their own audit cycle, sometimes many months later, so the overpayment transaction keeps the money visible and explained for however long that takes.
Reconciling the bulk settlement run
The large weekly remittance is the same job as any one-payment-many-invoices reconciliation in Xero, scaled up and complicated by the behaviours above. A workable manual routine:
- Work from the remittance rather than the bank line, ticking each remittance line off against an open invoice, searching by invoice number first and claim reference second.
- Separate the exceptions as you go, the lines that part-pay an invoice, the lines referencing invoices that show as paid, and the lines you can't match at all.
- Resolve the exceptions before you touch the bank reconciliation screen, so Find & Match confirms what you've already worked out instead of being where you work it out.
- Only then reconcile the bank credit against the full allocation. If it doesn't balance to the penny, the gap is almost always in the exceptions rather than the clean matches.
The arithmetic discipline matters more here than with most payers, because a remittance that doesn't sum to the bank credit isn't automatically wrong when part-payments are legitimate, and a line that matches nothing open isn't automatically junk when duplicates exist. Every exception needs a decision, which is what makes the manual version of this work slow.
When the manual version stops scaling
The volume profile is what defeats people. A business billing insurers per claim can easily carry thousands of open invoices at modest values, receive several bulk settlements a week that each take the best part of an hour to work through, plus a daily trickle of small email-body payments. (Those figures are illustrative, but the shape is typical of the vertical.) At that point reconciliation is a part-time job in its own right, and the exceptions that need human judgement are buried in hundreds of lines that don't.
That split, a large majority of routine matches concealing a small number of real decisions, is the shape automation handles well, and the point of automating it is to put the lines that need a person in front of that person.
Where RemitClear fits
A settlement run from an insurer is a long list of claim references with your invoice numbers scattered through it, and that document is what RemitClear works from, as a PDF, a spreadsheet or the text of an email. Matching against the open invoices in your Xero organisation handles exact, partial and prefix-based invoice numbers, and where your invoice number isn't on the line it falls back to the other references the line carries. The three insurer behaviours above come back as flags on the review screen:
- Where a row points at an invoice Xero has already settled, it's marked Already Paid and kept out of the allocation, so a second payment for the same invoice can't be pushed onto whichever invoice happens to be open.
- A row that settles less than the invoice posts as a part-payment and the invoice stays open for the balance, with the line flagged so you see it.
- Where the allocated total and the remittance total disagree, the difference is shown and nothing posts until you've decided what it is, which is where a duplicate or an excess deduction shows up.
The overpayment itself is still yours to post, because deciding whether to sit on an insurer's money or send it back is a call for the business. RemitClear's part is the two hundred routine lines either side of it. The Xero remittance advice matching page covers the workflow end to end, and email remittance capture covers the forwarding inbox that picks up the daily email-body payments.
Summary
Insurer receivables reward a few specific habits, so quote the claim reference on every invoice and record it in Xero, treat part-payments as balances still to collect from the policyholder instead of shortfalls to write off, and record duplicates as referenced overpayments as soon as you find them. Work every bulk remittance from the document line by line rather than from the bank feed, because forcing allocations to make the numbers balance only moves the work to month-end. For the underlying mechanics, see the step-by-step guide to reconciling a remittance advice in Xero.
