Your invoice extractor sometimes returns a total that doesn't equal the sum of its line items — usually because OCR misread one line ($1,287 read as $287, etc.). The accounting team catches these days later as anomalies, after they've already been propagated downstream.
How can the schema design itself surface these errors at extraction time?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Returning both values plus a discrepancy flag turns a downstream anomaly into an upstream signal. The extraction now surfaces the disagreement at the moment it's detected, with both values preserved. Downstream systems can route discrepancies to human review without losing the underlying data. This is a recurring pattern in extraction schema design: when two computations of the same quantity could disagree, capture both and flag the disagreement rather than picking one and hoping.
OCR errors on individual line items can produce a stated_total that doesn't match the actual line items. Trusting stated_total blindly hides that exact failure mode.
OCR errors on the total line are also possible. Ignoring stated_total discards the document's explicit claim and substitutes your computation, which has its own failure modes.
Hard-rejecting every discrepancy throws away genuine extractions where the math is fine but a single OCR error caused a small mismatch. The right pattern is to flag the discrepancy and route appropriately, not refuse to return anything.