Python PDF Table Extraction: pdfplumber vs Camelot vs Tabula

Extracting structured line item data from PDF invoices is a different problem than extracting text. You need a library that can detect tabular structure within the PDF's native text layer, map columns to headers, and return clean rows you can feed into a database or ERP system. Three Python libraries dominate this space: pdfplumber, Camelot, and tabula-py. Each takes a fundamentally different approach to finding and parsing tables, and the right choice depends entirely on the invoice formats hitting your pipeline.

Here is how they compare at a high level. pdfplumber gives you pixel-level control over table detection with built-in visual debugging, making it the strongest option for complex invoice layouts where column boundaries are ambiguous or inconsistent. Camelot uses lattice and stream detection modes that excel at well-structured tables with clear cell borders but struggles with the borderless aesthetic layouts common in modern invoices. tabula-py wraps Java's Tabula engine for fast extraction with minimal code, though it requires a JRE dependency and offers less granular control when edge cases surface. The consistent finding across all three: for production pipelines processing invoices from varied vendors, every library demands significant per-format tuning.

Most Python PDF table extraction tutorials test against clean, predictable documents like employee directories or academic paper tables. Invoice PDFs are structurally harder. They introduce patterns that generic benchmarks miss entirely:

Variable column counts across vendors. One supplier includes a discount column; another splits tax into state and federal. Your extraction logic has to handle both without manual reconfiguration.
Subtotal, tax, and total rows that break table structure. These summary rows span multiple columns or use different alignment, causing libraries to merge them into line item data or drop them entirely.
Borderless aesthetic layouts. Design-forward invoices rely on spacing and alignment rather than ruled lines, which defeats lattice-based detection methods.
Multi-page continuation tables. A single purchase order can span three pages, and the library needs to stitch those tables together without duplicating headers or losing rows at page breaks.

This comparison tests each library against these real invoice patterns rather than synthetic benchmarks.

One critical scope boundary: pdfplumber, Camelot, and tabula-py all operate on native text-based PDFs where the text layer is already embedded. Scanned invoice images require OCR preprocessing, a fundamentally different toolchain involving Tesseract or cloud vision APIs before any table detection can begin. The toolchain choice also shifts when the script itself is non-Latin or right-to-left — see our comparison of Python OCR libraries for Arabic invoice tables for how RTL layouts and Arabic numerals change the calculus. This article focuses exclusively on native PDF table extraction. If you need a broader view of the Python extraction landscape that covers OCR-based workflows alongside programmatic parsing, see our broader guide to extracting invoice data with Python.

Fortune Business Insights reports that the global intelligent document processing market was valued at USD 10.57 billion in 2025 and is projected to reach USD 91.02 billion by 2034; it also expects finance and accounting to account for 45.57% of the market in 2026. Your choice of Python library for invoice table extraction shapes the rest of the pipeline.

Quick Decision Summary

	pdfplumber	Camelot	tabula-py	Managed API
Borderless invoices	Manual coordinate tuning	Stream mode, less reliable	Stream mode, less reliable	Handled natively
Multi-page tables	Manual page stitching	Manual page stitching	`pages="all"`, then merge	Automatic
Debugging tools	Visual rendering	Accuracy score only	Limited	Not rule-based
Dependencies	pip only	Ghostscript	JRE	pip only SDK
Multi-vendor scale	Config per vendor	Config per vendor	Config per vendor	Single prompt
Best fit	Complex layouts, stable vendors	Bordered tables, standard formats	Quick extraction, JRE OK	Diverse vendors at scale

pdfplumber: Pixel-Level Control for Complex Invoice Layouts

pdfplumber works from the PDF's character positions and line geometry rather than treating extraction as a black-box table guess. It parses the PDF's underlying layout data — every character's position and every line segment's coordinates — then uses coordinate geometry to identify table boundaries. Instead of guessing where tables might be, you define precisely which regions of a page contain tabular data and how cell boundaries should be detected.

This gives you pixel-level control over extraction. You can specify exact vertical and horizontal line positions, adjust snap tolerances for slightly misaligned rules, and target specific page regions while ignoring headers, footers, and totals blocks. For invoice extraction, that precision matters: invoice tables sit alongside addresses, logos, payment terms, and tax summaries, and you need the parser to isolate the line item table cleanly.

Extracting Invoice Line Items with pdfplumber

Here's a practical example that extracts a line item table from an invoice PDF. The table settings are tuned for a typical invoice structure with description, quantity, unit price, and total columns:

import pdfplumber

def extract_invoice_line_items(pdf_path):
    with pdfplumber.open(pdf_path) as pdf:
        page = pdf.pages[0]

        table_settings = {
            "vertical_strategy": "lines",
            "horizontal_strategy": "lines",
            "snap_tolerance": 4,
            "intersection_x_tolerance": 8,
            "intersection_y_tolerance": 8,
            "min_words_vertical": 2,
        }

        table = page.extract_table(table_settings)

        if not table:
            return []

        headers = [
            cell.strip().lower() if cell else ""
            for cell in table[0]
        ]
        line_items = []

        for row in table[1:]:
            if not any(row):
                continue
            item = dict(zip(headers, [
                cell.strip() if cell else "" for cell in row
            ]))
            line_items.append(item)

        return line_items


items = extract_invoice_line_items("vendor_invoice.pdf")
for item in items:
    print(item)
# {'description': 'Consulting Services - March',
#  'quantity': '40', 'unit price': '150.00', 'total': '6,000.00'}
# {'description': 'Expense Reimbursement - Travel',
#  'quantity': '1', 'unit price': '842.50', 'total': '842.50'}

The snap_tolerance and intersection_tolerance parameters are doing the real work here. Invoice PDFs generated from different tools produce table lines that don't always align to the exact same coordinates. A snap tolerance of 4 pixels lets pdfplumber treat nearly-aligned lines as the same boundary, which prevents phantom columns or split cells.

For invoices where the table region shares the page with dense surrounding content, you can crop to a bounding box first:

# Target only the line items region of the page
cropped = page.within_bbox((30, 280, 580, 520))
table = cropped.extract_table(table_settings)

Visual Debugging for Invoice Formats

One of pdfplumber's strongest features for invoice work is its visual debugging. You can render the page with detected table boundaries, cell divisions, and character positions overlaid directly onto the page image:

with pdfplumber.open("vendor_invoice.pdf") as pdf:
    page = pdf.pages[0]
    im = page.to_image(resolution=150)
    im.debug_tablefinder(table_settings)
    im.save("debug_output.png")

This produces an annotated image showing exactly which lines pdfplumber detected, where it placed cell boundaries, and which regions it classified as table content. When a vendor's invoice extracts incorrectly—a merged header cell splitting into two columns, or a description field wrapping across rows—the debug image tells you why in seconds. You can then adjust explicit_vertical_lines or explicit_horizontal_lines in your table settings to force correct boundaries for that format.

Where pdfplumber Is the Strongest Choice

pdfplumber excels in scenarios where invoice layouts defy standard grid assumptions. Invoices with merged header cells (a single "Amount" header spanning "Unit Price" and "Tax" subcolumns), variable-height description rows that wrap across multiple lines, or tables without visible borders that rely on whitespace alignment—these are cases where pdfplumber's fine-tuning parameters let you build an extraction config that handles the format reliably.

If you're processing invoices from a known, stable set of vendors, pdfplumber is a strong fit. You invest time upfront to tune table_settings per vendor format, and the result is precise, repeatable extraction. Teams that maintain per-vendor configurations for a stable supplier base tend to find pdfplumber delivers the highest accuracy of the three libraries.

The Vendor Diversity Problem

The same configurability that makes pdfplumber accurate on known formats becomes a liability as vendor count grows. The table settings that extract line items perfectly from Vendor A's invoice will misparse Vendor B's layout. Each new vendor format requires its own tuned configuration: adjusted tolerances, different line detection strategies, sometimes explicit coordinate overrides.

With a small, stable vendor base, this is manageable. But invoice pipelines that regularly onboard new suppliers—or receive invoices from hundreds of vendors—hit a maintenance wall. Every format change, every new vendor, means another round of visual debugging and parameter tuning. The extraction logic itself works; the operational cost of keeping configurations current across a growing vendor portfolio is what eventually pushes teams toward alternatives.

Camelot: Lattice and Stream Modes for Invoice Tables

Camelot approaches table detection differently from pdfplumber by offering two distinct extraction modes, each built for a different kind of PDF structure. Choosing the right mode is the single biggest factor in whether Camelot produces usable output from your invoices.

Lattice mode detects tables by tracing the actual drawn lines in a PDF — cell borders, row separators, and column dividers that exist as vector objects in the document. When an invoice has a fully bordered table with visible gridlines, lattice mode identifies cell boundaries with high precision because it's working with explicit structural data rather than guessing.

Stream mode takes the opposite approach. It infers table structure from whitespace gaps and text alignment patterns when no visible borders exist. Stream mode scans for consistent spacing between text elements and groups them into columns and rows based on their spatial positions on the page.

This distinction matters for invoice processing because it maps directly to the two most common invoice designs you'll encounter in production.

Extracting an Invoice Table with Camelot

A basic Camelot extraction in lattice mode looks like this:

import camelot

# Extract tables using lattice mode (default)
tables = camelot.read_pdf("invoice.pdf", flavor="lattice", pages="1")

if tables:
    # Access the first detected table as a DataFrame
    invoice_table = tables[0].df
    print(invoice_table)

    # Check the parsing accuracy report
    print(tables[0].parsing_report)
    # {'accuracy': 97.85, 'whitespace': 12.3, 'order': 1, 'page': 1}

The parsing_report property returns an accuracy score that reflects how cleanly Camelot could map the detected lines to a table grid. For invoices with well-defined borders, you'll typically see accuracy scores above 90%, and the resulting DataFrame will have correctly aligned columns for item descriptions, quantities, unit prices, and totals.

The Stream Mode Problem with Borderless Invoices

Here's where Camelot's dual-mode design creates a practical challenge for invoice pipelines. Many professionally designed invoices — particularly from SaaS platforms, design agencies, and modern accounting tools — use minimal or no visible table borders. They rely on spacing, shading, and typography to visually separate line items rather than drawn gridlines.

These borderless invoices force you into stream mode:

tables = camelot.read_pdf("borderless_invoice.pdf", flavor="stream", pages="1")

Stream mode's whitespace-based detection is significantly less reliable than lattice for real invoice data. The core issue: invoice layouts frequently use variable spacing between columns. A short item description leaves a wide gap before the quantity column, while a long description compresses that gap. Stream mode interprets these inconsistencies as column boundaries shifting, which causes it to misalign columns or merge adjacent fields into a single cell.

Accuracy scores for stream-mode extractions on borderless invoices can drop into the 50–70% range. At that level, you need programmatic validation on every extracted table before the data enters your pipeline:

for table in tables:
    report = table.parsing_report
    if report["accuracy"] < 80:
        # Flag for manual review or fallback extraction
        log_low_confidence_extraction(table, report)

Deployment and Multi-Page Constraints

Two practical constraints affect Camelot in production environments. First, Camelot depends on Ghostscript as a system-level dependency — it's not bundled in the pip install. In containerized deployments, you need to add Ghostscript to your Docker image or system packages, which increases image size and adds a dependency that lives outside your Python dependency management.

Second, Camelot processes one page at a time. Multi-page invoice tables — common with purchase orders containing dozens of line items — require you to detect where a table continues from one page to the next and stitch the resulting DataFrames together manually. There's no built-in continuation detection, so your code needs to handle matching column structures across pages and removing repeated header rows that many invoices print on each page.

tabula-py: Java-Backed Extraction and the JRE Trade-Off

tabula-py is not a native Python extraction engine. It is a Python wrapper around Tabula, a Java library, and that distinction shapes every deployment decision you will make with it. When you call tabula-py's extraction functions, Python spawns a JVM subprocess that does the actual PDF parsing. The structured data flows back into your Python process as a pandas DataFrame. This architecture means every machine in your pipeline, from your laptop to your production server, needs a Java Runtime Environment installed alongside Python.

Here is a basic extraction using tabula-py against an invoice PDF:

import tabula

# Lattice mode for invoices with visible cell borders
dfs = tabula.read_pdf(
    "invoice_009.pdf",
    pages="1",
    lattice=True,
    pandas_options={"header": 0}
)

invoice_table = dfs[0]
print(invoice_table)

Item Code	Description	Qty	Unit Price	Amount
WDG-441	Steel bracket	200	3.25	650.00
WDG-442	Mounting plate	100	7.80	780.00
WDG-443	Hex bolt M8x40	500	0.45	225.00

Switching to stream=True instead of lattice=True targets invoices that lack visible borders and rely on whitespace alignment. The API surface is minimal, which is either an advantage or a limitation depending on how much control you need.

The JRE dependency in practice

On a developer's local machine, installing Java is a non-issue. The friction shows up in production. A slim Python Docker image becomes materially larger once a JRE is included, and that extra runtime can affect build times, cold starts, package-size limits, and patch management. Your Dockerfile now manages two language runtimes, and you are tracking security updates for both.

Where tabula-py earns its place

For well-bordered invoice tables with consistent grid layouts, tabula-py is fast and requires almost no configuration. If your invoices come from a single vendor or ERP system with a standardized template, calling read_pdf() with lattice=True may be all you need. The library gets you from PDF to DataFrame in the fewest lines of code of any option in this comparison.

tabula-py also benefits from the broader Tabula ecosystem. Teams already familiar with the Tabula desktop application can transfer that knowledge directly, and there is substantial community documentation around Tabula's extraction behavior.

Where it falls short on invoices

tabula-py offers less fine-grained control than pdfplumber over table detection. When extraction produces garbage data or merged columns, the error output gives you little to diagnose the cause. Debugging becomes trial and error: adjusting area coordinates, toggling between lattice and stream, re-running until the output looks right. Where pdfplumber offers visual rendering of detected lines and characters to pinpoint exactly why extraction failed, tabula-py has no equivalent.

Invoice Patterns That Break Open-Source Table Extraction

Library demos look clean because the inputs are clean. Production invoices from varied vendors break in predictable ways:

Failure mode	What happens	Practical mitigation
Subtotal and tax rows	Summary rows span different columns, so values shift into the wrong fields.	Detect subtotal, tax, shipping, and total rows by label and separate them from line items before normalization.
Multi-page tables	pdfplumber and Camelot process each page independently; tabula-py still returns page-level DataFrames.	Stitch pages by matching column structure, then strip repeated headers or infer headers from page one.
Borderless tables	Stream and whitespace-based modes misalign columns when descriptions wrap or spacing varies.	Use pdfplumber coordinates for stable formats; expect per-template tuning for diverse vendors.
Scanned PDFs	These libraries require an embedded text layer and return nothing for image-only PDFs.	Classify documents first, then route scans through OCR preprocessing before table extraction.
Per-vendor variation	Coordinates, column order, labels, and summary rows change from vendor to vendor.	Treat each vendor config as maintained code, then normalize outputs into a consistent schema such as structured invoice JSON.

The practical ceiling of open-source table extraction is not any single library's parsing accuracy. It is the engineering effort required to handle the full diversity of real invoices at scale.

When a Managed Extraction API Replaces the Library Approach

The previous sections expose a pattern: each library requires per-vendor tuning, and that tuning breaks when invoice formats change. At some point, the engineering cost of maintaining extraction rules exceeds the cost of letting someone else solve the problem.

Four thresholds signal it's time to switch:

Vendor format diversity. Your pipeline processes invoices from more than a handful of vendors, each with different table structures, column orders, and labeling conventions. Every new vendor means a new configuration pass through pdfplumber, Camelot, or tabula-py.
Mixed document types. The incoming document mix includes both native text-based PDFs and scanned PDFs or images. You're maintaining separate OCR pipelines alongside your table extraction logic, with classification code to route documents to the right path.
Multi-page complexity. Table stitching across page breaks and subtotal row separation require significant custom code for each vendor format. The heuristics you built for one vendor's three-page invoice fail on another vendor's five-page layout.
Format drift. Vendors update their invoice templates without warning. Your extraction rules break silently, producing incomplete data that surfaces only when someone notices missing line items downstream.

Practical implementation with the Python SDK

Instead of the rule-based parsing that open-source libraries rely on, AI-based extraction analyzes the document's visual and textual structure together, identifying fields and table rows without format-specific rules. The Invoice Data Extraction API provides a Python SDK built on this approach:

pip install invoicedataextraction-sdk

The call pattern stays compact:

import os
from invoicedataextraction import InvoiceDataExtraction

client = InvoiceDataExtraction(
    api_key=os.environ.get("INVOICE_DATA_EXTRACTION_API_KEY")
)

result = client.extract(
    folder_path="./invoices",
    prompt="Extract invoice number, vendor, date, and line items.",
    output_structure="per_invoice",
    download={"formats": ["xlsx", "json"]}
)

The SDK handles upload, extraction, and result download in that single client.extract() call. Output is available as XLSX, CSV, or JSON; for downstream schema planning, see what a line item extraction API should return. Both native text PDFs and scanned images are processed natively, so you can drop document classification, OCR preprocessing, and per-vendor table rules.

The cost trade-off, honestly

The API uses credit-based pricing: one credit per successfully processed page, with credits only consumed on successful extractions. A permanent free tier covers 50 pages per month with full functionality, no credit card required.

For production volumes, this is a recurring per-page cost. Open-source libraries are free to run but carry ongoing maintenance costs: developer time spent building per-vendor configurations, debugging edge cases, handling format changes, and maintaining OCR infrastructure for scanned documents. The trade-off favors a managed API when vendor format diversity makes the cumulative maintenance hours more expensive than the per-page processing cost. For a team processing invoices from three consistent vendors, the math may favor open-source. For a team handling invoices from dozens of vendors with mixed document types, the maintenance cost compounds quickly.

If every Python table-extraction library still needs a new configuration pass for each vendor, the library is no longer the bottleneck worth optimizing.