Batch convert PDFs to CSV on Mac (2026 workflow)

You have a folder of PDFs. Twelve monthly statements, forty vendor invoices, a quarter of expense receipts — or all three, piled up because the one-at-a-time workflow never survives contact with a real month-end.

Converting one PDF to CSV is a solved problem. Doing it across a folder, in a way that leaves you with one spreadsheet rather than forty individual CSVs you then have to merge, is where most tools fall apart. The free web converters hit a rate limit at file three. The Python scripts you wrote last year break on the one invoice that used a different template. The AppleScript from 2015 predates every OCR engine worth using.

This guide walks through the workflow that actually works in 2026: batch convert PDFs to CSV on Mac — files read on-device, never uploaded — one prompt, one single consolidated output.

Why batch is harder than “just loop over files”

The naïve plan is: take your one-file solution and loop. This fails for three reasons that show up within the first real batch:

1. Heterogeneous templates. The twelve monthly statements might be from two banks that changed their PDF format mid-year. The forty invoices are from forty vendors. A prompt tuned to one layout produces junk on another. You need an extraction approach that generalizes, not one that memorizes coordinates.
2. No provenance. If you loop and concatenate, the output is one giant CSV where every row looks the same and you have no way to trace a suspicious number back to its source PDF. Three months later, when a bookkeeper asks “where did $3,412.50 come from?”, you re-process everything. Traceability has to be designed in — either your loop injects the filename into each row, or the extraction itself pulls an identifying field (vendor name, account number, statement period) out of every document.
3. Partial failure. One PDF in forty is corrupted, password-protected, or a 200MB scan that blows the model’s context window. A dumb loop either dies on that file or silently skips it — and you need to notice, fix the offending file, and run again.

A real batch workflow solves all three. The rest of this post is the Mac-native version.

Method 1: ignitai on Mac (the no-upload way)

ignitai is designed for this. The whole pitch is that extraction is a language task — you describe what you want, the model finds it across every file in the batch, and the output is one spreadsheet. The full flow, end to end:

1. Select the files (⌘A in the folder) and drag them into ignitai. Everything queues as a single batch. Scanned and born-digital PDFs mix fine in one batch; image files (JPEG, HEIC, PNG) run as their own batch — add them via the Photos picker or convert them to PDF first.
2. Describe what to extract, once. Plain English, for the whole batch. Examples that work well:
   • “For each transaction, return date, description, amount (negative for debits), and running balance. Skip account summaries and marketing pages.”
   • “For each line item, return invoice number, vendor name, description, quantity, unit price, and line total.”
   • “For each receipt, return date, merchant, category, amount, and tax. If the category isn’t printed, infer from the merchant name.”
3. Pick CSV. Or XLSX if the destination is Excel. CSV is the right choice if you’re piping into QuickBooks, Xero, or a custom ledger.
4. Hit Convert. ignitai reads each PDF on-device and sends only the recognized text to its private hosted pipeline, building one consolidated output with live progress (pages read, parts uploaded). A 40-file invoice batch typically takes a few minutes.
5. Review the consolidated output. One CSV, one row per record across every PDF. If you need to trace rows back to their documents, put an identifying field in the prompt — vendor name, account number, statement period — so the extractor pulls it from each document’s own text, and you can filter by it to sanity-check any one vendor’s rows without reopening the PDF.
6. Export — and if the batch trips, fix and re-run. If a file fails (corrupted, empty, password-protected), fix it — rotate a scan, unlock a password — and run the batch again.

The PDF files themselves never leave your Mac — each one is read on-device, and only the recognized text goes to ignitai’s private pipeline to build the CSV. For a bookkeeper or finance operator who runs this weekly, the time savings are the kind that change what’s possible — a weekend of statement reconciliation becomes a coffee.

Method 2: Automator + Folder Actions (the macOS-native DIY)

If you want to build it yourself, macOS gives you most of the pieces:

1. Use Automator to create a Folder Action: watch an /inbox/ folder, and when a PDF lands, run a Shell Script.
2. The shell script calls pdftotext -layout "$1" - (requires brew install poppler), pipes the output to a Python or Node script you wrote, and appends the parsed rows to a master CSV in an /out/ folder.
3. Source-file provenance is your responsibility — prepend the filename to each row before writing.
4. Failures: you’ll want to || echo "$1" >> failures.log in the shell script so you can re-process later.

This is a valid path if you have hundreds of identically-structured PDFs — say, monthly statements from one bank, where the template is stable — and you want zero ongoing cost. It’s the wrong path if:

• Your PDFs vary in structure (multiple vendors, multiple formats).
• Any of them are scans. pdftotext can’t OCR; you’d need to swap in Tesseract and the accuracy drops sharply on real-world invoice fonts.
• You don’t enjoy maintaining parsing scripts when a vendor changes their billing software.

For most solo operators, the time to build and maintain this pipeline exceeds the cost of an app that just does it.

Method 3: Python / CLI loop (for developers with uniform inputs)

If you’re comfortable in Python and your batch is genuinely uniform:

brew install poppler
pip install pdfplumber pandas

Then a script that opens each PDF with pdfplumber, extracts tables with page.extract_tables(), concatenates into a pandas DataFrame with a source_file column, and writes one CSV:

import pdfplumber, pandas as pd
from pathlib import Path

rows = []
for pdf_path in Path("./inbox").glob("*.pdf"):
    with pdfplumber.open(pdf_path) as pdf:
        for i, page in enumerate(pdf.pages):
            for table in page.extract_tables():
                for row in table:
                    rows.append([*row, pdf_path.name, i + 1])

df = pd.DataFrame(rows, columns=[..., "source_file", "source_page"])
df.to_csv("out.csv", index=False)

This is fine for clean text-based PDFs with identical table structures. It breaks on:

• Scans — pdfplumber sees no text. You’d layer in pytesseract and your accuracy drops.
• Variable layouts — extract_tables() infers grids from lines. A different vendor with a different border style returns a different shape.
• Multi-line cells — pdfplumber splits them, and you need custom logic to re-join.

For a stable monthly-statement feed, it’s a one-time cost. For a real-world bookkeeping batch, you’ll spend more time fixing edge cases than processing invoices.

Method 4: Web batch endpoints (and the tradeoffs)

Paid tiers of Smallpdf, iLovePDF, and similar offer batch endpoints. The flow is: upload ZIP, wait, download ZIP. They work, with the same caveats the one-file versions have, amplified:

• You’re uploading the whole folder. For bank statements, vendor invoices, or anything with financial detail, this is a much bigger surface than uploading one file.
• Per-file cost scales linearly. Most paid tiers cap at 500–1000 files/month; past that, enterprise tiers kick in.
• Invoice-aware extraction is rare. The generic “convert PDF to Excel” endpoint isn’t parsing your invoice as an invoice; it’s looking for table grids. Expect the same header-metadata loss as in the one-file version.

For public document batches — research corpora, open-data dumps — they’re fine. For your operational data, a tool that reads the files on your Mac instead of collecting them on a server is the better trade.

Prompt design for heterogeneous batches

The single highest-leverage step in a real batch is writing a prompt that generalizes. Principles that work:

1. Describe the fields, not the layout. “Return date, description, amount” generalizes. “Return the value in the third column” doesn’t.
2. Be explicit about sign conventions. “Debits are negative, credits are positive” removes an entire class of silent errors that will show up as a reconciliation mismatch later.
3. Give the model permission to infer. “If the category isn’t printed, infer it from the merchant name” produces a usable category column when some receipts have one and some don’t. Without it, half your rows have blanks.
4. Keep the output one flat table. The batch produces a single table, so decide the row grain up front — one row per line item, or one row per invoice — and repeat document-level fields (invoice number, vendor, grand total) on each row. If you genuinely need both grains, run the batch twice with two prompts and get two files.
5. State what to skip. “Skip cover pages, terms-and-conditions pages, and marketing inserts” saves you from hundreds of junk rows.

A prompt that nails these five across a heterogeneous 40-file batch is worth more than a faster model. ignitai keeps it in Previous Prompts; reuse it next month.

Provenance: design the audit trail in

Whatever batch approach you use, every output row should be traceable to the document it came from.

Three reasons this is non-negotiable:

• Audit. Three months later, a number looks wrong. With a traceable row, you open one PDF. Without it, you open forty.
• Partial re-run. One vendor changes their template and corrupts a hundred rows in your next batch. With traceable rows, you filter those out and re-process just that vendor’s files. Without it, you re-process everything.
• Review speed. When your accountant asks “what’s this $3,412 entry?”, the answer should take 20 seconds, not 20 minutes of PDF-digging.

How you get it differs by method. In a DIY script, inject the filename into each row as you loop. In ignitai, filenames never leave your Mac — so ask the prompt for an identifying field that’s printed in the document itself (vendor name, invoice number, account last four, statement period), or run files one at a time when you need a strict per-file audit trail. Either way, don’t skip the step.

When batch breaks

Honest edge cases for any batch pipeline:

• Password-protected PDFs. Strip the password first (Preview → Export → uncheck “Encrypt”). Batching over encrypted files fails silently or loudly depending on the tool; either way, not what you want.
• Massive scans. A 200-page 400-DPI scan of an old archive can blow past even a large model’s context. Split into chapters with Preview’s page-extract tool before batching.
• Mixed languages in one batch. Either run two batches with language-specific prompts, or add “preserve original-language descriptions” explicitly. Inconsistent handling across a batch is worse than either pure choice.
• One file that’s actually not a PDF. A .heic that got renamed .pdf, a .docx that’s in the folder by mistake. ignitai’s picker and drop target only accept PDFs, so the stray simply won’t import; a shell loop dies on it. Worth checking the folder before hitting Convert.

Bottom line

For a folder of PDFs that needs to end up as one CSV on Mac: install ignitai, select the PDFs and drag them in, write the prompt once, pick CSV, hit Convert. For stable monthly batches over hundreds of identically-formatted PDFs, a pdftotext-plus-Python pipeline is a valid alternative if you want the full DIY path and don’t mind maintaining it. For anything with scans, mixed vendors, or documents you’d rather not upload, the native path — files read on-device, never uploaded — is the shortest distance from folder to spreadsheet.

When the destination is Excel rather than CSV, the batch PDF-to-Excel walkthrough on Mac is the same flow with a different output pick. The single-file Mac workflow is covered in the Mac PDF-to-CSV guide; the iPad-native equivalent for invoices is the iPad invoice walkthrough; the iPhone version for bank statements is here. The app is the same across all three — the Mac is the batch engine and the mobile devices are the capture surfaces.

Get ignitai on the App Store — free download, $19.99/mo unlocks unlimited batch extractions after the 3-day trial.

FAQ

How many PDFs can I batch convert to CSV at once on a Mac?

Select the whole batch — dozens of files in one drag — apply one plain-English prompt, and ignitai writes a single consolidated CSV with one row per record. If a file trips the batch (password-protected, corrupt), unlock or fix it and run the batch again.

Do the PDFs get uploaded during a batch conversion?

No. Each PDF is read on-device on every supported macOS version (14.4 and later) — only the text recognized on the Mac is sent to ignitai’s private hosted pipeline to build the CSV. On macOS 26, Apple’s newest on-device document recognition sharpens table extraction further.

How much does batch PDF to CSV conversion cost on Mac?

ignitai is a free download and your first conversion is free. Unlimited conversions and batch mode are $19.99/month after a 3-day free trial — cancel anytime.