DEV Community: risha-max

Extract Tables from PDFs Without Tabula -- A Simpler Approach

risha-max — Wed, 25 Feb 2026 05:00:25 +0000

Approach

If you have ever extracted tables from PDFs in production, you know the pain:

It works on one statement
Breaks on the next vendor
Fails when spacing, borders, or merged cells change

For many teams, the workflow becomes: "try Tabula/Camelot, patch for edge cases, repeat forever."

In this post, I will show a simpler schema-driven approach to extract table data from PDFs, including bank statements and multi-page tables.

The table extraction problem

PDFs are designed for visual rendering, not structured data exchange.

That means table boundaries are often implied by layout, not explicit data structures.

Common issues:

Inconsistent row spacing
Missing or broken cell borders
Wrapped text in description columns
Header rows repeated across pages
Totals and footers mixed into table body

Traditional "line/coordinate based" extraction can become fragile quickly.

Why Tabula and Camelot break on complex layouts

Tabula and Camelot are useful tools, especially for clean, machine-generated PDFs with predictable geometry.

But they often struggle when:

Tables are borderless
Columns drift slightly page-to-page
Text wraps across lines
The PDF is scanned or low quality
Multiple table styles appear in one file

You then end up writing post-processing logic:

manual column repair
row stitching
heuristic cleanup for bad splits

At scale, maintenance cost grows fast.

Schema-driven table extraction

A schema-driven approach flips the problem:

Instead of trying to reconstruct a perfect grid from geometry, you declare the output structure you want, and parse the document into that structure.

For example, for a bank statement:

account metadata
statement period
transactions array with typed fields

This is much more robust for real-world variations across issuers and templates.

Tutorial: define a table schema and parse a bank statement

1) Install dependencies

pip install oxpdf

2) Define a schema for statement transactions

BANK_STATEMENT_SCHEMA = {
    "type": "object",
    "properties": {
        "bank_name": {"type": "string"},
        "account_last4": {"type": "string"},
        "statement_start_date": {"type": "string"},
        "statement_end_date": {"type": "string"},
        "transactions": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "date": {"type": "string"},
                    "description": {"type": "string"},
                    "debit": {"type": "number"},
                    "credit": {"type": "number"},
                    "balance": {"type": "number"}
                },
                "required": ["date", "description"]
            }
        }
    },
    "required": ["transactions"]
}

3) Parse a sample statement

import os
from oxpdf import Oxpdf

client = Oxpdf(api_key=os.environ["OXPDF_API_KEY"])

with open("sample-bank-statement.pdf", "rb") as f:
    result = client.pdf.parse(
        file=f,
        schema=BANK_STATEMENT_SCHEMA,
        use_ocr=True  # keep true if scans/photos are common
    )

4) Access table rows (transactions)

data = result["data"]
rows = data.get("transactions", [])

print("Transactions:", len(rows))
for row in rows[:5]:
    print(row.get("date"), row.get("description"), row.get("debit"), row.get("credit"), row.get("balance"))

This gives you row-wise JSON ready for analytics, reconciliation, and storage.

Handling multi-page tables

Multi-page statements are where many extraction pipelines fail.

With schema-driven extraction, the expected output is already a single transactions[] array, so rows can be normalized across pages.

Recommended safeguards:

Ensure date + description are required fields per row
Filter known footer/header artifacts post-parse
Add validation checks (e.g., row count, running balance sanity)
Keep raw parse payload for audit/debugging

A simple validation helper:

def valid_transaction(row: dict) -> bool:
    if not row.get("date") or not row.get("description"):
        return False
    if all(row.get(k) is None for k in ("debit", "credit", "balance")):
        return False
    return True

clean_rows = [r for r in rows if valid_transaction(r)]

Comparison with traditional tools

Traditional coordinate/grid extraction

Pros:

Fast on clean, consistent layouts
Good for fixed internal templates

Cons:

Fragile on real-world variation
Heavy post-processing burden
Harder to maintain across multiple vendors

Schema-driven extraction

Pros:

Output shaped for your app from the start
More resilient to layout changes
Easier to maintain as document variety grows

Cons:

Requires clear schema design upfront
May still need light normalization for edge cases

Final thoughts

If your table extraction keeps breaking on new PDF templates, the issue is often not your regex -- it is the extraction strategy.

For production pipelines, schema-driven parsing is usually the better long-term bet:

more stable
easier to reason about
lower maintenance overhead

If you want to test this with your own statements/invoices, start with a narrow schema and expand field-by-field as needed.

OCR vs Layout Parsing: When to Use What for PDF Data Extraction

risha-max — Wed, 25 Feb 2026 04:59:14 +0000

If you work with PDF data extraction long enough, you run into the same question:

Should I use OCR, or is text/layout parsing enough?

The short answer: it depends on the source document.

The practical answer: you should detect document type early and choose the cheapest reliable path.

In this post, we will break down:

Text-based PDFs vs scanned/image PDFs
When text extraction is enough (and faster)
When OCR is required
How 0xPdf handles both automatically
Performance and cost trade-offs

Text-based PDFs vs scanned/image PDFs

Not all PDFs are equal.

Text-based PDFs

These are generated digitally (from software exports, billing systems, etc.).

The text is selectable/copyable.

Typical examples:

SaaS invoice exports
E-invoices from ERP systems
Bank statements generated from online portals

Scanned/image PDFs

These contain image data, not machine-readable text.

Typical examples:

Scanned paper invoices
Photos of receipts converted to PDF
Faxed/printed documents re-uploaded

For these, plain text extraction often returns little or nothing useful. You need OCR.

When text extraction is enough (and faster)

Use text/layout parsing when your PDFs are mostly digital and clean.

Why:

Lower latency
Lower compute cost
Fewer OCR-induced recognition errors
Better throughput in bulk jobs

If your incoming docs are 90% machine-generated invoices, start with text extraction first.

In many production systems, this is the default path.

When you need OCR

Use OCR when documents are scanned, photographed, or have embedded text issues.

Common signs OCR is needed:

Extracted text is empty or very sparse
Page appears as one large image layer
Line items or totals are unreadable in raw extraction
Mobile-captured docs (skewed, noisy, blurry)

OCR is often the difference between "no parse" and "usable parse" on real-world messy data.

How 0xPdf handles both automatically

A robust pipeline should not force you to hardcode one mode forever.

0xPdf supports both strategies and can be used with a practical fallback model:

Try text/layout extraction for speed
If confidence/coverage is low, retry with OCR
Return structured JSON in the same schema shape

That means your downstream systems do not care whether OCR was used -- they still receive the same JSON contract.

Example flow:

Clean invoice PDF -> text parse path
Scanned receipt PDF -> OCR path
Same output schema -> same integration code

Performance comparison: with OCR vs without

Actual numbers vary by file quality and page count, but the pattern is consistent:

Without OCR: faster, cheaper, ideal for machine-generated PDFs
With OCR: slower, more compute-heavy, necessary for image documents

A practical benchmark pattern:

1-page digital invoice: text extraction significantly faster than OCR
10-page scanned statement: OCR slower but required for correctness
Mixed workload: hybrid/fallback strategy gives best reliability/cost balance

If you care about both speed and accuracy, avoid "always OCR everything."

Cost implications

OCR costs more because it is computationally heavier.

If you run OCR on every document regardless of need, you will:

Increase infrastructure/API costs
Increase processing time
Reduce throughput under load

A better strategy:

Default to text/layout extraction
Escalate to OCR only when needed
Cache results for repeat documents
Track OCR usage rate as an ops KPI

This keeps your unit economics healthy as volume scales.

Practical decision framework

Use this quick rule:

Digital, selectable text PDF? Start without OCR.
Scanned/photo-based or poor extraction quality? Enable OCR.
Mixed unknown traffic? Use automatic fallback.

This gives you the best balance of latency, cost, and extraction quality.

Final thoughts

OCR and layout parsing are not competing strategies -- they are complementary tools.

If your goal is reliable production extraction, treat them as a routing problem:

Fast path for clean digital docs
OCR path for messy image docs
Unified structured JSON output for the rest of your stack

That is the approach we use with 0xPdf to keep both developer experience and operational cost under control.

# How to Parse Invoices into JSON with Python (No Regex)

risha-max — Tue, 24 Feb 2026 22:29:27 +0000

Parsing invoices sounds easy until you do it at scale.

One supplier sends a clean text PDF. Another sends a scanned image. A third changes layout every month. Suddenly your extraction logic breaks and you are patching regex rules at midnight.

In this post, I will show a schema-first approach with 0xPdf that turns invoice PDFs into structured JSON in Python -- without brittle regex parsing.

The problem: why invoice PDF parsing is hard

Invoices are not standardized documents. Even when they contain the same fields, they vary by:

Layout and visual hierarchy
Label naming ("Invoice #", "Invoice No.", "Ref")
OCR quality (for scanned PDFs)
Currency/date formatting
Multi-line items and totals sections

Most failures happen when extraction code assumes one fixed layout.

Traditional approaches (and where they break)

`pdfplumber` (or similar text extractors)

Good for extracting text blocks, but you still need to map unstructured text into business fields yourself.

That usually means:

Regex for each field
Manual heuristics per vendor
Ongoing maintenance when templates change

AWS Textract / raw OCR APIs

Useful for OCR and document signals, but output is still mostly low-level structure. You still need significant post-processing to get final business JSON.

In other words: you pay for extraction and still write parsing logic.

The schema-first approach with 0xPdf

With 0xPdf, you define the shape of the data you want up front (schema), then parse the document directly into that structure.

Instead of:

PDF -> text -> regex -> custom parser -> JSON

you do:

PDF + schema -> structured JSON

This is much easier to maintain across different invoice formats.

Step-by-step Python tutorial

1) Install the SDK

pip install oxpdf

2) Define an invoice schema

Create a schema for the fields your app actually needs:

INVOICE_SCHEMA = {
    "type": "object",
    "properties": {
        "invoice_number": {"type": "string"},
        "invoice_date": {"type": "string"},
        "due_date": {"type": "string"},
        "vendor_name": {"type": "string"},
        "vendor_address": {"type": "string"},
        "currency": {"type": "string"},
        "subtotal": {"type": "number"},
        "tax": {"type": "number"},
        "total": {"type": "number"},
        "line_items": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "description": {"type": "string"},
                    "quantity": {"type": "number"},
                    "unit_price": {"type": "number"},
                    "amount": {"type": "number"}
                }
            }
        }
    },
    "required": ["invoice_number", "invoice_date", "vendor_name", "total"]
}

3) Parse a sample invoice

import os
from oxpdf import Oxpdf

client = Oxpdf(api_key=os.environ["OXPDF_API_KEY"])

with open("sample-invoice.pdf", "rb") as f:
    result = client.pdf.parse(
        file=f,
        schema=INVOICE_SCHEMA,
        use_ocr=True  # set True if scanned/image-based invoices are common
    )

4) Handle the JSON response

data = result["data"]

print("Invoice #:", data.get("invoice_number"))
print("Vendor:", data.get("vendor_name"))
print("Total:", data.get("total"))

for item in data.get("line_items", []):
    print("-", item.get("description"), item.get("amount"))

This gives you clean, application-ready JSON you can store directly in your DB or pass to downstream systems.

Results comparison: Textract-style raw output vs 0xPdf structured output

Typical raw OCR output (simplified)

{
  "blocks": [
    {"type": "LINE", "text": "Invoice No: INV-2039"},
    {"type": "LINE", "text": "Total Due USD 1,284.44"},
    {"type": "LINE", "text": "Widget A   2   120.00   240.00"}
  ]
}

You still need custom parsing code for every field.

0xPdf schema-first output

{
  "invoice_number": "INV-2039",
  "invoice_date": "2026-02-10",
  "due_date": "2026-03-12",
  "vendor_name": "Acme Supply Co.",
  "currency": "USD",
  "subtotal": 1150.0,
  "tax": 134.44,
  "total": 1284.44,
  "line_items": [
    {
      "description": "Widget A",
      "quantity": 2,
      "unit_price": 120.0,
      "amount": 240.0
    }
  ]
}

This is immediately usable by your billing, reconciliation, or ERP workflows.

When to use OCR vs text extraction

Use text extraction when:

PDFs are digitally generated (machine text selectable)
Quality is consistent
You want faster and cheaper processing

Use OCR when:

PDFs are scanned images
Mixed quality and skewed scans are common
You need robust parsing across messy inputs

Practical rule: default to text extraction, auto-fallback to OCR for low-quality or image-only files.

Conclusion

Regex-based invoice parsing does not scale well across vendors and layout changes.

A schema-first workflow gives you cleaner, more stable output and dramatically reduces custom parsing maintenance.

If you want to try it, start with the 0xPdf free tier and parse a few real invoices from your workflow:

https://0xpdf.io/pricing

Tags: python, pdf, api, tutorial

Building a Document Processing Pipeline with 0xPdf and Python

risha-max — Tue, 24 Feb 2026 22:27:01 +0000

Building a Document Processing Pipeline with 0xPdf and Python

Most document workflows start simple and become painful fast.

You parse a few PDFs by hand, maybe write a quick script, and everything seems fine -- until volume grows. New vendors appear, layouts change, and your extraction breaks in production. Suddenly you're spending more time fixing parsing logic than building product features.

In this guide, I'll show a practical, production-style pipeline for document processing with Python and 0xPdf:

Watch a folder for incoming PDFs
Parse files into structured JSON with 0xPdf
Store results in PostgreSQL
Send Slack notifications
Add retries and error handling
Scale to async processing for bigger workloads

This is the pattern I'd use for internal ops automation, AP/finance workflows, and document-heavy backend services.

Why automate document processing

If your team deals with invoices, forms, contracts, or reports, you probably face one or more of these issues:

Manual copy/paste into systems
Fragile regex-heavy parsers
OCR output that still needs custom post-processing
No visibility when parsing fails

Automation solves this by giving you:

Structured JSON output that downstream systems can use immediately
Faster throughput with fewer human errors
Reliable retries, logging, and monitoring hooks
A scalable path from "small script" to "production workflow"

Architecture overview

The pipeline flow is straightforward:

A PDF lands in an input folder (./inbox)
A file watcher detects the new file
The parser sends it to 0xPdf
Parsed output is written to PostgreSQL
Slack receives success/failure notifications
Retry logic handles transient API/network failures

Conceptually:

Incoming PDFs -> Watcher -> 0xPdf Parse -> PostgreSQL

-> Slack Notification

-> Retry / Error Handling

Setup

Create a virtual environment and install dependencies:

python -m venv .venv
source .venv/bin/activate
pip install requests watchdog sqlalchemy psycopg2-binary tenacity slack_sdk python-dotenv

Create your .env file:

OXPDF_API_KEY=your_api_key
OXPDF_BASE_URL=https://api.0xpdf.io/api/v1
DATABASE_URL=postgresql://user:pass@localhost:5432/documents
SLACK_BOT_TOKEN=xoxb-...
SLACK_CHANNEL_ID=C1234567890

Code walkthrough

1) File watcher (`watchdog`)

The watcher listens to a folder and triggers processing when a PDF appears.

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
from pathlib import Path
import time

INBOX_DIR = Path("./inbox")
INBOX_DIR.mkdir(exist_ok=True)

class PDFHandler(FileSystemEventHandler):
    def __init__(self, on_pdf):
        self.on_pdf = on_pdf

    def on_created(self, event):
        if event.is_directory:
            return
        path = Path(event.src_path)
        if path.suffix.lower() == ".pdf":
            # small delay if copy/write is still in progress
            time.sleep(0.5)
            self.on_pdf(path)

def start_watcher(on_pdf):
    observer = Observer()
    observer.schedule(PDFHandler(on_pdf), str(INBOX_DIR), recursive=False)
    observer.start()
    return observer

2) Parse with 0xPdf

Call the parse endpoint with your API key and a schema template.

import requests
import os

OXPDF_API_KEY = os.getenv("OXPDF_API_KEY")
OXPDF_BASE_URL = os.getenv("OXPDF_BASE_URL", "https://api.0xpdf.io/api/v1")

def parse_pdf(pdf_path: str, schema_template: str = "invoice") -> dict:
    url = f"{OXPDF_BASE_URL}/pdf/parse"
    headers = {"X-API-Key": OXPDF_API_KEY}
    params = {"schema_template": schema_template}

    with open(pdf_path, "rb") as f:
        files = {"file": (os.path.basename(pdf_path), f, "application/pdf")}
        response = requests.post(
            url,
            headers=headers,
            params=params,
            files=files,
            timeout=120
        )
        response.raise_for_status()
        return response.json()

3) Store results in PostgreSQL

Persist both successful output and failure metadata for observability.

from sqlalchemy import create_engine, Column, Integer, String, JSON, DateTime, func
from sqlalchemy.orm import declarative_base, sessionmaker
import os

DATABASE_URL = os.getenv("DATABASE_URL")
engine = create_engine(DATABASE_URL)
SessionLocal = sessionmaker(bind=engine)
Base = declarative_base()

class ParsedDocument(Base):
    __tablename__ = "parsed_documents"

    id = Column(Integer, primary_key=True)
    filename = Column(String, nullable=False)
    status = Column(String, nullable=False)  # success | failed
    schema_template = Column(String, nullable=False)
    payload = Column(JSON, nullable=True)
    error_message = Column(String, nullable=True)
    created_at = Column(DateTime(timezone=True), server_default=func.now())

Base.metadata.create_all(bind=engine)

def save_result(filename: str, schema_template: str, status: str, payload=None, error_message=None):
    db = SessionLocal()
    try:
        row = ParsedDocument(
            filename=filename,
            schema_template=schema_template,
            status=status,
            payload=payload,
            error_message=error_message
        )
        db.add(row)
        db.commit()
    finally:
        db.close()

4) Send Slack notification

Slack helps your team see pipeline health in real time.

from slack_sdk import WebClient
import os

slack = WebClient(token=os.getenv("SLACK_BOT_TOKEN"))
SLACK_CHANNEL_ID = os.getenv("SLACK_CHANNEL_ID")

def notify_slack(message: str):
    slack.chat_postMessage(channel=SLACK_CHANNEL_ID, text=message)

5) Handle errors and retries

Retries protect you from transient failures (network timeout, temporary upstream issues, etc.).

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=1, max=10),
    retry=retry_if_exception_type((requests.Timeout, requests.ConnectionError, requests.HTTPError))
)
def parse_with_retry(pdf_path: str, schema_template: str = "invoice") -> dict:
    return parse_pdf(pdf_path, schema_template)

End-to-end processing function

Tie everything together in one worker function:

def process_pdf(path):
    filename = path.name
    schema_template = "invoice"

    try:
        result = parse_with_retry(str(path), schema_template=schema_template)
        save_result(filename, schema_template, "success", payload=result)
        notify_slack(f"Parsed `{filename}` successfully")
    except Exception as e:
        save_result(filename, schema_template, "failed", error_message=str(e))
        notify_slack(f"Failed parsing `{filename}`: {e}")

And run the watcher:

if __name__ == "__main__":
    observer = start_watcher(process_pdf)
    print("Watching ./inbox for new PDFs...")
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
        observer.join()

Drop a PDF into ./inbox, and it processes automatically.

Scaling with async mode (large batches)

For larger workloads, move from direct synchronous processing to an async job pipeline:

Queue jobs with Celery/RQ/worker processes
Process many PDFs in parallel
Use async/polling workflow where appropriate
Batch writes to reduce DB overhead
Send summary notifications instead of one Slack message per file

Recommended production upgrades:

Idempotency keys (avoid duplicate processing)
Dead-letter queue for repeated failures
Structured logging and alerting
Backpressure controls + rate limiting

Final thoughts

A strong document pipeline is not just OCR -- it's reliability, recoverability, and clean structured output.

0xPdf helps by turning PDFs into structured JSON directly, so you can focus on building business workflows instead of writing brittle extraction logic for every new layout.

If you want, I can publish a full GitHub repo version of this exact pipeline (Docker Compose, migrations, and a ready-to-run starter).

Tags: python automation pdf api postgresql backend

DEV Community: risha-max

Extract Tables from PDFs Without Tabula -- A Simpler Approach

The table extraction problem

Why Tabula and Camelot break on complex layouts

Schema-driven table extraction

Tutorial: define a table schema and parse a bank statement

1) Install dependencies

2) Define a schema for statement transactions

3) Parse a sample statement

4) Access table rows (transactions)

Handling multi-page tables

Comparison with traditional tools

Traditional coordinate/grid extraction

Schema-driven extraction

Final thoughts

OCR vs Layout Parsing: When to Use What for PDF Data Extraction

Text-based PDFs vs scanned/image PDFs

Text-based PDFs

Scanned/image PDFs

When text extraction is enough (and faster)

When you need OCR

How 0xPdf handles both automatically

Performance comparison: with OCR vs without

Cost implications

Practical decision framework

Final thoughts

# How to Parse Invoices into JSON with Python (No Regex)

The problem: why invoice PDF parsing is hard

Traditional approaches (and where they break)

pdfplumber (or similar text extractors)

AWS Textract / raw OCR APIs

The schema-first approach with 0xPdf

Step-by-step Python tutorial

1) Install the SDK

2) Define an invoice schema

3) Parse a sample invoice

4) Handle the JSON response

Results comparison: Textract-style raw output vs 0xPdf structured output

Typical raw OCR output (simplified)

0xPdf schema-first output

When to use OCR vs text extraction

Conclusion

Building a Document Processing Pipeline with 0xPdf and Python

Building a Document Processing Pipeline with 0xPdf and Python

Why automate document processing

Architecture overview

Setup

Code walkthrough

1) File watcher (watchdog)

2) Parse with 0xPdf

3) Store results in PostgreSQL

4) Send Slack notification

5) Handle errors and retries

End-to-end processing function

Scaling with async mode (large batches)

Final thoughts

`pdfplumber` (or similar text extractors)

1) File watcher (`watchdog`)