Billing Discrepancy Classifier

Freight invoices fail settlement for many reasons that look similar on a queue: a duplicate charge, a rate that does not match the tender, an accessorial that was never authorized, a weight or distance mismatch, or a payment that was already applied. Clerks spend time reading line items, guessing the category, and sending the case to whoever usually handles that kind of problem. Wrong routing adds days. Correct routing still depends on someone naming the problem clearly enough for the next person to act.

A billing discrepancy classifier sits after extraction and anomaly detection. It does not approve or reject payment. It assigns a discrepancy type ID to each flagged issue, cites the invoice line span that supports the label, and hands a structured packet to the clerk who still owns resolution. When the invoice is unstructured or the evidence span cannot be grounded, the classifier returns empty rather than inventing a category.

This pattern fits the confirm stage of logistics AI adoption: speed the decision of what kind of problem this is, without removing human control over settlement.

The model consumes structured invoice fields (carrier, SCAC, PRO, ship date, line charges, accessorial codes, totals) plus optional signals from upstream agents: match failures from automated three-way match, outlier flags from an invoice anomaly detector, and line text from a freight invoice extractor. Contract or tariff snippets from a contract entitlement check can narrow whether an accessorial was allowed, but the classifier’s job remains labeling, not adjudicating.

Typical discrepancy type IDs include:

• Duplicate invoice or duplicate line
• Rate or tariff mismatch
• Unauthorized or inflated accessorial
• Quantity, weight, or mileage variance
• Tax, fuel, or currency misapplication
• Missing supporting document for a billed service
• Already paid or credit-balance conflict

Each positive classification must cite an invoice line span (page and line indices, or field IDs from the extractor) and a stable discrepancy type ID from your controlled vocabulary. Citations make review auditable: a clerk can jump to the same lines the model used. Empty output is required when lines are missing, OCR confidence is below threshold, or the invoice cannot be mapped to the schema. Guessing a type without a span creates false routing and erodes trust.

The clerk still resolves. They may accept the label, reclassify, request carrier evidence, short-pay, or escalate. The AI only shortens the “what is this?” step so the right resolver queue gets the case sooner.

Most AP and freight-audit backlogs are not short on people; they are short on triage. A mixed “exception” queue forces every clerk to re-diagnose from scratch. Typed queues (duplicates to one team, accessorial disputes to another, rate errors to pricing) cut handoffs and template the first reply to the carrier.

Speed gains show up as:

1. Faster first-touch routing — cases land in the specialty queue on day zero instead of after a generalist skim.
2. Shorter cycle time to carrier contact — the outbound note already names duplicate vs rate vs accessorial with line references.
3. Cleaner metrics — you measure aging and win rates by discrepancy type, not by a catch-all exception bucket.
4. Safer automation later — only high-confidence, repeatedly validated types should ever move toward auto short-pay rules; classification is the prerequisite taxonomy.

Keep the outcome scoped to speed. Accuracy of settlement still belongs to policy, contracts, and the clerk. A wrong label that is easy to override is less harmful than a silent auto-reject.

Start with a small, operationally owned type catalog (often 8–15 codes). Align codes with how disputes are already worked and with carrier response templates. Map vendor or EDI reason codes into your IDs rather than letting the model invent free-text categories.

Require span grounding in the prompt and in post-processing: if the model emits a type without a resolvable span, discard to empty. Prefer field-level spans from the extractor over raw PDF coordinates when both exist. For multi-line issues (for example, a rate error that cascades across fuel), allow multiple spans under one type ID, still with explicit line references.

Empty cases should route to a generic “needs structuring” path: re-run extraction, request a better image, or send to a senior clerk. That path is itself a speed win; you stop burning specialist time on invoices that cannot yet be classified.

Human feedback closes the loop. When clerks override a type, store the override with the span and invoice hash. Use those pairs for evaluation and periodic prompt or fine-tune refresh. Track precision and override rate by type; retire or merge codes that clerks never use.

Enterprise stacks rarely start from a blank LLM. Classification usually sits beside (or inside) platforms that already move freight invoices and payments:

• Cass AI — Strong in freight audit and payment networks. Use classification to enrich Cass-flagged exceptions with your internal discrepancy type IDs and line spans before cases enter specialist queues, especially when your playbooks differ from the network’s default reason codes.
• TriumphPay — Common in broker and carrier payables. Pair classifier output with TriumphPay exception workflows so duplicate and rate disputes route differently from accessorial fights, without changing who authorizes the final pay action.
• Billtrust — Focused on B2B receivables and invoice presentment on the supplier side. On the shipper or 3PL AP side, treat Billtrust-originated PDFs or portals as another intake channel: extract, detect anomalies, then classify discrepancies the same way as EDI invoices so channel does not dictate process.
• Coupa — Broader procurement and invoice automation. Coupa’s matching and exception rules catch many structural failures; an LLM classifier adds nuance for freight-specific accessorial and tariff disputes that generic PO match codes do not express. Export Coupa exception payloads into the classifier and write the type ID back as a custom field or comment for routing.

None of these vendors replaces the need for your type catalog and span citation rules. They supply intake, matching, and payment rails. The classifier supplies a logistics-native label layer for confirm-stage speed.

Pilot on one mode or one high-volume lane family. Freeze the type list for the pilot. Wire only read-only enrichment into the clerk UI: type, confidence, spans, and links to extractor and match outputs. Measure median time from exception creation to first specialist touch and override rate by type.

Expand only after override rates stabilize and empty rates are explained (unstructured PDFs, missing BOLs, poor scans). Do not auto-resolve from classification alone in the first phases. Keep the human as the resolver; use the model to name the problem with evidence.

When extraction quality improves and contract entitlement checks are reliable for a subset of accessorials, you can later attach playbooks per type ID. That is a separate adoption step. Classification done well is the shared language that makes those playbooks possible without rebuilding the queue every quarter.