Why Invoice OCR Fails on Line Items

Deterministic Ingestion Standard

Traditional template-based OCR and generic LLM extractors fail on vendor invoices because they treat numbers as visual glyphs or text tokens rather than mathematical values. Fixing this requires a deterministic mathematical reconciliation step in code: every line item's quantity multiplied by unit price must equal the extended price, and the sum of all lines plus tax and shipping must equal the invoice total down to the cent before posting to your accounting software.

The 4 root causes of bad invoice extraction in accounts payable

1. Multi-Page Subtotal Stacking

When a vendor sends a 3-page invoice with page subtotals, legacy OCR engines frequently grab page 1's subtotal as the grand total or duplicate line items across page headers.

2. Ambiguous Decimal Separators

International invoices alternate between commas and periods (`1,250.00` vs `1.250,00`). Pure OCR treats commas as noise, converting $1,250 into $125,000 or $1.25.

3. Missing or Implied Tax Rates

Invoices often display a 0% tax line, multiple county taxes, or combined freight/fuel surcharges. Generative AI models guess tax percentages, corrupting GL account balances.

4. Skewed Scans & Table Borders

Box-based OCR coordinates drift when mobile phone camera photos or faxes arrive skewed, reading quantity `10` as unit price and shifting the entire column payload.

The Python Pydantic Mathematical Gate

We never post an invoice directly to QuickBooks or NetSuite APIs. Instead, the extracted payload passes through a strict Python validation model before any accounting write occurs:

# Python Pydantic Schema: Reconciles line math down to the cent

class ValidatedInvoice(BaseModel):

vendor_name: str

invoice_total: Decimal

tax_amount: Decimal = Decimal('0.00')

line_items: list[InvoiceLineItem]

@model_validator(mode='after')

def verify_math(self):

sum_lines = sum(item.quantity * item.unit_price for item in self.line_items)

expected_total = sum_lines + self.tax_amount

if abs(expected_total - self.invoice_total) > Decimal('0.02'):

# Math mismatch: Route to human operator via Slack button

raise ValueError(f"Math check failed: items sum to {sum_lines} + tax, but invoice claims {self.invoice_total}")

return self

Automate vendor invoice intake with guaranteed math accuracy

We build custom serverless invoice processing pipelines connecting your inbox, vision AI models, and QuickBooks/NetSuite accounts with deterministic human approvals.

Document Processing Services QuickBooks API Guide