Conversion troubleshooting
Fix shifted columns after PDF-to-Excel conversion
Diagnose whether a broken table comes from recognition, layout reconstruction, or spreadsheet import before repairing it.
Locate the stage that introduced the error
When prices land under descriptions or quantities move into the wrong column, preserve the broken output before editing it. Compare the source page, the untouched exported file, and the spreadsheet after import. This separates a recognition or layout problem from an import setting that changes an otherwise usable file.
Choose a small affected region and one unaffected region. They provide a way to check whether a repair helps the problem without damaging good rows. If the error occurs only after opening a CSV, inspect delimiters and text handling before spending time rerunning OCR on the same document.
Identify the pattern
Look for wrapped descriptions, blank cells, merged headings, several adjacent price columns, and page breaks. A single row shifted by one cell is different from an entire table reconstructed with the wrong number of columns. Write down which condition accompanies the problem instead of treating all misalignment as the same failure.
Microsoft's PDF connector guidance acknowledges that multi-line rows can need cleanup. That supports inspection and targeted transformation, not a universal instruction to shift every row. Keep the source beside the table while classifying the error. Record whether the missing value exists elsewhere in the output or was not recognized at all.
Repair a small sample explicitly
Create a corrected sample with the intended columns. Keep identifiers, units, quantities, and prices separate. If a description belongs to the previous line, join it only after verifying the relationship on the source page. Do not infer that every blank first cell is a continuation.
When the pattern is consistent, describe a rule using observable conditions. For example, a particular supplier's continuation row may have text only in the description area and no amount. Test the rule on several pages, including rows it should leave unchanged. Retain an exception path for anything that does not meet the conditions.
Recheck types and numerical meaning
After realigning columns, verify that numeric fields contain numbers and identifiers remain text. Microsoft's Power Query documentation explains explicit types and locale-dependent interpretation. A repaired amount that uses the wrong decimal convention remains incorrect even if it sits beneath the right heading.
Check relationships between fields. A plausible unit price beside the wrong SKU is often harder to notice than a visibly broken cell. Compare the affected rows in full, then inspect nearby rows for collateral changes. Include negative amounts and empty values in the review rather than treating them as automatic mistakes.
Decide whether to repair or reconvert
If a small, stable pattern explains the damage, a documented transformation may be the simplest recurring solution. If the table structure changes unpredictably across pages, revise the extraction approach or test another tool on the same sample. Avoid an expanding collection of special rules that nobody can explain.
Store the raw export, the corrected sample, and the final result separately. Record the rule and its scope so a colleague can reproduce the work. The success condition is not that the spreadsheet looks tidier; it is that each required source value survives in the correct record and column.
Sources
Evidence status: methodology. No unverified accuracy, savings or traffic claim is made.