Batch Convert PDFs to Excel on Mac (one pass, one workbook)

The folder on your Mac has forty PDFs in it, and the deliverable is one Excel file. Twelve months of bank statements that need to become a single transaction sheet. A quarter of vendor invoices that need to become a line-item workbook the accountant can pivot. Sixty expense receipts that need to become the reimbursement sheet, subtotaled by month. Converting one PDF to Excel is a solved problem; what nobody hands you is the folder-shaped version — and the naïve answer, converting them one at a time and pasting the results together, dies somewhere around file six, every time, with formatting drift and a column that stopped lining up.

This guide is how to batch convert PDF to Excel on Mac in 2026: point an AI extractor at the whole folder, describe the rows you want once in plain English, and get back a single .xlsx — typed columns, one row per record, and a source_file column tying every row back to its PDF. On an Apple silicon Mac running macOS 26, the entire batch is processed on-device; the statements never leave the machine.

Why batch-to-Excel is harder than a loop

The obvious plan — take any single-file converter and run it forty times — produces forty Excel files, which is not the deliverable. Merging them by hand surfaces the three problems every real batch has:

The PDFs don’t match. Forty invoices from forty vendors, or statements from a bank that changed its layout in March. A converter that guesses table boundaries from one layout produces junk on the next. The extraction has to generalize across formats, not memorize one.
Merged rows lose their origin. Paste forty sheets together and every row looks the same. When a number looks wrong in month three — and one will — there is no way back to the source document except opening PDFs until you find it. Every row needs source_file (and ideally source_page) stamped on automatically.
One file always fails. A password-protected statement, a corrupted download, a .docx renamed .pdf. A dumb loop either halts or silently skips it, and silent is worse: the sheet looks complete and isn’t. A real batch reports which files failed and why, and re-runs just those.

The CSV version of this workflow covers the DIY routes — Automator folder actions, a pdfplumber loop — and when they’re worth building. The short version: they suit hundreds of identically formatted text PDFs and break on everything else, scans especially. This post is the Excel-shaped path, because Excel output changes what the batch can deliver.

Why Excel output, specifically

CSV is the right target when the destination is another system — QuickBooks, Xero, a database import. When the destination is a person — you, your accountant, the controller who asked for “one file with everything” — .xlsx carries structure a CSV can’t:

Typed columns. Dates arrive as dates, amounts as numbers with currency formatting. =SUM() works immediately; nothing needs Text-to-Columns first. A CSV of European-formatted amounts opened carelessly in Excel is a classic silent corruption; a typed .xlsx never goes through that door.
Multiple sheets in one file. Invoice batches have two natural tables: line items (one row per item) and invoice metadata (one row per invoice — number, vendor, dates, grand total). In Excel, those are two sheets of one workbook that a VLOOKUP joins. In CSV, they’re two files someone has to keep together.
Pivot-ready. The point of consolidating forty documents is usually a question: spend by vendor, expenses by category, cash flow by month. One typed sheet with clean headers is thirty seconds from a pivot table that answers it.

If your batch ends in an import pipeline, use the CSV workflow. If it ends in front of a human, keep reading.

The workflow: folder in, workbook out

ignitai treats a batch as one job with one description. The full Mac flow:

Drag the folder into ignitai. Or a multi-selection of files, or several folders — the queue flattens them into one batch, up to 500 PDFs in a pass on an M-series Mac. Mixed inputs are fine: born-digital PDFs, scans, even photos of paper ride the same queue, each routed through the right pipeline automatically. (If a chunk of your batch is scanned paper, the scanned-PDF guide covers what quality matters and what doesn’t.)
Describe the rows you want, once. Plain English, applied to every file in the batch:

“For each transaction: date, description, amount — negative for debits. One row per transaction. Skip summary boxes and marketing pages.”

“For each invoice line item: description, quantity, unit price, line total. On a second sheet, one row per invoice: invoice number, vendor, issue date, due date, grand total.”

Describe fields, not layouts — “return date, description, amount” generalizes across forty vendors; “take the third column” doesn’t. State sign conventions explicitly, and say what to skip. A prompt that nails this is reusable: save it as a preset and next month’s folder is a drag and a click.
Pick Excel (.xlsx) and note the second-sheet option. This is the fork where Excel output earns its keep: ask for line items and header metadata as separate sheets and you get a workbook, not a flat file. Column types are set during extraction — dates as dates, amounts as numbers.
Click Extract and watch the per-file status. On an Apple silicon Mac running macOS 26, the batch runs on-device — relevant precisely because batch jobs are the sensitive ones: a year of statements, a quarter of payroll, the whole vendor ledger in one folder. A 40-file batch typically finishes in a few minutes, results streaming into the consolidated workbook as files complete.
Re-run the failures, not the folder. Files that fail — encrypted, corrupted, unreadable — are listed with reasons. Fix them (Preview → File → Export, uncheck encryption, is the usual move for password-protected statements) and re-run just those; the rows append to the same workbook.
Verify one number per source. Filter the sheet by source_file, pick one document, and make the workbook reproduce a number printed on it: =SUMIF(source_file, "march.pdf", amount) against March’s printed closing balance. One tie-out per file class — one statement, one invoice, one receipt — is the difference between a spreadsheet you trust and one you hope about.

The provenance column, again, because it saves the quarter

Whatever tool runs your batch, the non-negotiable output feature is source_file on every row. Three months after the batch, someone asks where $3,412.50 came from. With provenance, that’s a filter and one PDF; without it, it’s an afternoon of re-opening forty documents — or re-running the whole batch. Provenance also makes partial re-runs possible: when one vendor’s template change corrupts their rows, you filter those out, re-process one vendor, and append. ignitai stamps source_file and source_page automatically; if you build your own pipeline, budget for the step.

What a real month-end batch looks like

A concrete composite, because “forty PDFs” hides the mess: the folder is eleven digital bank statements plus one that’s a scan (February — the download failed, someone printed and re-scanned it), twenty-six vendor invoices in nine layouts, two of them password-protected, and a .docx a colleague dropped in by mistake.

The digital statements and the scan ride the same prompt — the scan just takes a few seconds longer.
The nine invoice layouts don’t matter, because the prompt describes fields, not positions.
The two encrypted PDFs fail loudly, get re-exported without passwords in Preview, and re-run.
The .docx is surfaced as an explicit failure, not silently skipped — it was a duplicate of an invoice already in the folder, so it’s deleted.

Output: one workbook. Sheet one, 1,340 transaction and line-item rows with source_file on each. Sheet two, 26 invoice-metadata rows. Total user time: about ten minutes, most of it fixing the two passwords. The same folder through a web converter’s batch endpoint means uploading a year of the company’s finances to someone else’s server and getting back a ZIP of forty separate files — the merge work still ahead of you, now with the upload behind you.

When not to use this

Honest boundaries:

Hundreds of identical statements from one source, forever. If the layout is genuinely stable and volume is high, a scripted pdftotext/pdfplumber pipeline (covered in the CSV batch guide) is free to run once built. It’s the maintenance that costs.
The destination is software, not people. Import pipelines want CSV. Skip the workbook.
Truly massive single documents. A 200-page archival scan is one document, not a batch — split it into chapters with Preview’s page extraction first.
You’re on the road with the folder on your iPad. Small batches run fine there — the invoice workflow on iPad covers it — but a 40-file consolidation is a desk job. Presets sync via iCloud, so the prompt you tuned on the Mac is already on the iPad, and vice versa.

Bottom line

A folder of PDFs that needs to become one Excel file on a Mac is a batch problem, and the failure modes are batch-shaped: mixed layouts, lost provenance, silent partial failure. The workflow that works in 2026: drag the folder into ignitai, describe the rows once in plain English, pick .xlsx with line items and metadata as separate sheets, let the failures surface loudly, and tie out one printed number per document class. On an Apple silicon Mac running macOS 26 the whole batch runs on-device, which matters most for exactly the folders you’d batch: statements, payroll, the vendor ledger. Use the CSV variant when the output feeds software; use this one when it lands in front of a person.

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

FAQ

How do I convert multiple PDFs to one Excel file on Mac?

Drag the folder into ignitai, write one plain-English description of the rows you want, choose .xlsx, and click Extract. The output is a single consolidated workbook — one row per record across every PDF, with a source_file column identifying where each row came from. Up to 500 PDFs run in one pass on an M-series Mac.

Can I batch convert PDFs with different layouts to Excel?

Yes — this is the case AI extraction handles that template-based converters can’t. Because the prompt describes fields (“date, description, amount”) rather than positions on the page, forty invoices in forty layouts produce consistent columns. Scans and born-digital PDFs can be mixed in the same batch; each file is routed through the right pipeline automatically.

Is it safe to batch convert bank statements to Excel?

On an Apple silicon Mac running macOS 26, ignitai processes the entire batch on-device — the PDFs are read and the workbook is written on your Mac, and nothing is uploaded. That’s the meaningful difference from web batch converters, where “batch” means uploading a year of statements to someone else’s server. On older Macs, a hosted fallback with documented zero retention is used instead.