Excel From PDF is missing or empty: check the connector, then the file

Having Power Query does not mean you have From PDF

Microsoft says Power Query is available in Windows Excel 2016 and later, but individual connectors differ. Its Excel data-source availability page marks the PDF connector as included in the two Microsoft 365 Windows columns. The Office 2016 and Office 2019 columns are blank for PDF. Don't read the page's broad “Applies To” list as a promise that every listed version has every connector.

The web table specifies organizational authentication for those SharePoint files, so a browser-based workflow isn't automatically a no-upload workflow. Sensitive statements still need to stay within the storage and processing arrangements you're allowed to use.

Changing the PDF can't add a missing menu item. If your installed Windows edition should have the connector but the command is absent, record its exact edition and build when asking your administrator or Microsoft for help.

A message saying “This connector requires one or more additional components” is a separate issue. Microsoft's Excel import instructions say the PDF connector requires .NET Framework 4.5 or higher, while the current cross-product PDF connector reference lists prerequisites as “None” and warns that capabilities differ by host. Use the guidance for the actual Excel error with your administrator, rather than treating an empty table as a reason to install components.

Check the transaction text, not just whether the PDF opens

A page can look like a crisp table while containing only a picture of one. Try copying a transaction description and amount into a local text editor, using a transaction page rather than the cover page or account heading. If nothing useful copies, the free PDF text-layer checker lets you see which pages return text without uploading the document.

The results need a careful reading. “No text returned” means that reader returned no non-whitespace characters; it doesn't prove the page was scanned. “Text found” can mean a footer, a page number or text that doesn't match the visible transaction rows. A failed page check is unknown, not zero, and a file with mixed text and image pages needs attention page by page.

For an image-only transaction table, you need another source, manual transcription or an OCR step that recognizes the pictured characters. Microsoft's PDF connector guide does not document an OCR step. Retrying its table selection won't recognize image text for you.

OCR still leaves you with text to review. Adobe's guide to correcting recognized text, updated September 23, 2025, says Acrobat flags uncertain words for review, showing the original image with searchable text behind it. A flagged word needs checking, not necessarily changing. Compare copied text with the picture, especially signs, decimal points and references: a selectable text layer is useful evidence for the next diagnostic, but it doesn't guarantee correct characters or usable columns. The scan-versus-text guide covers that distinction in more detail.

Select the transaction table before loading it

On a supported Windows installation, Microsoft's Excel import guide gives this path: Data > Get Data > From File > From PDF. Once you've opened the file, Navigator lets you select and preview the available tables. If you need to inspect or repair rows before loading them into a worksheet, choose Transform Data.

A summary table that imports perfectly still leaves you without the transaction history you wanted. Compare the preview with the statement to see whether it contains transactions or only the account summary. Check the first and last transactions, including the first entry's date, full description and amount.

If no candidate contains the rows, go back to the text check rather than choosing an unrelated table just to get a result. If transactions appear in several candidates, inspect their page coverage before combining them. Keeping each candidate's source page and account context in your working notes helps you tell a continuation from a second account. Loading two representations of the same rows would count them twice.

Page boundaries and wrapped descriptions need different repairs

Microsoft's connector guidance describes problems identifying multi-line rows. A description that wraps onto a second printed line can become a separate extracted row, with the date or amount left elsewhere. A blank date is not permission to delete the row: it might contain the reference you need to identify the payment.

The connector guidance suggests filling down values or grouping adjacent rows. These are repair techniques, not instructions to fill every blank cell. Before joining description text, confirm which printed lines belong to one transaction. Filling an amount into a continuation line and then summing both rows counts the payment twice.

A table continuing onto another page is a different problem. Microsoft's Pdf.Tables reference says MultiPageTables defaults to true and automatically combines similar tables on consecutive pages. This explains why page-spanning data can arrive as one table. If the combined result mixes sections you need to keep separate, inspect the pages independently: similar columns alone don't establish that two sections belong to one account.

For a large file or a timeout, the connector documentation recommends examining one page or a small range using StartPage and EndPage. It also suggests disabling MultiPageTables when a huge table creates large intermediate results. These are options in the Pdf.Tables query step, edited in the formula bar or advanced editor, not a separate OCR mode. Keep a copy of the query before changing it. A successfully loaded range isn't the whole job; you still need to work through every relevant page.

For cells or columns merged across visible ruling lines, the reference also documents EnforceBorderLines: true treats those lines as cell boundaries; the default false treats them as one hint. If the source has meaningful grid lines, compare the two interpretations rather than applying the option as a universal fix. With either setting, check that a minus sign has stayed with its amount.

A fictional statement has three transactions, not four

This synthetic USD checking-account example has an opening balance of $1,000.00. The following table represents the printed layout across two pages, including one wrapped description. It is not an Excel screenshot or a claimed extraction result.

There are four printed text lines but only three transactions. The supplies reference belongs to the preceding description. After checking that relationship against the source, the intended normalized CSV is:

Date,Description,Amount,SourcePage
2026-06-03,Client payment,850.00,1
2026-06-04,Supplies Reference S-104,-120.25,1
2026-06-05,Account fee,-9.75,2

Import this sample as comma-delimited data, with ISO dates and dot-decimal numeric amounts. Money entering this bank account is positive; money leaving is negative. The credit total is $850.00 and the debit total is $130.00, so net movement is $720.00 and the expected closing balance is $1,720.00.

Missing page 2 leaves net movement of $729.75, which is $9.75 too high. Copying the supplies amount into its continuation line creates a fourth transaction and leaves net movement of $599.75. Changing the worksheet's number format won't fix either problem because the row set is wrong.

If the same printed layout were saved only as page images, with no text layer, the intended transactions and totals would be unchanged. But a text-only extraction would have no transaction characters to read. That's a different failure from losing page 2 or splitting a description. This comparison explains the diagnostic; it isn't a claim that we ran those PDFs through Excel.

Use the local extractor when text exists but the table needs your help

If the transaction text is usable but Excel lacks the connector or chooses unhelpful boundaries, try the free local PDF table extractor. You select the table area and column boundaries, then preview and download raw rows as CSV. The PDF is processed in your browser rather than uploaded. This is manual text extraction, not OCR, automatic bank recognition or an Excel workbook export.

The checker answers “does this page return text?” while the extractor answers “can I place this text into the columns I need?” Neither tells you whether every transaction has been captured, so wrapped lines still need review. Before using the CSV, compare the raw output with the visible page and account for any excluded regions.

A short table may be faster to transcribe and check manually. For a larger PDF-only job, compare the bank's native export and Excel's own connector first; AnyStatement's separate upload-based conversion is another route to reviewable Excel or CSV data. The local tools don't send your file into that workflow. Whichever extraction method you use, the rows still need review.

Finish with the statement, not the import success message

Before using the CSV, compare its transaction count, first and last entries, debit and credit totals, and opening-to-closing movement with the source. Page boundaries need a check for missing or duplicated rows; remove repeated headers only after identifying them. Keep different accounts and currencies separate throughout the check.

The statement balance checker can compare the arithmetic once your CSV amounts and signs are correctly mapped. A zero difference doesn't prove every row is correct because omitted or duplicated movements can offset each other. Keep the original PDF and your review notes, especially where you joined lines or chose which table to include, before moving on to combining monthly files.

What we checked

We opened the linked Microsoft and Adobe pages on October 18, 2026. Microsoft's retrieved update metadata was October 9, 2026 for the PDF connector, June 25, 2026 for the Excel availability matrix, August 12, 2026 for the import instructions and April 2, 2026 for Pdf.Tables. These are metadata dates, not desktop release dates. Adobe showed September 23, 2025 as its page update date.

We parsed the fictional CSV and recomputed its row count, credit and debit totals, closing balance and both error scenarios with Python Decimal. We did not run desktop Excel, execute a Power Query query, perform OCR or test a real bank statement for this article. The menu path and query options are documented instructions, not a benchmark of extraction accuracy or a promise about your installed edition.