To get a general ledger to Excel, first identify what the client sent: a selectable PDF, a scan, a CSV export or a printout. Convert it into a sheet with one row per posting, copy each account number onto its rows, then prove every account's beginning balance plus debits minus credits equals the ending balance the report prints.
Which general ledger formats do clients send?
Clients send a general ledger in four shapes: a PDF printed from accounting software, a scanned or photographed paper report, a CSV or Excel export, and occasionally a paper printout handed over at a meeting. Each one needs a different route into Excel, so the first job is to open the file and work out which shape it is.
A general ledger is the report that lists every posting to every account for a period, grouped by account. The IRS Publication 583 describes the underlying idea: transactions are first entered in a journal and then posted to ledger accounts. What the client hands you is a printed or exported view of those ledger accounts. If any of the columns on that view are unfamiliar, the guide on how to read a general ledger report explains each one, from the type and number columns to the split column.
The four shapes behave very differently:
- A native PDF was saved straight from the software. Its text is real text. You can drag across a figure and copy it.
- A scanned PDF or phone photo is a picture of a page. Nothing on it can be selected, and every figure has to be recognised before it is data.
- A CSV or Excel export is already rows and columns, though the layout may still group postings under account headers.
- A paper printout has to be scanned first, which turns it into the second case.
A quick test sorts most files. Open the PDF and try to highlight one amount. If the highlight snaps to the characters, the file has a text layer. If the whole page highlights as one block, or nothing happens, it is an image.
Check the period and the scope while the file is open. A ledger "for the year" sometimes stops at November, and a ledger "for all accounts" sometimes covers only balance sheet accounts. The header usually prints the date range and the basis, cash or accrual. Write both down before converting anything, because you will need them when you prove the totals later.
Ask who produced the file, too. A ledger exported by the client's bookkeeper is usually complete. A ledger the client printed from a report they saved two years ago may carry filters nobody remembers setting.
General ledger PDF to Excel when the text is selectable
A general ledger PDF with selectable text converts to Excel through Power Query, which reads the tables a PDF contains and loads them as rows. The work is in checking that each column landed in the right place and that page breaks did not split or merge postings, not in the conversion itself.
Microsoft documents the route in its Power Query PDF connector guide. You choose the PDF connector, select the file, and in the Navigator pick the table or page you want, then either load it or open it in the Power Query Editor to transform it first. For a ledger, choose to transform. The raw load almost never has the shape you want.
Two connector options matter for long ledgers. The guide says the MultiPageTables option controls whether similar tables on consecutive pages are combined into one table, and it is on by default. That is usually what you want for a ledger that runs across forty pages. The StartPage and EndPage options let you read a range of pages at a time, which the guide suggests for very large files. If the client's PDF opens with a cover sheet and a report summary, starting at the first ledger page avoids importing them.
Watch for three problems after the load:
- Memo text that wraps onto a second line. The connector may read the second line as its own row with only a memo and no amounts. The Microsoft guide mentions this case and points to fill down or grouping to repair multi-line rows.
- Debit and credit columns that collapse into one when a page has few entries. Compare a handful of rows against the PDF and confirm every amount sits under the right heading.
- Repeated page headers in the middle of the data. Each new page may bring the report title and column labels back in as rows. Filter them out.
Numbers sometimes arrive as text, especially when the PDF prints credits in parentheses or with a trailing minus sign. Convert those columns to numbers in the editor before loading, and confirm that a value printed as (1,180.00) became -1,180.00 rather than an error.
Keep the original PDF next to the workbook. Every check later in this process compares the sheet back to that file.
Extracting a general ledger from a scanned PDF
A scanned general ledger is an image of a report, so there is no text to extract until each figure has been recognised by optical character recognition. Once recognised, the figures need a closer check than a native PDF, because a misread digit still produces a valid-looking number that silently breaks the balance.
Excel has its own tool for this. Microsoft's guide to inserting data from a picture describes taking an image file or a screenshot through Data, From Picture, letting Excel analyse it, and then reviewing the results and correcting any errors before selecting Insert Data. That review step is where the real work happens with a ledger. Read across each row on screen against the image rather than accepting the preview.
Recognition errors cluster in predictable places. Ones read as sevens, eights as threes, decimal points dropped so that 1,180.00 becomes 118000, and commas read as periods. Faint photocopies and pages shot at an angle make all of these worse. The post on where financial statement OCR misreads figures covers those failure patterns in more detail.
A scan also loses structure. The account header, the beginning balance line and the postings all look the same to a picture reader. Expect to rebuild which rows belong to which account by hand, using the next section's method.
Check each page as you go rather than at the end. The running balance column is your friend here. If every posting's balance equals the previous balance plus its debit minus its credit, the page read cleanly. Where one row breaks that chain, the error is on that row or the one before it.
For a long scanned ledger, it is often faster to ask the client for a fresh export than to recognise and check every page. The last section covers when to make that request.
Flattening general ledger account headers into one row per posting
A general ledger prints each account number once, in a header above its postings, but Excel needs that account number on every posting row so the rows can be sorted, filtered and totalled. Flattening means adding an account column, filling it down from each header, and then deleting the header, beginning balance and total rows.
Here is a worked example. The client is a fictional florist, Larkspur Floral LLC, and every name, number and amount below is made up for illustration. This is one page of its March ledger as printed, covering two accounts.
| Printed line | Date | Ref | Memo | Debit | Credit | Balance |
|---|---|---|---|---|---|---|
| 1010 Operating Checking XXXX-4821 | ||||||
| Beginning balance | 03/01 | 12,400.00 | ||||
| 03/03 | DEP-0311 | Customer payments | 3,250.00 | 15,650.00 | ||
| 03/08 | CHK-1042 | Hillside Wholesale | 1,180.00 | 14,470.00 | ||
| 03/15 | CHK-1043 | March rent | 2,000.00 | 12,470.00 | ||
| Total 1010 | 3,250.00 | 3,180.00 | 12,470.00 | |||
| 4000 Sales | ||||||
| Beginning balance | 03/01 | -18,600.00 | ||||
| 03/03 | DEP-0311 | Customer payments | 3,250.00 | -21,850.00 | ||
| 03/21 | INV-2207 | Brookside Cafe | 875.00 | -22,725.00 | ||
| Total 4000 | 0.00 | 4,125.00 | -22,725.00 |
The same data as flat rows looks like this. The balance column keeps credit balances as negative numbers, as the printed page did.
| Account | Date | Reference | Memo | Debit | Credit | Balance |
|---|---|---|---|---|---|---|
| 1010 | 03/03 | DEP-0311 | Customer payments | 3,250.00 | 0.00 | 15,650.00 |
| 1010 | 03/08 | CHK-1042 | Hillside Wholesale | 0.00 | 1,180.00 | 14,470.00 |
| 1010 | 03/15 | CHK-1043 | March rent | 0.00 | 2,000.00 | 12,470.00 |
| 4000 | 03/03 | DEP-0311 | Customer payments | 0.00 | 3,250.00 | -21,850.00 |
| 4000 | 03/21 | INV-2207 | Brookside Cafe | 0.00 | 875.00 | -22,725.00 |
The flat version has five rows, one per posting. Nothing was lost. The beginning balances and totals moved out of the data and into a separate proof table, covered in the next section.
The steps in Power Query follow the same order:
- Add a column that holds the account number only on header rows and is empty elsewhere. A header row is usually the one with text in the first column and nothing in the amount columns.
- Fill that column down. Microsoft's guide to filling values in a column explains that fill down replaces each null with the last value above it until a new value appears. Empty cells may need replacing with null first, which the same guide shows.
- Filter out the header rows, the beginning balance rows and the total rows. What remains is postings.
- Replace empty debit and credit cells with zero so that sums work.
Keep the account name in its own column if the ledger prints one. Sorting by number and reading by name is easier than memorising a chart of accounts.
How do I prove the general ledger workbook matches the source?
A general ledger workbook matches its source when, for every account, the printed beginning balance plus the sum of the converted debits, minus the sum of the converted credits, equals the printed ending balance. Build a small proof table with one line per account, and do not use the sheet until every line shows a difference of zero.
For the Larkspur Floral example, the proof looks like this.
| Account | Beginning (printed) | Debits (sheet) | Credits (sheet) | Computed ending | Ending (printed) | Difference |
|---|---|---|---|---|---|---|
| 1010 | 12,400.00 | 3,250.00 | 3,180.00 | 12,470.00 | 12,470.00 | 0.00 |
| 4000 | -18,600.00 | 0.00 | 4,125.00 | -22,725.00 | -22,725.00 | 0.00 |
The computed ending for 1010 is 12,400.00 plus 3,250.00 minus 3,180.00, which is 12,470.00. For 4000 it is -18,600.00 plus 0.00 minus 4,125.00, which is -22,725.00. Both agree with the printed totals, so every posting on that page came across.
Three further checks catch problems the per-account proof can miss:
- Row count. Count the postings on a sample page of the PDF and count the rows for the same accounts in the sheet. A posting read twice and another dropped can cancel each other out in the totals.
- Running balance chain. Add a column that computes each row's balance from the previous row's balance plus debit minus credit, and compare it with the printed balance. Any mismatch points to a single row.
- Whole-report totals. If the ledger covers every account, total debits for the period should equal total credits, because each posting has two sides. Publication 583 states the same rule: total debits must equal total credits after posting.
That last check connects the ledger to the trial balance. The comparison of what a trial balance shows against a general ledger explains how the ending balances in this proof table become the lines of a trial balance.
Save the proof table in the same workbook as the data. When someone asks later whether the conversion was complete, the answer is on a tab rather than in someone's memory.
When a general ledger export beats converting the PDF
A general ledger export from the client's accounting software beats converting a PDF whenever the client can produce one, because the export already holds every posting as data with no recognition step. Ask for the export when the PDF is a scan, runs past a few dozen pages, or prints filters you cannot see.
Most accounting software can export the ledger directly. For QuickBooks Online, Intuit's article on fixing General Ledger report display errors gives the steps: open Standard reports from Reports, search for General Ledger, set the report period, then choose Export to Excel from the More actions menu. The same article says that when the report is too large to display, an export often still works, and otherwise to run a series of smaller reports by account or period and combine them in Excel.
Write the request so the client cannot misread it. Name the report, the exact date range, the basis and the file type you want. "General Ledger, January 1 to December 31, 2026, accrual basis, exported to Excel" leaves less room for a second round of email than "please send the GL."
An export does not remove the checks. It still groups postings under account headers in most cases, so it still needs flattening, and it still needs a proof table. What it removes is the risk of a misread digit. Decide between XLSX and CSV for your own working file once the rows are clean; the guide to choosing between XLSX and CSV for an accounting export covers what each format keeps and loses.
Sometimes the PDF is all there is. The client may have changed software, lost access to an old file, or be sending a ledger produced by a former bookkeeper. In those cases the conversion route above is the only route, and the proof table matters even more.
When ledgers arrive alongside everything else a client sends, Schema CPA reads general ledgers from the upload and exports what it reads to Excel or CSV, so the proof starts from a spreadsheet instead of a printed page. The list of document types Schema CPA reads shows where ledgers sit beside bank statements and tax forms.