Skip to content
ignitai
← Back to blog 11 min read

Convert general ledger PDF to Excel on Mac (2026 guide)

Turn general ledger PDFs into Excel on Mac — read on-device; only the text is uploaded — one row per transaction, its account on every row, tied out to the trial balance.

Turn your PDFs into clean Excel workbooks with ignitai on your Mac — first document free (up to 4 pages), then $29.99/month (USD).

Get ignitai on the App Store

The engagement letter says the audit starts in October, and the client’s bookkeeper has delivered the PBC list’s biggest item: the full general ledger for the fiscal year. Not a backup file, not an export — a PDF, 412 pages, because that’s what the report screen prints. Every account in the chart gets a heading, then its transactions — date, journal number, description, debit or credit, running balance — then a total line, then the next account. Somewhere in those pages are the samples to pull, the journal entries to test, and the answer to why repairs and maintenance doubled. None of it is usable until the ledger becomes rows.

Every accountant who works downstream of someone else’s system meets a version of this. The auditor whose sampling and journal-entry testing need the population in a spreadsheet. The bookkeeper rebuilding a year of books after a mid-year switch, when the old system’s access ended with the subscription and what survives is the final GL print. The forensic accountant tracing payments through a ledger produced in discovery. The tax preparer reconstructing fixed-asset additions from the GL detail behind the schedule. The controller who needs last year’s detail from the entity the company acquired — whose legacy system nobody has credentials for anymore. The transactions are all there; the transactions are all trapped.

This guide is the Mac workflow: convert general ledger PDFs to Excel on Mac — read on-device, only the text sent to ignitai’s servers — with one row per transaction, the account carried onto every row, and a pivot that ties to the trial balance as your completeness check.

In this guide10 sections

Why GL reports defeat table extractors

A general ledger report is the least table-shaped table in accounting. Grid-based extractors fail on it structurally, for four reasons:

  1. The key column isn’t a column. The account number and name print once, as a section heading above each account’s transactions. Every row below belongs to that heading — but no row says so. A grid tool imports the headings as stray rows mixed into the data, and the one field you need on every transaction exists on none of them.
  2. Not every printed row is a transaction. Beginning-balance lines, “Total for 6100 Repairs and Maintenance” lines, and carried-forward lines print in the same columns as real entries. Import them as data and every account double-counts; the tie-out fails and you hunt phantom differences for an hour.
  3. The running balance column is a trap. It looks like an amount column and it must not be summed — it’s derived, not data. Grid tools hand it to you as a fourth numeric column and the first careless SUM poisons the analysis.
  4. Descriptions wrap and pages break. Memo text wraps onto second lines that become spurious rows; a 412-page report repeats its headers on every page and splits accounts across page boundaries. And the acquired entity’s prior years exist as scans, where a layout parser — which needs a text layer — returns nothing.

The fix is an extractor that understands the document: that a row’s account is the heading two inches above it, that “Beginning Balance” isn’t a transaction, that the last number on the line is a running balance to ignore. 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 QuickBooks, Sage, Xero, and the legacy system’s GL print alike:

  1. Drag the PDFs in — or use the file picker, or right-click → Open With from Finder. Born-digital reports and the scanned legacy years go through the same flow; the scanned-PDF walkthrough covers capture quality 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 Table starter or write your own, one clause per failure mode above:

    “One row per transaction: date, account_number, account_name, journal_no, description, debit, credit. Repeat the account number and name from the section heading onto every transaction row. Skip beginning-balance rows, account total rows, and carried-forward lines. Ignore the running balance column. ISO dates, bare amounts, no thousands separators.”

    That second sentence — carrying the heading down onto every row — is the whole game. It’s the un-pivot no grid tool can perform, and it’s one clause of English. Save the prompt as a preset — it syncs to your other devices via iCloud.

  3. Pick Excel, hit Convert. Each PDF is read on your Mac — never uploaded — and only the recognized text goes to ignitai’s servers to build the sheet. On macOS 26, Apple’s native on-device table recognition sharpens extraction from dense report layouts; the same flow works back to macOS 14.4. Progress shows in aggregate as pages are read, and a typical report is usually ready in under a minute. Before it starts, ignitai shows how many pages the run will use and how many you have left. At 412 pages, this ledger is more than a month of the plan’s allowance (80 pages a week, up to 320 a month), so plan on extra pages, which never expire — and prove the prompt on a four-page excerpt first; a new account’s first document, up to 4 pages, converts free.

  4. Open the result in Excel or Numbers. One worksheet, one row per transaction — ISO dates, bare amounts, blanks where the document was blank — and the amounts are real numbers in the Excel file, so the pivot runs the moment it opens. Before you export, ignitai’s table numbers the rows, totals the amount columns on screen, and keeps the original page a click away; edits happen in the spreadsheet.

Twelve months, one batch. If the system prints the GL month by month, select all twelve PDFs and run them as one batch with the one prompt — the batch-conversion walkthrough covers the mechanics. The date column already identifies each transaction’s month, so the monthly files consolidate cleanly into one year of detail. Consolidating entities instead? Add “company name from the report header” as a column — filenames never leave your Mac, so identity has to come from the printed page. Scanned legacy years photographed as images run as their own batch: a drop mixing PDFs and images imports only the PDFs.

One table per run — pick the grain. One row per transaction is the analysis grain. The trial balance printed from the same system is a different document at a different grain — it has its own Mac flow — and a second run, not extra sheets in the same workbook.

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, a GL report is the grid detector’s worst case: the account headings arrive as junk rows instead of a column, balance and total lines embed in the data, and a 412-page report imports as hundreds of page-fragments to stitch and de-header by hand. Against the scanned years it returns nothing at all.

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

A GL report is the one document where a hand-rolled script means writing a real parser: a state machine that recognizes account headings, carries the current account onto each row, filters balance and total lines by label text, joins wrapped description lines, and drops the running balance by position. For a single system’s born-digital format that you’ll process monthly for years, pdfplumber plus pandas can earn its keep. The costs arrive on schedule anyway: the system’s next report-format update silently shifts the coordinates, the second system doubles the parser, and the scanned years stay out of reach. For an auditor whose clients print from four different systems, the maintenance never amortizes.

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

Generic web PDF-to-Excel tools inherit every structural failure above — and on this document the quality question is beside the point. A general ledger is every transaction the business made for a year: every customer, every vendor, every payroll entry, every account balance, with descriptions. It is the single most complete financial document a company produces. Uploading it to a free converter you don’t control is a confidentiality decision made on the client’s behalf — the kind engagement letters and professional-conduct rules have opinions about. With ignitai the PDF stays on your Mac and only the recognized text goes to ignitai’s servers, where the AI builds the sheet; the finished file is kept in your ignitai account until you delete it. That is a smaller exposure than handing the whole PDF to a free converter, not a zero one — check it against your own confidentiality terms before running someone else’s documents.

On iPhone and iPad

The ledger doesn’t always arrive at the desk:

  • iPhone — the client’s office manager hands you a bound GL print for the acquired entity: capture the relevant account sections with the in-app camera scan, apply the saved preset, and the detail is rows before you leave the site. A Live Activity shows conversion progress from the lock screen. A PDF in Mail goes in through the share sheet the same way.
  • iPad — fieldwork at the client’s office: collect the PDFs they AirDrop you in Files, multi-select 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 workpapers live.

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

The tie-out: pivot to the trial balance

Before the analysis starts, prove completeness. Pivot the extracted sheet by account_number, summing debits and credits. Two checks fall out immediately:

  • Each account’s pivot totals should match the account total lines printed in the GL report. A missed transaction, a wrapped description that became a row, or an imported balance line each breaks its account’s match — and the pivot tells you which account to inspect, so you’re checking one section, not 412 pages.
  • Beginning balance plus net movement should equal each account’s ending balance on the trial balance. When the GL detail ties to the trial balance and the trial balance foots, the population is complete — which is the property every audit procedure downstream depends on.

Then the sheet goes to work:

  1. Pull the samples. Filter to the account, sort by amount, and the selections come off a spreadsheet instead of a highlighter on page 218.
  2. Test the journal entries. Round amounts, period-end postings, weekend dates, unusual journal numbers — each is a filter on typed columns. This is the test that’s simply not runnable against a PDF.
  3. Explain the flux. Repairs doubled? Filter the account, sort descending, and the three invoices that did it surface in seconds — then the invoice flow extracts the supporting documents when they’re PDFs too.
  4. Rebuild the books. For a system migration, the flat transaction table is the import file the new system wants — map the columns, and a year of history moves without retyping. The cash accounts should also reconcile against the bank statements while you’re at it.

When not to use this

  • You have system access. Every mainstream accounting system exports the GL to XLSX or CSV from the report screen, and the export carries the account on every row already. If you can log in — or can get the client to click Export instead of Print — take the export. The PDF path is for closed systems, predecessor records, discovery productions, and the scanned years.
  • You need the drill-down. A live GL lets you click through to the source document behind an entry. The extracted sheet holds what the report printed — dates, amounts, descriptions — not the attachments. When the question is “show me the invoice,” you still need the client.

Bottom line

For general ledger PDFs that need to become a population on a Mac: gather the folder — every month, every entity, the scanned legacy years, all of it — drag the stack into ignitai (its up-front page count tells you how many extra pages a full year needs beyond the plan’s weekly allowance), write the one-paragraph prompt (one row per transaction, account repeated from the heading, skip the balance and total lines, ignore the running balance), pick Excel, Convert, then pivot by account and tie it to the printed totals and the trial balance before anything else. Build a pdfplumber parser only for a single-system feed you’ll own for years; keep client ledgers away from web converters entirely. The engagement’s hours belong in the sampling, the testing, and the explanation — not the retyping — and the on-device read means the client’s entire transaction history never left your Mac to get there.

Get ignitai on the App Store — free download; your first document (up to 4 pages) converts free with Sign in with Apple, and one subscription covers iPhone, iPad, Mac, and Vision Pro.

FAQ

How do I convert a general ledger PDF to Excel on a Mac?

Drag the GL PDF into ignitai, describe the rows in one sentence — date, account number and name repeated from each section heading, description, debit, credit, skip the beginning-balance and total rows and the running balance column — pick Excel, and hit Convert. The PDF is read on your Mac, and only its text goes to ignitai’s servers; the result is one sheet with one row per transaction.

How do I get the account name onto every transaction row?

Say so in the prompt. A GL report prints the account only once, as a section heading above its transactions, which is exactly what makes grid extractors useless here. A prompt-driven extractor carries the heading down: write “repeat the account number and name from the section heading onto every transaction row” and the grouped print layout becomes a flat, pivotable table.

How do I check the extraction against the books?

Pivot the extracted sheet by account and sum debits and credits. Each account’s totals should match the account totals printed in the GL report, and beginning balance plus net movement should equal each account’s ending balance on the trial balance. If the pivot ties, every transaction made it across.