Billing invoice anomaly detection

A billing invoice anomaly detector is useful only when it returns a flag that names two things: the invoice line that looks wrong, and the policy billing term that makes it wrong. If amount, installment split, taxes, and fees match those terms, the output stays empty. Empty is a pass, not a missing result.

The detector does not rewrite premium. It does not invent a tax line. It does not produce a "corrected" invoice for the policy admin system to post. Billing still decides whether to hold the invoice or send it. The model is a reviewer that cites, not a clerk that posts.

Treat the flag as evidence for a hold, a send, or a callback to underwriting or rating. If someone pastes the model's suggested numbers into the invoice and dispatches, they have treated the flag as a corrected invoice. That is the failure this page is written to prevent.

The detector sits beside the platforms that generate the invoice and hold the terms. It does not replace rating or tax tables.

Load both sides in the same job. One side is the invoice about to dispatch: billed amount, installment schedule, tax lines, fee lines, due date, and the identifiers that tie the bill to a policy and a term. The other side is the policy billing terms that were in force when that invoice was built: modal premium, installment factors, permitted fees, tax treatment, and any endorsement that changed billing after issue.

Do not score an invoice against a product brochure, a prior term, or a neighboring policy in the same household. The cite has to be the term that governs this bill. If the terms file is missing, incomplete, or from a different effective date, stop. Do not flag. A flag with no term cite is noise billing cannot act on.

Match keys the way ops already keys a bill: policy number, term effective dates, billing account, and invoice sequence. Installment invoices need the installment number and the agreed split, not only the annual premium. A mid-term endorsement that changed modal premium must be in the terms payload, or a true change looks like an anomaly and a true anomaly looks like a change.

Taxes and fees belong in the same load. If the terms say surplus-lines tax is billed, the invoice should show it. If the terms say the carrier absorbs a policy fee, the invoice should not add it. The detector compares what is on the invoice to what the terms allow. It does not look up a jurisdiction table and write a tax the terms never stated.

Once both payloads are present and keyed, run the comparison. Amount, installment split, taxes, and fees are the four surfaces. Other invoice fields (payor name, mailing address, payment method) are out of scope unless a billing term explicitly constrains them.

Every flag names the invoice line and the policy billing term. Both cites are required. "Premium looks high" is not a flag. "Line 1 billed $X; term modal premium is $Y for this installment" is a flag. The same pattern applies to a wrong installment split, a fee the schedule does not list, or a tax line the terms exclude.

If they match, leave the flag blank. Do not emit a confidence score, a "no issue found" paragraph, or a suggested restatement of the premium. Silence is the pass. Billing should not have to parse a green check as if it were a hold.

When they do not match, stop at the cite. Do not compute a replacement premium. Do not round the installment to what the model thinks the split should be. Do not add a tax because a similar policy in the book had one. Inventing a tax is worse than a missed flag: it creates a bill the insured never agreed to and that finance cannot defend.

One path, not a measured case: a commercial package on monthly installments is about to dispatch. The invoice puts the full annual policy fee on installment 1 and still includes a prorated slice of that fee on the remaining installments. The terms say the fee is billed once, on the first installment, and is not part of modal premium. The detector flags the fee line on installments 2 through 12 and cites the fee clause in the billing schedule. It does not recompute modal premium or drop the fee from installment 1. Billing holds the run. A clerk confirms the schedule and either corrects the invoice in the billing system or sends it as written if the fee clause was endorsed after the terms extract.

A flag that cites only the invoice line ("fee repeated") without the term, or only the term ("fee is first-installment only") without the line, is incomplete. Route incomplete flags back to the extractor. Do not put them in the hold queue. Ops will either ignore them or, worse, treat the fragment as a license to rewrite the bill.

Hold when the dual cite is present, the mismatch is on amount, split, tax, or fee, and the invoice has not gone to the insured or into a lockbox file. A person uses the two cites to decide whether the invoice is wrong, the terms extract is stale, or an endorsement has not landed. They correct in the billing platform, not in the model output.

Send when the flag is empty, or a person has reviewed the cite and confirmed the invoice matches the in-force terms, including an endorsement the first extract missed. Dispatch through the same channels you already use. The detector does not become a second mailstream.

Ask when the invoice and the terms disagree, but billing cannot settle the disagreement: rating, surplus-lines eligibility, a fee underwriting never priced. Pass the dual cite to the team that owns that term. Do not invent a number so the bill can go out on time.

Do not auto-correct premium. A "fixed" amount that never posted through rating and billing controls will not match cash, commission, or the declaration page. Downstream premium audit automation will then see a bill that was never the book premium.

Failed payments and lapse risk are separate. An invoice that was correctly billed and then bounced is a recovery problem, not an anomaly. Hand that to failed payment recovery sequencing. A correctly billed account that may not renew is a retention problem; see lapse propensity scoring. Mixing those scores into this detector trains the model to flag late payers as wrong invoices.

When an insured calls about a line item, the agent should read the same dual cite billing used, or confirm there was no flag. An improvised explanation turns a silent pass into a disputed bill. Keep inquiry handling on billing inquiry voice agent so the cite, if any, is the script.

Scope creep is how this job dies. The detector compares invoice lines to billing terms for a bill that has not yet dispatched, or that is still recallable. It is not a premium audit of exposure. It is not a collections sequencer. It is not a tax engine. It is not a customer-service bot.

Keep the output a structured flag: invoice identifier, line identifier, line amount or code as billed, term identifier, term clause or field as extracted, and a short mismatch type (amount, installment split, tax, fee). No free-text recommendation that looks like a posting instruction. People will follow a sentence that says bill this amount instead.

If your stack already produces invoices from Guidewire, Duck Creek, Majesco, or Salesforce, write the flag back as an exception on that invoice, in that system of record. Do not maintain a parallel invoice. Do not let a spreadsheet of model amounts become the legal bill.

Re-run only when the invoice or the terms change. After an endorsement, reload terms and score the next invoice, not bills already sent, unless you have a documented recall process.

Every non-empty output is something a billing lead can take to a clerk without adding a cite by hand. Every empty output is something a lead can let go without opening the PDF.