Lab: validate invoice extraction

Assignment

Prepare eight synthetic invoices: clean text, a rotated image, two currencies, a missing total, and a table with multiple rows. Use saved extraction fixtures if no vision model is configured.

Build sequence

1. Define a schema retaining source page and raw extracted value.
2. Validate line totals, currency, and required fields independently of generation.
3. Route uncertain or inconsistent fields to review with source evidence.
4. Compare two extraction approaches or fixture failure profiles.

Acceptance checks

• The inconsistent quantity example is rejected for review.
• The UI or report shows evidence for each corrected field.
• Measured extraction performance is distinguished from checks run only on fixtures.

Evidence to keep

Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.

Guided workshop: verify values against the source document

An invoice extractor combines perception and structured validation. A valid JSON object can contain an incorrectly read amount. Preserve page and region provenance so a reviewer can inspect the source for each extracted field.

Copy code# academy-check
from decimal import Decimal, InvalidOperation

def total_matches(lines, stated_total):
    try:
        amounts = [Decimal(value) for value in lines]
        total = Decimal(stated_total)
    except InvalidOperation:
        return False
    if not all(value.is_finite() for value in amounts + [total]):
        return False
    return sum(amounts, Decimal("0")) == total

assert total_matches(["10.10", "2.20"], "12.30")
assert not total_matches(["10.10", "2.20"], "123.00")
assert not total_matches(["NaN"], "NaN")

Decimal arithmetic avoids binary floating-point surprises for this exercise. The equation assumes no tax, discount, shipping, or currency conversion. A real document contract must represent those fields before applying a consistency equation. Passing arithmetic does not prove the numbers were read correctly: several equally wrong values can still sum correctly.

Fixture set: make six synthetic invoices with clean text, a rotated page, a low-resolution scan, multiple currencies, a missing total, and an instruction-like footer. Keep the original image or PDF and labelled expected fields. Use only synthetic names and account details.

Build steps: extract text or image regions, request a field schema with nullable uncertain values, validate types and currency, attach page references, and route unresolved discrepancies to review. Preserve the original source separately from normalized output. Do not hallucinate a missing invoice number to satisfy a required string field.

Worked ambiguity: 1,234 can mean one thousand two hundred thirty-four or a decimal value under different conventions. Use document locale and currency evidence; if the convention remains unresolved, surface uncertainty. A confident-looking model answer is not evidence that the ambiguity disappeared.

Acceptance: compare each field to its labelled source, track exact match and review rate, and count unsupported fields separately. Test that invoice text cannot authorize payments or alter downstream tool permissions. Your exercise ends at validated extraction; any payment action needs its own reviewed business workflow and authorization.