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

The pallets landed Tuesday morning, and with them the paperwork: four packing lists pulled from plastic pouches on the cartons, two more that arrived by email as PDFs, and one photographed by the driver because the pouch copy tore. The receiving log needs the same thing from every one of them — PO number, SKU, what was ordered, what actually shipped, what’s backordered — as rows that can be checked against the purchase order before anyone signs off. The paper has all of it, printed in whatever layout each vendor’s ERP favors. So the receiving desk does what receiving desks have always done: counts the boxes, then retypes the lists line by line into a spreadsheet, and hopes the shorted item gets noticed before the invoice for the full quantity does.

Everyone who receives goods lives this. The small retailer checking in a distributor’s weekly delivery. The e-commerce operation reconciling what the 3PL says shipped against what the supplier says it sent. The purchasing manager whose three-way match is stuck because the middle document — proof of what physically arrived — exists only on paper. The workshop that needs received parts in the inventory sheet the day they land, not at month-end. A packing list is a document built to ride in a pouch on a box — and the quantities on it die in a drawer unless someone retypes them.

This guide is the Mac workflow: convert packing list PDFs to Excel on Mac — read on-device, never uploaded — with PO number, SKU, and ordered, shipped, and backordered quantities in their own columns, one row per line item, ready to match against the order.

Why packing lists defeat table extractors

A packing list is two documents stapled together — a shipping form on top, a line-item table below — and that hybrid shape breaks grid-based tools:

1. The header is a form, the body is a table. Ship-to and ship-from blocks, PO number, order date, and carrier sit in labeled boxes above the grid. A grid extractor either misses the header entirely — orphaning every line item from its PO number — or shreds the address blocks into noise rows above the data.
2. Every vendor’s ERP prints a different layout. SAP’s packing slip, NetSuite’s, QuickBooks’, ShipStation’s, and the distributor’s dot-matrix holdover all carry the same fields in different arrangements. Template-based extractors need a mapping per vendor; one receiving day sees five.
3. The quantity columns are the whole point, and they’re the first thing garbled. Ordered, shipped, and backordered sit in adjacent narrow columns — precisely the geometry that makes grid detectors merge cells or shift a column over by one. A quantity that slides from shipped to backordered inverts what the document says, silently.
4. The copy that matters came out of a box. The pouch copy is folded, crumpled, sometimes torn — and it’s often the only copy, because plenty of vendors still don’t email the list. A layout parser gets nothing from a photographed crumple; it needs to be read, not parsed for a text layer.

The fix requires understanding the document — knowing that the number under “B/O” is a backorder quantity that belongs with the SKU on its row, whichever vendor printed 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 vendor’s ERP prints:

1. Drag the PDFs in — or use the file picker, or right-click → Open With from Finder. The emailed PDF and the scanned pouch copy work the same way; the scanned-PDF walkthrough covers the scan-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 line item: po_number, packing_list_number, ship_date, vendor, sku, description, qty_ordered, qty_shipped, qty_backordered. Repeat the PO number and vendor on every row. Take quantities from their labeled columns; if a column isn’t printed, leave it empty. Skip the address blocks, carton counts, and totals. ISO dates, bare quantities.”

   Save it as a preset — it syncs to your other devices via iCloud — and the next delivery is one click.

3. Pick Excel, hit Convert. Each packing list 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 dense line-item grids extract noticeably sharper; the same flow works back to macOS 14.4. A typical delivery’s batch is usually ready in under a minute.

4. Open the result in Excel or Numbers. One worksheet, one row per line item, every cell clean text — ISO dates, bare quantities — so one formatting pass types the columns and the ordered-vs-shipped math works. The in-app preview is read-only (rename only); edits happen in the spreadsheet.

A delivery day is one batch. Select all seven lists in Finder and drag them in together with the same prompt — they consolidate into one worksheet, which is the receiving log. The prompt’s po_number column does the work of keeping shipments apart: filenames never leave your Mac, so there’s no filename column, and identity has to come from the document itself — and the PO number is on every packing list precisely because it’s how shipments are told apart. The driver’s photo of the torn copy 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 line item” builds the receiving log. Want a shipment-level summary instead — one row per packing list with carton count and total pieces, for the freight side of the paperwork? That’s 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. And a packing list is a bad case even on Windows: From PDF detects visual grids, so the header block arrives as disconnected mini-tables, the line items come back orphaned from their PO number, and the narrow adjacent quantity columns are exactly where column-shift errors live. Against the photographed pouch copies it returns nothing at all.

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

For a single emailed, born-digital packing list: open it in Preview, select the line-item grid, paste into Numbers, and repair by hand — reattaching the PO number, splitting merged quantity cells, deleting the address noise. Workable for the occasional one-vendor delivery; at seven lists per receiving day it’s slower than retyping, and against the pouch copies it’s nothing at all.

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

Generic web PDF-to-Excel tools share Power Query’s grid blindness — forms come back as fragments, if the free tier’s page gate admits the batch at all. But the disqualifying issue is the content. A packing list names your suppliers, your SKUs, your order volumes, and your ship-to addresses — your supply chain, one upload away from a converter you don’t control. 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

Packing lists are born on the receiving dock, not at the desk:

• iPhone — pull the list from the pouch and capture it with the in-app camera scan before it disappears into a drawer, apply the saved preset, and the line items are in a sheet while the pallet’s still on the forklift. A Live Activity shows conversion progress from the lock screen. The driver’s photo of a torn copy goes in through the share sheet the same way.
• iPad — the receiving-office iPad collects the emailed 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 receiving log lives.

One subscription covers iPhone, iPad, Mac, and Vision Pro, so the preset travels with you.

The receiving pass: what the log unlocks

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

1. Close the three-way match. The PO says what was ordered, the invoice says what’s being charged, and the packing list is the missing middle: what physically arrived. Match on po_number + sku, compare quantities, and the shorted line surfaces before AP pays for the full one. The purchase-order workflow builds the order side and the invoice-to-Excel guide builds the billing side; this sheet closes the triangle.
2. Chase the backorders. Filter qty_backordered for non-empty and the follow-up list writes itself — vendor, SKU, quantity, ship date — instead of living in someone’s memory of what the pouch copy said.
3. Feed the inventory sheet. One row per SKU received, with clean quantities, imports straight into whatever tracks stock — a stock sheet built with the inventory-list workflow, a shared workbook, or Google Sheets via the PDF-to-Google-Sheets Mac guide.
4. Anchor the freight claim. When the carton count doesn’t match the freight bill, the packing-list rows plus the bill-of-lading workflow put both sides of the discrepancy in columns — the paper trail a shortage claim needs, with dates and numbers instead of recollections.

When not to use this

• Your vendor sends an ASN or EDI feed. An 856 advance ship notice already carries the line items as data. If your system ingests it, use it — extracting from the printed list when the feed exists is a workflow built backwards. The PDF path is for the vendors who send paper, which for most small operations is most of them.
• You need item-level serial or lot tracking at scale. A prompt can pull printed serial numbers into a column, but if you’re receiving hundreds of serialized units per delivery, that’s a barcode-scanner workflow, not an extraction one.

Bottom line

For packing list PDFs that need to become a receiving log on a Mac: drag the delivery’s stack into ignitai, write the one-paragraph prompt (one row per line item, PO number repeated on every row, quantities from their labeled columns, empty when not printed), pick Excel, Convert, then run the three-way match and the backorder filter. Use Preview-and-paste for a single born-digital list; keep supplier and volume data away from web converters entirely. The receiving desk’s hour belongs on the shorted pallet and the freight claim, not the retyping — and the on-device read means the paperwork 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 a packing list PDF to Excel on a Mac?

Drag the packing list PDFs into ignitai, describe the line-item columns in one sentence — PO number, SKU, description, quantity ordered, quantity shipped, quantity backordered — and tell it to repeat the PO number on every row and skip the address blocks. Pick Excel and hit Convert. The batch comes back as one sheet with one row per line item, ready to match against the PO.

Does it work on the crumpled paper copy from inside the box?

Yes — the paper copy pulled from the carton is the normal case. Scan or photograph it and it converts the same way as an emailed PDF, because the document is read on-device rather than parsed for a text layer. Flatten it enough to photograph legibly; the cleaner the capture, the sharper the extraction, and macOS 26’s native table recognition helps on dense line-item grids.

Can it split shipped and backordered quantities into separate columns?

Yes — name them as separate columns in the prompt (qty_ordered, qty_shipped, qty_backordered) and each value lands in its own column, with the cell left empty when the vendor’s layout doesn’t print it. That split is exactly what grid-based extractors garble, and it’s the column the backorder chase list filters on.