Fixing Multi-Line Transaction Descriptions After PDF-to-Excel Conversion
A practical, step-by-step guide to repairing wrapped descriptions that get orphaned from their date and amount after a PDF-to-Excel conversion.
Wrapped transaction descriptions in statement PDFs often turn into orphaned extra rows during export. This guide explains why it happens and how to merge them back correctly in Excel.
Why Wrapped Descriptions Turn Into Orphaned Rows
A PDF has no real concept of a table row — it only stores text as individual objects positioned at x/y coordinates on a page. When a tool converts a PDF to Excel, it has to reconstruct rows by clustering text that shares roughly the same vertical position, then reconstruct columns by clustering text that shares similar horizontal position. This works fine when every field in a transaction — date, description, amount — sits on a single visual line. The problem starts when a statement design wraps a long merchant description onto a second line to keep the page narrow. Chase and Bank of America statements, for example, typically cap the description column around 34-40 characters before wrapping; anything longer, like 'ACH DEBIT PAYPAL INST XFER WEB ID 402935 CCD ID 3847583920,' gets split so the tail end ('CCD ID 3847583920') sits on its own line below the date and amount. Because that continuation line has its own distinct y-coordinate, most extraction engines — including Tabula in stream mode, Adobe Acrobat Pro's Export PDF tool, and Excel's own Power Query PDF connector — treat it as an entirely new row. The date and amount columns for that row come back blank because there's no date or amount text at that y-position, and you end up with a phantom row containing only a fragment of a description, disconnected from the transaction it belongs to.
Spotting the Defect Before It Corrupts Your Numbers
The telltale sign is a row where the Date and Amount columns are empty but the Description column has text — usually short fragments like account numbers, reference IDs, or the second half of a merchant name. If you don't catch this, two things go wrong downstream. First, your row count no longer matches the actual transaction count on the statement; a 200-transaction month might export as 240+ rows. Second, if you sum the Amount column expecting it to reconcile against the statement's printed 'Total Withdrawals' or 'Total Deposits' figure, it will actually still match, because the orphaned rows carry no amount — but any row-based logic (like VLOOKUP by transaction number, or a pivot table counting transactions) will be wrong. A fast sanity check: compare your exported row count against the statement's summary section, which most banks print on the last page (e.g., 'Total transactions this period: 187'). If your spreadsheet has more non-blank-amount... actually more total rows than that number, you likely have orphaned continuation lines. On a 200-line statement, manually scrolling to find and merge these by eye typically takes 20-40 minutes — long enough that it's worth automating with the techniques below rather than eyeballing every row.
Fixing It with Power Query (Recommended for Recurring Statements)
If you regularly import statements from the same bank, building a repeatable Power Query step is far more reliable than manual cleanup. In Excel: Data → Get Data → From File → From PDF, select the transaction table in the Navigator, then click Transform Data to open the Power Query Editor. Add a custom column (Add Column → Custom Column) that flags a row as a continuation when the Date column is null: something like `if [Date] = null then "continuation" else "transaction"`. Next, add an index column (Add Column → Index Column) so you can reference the row above. Then use a second custom column that, for continuation rows, pulls the Description from the row above using `Table.Buffer` and an index lookup, and concatenates it with the current row's fragment via `Text.Combine`. Once the merged description is built, filter out the now-redundant continuation rows (Home → Remove Rows → Remove Duplicates won't work here — use a filter on your flag column instead). This whole sequence takes about 10-15 minutes to build the first time, but once saved as a query, refreshing it on next month's statement is a single click via Data → Refresh All. The trade-off is that this logic assumes exactly one continuation line per wrapped transaction; if a description wraps across three lines instead of two, the query needs an extra concatenation step or a recursive fill-down, which is where hand-built Power Query logic starts to get fragile.
A Formula-Based Fix When You Don't Use Power Query
If you're working with a one-off statement and don't want to build a query, a helper-column formula approach works well. In the column next to your raw Description column, use a formula that tests whether the Date cell is blank: `=IF(A2="", C1&" "&C2, C2)` where column A is Date and column C is Description — this appends the current row's text to the row above's cleaned description whenever the date is missing. Copy this down the full range, then convert the helper column to values (Copy → Paste Special → Values) to break the formula's dependency chain before deleting the original rows. After that, filter column A for blanks and delete those rows entirely, since their content has already been folded into the row above. One nuance worth understanding: this formula only handles a single line of wrap. If a description wraps twice, you need to chain the concatenation — `=IF(A2="", C1&" "&C2, IF(A3="",...))` — or better, use TEXTJOIN with an array formula that walks forward until it hits a row with a non-blank date. This is also where OCR-derived statements introduce an extra failure mode: scanned PDFs run through OCR sometimes drop the blank-date signal entirely because a stray character (a period, a smudge misread as '1') lands in the Date column, making the row look like a legitimate transaction instead of a continuation. A quick mitigation is to validate the Date column against a regex or a date-parsing check (`=ISNUMBER(DATEVALUE(A2))`) rather than just testing for blank.
Preventing the Problem at the Extraction Stage
The most durable fix is choosing extraction settings that respect row boundaries in the first place, rather than repairing broken rows after the fact. Tools that use a 'lattice' mode — meaning they detect the actual ruled lines of a table on the page, like Tabula's lattice setting or Camelot's lattice flavor in camelot-py — tend to preserve row groupings better than 'stream' mode, because they anchor rows to the table's physical grid rather than to raw text y-coordinates. The catch is that lattice mode only works if the PDF actually has visible cell borders; many bank statements use whitespace instead of ruled lines, which forces you back into stream-based extraction and the wrapping problem described above. For scanned statements, image quality matters too — OCR engines processing statements below 300dpi tend to lose the subtle vertical alignment cues that distinguish a continuation line from a new row, worsening the merge problem. AI-based extraction tools that read the document more like a human — associating a wrapped line with its transaction based on layout context and semantic cues rather than pure coordinate clustering — can reduce this failure mode significantly, but they aren't infallible either, especially on statements with unusual layouts, footnote-style annotations wedged between transactions, or highly compressed columnar formats. Whichever tool you use, the discipline that actually prevents downstream errors is always reconciling your final row count and total amount against the statement's own summary line before you trust the spreadsheet for reporting or reconciliation.
Who This Is For
- Bookkeepers reconciling bank or credit card statements exported from PDF
- Finance analysts building transaction ledgers from scanned or digital statements
- Accountants who need clean, one-row-per-transaction data for QuickBooks or Excel pivot tables
- Anyone troubleshooting broken rows after using a PDF table extraction tool
Limitations
- Formula and Power Query fixes assume a predictable pattern (blank Date signals a continuation row); statements with unusual layouts or inconsistent wrapping may need custom logic per bank
- Lattice-mode table extraction only helps on PDFs with visible ruled cell borders; many statements use whitespace-based layouts where this doesn't apply
- OCR-derived statements introduce additional risk because misread characters can land in the Date column and mask a continuation row as a real transaction
- AI-based layout-aware extraction reduces but does not eliminate misattached continuation lines, especially on statements with footnotes or non-standard column widths
Frequently Asked Questions
Why do bank statements wrap descriptions across multiple lines in the first place?
Statement layouts are designed for print readability on a fixed page width, so banks truncate the visible description column at a set character count (often around 34-40 characters) and wrap the remainder onto a second line rather than shrinking the font or widening the page. This is a print design choice, not a data structure — the underlying transaction is still one record, but the PDF renders it as two visually separate lines of text.
Can I fix this with a simple Find & Replace?
Not reliably. Find & Replace works on text patterns within a single cell, but the problem here is that the continuation text lives in a separate row entirely. You need a row-merging approach — either a formula that checks for a blank Date cell and concatenates the row above, or a Power Query step that flags and folds continuation rows — rather than a text substitution.
Does this same problem happen with CSV exports, not just Excel?
Yes, if the CSV was generated by the same coordinate-based PDF extraction process. CSV has no concept of merged cells or row grouping either, so a wrapped description still lands as its own line with empty Date and Amount fields. The fix logic is the same — you're just applying it after importing the CSV into Excel or a script instead of directly against a PDF-derived table.
How do I know if a continuation line got merged into the wrong transaction instead of just being orphaned?
Check whether the total dollar amount reconciles against the statement's printed summary and whether your row count matches the printed transaction count. If both match but a description reads oddly (for example, two unrelated merchant names concatenated together), the continuation line was likely attached to the row below or above it incorrectly rather than left orphaned — this usually happens when a blank separator row between two wrapped transactions was silently dropped during extraction.
Ready to extract data from your PDFs?
Upload your first document and see structured results in seconds. Free to start — no setup required.
Get Started Free