Pick an invoice
Three fictional invoices, deliberately messy. Or upload one of your own.
The scan
Member on file
Three model calls, about 30 seconds.
That run did not finish
Line by line
tap a row for the reasoning| Billed line | Billed | Benefit | Plan pays | Discount | Client owes |
|---|
Draft note to the client
written from the adjudicated figuresWhat the model read off the page
The plan the matcher was given
How it is put together
Judgement and arithmetic are separated
The model reads the page and decides which benefit a line belongs to. It is never asked for a dollar figure. Allowances, annual limits and every subtotal are computed in code, in integer cents, and the run reconciles: plan share plus discounts plus client balance has to equal the invoice, or the result is flagged instead of shown.
The plan is data, not code
Snout builds each plan around a clinic's own pricing and codes, so the schedule of benefits is handed to the matcher as text and read fresh on every run. A new plan, a clinic with its own item codes, or a mid year change to an allowance is a data edit. Nothing in the pipeline is hard coded to a particular clinic's item names.
It checks the invoice, not just itself
Each line is re-multiplied from quantity and unit price, and the extracted lines are summed against the total printed on the page. On the third sample those two numbers disagree, because the receipt itself does not add up. The run says so rather than quietly picking one.
Built to be argued with
Every verdict carries the sentence of plan wording it leaned on and a confidence, so a reviewer can disagree with a specific line instead of distrusting the whole batch. That is what turns this from a party trick into something a claims team will actually run.