Convert payroll register PDF to Excel on Mac (2026 guide)

The client switched payroll providers in July, and the new system needs year-to-date figures for every employee — gross, per-tax withholdings, deductions — before it can run its first payroll correctly. The old provider’s portal access ended with the contract. What survives is a folder of PDFs: thirteen payroll registers, one per pay period, each a landscape-printed report block-listing every employee with earnings, taxes, and deductions in the provider’s own arrangement. The numbers to onboard the new system, tie out the general ledger, and answer the workers-comp auditor are all in that folder. None of them is usable until the registers become rows.

Every bookkeeper and small-shop owner meets a version of this. The accountant who inherits an engagement and gets a banker’s box of register printouts instead of portal credentials. The owner whose workers-comp auditor wants gross wages by employee by quarter — from a provider the business left two years ago. The bookkeeper tying the P&L’s labor line to actual payroll runs, one journal entry per pay period, from register PDFs the client forwards each cycle because nobody’s granting the accountant portal access. The controller running a W-2 pre-check in January against the year’s registers. The registers have every number; the numbers are trapped in a print layout, one pay period per PDF.

This guide is the Mac workflow: convert payroll register PDFs to Excel on Mac — read on-device, never uploaded — with employee, gross, per-tax withholdings, deductions, and net in their own columns, one row per employee per pay period, ready for the GL entry and the comp audit.

Why payroll registers defeat table extractors

A payroll register looks like a table and behaves like four of them, which is exactly why grid-based tools mangle it:

1. Employees print as blocks, not rows. Most providers — ADP is the canonical example — print each employee as a multi-line block: earnings lines, then tax lines, then deduction lines, stacked under the name. A grid extractor reads that as dozens of ragged fragments; the “one row per employee” shape you need doesn’t exist visually anywhere on the page.
2. Subtotals ambush the data. Department subtotals, page subtotals, employer-tax summaries, and the grand-total block all print in the same font and alignment as employee data. A grid tool imports them as employees; sum the gross column and the total is silently double-counted.
3. Every provider prints a different layout. An ADP register, a Paychex journal, a Gusto report, and a QuickBooks Payroll summary carry the same fields in incompatible arrangements — and a provider switch mid-year, the most common reason you’re holding PDFs at all, guarantees two layouts in one folder.
4. The old years are scans. The comp audit and the amended 941 reach back into registers that exist as filing-cabinet paper or a predecessor’s rasterized archive. A layout parser needs a text layer; a scan has none. It has to be read, not parsed.

The fix is an extractor that understands the document — that “1,847.20” on the Medicare line inside Jane Alvarez’s block is Jane’s Medicare withholding, whichever provider printed it, wherever the block falls on the page. 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 every provider in the folder:

1. Drag the PDFs in — or use the file picker, or right-click → Open With from Finder. The client’s forwarded PDFs and the scanned filing-cabinet years work the same way; the scanned-PDF walkthrough covers capture-quality details for the paper ones.

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 employee per pay period: pay_date, pay_period_end, employee, department, regular_hours, overtime_hours, gross, federal_tax, social_security, medicare, state_tax, retirement, health_premium, other_deductions, net. Read each employee’s block into one row. Skip department subtotals, page totals, and the employer-tax summary. ISO dates, bare amounts without currency symbols.”

   Save it as a preset — it syncs to your other devices via iCloud — and every forwarded register is one click from being journal-entry-ready.

3. Pick Excel, hit Convert. Each register 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 sharpens extraction from the dense block layouts; the same flow works back to macOS 14.4. A year of registers is usually ready in under a minute.

4. Open the result in Excel or Numbers. One worksheet, one row per employee per pay period, every cell clean text — ISO dates, bare amounts — so a single formatting pass types the columns, a sort on pay_date puts the year in order, and the pivot works immediately. The in-app preview is read-only (rename only); edits happen in the spreadsheet.

The whole year, one batch. Select all twenty-six registers in Finder and drag them in together with the same prompt; they consolidate into one worksheet. Filenames never leave your Mac, so there’s no filename column — identity has to come from the document itself. That’s why the prompt asks for pay_date and pay_period_end: every register prints them in its header, and they’re what keeps twenty-six pay periods apart in one sheet. Scanned paper registers photographed as images run as their own batch: a drop mixing PDFs and images imports only the PDFs.

One table per run — you pick the grain. “One row per employee per pay period” feeds the GL and the YTD load. The employer-side detail — one row per employer tax and contribution (FICA match, FUTA, SUTA, retirement match) per period — is a different grain, and 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 payroll register is a worst case even on Windows: From PDF detects visual grids, so the block-per-employee layout comes back as fragments, subtotal rows arrive embedded in the data, and the multi-line deduction stacks shred across rows. Against the scanned years it returns nothing at all.

Method 3: a pdfplumber script (for one provider, forever)

If every register in the folder comes from one provider, one layout, born-digital, a Python script — pdfplumber to pull words by position, pandas to assemble rows — can work, and for a recurring single-provider feed it’s a defensible build. The costs arrive on schedule: the block layout means you’re writing positional logic per line type, the subtotal rows need their own exclusion rules, the provider’s next report tweak silently shifts your coordinates, and the second provider — the one the client just switched to — doubles the script. The scanned years it can’t touch at all. For a folder that mixes providers, years, and paper, the maintenance never amortizes.

Method 4: web converters (the never-upload line)

Generic web PDF-to-Excel tools share Power Query’s grid blindness on block layouts — and on this document the quality question is beside the point. A payroll register carries every employee’s name, pay rate, gross wages, and deduction detail — sometimes SSN fragments — for the whole company, on every page. Uploading it to a free converter you don’t control is a data-handling decision made on every employee’s behalf at once. This is precisely the document class the on-device read exists for: the PDF stays on your Mac, and only recognized text touches ignitai’s private pipeline.

On iPhone and iPad

Registers don’t always arrive at the desk:

• iPhone — the client texts a photo of a filing-cabinet register during the comp audit: capture pages with the in-app camera scan, apply the saved preset, and the quarter’s grosses are rows before the call ends. A Live Activity shows conversion progress from the lock screen. A register PDF in Mail goes in through the share sheet the same way.
• iPad — month-end triage away from the desk: collect the client’s forwarded 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 books live.

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

The reconciliation pass: what the register sheet unlocks

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

1. Load the new provider. Pivot rows = employee, values = YTD sums of gross and each tax as of the switch date: the exact per-employee figures the new payroll system’s setup screen demands. This is the task that has no manual shortcut — thirteen registers × a dozen employees × eight numbers each is retyping purgatory, and one wrong YTD figure surfaces next January as a wrong W-2.
2. Book the journal entries. One row per employee per period rolls up to per-period totals — gross, each withholding, net — which is the payroll journal entry, period by period, tied to a source document instead of a portal screenshot.
3. Answer the comp audit. Filter to the policy period, pivot gross by employee (by department, if class codes follow departments), and the auditor’s worksheet fills from the sheet — from a provider the business may have left years ago.
4. Run the year-end tie-out. Sum each employee’s federal_tax, social_security, and medicare across the year and check them against the W-2s via the W-2 Mac flow; the per-employee view from the stub side comes from the paystub Mac flow, and the hours behind the gross come from the timesheet Mac flow. Register to stub to W-2 — the whole chain reconciles.
5. Reconcile against the bank. The register says what payroll should have cost; the operating account says what left. The bank-statement-to-Excel guide extracts that side, and the per-period net-pay totals should match the payroll-run debits to the cent.

When not to use this

• You still have portal access. ADP, Gusto, Workday, and Paychex all export payroll registers as CSV/Excel from the admin portal. If you can log in, export — extracting from print layouts of data the system will hand you directly is a workflow built backwards. The PDF path is for closed portals, predecessor records, PEO exits, and the scanned years.
• You need a payroll calculator. The registers record what was withheld; whether it was withheld correctly is a tax-table question for the payroll system or the accountant. Build the check from the sheet’s verified figures — but the recomputation itself isn’t an extraction job.

Bottom line

For payroll register PDFs that need to become books on a Mac: gather the folder — both providers, the scanned years, all of it — drag the stack into ignitai, write the one-paragraph prompt (one row per employee per pay period, read each block into one row, skip the subtotals), pick Excel, Convert, then run the YTD pivot and the bank tie-out. Use a pdfplumber script only for a single-provider born-digital feed you want to own; keep company-wide pay data away from web converters entirely. The engagement’s hours belong on the reconciliation and the audit response — not the retyping — and the on-device read means the registers 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 payroll register PDFs to Excel on a Mac?

Drag the register PDFs into ignitai, describe the columns in one sentence — pay date, employee, gross, federal tax, Social Security, Medicare, state tax, other deductions, net — and tell it to skip the department subtotals and grand-total blocks. Pick Excel and hit Convert. A year of registers comes back as one sheet with one row per employee per pay period.

Can it handle registers from different payroll providers in one batch?

Yes. The extraction is driven by your column description, not by any one provider’s layout, so an ADP register and a Gusto register land in the same columns in the same run. That’s the point when a client switched providers mid-year, or when a predecessor bookkeeper left records from two systems — one prompt, one batch, one sheet.

What if I no longer have access to the payroll provider’s portal?

That’s exactly when this workflow applies. Portal access ends when a business switches providers, a PEO relationship closes, or an engagement changes hands — and what survives is the PDFs someone saved. The registers themselves carry every number the portal would have exported; converting them rebuilds the export you can no longer download.