P&C insurance billing software is the system that turns a policy's premium into bills and collects them: payment plans and installments, invoices and statements, payment posting, delinquency notices, and the handoff of a cancellation for nonpayment to the policy system. It works well on the payments it was designed for, the ones that arrive with a policy number attached, such as a scanned coupon, an insurer-initiated ACH debit or a portal payment. It leaves behind the payments and notices that do not fit: a check with no coupon, a debit that comes back from the customer's bank, a premium finance company's request for cancellation, a refund that needs a payee and an approver. Those exceptions are where customers who paid get cancelled and where examiners find late refunds, so a buyer comparing billing software for insurance companies should decide early who will work them. Botminds' Insurance Billing Exception Management does not replace the billing system; it works those four exceptions beside it, with six agents proposing and named people deciding.
The examples come from the solution's sample data: a fictional direct-bill carrier, Kestrel Point Mutual, with fictional customers. The ACH rules are Nacha's, the non-profit association that writes the operating rules for the ACH Network, and are linked where used.
What a billing system does with each exception, and what an exception layer adds
P&C billing system: Posts what it can match by reference; parks the rest in unapplied cash for a person to search.
Exception layer: Insurance Billing Exception Management: Reads the check image, scores every candidate policy on memo, payer, address and amount, and shows the amount-only result beside it.
P&C billing system: Reverses the payment, marks the installment unpaid, may start delinquency.
Exception layer: Insurance Billing Exception Management: Sets the action the return code allows, schedules only permitted retries, and tracks the insurer's return rates against Nacha's thresholds.
P&C billing system: Often arrives outside the system, by email or mail, and is keyed by hand.
Exception layer: Insurance Billing Exception Management: Reads the notice, matches the agreement to the policy, counts the days since the notice of intent, holds a request that came too early.
P&C billing system: Computes the return premium; approval often happens in email.
Exception layer: Insurance Billing Exception Management: Prepares the worksheet, checks the payee and the state's deadline, routes it by authority; a person releases it.
P&C billing system: Not visible: each payment and each notice is processed on its own.
Exception layer: Insurance Billing Exception Management: Lines up every pending nonpayment cancellation against money received, retries and cures each morning.
What does P&C insurance billing software do?
P&C insurance billing software manages the money side of a policy from bind to cancellation: it sets up the payment plan, issues bills and installment notices, receives and posts payments, runs the delinquency cycle when a payment is missed, and passes nonpayment cancellations and reinstatements to the policy administration system. Direct-bill carriers depend on it for every customer; agency-billed business uses a lighter version that bills agents rather than insureds.
The examination standard it serves is short. Among the NAIC's policyholder service standards, the first asks whether "Premium notices and billing notices are sent out with an adequate amount of advance notice" (NAIC Market Regulation Handbook Examination Standards Summary, 2024). A good billing system meets that standard on its own. What it cannot meet on its own is the standard's sequel: that the money the customer sends in answer to the notice is recognised in time.
The four exceptions billing software leaves behind
On the sample carrier's Monday, 2,422 payments arrived worth $2,609,396.13, and the billing system applied 2,414 of them. The rest of the morning's work came from four places that every direct-bill carrier has.
- Unapplied cash. Nine items, $15,491.88, including a lockbox check with the policy number handwritten in its memo line and a mortgage servicer's escrow check. The billing system had the money and could not tell whose it was.
- Returned payments. Seven ACH debits and checks back from customers' banks, $5,393.80, each with a reason code that decides what may happen next.
- Premium finance notices. Six notices from three finance companies, including one request that arrived too early and one withdrawal of a request whose cancellation was on file for the next morning.
- Refunds awaiting approval. Five refunds, $8,284.75, two of them above the specialists' authority.
None of the four is a billing system failure. Each needs evidence the billing system does not hold, such as a check image, a return code's rules or a finance company's letter, or a decision it should not make. The question for a buyer is whether the billing software being evaluated works them, hands them to people with the evidence attached, or simply parks them. Billing exception management software, task by task sets out which of the dozen tasks inside them software should take.
One board for the four lanes, ranked by the cancellation each item could cause
Returned premium payments: what each ACH return code allows an insurer
A returned ACH payment is a debit the customer's bank sent back, with a return reason code that says why. For an insurer that collects premium by ACH debit, the code decides three things: whether the debit may be tried again, whether the authorization still stands, and which of Nacha's return rates the return counts against. A billing system that treats every return as "unpaid" and retries on a schedule will, sooner or later, retry one the rules forbid.
ACH debit return codes an insurer sees most, and what the Nacha Rules allow next
| Code | What it means | Counts toward | What may happen next |
|---|---|---|---|
| R01 | Insufficient funds: the available balance does not cover the debit | Overall rate | Retried in the sample settings; Nacha limits any reinitiation to two times, with "RETRY PYMT" and the same amount |
| R09 | Uncollected funds: a ledger balance exists but the available balance is too low | Overall rate | As R01 |
| R02 | Account closed by the customer or the bank | Administrative and overall | Not retried in the sample settings; ask the customer for a new way to pay |
| R03 | No account, or unable to locate the account | Administrative and overall | As R02; often a mistyped account number |
| R04 | Invalid account number structure | Administrative and overall | As R02 |
| R07 | Authorization revoked by the customer | Unauthorized and overall | Not reinitiated; a debit is not a reinitiation only if a new authorization is obtained after the return |
| R10 | Customer says the originator is not known or not authorized to debit the account | Unauthorized and overall | As R07: "an unauthorized debit cannot be remedied" |
| R11 | Customer says the entry was not in accordance with the terms of the authorization | Unauthorized and overall | The originator may correct the error and send a new entry within 60 days, without a new authorization |
| R29 | A business customer says the entry was not authorized | Unauthorized and overall | As R07 |
Three rules in the table trip up premium collection most often. Nacha's 2019 rules change "clarifies the existing intent that reinitiation is limited to 2 times" (Nacha), so a premium debit returned for insufficient funds may be presented at most three times in all, and each retry must carry "RETRY PYMT" in the company entry description and the same company name, company ID and amount as the original. "Reinitiating any entry in an amount greater or less than the original entry would be considered an improper reinitiation practice" (Nacha), which rules out adding a late fee to the retry. And a debit returned as unauthorized cannot be tried again on the old authorization at all.
R11 is the exception, and one many billing setups treat too harshly. Since 2020 it covers a debit the customer authorised but that was wrong, such as the wrong date or amount, and Nacha's rule lets the originator fix the error, where it can, and send a corrected debit without a fresh authorization, within 60 days of the return's settlement (Nacha; the banking side of each code is in the guide to ACH return codes). The sample carrier's settings stop all debits after an R11 until a new authorization arrives: a stricter choice than the Rules require, and one a carrier can make, provided it knows it is a choice.
Nacha return rate thresholds on an insurer's premium debits
An insurer that originates premium debits is measured on three return rates, each over the preceding 60 days or two calendar months: unauthorized returns against a threshold of 0.5 percent, administrative returns (R02, R03, R04) against a level of 3.0 percent, and all returns against a level of 15.0 percent (Nacha, unauthorized return rate; Nacha, administrative and overall rates). The arithmetic, including the two ways Nacha allows the denominator to be counted, is worked through in the banking guide to ACH return rate calculation for one originator.
How much of each Nacha threshold one sample carrier has used over 60 days
The three numbers are not equal in weight. The unauthorized threshold is a rule: an originator above it can be required by its bank to bring the rate down. The administrative and overall figures are "Return Rate Levels", and Nacha is explicit that crossing one is not in itself a breach of the Rules; it starts an inquiry (Nacha, Risk and Enforcement topics; how a bank watches those levels is in the guide to ACH return rate monitoring). Nacha set them against network averages of the time: when the rule took effect in 2015, the unauthorized threshold was "more than 16 times higher" than the 2013 network average of 0.03 percent, and the overall level "approximately 10.5 times higher" than the 1.42 percent average.
For an insurer, the useful reading is by reason. Insufficient funds drives the overall rate and is a collections problem. Administrative returns mean bad account data, usually captured at enrolment, and are a form-design problem. Unauthorized returns are the dangerous ones: a customer who tells their bank the insurer had no authority to debit them. A billing team that sees only one combined return rate cannot tell which problem it has.
Returns in Insurance Billing Exception Management: the 60-day rates beside each threshold, and the action each code allows
Billing software for insurance companies: what to compare
Compare billing software for insurance companies on the exceptions, not the happy path. Every product posts a coupon payment. The differences show on the uncouponed check, the R10, the finance company letter and the refund owed to a mortgagee.
Nine questions for P&C insurance billing software, asked about the exceptions
- What happens to a check with no coupon?
Does anything read the image, or does it wait in unapplied cash for a search by amount?
- Does a payment on a policy with a notice pending rescind the notice?
Or does it cure the installment and leave the cancellation running?
- How are retries scheduled after a returned debit?
By code, at most two reinitiations, with "RETRY PYMT" and the same amount; never after an unauthorized return.
- Can you see return rates by reason, over 60 days?
Unauthorized, administrative and overall separately, against 0.5%, 3.0% and 15.0%.
- Where do premium finance notices go?
Into the system with the agreement matched to the policy, or into someone's inbox?
- Is the notice period checked by state?
Ten days in Florida and Texas; ten plus three for mailing in New York.
- Who approves a refund, and against which deadline?
Authority by amount, and the state's refund clock on every item.
- Does anything compare pending cancellations with money received, daily?
This finds the customer who paid before the notice takes effect.
- Can you replay last month?
Run a past month of exceptions through the product and compare its proposals with what your team did.
Insurance billing systems trends worth testing, not trusting
Three directions dominate how billing products describe themselves, and each one creates a question a buyer can test on their own data rather than take on trust.
More electronic payment. More autopay means fewer checks to read and more returned debits to work. The test is the returns table above: does the product know which codes may be retried, how often and how, and does it report the three Nacha rates separately?
Machine matching. Matching that learns from history can raise the share of payments applied automatically. The test is accuracy on the policy the money reached, not the match rate, because an amount match on a standard installment can be valid and wrong; insurance unapplied cash payments sets out how to measure it with your own history.
Real-time posting. Faster posting shortens the time money spends unapplied. It does not, on its own, connect a payment with a pending cancellation, a finance company's withdrawal or a scheduled retry. The test is whether anything looks across all of them before a cancellation takes effect.
Replace the billing system, or add an exception layer?
Replace the billing system when it fails on the ordinary work: plans it cannot model, bills it cannot produce, posting it cannot do. Add an exception layer when the ordinary work is fine and the losses are in the remainder. The second is cheaper, faster and reversible, and it does not touch the system of record; the first is a large programme that will still leave exceptions behind, because the four lanes above exist on any billing system.
The deciding evidence is last month. Count the items that went to unapplied cash, the returned debits and their codes, the finance company notices and the refunds, and note how many ended badly: a payment applied to the wrong policy, a cancellation on a policy already paid, a retry the rules did not allow, a refund paid after the state's deadline. If those are rare and the billing system is the cause, fix the billing system. If they cluster in the exceptions, work the exceptions.
Where Insurance Billing Exception Management fits
Insurance Billing Exception Management sits beside the billing system and reads what the carrier already receives: lockbox and bank remittance files with check images, returned payment files with their reason codes, finance company notices by email and mail scan, and billing account and policy data. It proposes actions and produces a daily exceptions report; it never moves money below the auto-apply line, cancels or reinstates a policy, rescinds a notice or releases a refund without a named person. Its design target is zero cancellations of customers whose money is already in, a target rather than a measured result. The honest way to test that, for this product or any other, is the replay in the last checklist item, run on your own month.
Questions people ask
What is a returned premium payment?
A premium collected by ACH debit that the customer's bank sent back unpaid, with a return reason code such as R01 for insufficient funds or R10 for a debit the customer says was not authorized. For an insurer, the code decides whether the premium may be collected again on the same authorization and which return rate the return counts against.
Which returned premium debits count as unauthorized?
Nacha's calculation guide lists R05, R07, R10, R11, R29 and R51 for the unauthorized return rate, which has a threshold of 0.5 percent over the preceding 60 days or two calendar months. Administrative returns are R02, R03 and R04, against a 3.0 percent level.
How many times can an insurer retry a returned premium debit?
Nacha limits reinitiation to two times, a limit it clarified in a rules change effective January 1, 2019. Each retry must carry "RETRY PYMT" and the same amount as the original, and a debit returned as unauthorized cannot be retried without a new authorization obtained after the return.
What happens if an insurer exceeds the Nacha return rate thresholds?
Above the 0.5 percent unauthorized threshold, the insurer's bank can be required to bring the rate down and can require the insurer to act. Above the administrative or overall levels, Nacha may open an inquiry, which is not automatically a rules violation.
Does P&C insurance billing software handle premium finance notices?
Check how it receives them. Finance companies send notices by email or mail in their own formats, so a product that cannot read them leaves the keying to people. Then check whether it matches the agreement to the policy and counts the notice period by state before anything is cancelled.