Convert inventory list PDF to Excel on Mac (2026 guide)

The handover folder from the previous owner has exactly one record of what’s on the shelves: a 34-page inventory valuation report, printed to PDF from a POS system whose license died with the sale. Every SKU is in there — description, bin location, quantity on hand, unit cost, extended value — grouped by category with subtotals after every section and a grand total on the last page. The new inventory system wants a CSV or XLSX import. The accountant wants a valuation number she can trace. The first physical count is Saturday, and it needs a sheet to count against. What exists is a print layout of all of it, and the standing plan is the worst one: retype eight hundred rows and hope the count doesn’t drift while you do.

Everyone who holds stock meets this document eventually. The retailer switching POS systems whose old system only exports reports as PDF. The e-commerce operation whose 3PL emails a monthly stock report — as a PDF, because it’s generated for humans, not systems. The bar or restaurant doing month-end counts against a distributor’s on-hand list. The workshop reconciling what the shelf says against what the system says. The accountant who needs year-end inventory valuation and got a print-formatted report instead of data. The numbers were born in a database; the PDF is the paper they got trapped in on the way out.

This guide is the Mac workflow: convert inventory list PDFs to Excel on Mac — read on-device, never uploaded — with SKU, description, location, quantity on hand, and unit cost in their own columns, one row per SKU, ready to reconcile.

Why inventory reports defeat table extractors

An inventory report looks like the friendliest possible case — it’s literally a table — and still breaks grid-based tools, for four reasons:

1. Subtotal rows are camouflaged data. Every category section ends with a subtotal row that sits in the same grid as the SKUs. A grid extractor dutifully keeps it, and now =SUM() on the quantity column double-counts every category — the single most common silent error in a retyped or grid-extracted inventory sheet.
2. The table spans dozens of pages. A stock report of any size repeats its column headers on every page and drops a page footer under the last row. Per-page grid detection returns 34 fragments with 34 header rows baked in as data, and stitching them back together by hand is its own afternoon.
3. Section headers carry data the rows need. Many layouts print the category — or the warehouse, or the supplier — once as a section heading, not as a column. Flatten the grid and every row below loses its category; the sheet sums correctly and can no longer answer “how much of this is glassware?”
4. The count sheet came back from the floor. Physical counts happen on printed sheets and come back scanned or photographed. A layout parser needs a text layer; a photographed count sheet has none. It has to be read, not parsed.

The fix is an extractor that understands what the document is — that the bold row after twelve SKUs is a subtotal to skip, that “Warehouse B” above a section belongs in a column on every row beneath it. That’s what a prompt-driven extractor does that a grid tool can’t.

Method 1: ignitai on Mac (the read-on-device way)

ignitai extracts by description, not by layout template, so one prompt covers whatever the POS, the 3PL, or the distributor prints:

1. Drag the PDFs in — or use the file picker, or right-click → Open With from Finder. The born-digital valuation report and the scanned count sheet work the same way; the scanned-PDF walkthrough covers the capture-quality details.

2. Describe the output shape in plain English. A prompt is required — the Convert button stays disabled without one. Start from the Tables starter template or write your own, one clause per failure mode above:

   “One row per SKU: sku, description, category, location, qty_on_hand, unit_cost, extended_value. Take the category from the section heading and repeat it on every row in that section. Skip subtotal rows, the grand-total block, repeated page headers, and page footers. Bare numbers for quantities and costs, no currency symbols.”

   Save it as a preset — it syncs to your other devices via iCloud — and next month’s 3PL report is one click.

3. Pick Excel, hit Convert. Each report is read on your Mac — never uploaded — and only the recognized text goes to ignitai’s private hosted pipeline to build the sheet. On macOS 26, Apple’s native on-device table recognition makes long, dense stock grids extract noticeably sharper; the same flow works back to macOS 14.4. A typical report is usually ready in under a minute.

4. Open the result in Excel or Numbers. One worksheet, one row per SKU, every cell clean text — bare quantities and costs — so a single formatting pass types the columns and qty_on_hand × unit_cost works down the whole sheet. The in-app preview is read-only (rename only); edits happen in the spreadsheet.

Multiple reports are one batch. Three months of 3PL stock reports, or one report per warehouse, selected together in Finder and dragged in with the same prompt, consolidate into one worksheet. Filenames never leave your Mac, so there’s no filename column — identity has to come from the document itself. Prompt for the columns that distinguish the reports (report_date from the header, warehouse from the section headings) and every row knows where and when it came from. A photographed count sheet runs as its own batch: a drop mixing PDFs and images imports only the PDFs.

One table per run — you pick the grain. “One row per SKU and location” builds the count sheet; a category-level summary — one row per category with total units and total value — is a second run with a second prompt, not extra sheets in the same workbook. Two shapes, two runs.

Method 2: Excel for Mac’s Get Data (no PDF connector)

Excel for Mac ships Power Query under Data → Get Data, but the Mac connector list — Text/CSV, XLSX, XML, JSON, SharePoint, SQL Server, OData — has no From PDF option; that connector is Excel-for-Windows-only. Even on Windows, an inventory report is a worst case for it: From PDF detects one grid per page, so a 34-page report arrives as 34 tables to append by hand, each carrying its header row as data, with the subtotal rows kept and the section categories lost. Against a scanned count sheet it returns nothing at all.

Method 3: Preview + Numbers (the one-page fallback)

For a single-page, born-digital list — a distributor’s one-page availability sheet — open it in Preview, select the table, paste into Numbers, and repair by hand: delete the subtotal rows, fix the merged cells, retype what pasted as one column. Workable once. At report length it’s slower than retyping, and against a scan it’s nothing at all.

Method 4: web converters (the business-data line)

Generic web PDF-to-Excel tools share Power Query’s per-page grid blindness — subtotals kept, categories orphaned, multi-page tables fragmented — if the free tier’s page gate admits a 34-page report at all. But the disqualifying issue is the content. An inventory report is your product mix, your stock depth, your unit costs — your margins, reconstructible by anyone who sees cost next to the shelf price. Uploading that to a converter you don’t control is a bigger decision than the retyping it saves. The on-device read exists for exactly this class of document: the PDF stays on your Mac, and only recognized text touches ignitai’s private pipeline.

On iPhone and iPad

Inventory work happens in the stockroom, not at the desk:

• iPhone — the distributor’s driver hands over a printed on-hand list with the delivery: capture it with the in-app camera scan, apply the saved preset, and the rows are in a sheet before the van pulls out. A Live Activity shows conversion progress from the lock screen while you keep shelving. Completed paper count sheets go in the same way, photographed page by page.
• iPad — the stockroom iPad collects the 3PL’s monthly PDFs in Files: multi-select them from the picker or share sheet (there’s no external drag-and-drop into the app on iPad), convert with the synced preset, and iCloud puts the XLSX on the Mac where the stock workbook lives.

One subscription covers iPhone, iPad, Mac, and Vision Pro, so the preset written at the desk works at the loading dock.

The reconciliation pass: what the sheet unlocks

The sheet isn’t the deliverable — the checks are:

1. Tie out the valuation. =SUMPRODUCT(qty_on_hand, unit_cost) against the report’s printed grand total. Because the subtotal rows were skipped at extraction, the sum is honest — no double-counting — and the accountant gets a number that traces to the source report.
2. Reconcile the count. Extract the system report and the completed count sheets into the same workbook, key both on sku, and =XLOOKUP puts counted next to expected. The non-zero differences are the shrinkage report — named, located, and costed instead of suspected.
3. Build the reorder list. Filter qty_on_hand under each item’s reorder point and the purchase list writes itself. The orders it generates come back as confirmations and deliveries — the purchase-order workflow rows up the order side, and the packing-list workflow checks in what actually arrives.
4. Re-cost against the new price list. unit_cost next to the supplier’s current prices — extracted via the price-list workflow — shows which items’ margins quietly eroded since the last update.
5. Feed the new system. One row per SKU with consistent columns is the shape every inventory system’s import wants. If the tracker is shared, the same XLSX imports straight into Google Sheets — the PDF-to-Google-Sheets Mac guide covers that handoff.

When not to use this

• Your system exports CSV. If the POS or 3PL portal has a real data export, use it — extracting from the print-formatted PDF of a report the system could have handed you as data is a workflow built backwards. The PDF path is for the systems that don’t, the portals that only print, and the paper that came off the floor.
• You’re counting serialized units at scale. A prompt can pull printed serial numbers into a column, but hundreds of serialized units per count is a barcode-scanner workflow, not an extraction one.

Bottom line

For inventory list PDFs that need to become a working stock sheet on a Mac: drag the report into ignitai, write the one-paragraph prompt (one row per SKU, category repeated from the section headings, skip the subtotals, bare numbers), pick Excel, Convert, then run the valuation tie-out and the count reconciliation. Use Preview-and-paste for a one-page availability sheet; keep cost and stock-depth data away from web converters entirely. The month-end hour belongs on the shrinkage line and the reorder list, not the retyping — and the on-device read means the report never left your Mac to get there.

Get ignitai on the App Store — sign in with Apple, first conversion free, then $19.99/mo after a 3-day trial; one subscription covers iPhone, iPad, Mac, and Vision Pro.

FAQ

How do I convert an inventory list PDF to Excel on a Mac?

Drag the inventory PDFs into ignitai, describe the columns in one sentence — SKU, description, location, quantity on hand, unit cost — and tell it to skip the category subtotals and the grand-total block. Pick Excel and hit Convert. The report comes back as one sheet with one row per SKU, ready to sum, filter, and reconcile against a physical count.

Can it handle a 40-page stock report where the table continues across pages?

Yes — that’s the normal shape for a 3PL or POS inventory report. The prompt describes the rows, not the page layout, so the table is followed across page breaks and the repeated column headers and page footers don’t become data rows. Ask for one row per SKU and the whole report lands as one continuous sheet, however many pages the print layout spread it over.

Does it keep quantities for different locations or bins in separate rows?

Yes, if you ask for it. Prompt for one row per SKU-and-location with a location column, and a SKU stocked in three bins comes back as three rows — the shape a count reconciliation needs. If you’d rather see one consolidated row per SKU, say that instead; the prompt decides the grain, not the PDF’s layout.