Biomix invoice triage

Where the invoices went

1. Tier 1 · Rules 6,468invoices checked against 9 rules
   • 6,043 pass every rule → approved
   • 404 billed ≤ 2 days after the customer's previous invoice → Jev
   • 14 flagged as a likely rebill → review
   • 7 sent twice (corrections) → out of scope
2. Tier 2 · Jev 404near-duplicates scored by the model
   • 397 score below 0.39 → approved
   • 7 score 0.39 or more → review
3. Tier 3 · People 21invoices for a reviewer, 0.3% of all
   • 14 from the rules
   • 7 from Jev

Invoices are split by billing date so nothing is tuned on the data it is judged on: tune before 2026-01-01 (choices are made here), test 2026-01-01 to 2026-08-31 (choices are checked here), demo from 2026-09-01 (the latest batch).

Tier 1: the rules

Arithmetic, prices, commissions, payment schedules and party data are checked line by line. The synthetic data is clean, so those rules all pass. The two rules about repeated billing do the real work.

Tier 2: what Jev was asked

Is this invoice the same order as the customer's previous invoice (billed again in whole or in part, or one order split across the two invoices), rather than a separate new order?

Jev (model jev-1.13.0) sees both invoices and the customer's history and answers yes or no with a probability. Scores ran from 0.05 to 0.46, median 0.19. Anything at or above 0.39 goes to a reviewer.

Does it catch the right invoices?

The data has no answer key, so the evaluation plants cases with a known answer. Each one is built from real invoices: a rebill, a rebill with changed quantities, a split order, or a real new order moved next to the previous invoice. Then every case goes through the same rules and the same Jev question.

Each cell shows tune / test. Green means the share is where it should be (≥ 90% for cases to review, ≤ 5% for cases to approve). “Sent to review” is the whole pipeline: rules first, then Jev.

The review queue

The 21 invoices a person would look at, with the evidence each one arrives with.

Data checks before any of this

The delivered files were audited against their documentation first, so the rules rest on facts about the data rather than assumptions.

• match
  Row counts match the delivered file tableall 7 tables match
• match
  Columns match the documented grain; every *_cents column is an integer typeall documented columns present; all *_cents columns are integers
• match
  Keys are unique and every reference resolves0 violations
• match
  Period: 2023-01-01 to 2026-09-25invoices 2023-01-02 … 2026-09-25; monthly_sales 2023-01 … 2026-09
• match
  Schedules: Upfront, 30 Days, 3 installments (30/60/90), and a 4-installment 0-30-60-90 variant4 distinct values: "30 Days", "3 installments (30, 60 and 90 days)", "Upfront", "4 installments (Upfront, 30, 60 and 90 days)"
• match
  Commission is exactly 5% on every line; invoice commission = Σ line commissionsrules matching all 19,361 lines: ceil, half_up (14,218 lines are exact, 5,143 are .5-cent ties); invoice total ≠ Σ lines: 0
• match
  Each product has ~4 unit prices, one per yearly price listmax 4 prices per product; 0 product-year(s) with more than one price
• match
  Each customer belongs to exactly one seller (so 'same seller' carries no signal)customers_with_many_sellers=0, customers_with_many_units=0, invoices_seller_ne_customer_seller=0
• info
  Payment schedule varies strongly by segment (usable 'unusual schedule' signal)Cramér's V (segment × schedule) = 0.298; table shows % of each segment's invoices
• match
  418 invoices are billed ≤ 2 days after a prior invoice of the same customer418 invoices with gap ≤ 2 days; 1,293 with gap ≤ 7 days (Phase 2 candidates)
• match
  invoice_number order can break same-day ties (point-in-time ordering)VARCHAR, 000001 … 006468; 0 out of order
• match
  Only 7 invoices have times_sent = 2 (corrections out of scope)7 invoices with times_sent = 2
• differs
  Invoices 2026-09-01 … 2026-09-25 (from_pending_delivery = true, ~145) are the demo batch146 pending (2026-08-26 … 2026-09-25); flag disagrees with date on 1
• info
  Splits: tune 2023–2025, test 2026-01 … 2026-08, demo = Sep 2026tune 5,115 · test 1,208 · demo 145
• info
  Agro peaks May–Oct; Home & Garden peaks before Mother's Day, Black Friday, Christmastop-4 months (2023–2025, index 1.00 = average month) → Agro: Jul/Aug/Jun/Sep; Home & Garden: Dec/Nov/Apr/May
• info
  A handful of large accounts dominate revenuetop 5 = 16.9%, top 10 = 31.0%, top 10% (31 customers) = 64.5% of invoiced sales
• match
  monthly_sales is an aggregate of invoices (so seasonality must use prior years only)monthly_sales equals the invoice aggregate on every row
• info
  customers.* summary columns are whole-period aggregates → not point-in-time safecustomers.invoice_count / total_sales_cents / first|last_billing_date cover the full period; features must recompute them from prior invoices. Differences vs. invoices: invoice_count_diff=0, total_sales_diff=0, first_date_diff=0, last_date_diff=0
• info
  Segments, business units and catalog (context for features)Agro: 12 products / 5 categories; Home & Garden: 12 products / 5 categories

Limits

• All data is synthetic. Customer, product and invoice numbers are made up.
• There is no real answer key. The rates above come from planted cases, and the planted rebills reuse the previous invoice's products, which is exactly what the rebill rule tests, so its 100% is a best case.
• Thresholds and rules were chosen on tune only and then reported on test.