Businesses that bill insurance companies sit in an unusual corner of accounts receivable. Every claim generates its own invoice, so the ledger fills with large numbers of small invoices. The insurer then settles on its own cycle, in bulk payments that cover weeks of work, accompanied by remittances organised around claim references rather than your invoice numbers. And insurers do three things other payers rarely do: they part-pay invoices by design, they pay with no remittance at all, and they pay the same invoice twice. This guide covers how to reconcile all of it in Xero.
It is 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; 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, not suppliers. Each invoice you send is 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.
This is why insurer reconciliation feels different from ordinary B2B debtors. The payer is systematically reliable in aggregate and unpredictable per invoice. You cannot chase a payment run, and you cannot assume that the oldest invoice gets paid first. The only reliable record of what a payment covers is the remittance itself.
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 are 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 makes recording it in Xero at the point of invoicing essential rather than optional.
Format varies with size. The weekly or fortnightly settlement run tends to arrive as a PDF or spreadsheet running to many pages. Between runs, smaller payments often arrive with nothing more than a line or two in the body of an email, no attachment at all. Both are remittances, and both need the same treatment: 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
When another payer short-pays an invoice, something has gone wrong. When an insurer does it, it is usually the policy working as designed. There are two common reasons in UK practice. The policy excess is 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, leaving 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, because it is still genuinely 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 is 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 has already been paid.
The wrong response is to force the allocation onto a different open invoice so the numbers balance. That quietly corrupts the ledger twice over: the forced invoice shows paid when its real payment has not arrived, and the duplicate is invisible when the insurer later asks for it back, which they do. Record the duplicate as what it is, 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 claim number fragment or nothing recognisable. The discipline that saves these is upstream: quote the claim reference on every invoice, and record it in the invoice reference field in Xero so it is 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. This is the step that pays for itself later: the insurer's statement of account now explains the credit 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 to hold the credit or refund it proactively is a business decision, not a bookkeeping one. Insurers reclaim duplicates on their own audit cycle, sometimes many months later. 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, not the bank line. Tick each remittance line off against an open invoice, searching by invoice number first and claim reference second.
- Separate the exceptions as you go: lines that part-pay an invoice, lines referencing invoices that show as paid, and lines you cannot match at all.
- Resolve the exceptions before touching the bank reconciliation screen, so Find & Match is a confirmation exercise rather than an investigation.
- Only then reconcile the bank credit against the full allocation. If it does not balance to the penny, the gap is almost always in the exceptions, not the clean matches.
The arithmetic discipline matters more here than with most payers. Because part-payments are legitimate, a remittance that does not sum to the bank credit is not automatically wrong, and because duplicates exist, a line that matches nothing open is not automatically junk. 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, each taking 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 do not.
That split, a large majority of routine matches concealing a small minority of genuine decisions, is exactly the shape automation handles well. The goal is not removing the person; it is making sure the person only sees the lines that need them.
Where RemitClear fits
RemitClear reads insurer remittances, PDF, spreadsheet or email body, and matches every line against your open invoices in Xero. Matching handles exact, partial and prefix-based invoice numbers, and falls back to other references on the line when the invoice number is missing. The insurer behaviours above surface as flags rather than silent failures:
- A line referencing an invoice that is already paid in Xero is flagged Already Paid, with a link to the existing payment, and is excluded from the allocation, so a duplicate cannot be forced onto the wrong invoice.
- Part-payments are allocated as part-payments, with the invoice left open for the balance, and flagged for review.
- If the allocation total does not equal the remittance total, the difference is shown and posting waits for a person to decide, which is precisely where a duplicate or an excess deduction gets caught.
Posting the overpayment itself stays with you, because holding or refunding an insurer's money is a decision that belongs to the business. What RemitClear removes is the two hundred routine lines around it. The Xero remittance 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 specific set of habits. Quote the claim reference on every invoice and record it in Xero. Treat part-payments as balances to collect from policyholders rather than shortfalls to write off. Record duplicates as referenced overpayments the moment they are found, and work every bulk remittance line by line from the document rather than the bank feed. Teams that hold that discipline stay reconciled; the ones that force allocations to make the numbers balance spend month-end untangling them. For the underlying mechanics, see the step-by-step guide to reconciling a remittance advice in Xero.