OCR & Document Extraction

A Format-Agnostic Invoice Extraction Pipeline for Multi-Supplier AP Automation

How Pfactorial Technologies designed and prototyped an invoice-data extraction pipeline that handles any supplier's layout without rigid templates, and evaluated five deployment architectures on real per-invoice cost.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_InvoiceFlow_AP_Automation image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client receives invoices from many suppliers, each using a different layout and format, and manual processing of that variety was slow and error-prone - exactly the kind of repetitive, high-volume task that doesn't tolerate rigid, template-based extraction rules.

A template-per-supplier approach breaks the moment a supplier changes their invoice layout, and doesn't scale to onboarding new suppliers without ongoing engineering effort. The client also needed the extraction cost itself understood before committing to an architecture, since cost scales directly with invoice volume.

Pfactorial built a proof of concept combining direct text extraction for digital PDFs with an OCR/vision fallback for scanned documents, feeding both into an LLM that structures the result into standardized JSON - and evaluated five deployment architectures side by side on real, per-thousand-invoice cost.

Why this engagement is representative This engagement shows Pfactorial treating architecture selection as a first-class deliverable, not an afterthought - the client got a working proof of concept and a transparent, evaluated cost comparison across five real deployment options before committing to one.

THE CHALLENGE

Automating extraction across every supplier's invoice format, without locking into rigid rules, meant solving for both technical variability and deployment economics.

1. Every supplier's invoice looks different

Layout, field placement and terminology vary supplier to supplier, and a template-based extraction rule breaks the moment a new supplier or a layout change appears.

2. Invoices arrive in fundamentally different formats

Some invoices are text-based PDFs with selectable content; others are scanned images with no extractable text at all - a single extraction method can't handle both.

3. Extraction needs a human check before it's trusted

Fully automated extraction without a review step risks silently propagating errors into downstream financial processing - the solution had to support human review before approval.

4. Architecture choice is also a cost decision

Cloud AI services, self-hosted models and hybrid combinations all carry meaningfully different per-invoice costs at scale, and that difference needed to be quantified before committing.

The real brief Not “extract data from invoices” but “build an extraction approach that works regardless of supplier format, and show exactly what it costs to run at different levels of cloud dependency.”

THE SOLUTION

Pfactorial built a hybrid extraction path - direct text extraction where possible, OCR/vision fallback where not - feeding into an LLM that standardizes every invoice into the same JSON structure, and benchmarked five deployment architectures on real cost.

Pfactorial_Case_Study_InvoiceFlow_AP_Automation image 2

Figure 2 - Any supplier, any format, one standardized output.

Architectural principles

Check for extractable text before falling back to OCR - The system first checks whether a PDF contains selectable text and extracts it directly if so, reserving OCR/Vision processing for genuinely scanned documents - avoiding unnecessary OCR cost and error on documents that don't need it.
LLM-driven structuring instead of per-template rules - Extracted content, regardless of source format, is sent to an LLM that converts it into a standardized JSON structure - avoiding rigid, template-based extraction rules that would need to be rebuilt for every new supplier.
Human review before approval - The current scope explicitly supports a review step before extracted data is approved, rather than pushing fully automated results straight into downstream financial systems.
Architecture evaluated on real economics - Five candidate architectures - from fully managed cloud to fully self-hosted open source - were priced out on a consistent basis (cost per 1,000 invoices) before a recommendation was made.

CAPABILITIES DELIVERED

The current proof-of-concept scope covers the extraction path end-to-end, with review, confidence scoring and integrations scoped as near-term next steps.

CAPABILITY	WHAT IT DOES
Multi-format invoice upload	Direct upload or integration pipeline ingestion, supporting text-based and scanned PDFs.
Text-first extraction	Direct text extraction when a PDF contains selectable content, avoiding unnecessary OCR.
OCR/Vision fallback	Automatic fallback processing for scanned, image-only invoices.
LLM-based standardization	Any extracted content converted into a consistent JSON structure regardless of source format.
Document management interface	Extracted results stored and displayed for review.
Five-architecture cost comparison	Documented per-1,000-invoice cost across cloud, hybrid and self-hosted deployment options.

Pfactorial_Case_Study_InvoiceFlow_AP_Automation image 3

Figure 3 - Five architectures, priced consistently on cost per 1,000 invoices.

Design note The recommended architecture is a hybrid: managed cloud OCR paired with a self-hosted LLM. It isn't the cheapest option available (fully open-source self-hosting is), but it balances setup speed against cost more favorably than an all-cloud approach - the kind of tradeoff worth making explicit rather than defaulting to "just use the cloud APIs."

ENGINEERING FOR SCALE AND RELIABILITY

Five architecture options were evaluated on a consistent cost basis, not just technical feasibility.

Cloud-native (GCP / AWS)

Document AI Invoice Parser with Vertex AI, or Textract Analyze Expense with Bedrock - fastest to stand up, at $10-$40 per 1,000 invoices.

Hybrid cloud OCR + cloud LLM

Textract or Document AI paired with a lightweight cloud LLM (e.g. GPT-4.1 Nano/Mini) at $12-$35 per 1,000 invoices.

Recommended: hybrid cloud OCR + self-hosted LLM

Managed OCR paired with a self-hosted open model (e.g. Qwen/Llama) at $10-$15 per 1,000 invoices, balancing setup speed and cost.

Fully open source, self-hosted

PaddleOCR or Tesseract with a self-hosted LLM, at $1-$5 per 1,000 invoices - the lowest cost, at the expense of more operational ownership.

Serverless GPU scaling

A serverless deployment option starts model inference automatically when invoices are ingested in batches and scales down afterward, avoiding the cost of a dedicated GPU instance running continuously.

DELIVERY APPROACH

The engagement scoped and prototyped the extraction pipeline while evaluating deployment economics in parallel.

1. Business problem definition - cataloging supplier format variability and the requirements for human review and standardized output.

2. Extraction pipeline prototype - text-detection routing, OCR/Vision fallback, and LLM-based JSON standardization.

3. Document management interface - storage and display of extracted results for review.

4. Architecture evaluation - pricing out five deployment options on a consistent per-1,000-invoice cost basis.

5. Recommendation & roadmap - a recommended hybrid architecture, with review workflow, confidence scoring and downstream integrations scoped as next steps.

RESULTS AND IMPACT

Pfactorial_Case_Study_InvoiceFlow_AP_Automation image 4

Figure 4 - Key outcomes from this engagement.

The proof of concept validated that a single pipeline - without per-supplier templates - could handle both text-based and scanned invoice formats through to standardized JSON output.

The five-architecture cost comparison gave the client a transparent, quantified basis for choosing a deployment approach before committing further engineering investment.

What it enabled commercially

The client now has both a working extraction approach and a clear, evidenced cost picture across deployment options - turning “should we automate invoice processing” into a scoped decision with real numbers behind it, rather than an open-ended estimate.

WHY PFACTORIAL

This engagement reflects Pfactorial's approach to proof-of-concept work: deliver a working technical path and make the deployment economics explicit, so the client's next investment decision is evidence-based.

Pfactorial_Case_Study_InvoiceFlow_AP_Automation image 5

Figure 5 - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with finance and operations teams automating document-heavy workflows across variable supplier formats. If you're evaluating an invoice or AP automation initiative, we're happy to give you an honest read on scope, cost and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_InvoiceFlow_AP_Automation image 6

© 2026 Pfactorial Technologies. Client identity and product-specific implementation detail are withheld or generalized; no client data, credentials, source code, or infrastructure detail is included in this document.