Why bank statement descriptions disappear in Excel

Find where the text changed before converting again

You can narrow the search by following one affected transaction through the files. Compare its complete PDF description, including the next printed line, with the untouched Excel or CSV export, then your cleaned worksheet and the imported transaction. Search for a distinctive reference as well as the merchant name, because the missing words might be in the next row, another column or a memo field.

If your bank offers a native transaction download for the same account and dates, check that first. It avoids reconstructing the PDF layout, though its description fields may differ from the printed statement. Compare equivalent fields rather than assuming the bank's CSV and PDF must contain identical strings. Converting again won't fix an import that mapped the wrong column.

A printed line is not necessarily a transaction row

A long description can wrap below its date and amount. An extractor may return the continuation as another spreadsheet row, attach it to the wrong transaction or place it in a neighboring column. Narrow gaps between columns add another problem: text that looks separated on the page can arrive in one cell.

In a historical Camelot bank-statement extraction report opened January 9, 2019, a user described columns arriving in one cell and multiline descriptions needing repair. Contributor vinayak-mehta suggested explicit column separators and custom code to combine rows; the reporter said the settings worked for one file but needed changing for other layouts. This is one reported case, not a test of current extractors or evidence of how often text is lost.

Microsoft's Power Query PDF connector documentation, with update metadata dated October 9, 2026, also identifies improperly recognized multiline rows. It suggests transformations such as filling down or grouping adjacent rows. Those are building blocks, not a safe instruction to merge every row with a blank date.

A blank-date row could be a continuation, a page heading, a subtotal or a separate transaction with an omitted date. Before joining its text, confirm the page, account, transaction boundary and reading order against the PDF, keeping page breaks and account changes out of any automatic grouping rule. Never fill an amount down into continuation rows: that would turn one payment into several.

Check whether Excel is hiding the text or has lost it

Select an affected cell and inspect its full contents in the formula bar. If the words are still there, the problem is display, not extraction. Widen the column or use Home > Wrap Text, then adjust the row height. Microsoft's wrapping guide, with update metadata dated June 25, 2026, notes that a fixed row height or merged cells can prevent wrapped text from being fully visible. Formatting cannot recover characters absent from the cell itself.

A merged workbook cell isn't the same as text joined into one value, so don't use Merge Cells to combine description fragments. Microsoft's merge and unmerge guidance, updated October 5, 2026, warns that merging retains only one cell's contents and deletes the others. Combine the confirmed text in a separate working column instead, retaining the original fragments. Unmerging a saved workbook is not a recovery method for text already deleted.

Four transactions, three changed descriptions, identical totals

This fictional example is one USD checking account, with money out negative and money in positive. The first payment occupies three printed lines in the imagined PDF:

2026-10-02  NORTH PIER PRINTING    -240.00
            INV NP-1042
            REF 004281

Those lines describe one payment, not three. Here is the fictional baseline, with continuation text joined by spaces. It is a synthetic reference CSV, not output from a tested PDF conversion. Save it as before.csv:

Date,Description,Amount
2026-10-02,NORTH PIER PRINTING INV NP-1042 REF 004281,-240.00
2026-10-03,CLIENT PAYMENT INV 771 REF 001907,900.00
2026-10-05,CARD PURCHASE RIVER CAFE TERMINAL 019,-12.50
2026-10-06,MONTHLY SERVICE FEE,-5.00

Now suppose the next stage leaves only the printing company's name, removes the deposit description and shortens the cafe text. Save this deliberately altered version as after.csv:

Date,Description,Amount
2026-10-02,NORTH PIER PRINTING,-240.00
2026-10-03,,900.00
2026-10-05,RIVER CAFE,-12.50
2026-10-06,MONTHLY SERVICE FEE,-5.00

Three descriptions changed, but counting blanks finds only one. The printing payment lost its invoice and reference, while the cafe row might be an intentional display cleanup. These two files alone can't tell you which stage caused the changes, but they do show exactly which text needs checking.

Count the rows, then compare the descriptions

A small before-and-after record gives you a starting point for each account, currency and period. Record the transaction count, nonblank-description count, blank-description count and amount totals, counting transaction records rather than printed PDF lines or headings. Whitespace-only text counts as blank, but a nonblank value isn't necessarily complete, as the printing example shows.

The free CSV before and after compare accepts two transaction CSVs in your browser. To try the files above, map Date, Description and Amount on each side and choose year-month-day dates, period-decimal amounts and Positive means money in. Both sides need the same account label and USD currency; confirm each file's settings once those are entered. For text-preservation checks, keep the default Date + amount + exact text comparison.

Its default matching includes the description. The unchanged fee can match exactly; the other three rows have distinct date-and-amount pairs and can appear as possible changed matches for review. A missing description stays in the comparison rather than making its transaction disappear. Choosing date-and-amount-only matching is not the right check for text loss because it leaves descriptions out of the matching key.

Repeated payments complicate this because two equal amounts on the same day may be separate purchases. Review ambiguous candidates against the source rather than pairing them by spreadsheet row number, which can shift after sorting or an inserted heading. The fields need to be comparable too: use the full description on both sides, not a cleaned payee on one side and raw bank text on the other.

This is a CSV comparison, not a PDF reader. If the first conversion already lost the text, two copies of that damaged output will agree. You need a source-reviewed baseline, a suitable bank download or a direct PDF-to-row review to find that earlier loss. Blank counts and shorter strings are warning signs, not proof that the other rows are complete. For a broader check, use the imported-transaction survival checklist.

The destination may be showing a different field

A column called Payee may hold a short name while Notes holds the invoice number. If you select only Payee for the destination description, those notes stay out of that field even though they survived the PDF export. That's why the actual values under each mapped heading matter in the import preview. Keep the original columns and check the destination's supported fields before preparing a narrower import file.

Automatic mapping deserves a check even on a round trip. In an Actual issue opened July 28, 2024, the reporter described incorrect payee and notes mapping when reimporting the app's own CSV. The issue was closed as completed on August 6, 2024. It is a historical reason to inspect the preview, not evidence that current Actual imports have this defect.

Payee cleanup is a separate step again. Intuit's QuickBooks Online bank-rule guidance, updated August 5, 2026, distinguishes original bank text from a simplified description, which may show only the vendor name. Its documented way to inspect bank text is All apps > Accounting > Bank transactions, then the settings within that section and Show bank details.

If the original details remain there, a short displayed name doesn't by itself mean the import lost the text. Before deleting or reimporting transactions, check what the destination retains and what it exports. A changed payee label isn't a reason to create another copy of the payment.

A balance checker cannot read a missing invoice number

The statement balance checker compares opening balance plus signed amounts with the supplied closing balance. When running balances are available and mapped, it can also compare the row-by-row arithmetic in the confirmed posting order. A missing payment or altered amount may produce a difference worth investigating.

In both fictional files, the calculation is 1,000.00 - 240.00 + 900.00 - 12.50 - 5.00 = 1,642.50. Removing an invoice number changes none of those terms. Even a complete running-balance chain cannot spot description-only loss, a swapped payee or a reference attached to the wrong row if the amounts and order are unchanged.

Arithmetic can also miss offsetting amount errors, as the balanced-but-wrong example explains. Use balance checks alongside source review, not instead of it. Neither check on its own reconciles your bookkeeping ledger or establishes document authenticity.

Repair from the source, not from what the name probably was

A repair needs text you can read in the original source and assign to the right transaction. When you restore a fragment, keep the source filename, page and transaction reference beside the correction, with the raw description separate from any merchant label you use for reports. If a reference is unreadable, leave it marked unresolved rather than filling in likely digits.

The bank's native export is the place to start if it contains the details you need. For PDF-only records, Excel's Power Query PDF connector, where available in your version, lets you inspect selected tables with Transform Data, though manual transcription may be simpler for a few rows. If you need a separate conversion workflow, AnyStatement's paid converter links transactions back to their source PDF lines so you can compare the extracted description with the page. That is a review aid, not a guarantee that every continuation was captured. It requires a separate file upload, unlike the browser-local CSV comparison.

What we checked

Sources were reopened on October 18, 2026. Alongside the Microsoft and Intuit guidance above, we read the historical Camelot and Actual reports and the relevant PDFTables review bodies on Trustpilot. Edd's September 25, 2023 review described cleanup of poorly formed PDF cells while praising the output; Gabriel Alapoti's review, updated September 3, 2019, described address fragments split across rows while saying the service performed better than alternatives. Both concern general PDF content; neither establishes a bank-description defect. These are individual reports, not independently reproduced results, a measure of frequency or an accuracy comparison.

We parsed both fictional CSVs and recomputed their counts, text differences and amounts with Python, using Decimal for money. We did not run a desktop Excel conversion, a competitor conversion or a live accounting import for this article. The examples demonstrate the checks; they are not measured extraction results.