{"id":1653,"date":"2026-08-18T09:00:00","date_gmt":"2026-08-18T00:00:00","guid":{"rendered":"https:\/\/blog.hancom.com\/table-data-extraction-merged-cell\/"},"modified":"2026-08-25T11:45:26","modified_gmt":"2026-08-25T02:45:26","slug":"table-data-extraction-merged-cell","status":"publish","type":"post","link":"https:\/\/blog.hancom.com\/en\/table-data-extraction-merged-cell\/","title":{"rendered":"If image\/table data extraction is corrupted during parsing: A complete guide from merged cells to multi-level headers"},"content":{"rendered":"\n

\u201cThe table was definitely extracted, but the AI keeps answering with numbers from a different quarter.\u201d \u201cAs soon as merged cells are involved, the values come out shifted by one cell.\u201d<\/p>\n\n

Tables are one of the most classic yet effective ways to visualize the relationship between items and values\u2014namely, key-value data\u2014and they are also one of the most commonly used formats in documents. In fact, according to a study that analyzed Google Search query datasets<\/a>, 25.6% of user questions required answers based on data stored in table form. In other words, about one quarter of the questions a RAG system receives require values inside tables or comparative reasoning across rows and columns. <\/p>\n\n

If you have tried table data extraction, there is a situation you likely encounter often. All the text appears to have been extracted, so it looks like a success, but the actual answers are inaccurate. This is because when a standard PDF parser merges rows and columns and breaks the relationships between data, the resulting structural loss carries through to the subsequent retrieval and answer-generation stages. <\/p>\n\n

In this article, we diagnose the causes of broken tables by type\u2014merged cells, multi-level headers, and nested tables\u2014and summarize the principles of restoring row\/column relationships with TSR (Table Structure Recognition).<\/p>\n\n

<\/div>\n\n

Why table structure loss reduces RAG accuracy<\/strong><\/h2>\n\n
<\/div>\n\n

If you extracted a table and the text came out but the AI gives irrelevant answers, the cause is usually table structure loss. If, during the parsing stage, the relationship between the table title and the data is damaged<\/strong>, the AI will struggle to distinguish what a number refers to even when it reads the same value. <\/p>\n\n

A table is a grid where rows and columns intersect, and a cell value has meaning only when it is linked to the header above or beside it. The number \u201c1,200\u201d reveals what it means only when it is attached to a header such as \u201cQ1 2026 revenue.\u201d However, general text extractors do not recognize this grid and simply read cells from top to bottom and left to right. As a result, the row\/column relationships disappear, and the linkage between titles and numbers is lost as well. <\/p>\n\n

This structural loss directly affects RAG\u2019s retrieval accuracy and answer quality. RAG (Retrieval-Augmented Generation) is an approach that retrieves relevant content from documents and uses it as evidence for LLM answers. If a table is stored with its structure damaged, the retrieval stage will pull the wrong cell values. As noted in NVIDIA technical materials<\/a> on RAG document-processing pipelines, when a standard PDF parser merges rows and columns and breaks relationships between data, the next stage produces results that are difficult to trust. <\/p>\n\n

*Source: <\/em>NVIDIA Technical Blog<\/em><\/a>, \u201cHow to Build a Document Processing Pipeline for RAG with Nemotron\u201d, 2026<\/em><\/p>\n\n

<\/div>\n\n

Why table parsing breaks: merged cells, multi-level headers, and nested tables<\/strong><\/h2>\n\n
<\/div>\n\n

The most common causes of broken table parsing are merged cells, multi-level headers, and nested tables. Even if a table looks neatly organized, the relationships between rows and columns can easily become distorted during extraction. <\/p>\n\n

With a simple table, reading from top to bottom and left to right usually does not cause major issues. However, when cells are merged, headers are split across two or more lines, or a table contains another table, the situation changes. Because text extractors do not understand these structures as table relationships and read only in character order, the linkage between headers and values is easily broken. <\/p>\n\n

Why values become misaligned with merged cells<\/strong><\/h3>\n\n
2026<\/td><\/tr>
Q1<\/td>Q2<\/td>Q3<\/td>Q4<\/td><\/tr>
1,200<\/td>1,350<\/td>1,500<\/td>1,420<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

Values become misaligned with merged cells because the extractor reads a merged cell only once. <\/strong>If we assume the \u201c2026\u201d cell merges four columns from Q1 to Q4, the extraction result shows \u201c2026\u201d only once, making it impossible to tell which quarter the numbers below belong to.<\/p>\n\n

\n 2026 Q1 Q2 Q3 Q4 1,200 1,350 1,500 1,420\n<\/div>\n\n

If, as in the table above, \u201c2026\u201d appears only once and the remaining values continue in sequence, the \u201cQ1 revenue\u201d header will be linked not to its original value, 1,200, but to the next value, 1,350. If this table is fed into RAG, even when a user asks for \u201cQ1 2026 revenue,\u201d the AI may actually return 1,350, which is the Q2 value. <\/p>\n\n

This issue is not a limitation of a single tool. Even in an official issue on the Python data analysis library Pandas<\/a>, a problem was reported where header-to-column linkage breaks when extracting merged cells (rowspan\/colspan). This serves as a reference case showing that the process of restoring merged-cell structures into machine-readable row\/column relationships is inherently challenging. <\/p>\n\n

Source: <\/em>pandas github<\/em><\/a>, \u201cENH: read_html to handle rowspan, colspan (GitHub Issue #17054)\u201d<\/em><\/p>\n\n

Column names that disappear with multi-level headers<\/strong><\/h3>\n\n

Column names disappear with multi-level headers because the extractor assumes the header is a single row. If you extract a two-level header table where the upper header \u201c2025 \/ 2026\u201d sits above the lower header \u201cH1 \/ H2,\u201d the values are listed without distinguishing which row is the column name and which row is data. <\/p>\n\n\n \n \n \n \n \n
2025<\/th>\n 2026<\/th>\n <\/tr>\n
H1<\/th>\n H2<\/th>\n H1<\/th>\n H2<\/th>\n <\/tr>\n <\/thead>\n
980<\/td>\n 1,040<\/td>\n 1,200<\/td>\n 1,310<\/td>\n <\/tr>\n <\/tbody>\n<\/table>\n\n

When the header spans two or more rows, either the upper or lower header may be omitted during extraction, or the header may be mixed into the body numbers as if it were data.<\/p>\n\n

For example, during extraction the table above may come out as a single line such as \u201c2025 2026 H1 H2 H1 H2 980 1,040 1,200 1,310.\u201d From the extractor\u2019s perspective, there is no criterion to determine where the header ends, so the hierarchy disappears and all values are listed at the same level. <\/p>\n\n

This is why conditions that require combining upper and lower headers\u2014such as \u201cH2 2026\u201d\u2014are particularly problematic. When the hierarchy is damaged, the AI loses the basis for linking the two and may retrieve the year and half-year separately and answer with an incorrectly combined value. The fact that one-directional reading and independent cell handling can easily miss these hierarchical relationships is also pointed out as a limitation of existing approaches in TSR research<\/a> on multi-level header processing. <\/p>\n\n

*Source: <\/em>Arxiv<\/em><\/a>, \u201cMulti-Cell Decoder and Mutual Learning for Table Structure and Character Recognition\u201d, 2024<\/em><\/p>\n\n

Coordinate information lost with nested tables<\/strong><\/h3>\n\n

Coordinate information is lost with nested tables because the coordinates of the inner table overlap with those of the outer table. If a cell in a table contains another small table, the inner table\u2019s cells can encroach on the outer table\u2019s coordinates in the extracted result (JSON), causing the overall row\/column indices to become misaligned. <\/p>\n\n\n \n \n \n \n \n \n \n
Category<\/th>\n Performance<\/th>\n <\/tr>\n <\/thead>\n
Q1<\/td>\n Target<\/td>\n 1,200<\/td>\n <\/tr>\n
Achieved<\/td>\n 1,180<\/td>\n <\/tr>\n
Q2<\/td>\n Target<\/td>\n 1,350<\/td>\n <\/tr>\n
Achieved<\/td>\n 1,400<\/td>\n <\/tr>\n <\/tbody>\n<\/table>\n\n

A parser assigns coordinates sequentially to the outer grid. When it encounters a new table inside a cell, the inner table also needs its own coordinates. If there is no criterion to distinguish the outer and inner tables, the two coordinate systems overlap at the same indices. From that point on, all subsequent cell coordinates become misaligned, and in the RAG retrieval stage, when searching for a specific figure, it may pull a different value from an adjacent cell. <\/p>\n\n

In RobusTabNet research<\/a> on table structure restoration, it is noted that TSR must precisely restore cell boundaries and coordinates, and that the more complex and distorted the table, the higher the difficulty. <\/p>\n\n

Ultimately, these three causes converge on one point: an extractor that does not understand structure reads a grid-based table sequentially. In that case, the solution is to restore the grid structure before reading the text. However, for images or scanned documents, there is an additional step\u2014so we will look at that first. <\/p>\n\n

Source: <\/em>Arxiv<\/em><\/a>, \u201cRobust Table Detection and Structure Recognition from Heterogeneous Document Images\u201d (RobusTabNet), 2022<\/em><\/p>\n\n

<\/div>\n\n

Why extracting tables from images and scanned documents is more difficult<\/strong><\/h2>\n\n
<\/div>\n\n

In digital documents (e.g., a PDF created digitally), text is stored as text data and can be extracted directly. However, in scanned documents or photos, text is an image made of pixels, so it must first be read with OCR before it can be converted into text. For this reason, table extraction from digital documents is already challenging, but image\/scanned documents make it even more difficult. <\/p>\n\n

If scan quality is low, characters may be misrecognized (e.g., 8 as B), and in number-heavy tables, even a single wrong character can throw off the entire value. If a typed form is mixed with handwriting, or handwritten annotations are overlaid on a table, you must first determine what is the table and what is the text region before reading the characters. <\/p>\n\n

Want to take a deeper look at OCR, the core technology behind table data extraction?<\/strong><\/p>\n\n

\ud83d\udc49 <\/strong>What is OCR? From core AI OCR technologies to a guide for document automation use cases<\/strong><\/a><\/p>\n\n

How processing differs between digital tables and tables in images<\/strong><\/h3>\n\n

The difference in how digital tables and tables in images are processed depends on how the text is stored. For digital documents with a text layer, direct text extraction is sufficient, but pages with low text density or text that exists only as an image require OCR.<\/strong> Therefore, before batch processing, it is more efficient to first determine whether a page is image-based and select only the pages that require OCR.<\/p>\n\n

Category<\/strong><\/td>Tables in digital documents<\/strong><\/td>Tables in image\/scanned documents<\/strong><\/td><\/tr>
How text is stored<\/td>Text data<\/td>Pixel image<\/td><\/tr>
Extraction method<\/td>Direct text extraction<\/td>Extract after OCR text recognition<\/td><\/tr>
Key factors affecting accuracy<\/td>TSR accuracy<\/td>Scan resolution\/clarity + TSR<\/td><\/tr>
Recommended processing<\/td>Parsing + TSR<\/td>Apply OCR + DLA + TSR together<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

Because image\/scanned documents add the additional variable of scan quality, they require both OCR to recognize text and technologies to restore structure.<\/p>\n\n

How low-quality scans and OCR noise lead to data errors<\/strong><\/h3>\n\n

The process by which low-quality scans lead to data errors begins at the text recognition stage. When scan quality is low, character shapes blur and OCR may misrecognize or omit parts of the text. In number-heavy tables, these misrecognitions immediately become data errors.<\/strong><\/p>\n\n

OCR is a technology that converts text in images, scans, and image-based PDFs into machine-readable text. Documents where text exists only as an image must go through OCR to become data. <\/p>\n\n

Noise introduced at this stage carries through to the subsequent stages. According to the OHRBench study<\/a> on how OCR noise affects RAG, the more imperfect the OCR is, the more RAG performance degrades in measurable ways. Errors caused by misread text reduce the accuracy of retrieval and generation results. Therefore, in image document processing, reducing noise and improving recognition accuracy is just as important as restoring table structure. <\/p>\n\n

*Source: <\/em>IBM<\/em><\/a>, \u201cWhat Is Optical Character Recognition (OCR)?\u201d<\/em><\/p>\n\n

*Source: <\/em>Arxiv<\/em><\/a>, \u201cOCR Hinders RAG\u201d (OHRBench), 2024<\/em><\/p>\n\n

<\/div>\n\n

How TSR restores tables<\/strong><\/h2>\n\n
<\/div>\n\n

TSR is a technology that finds a table\u2019s row\/column\/cell boundaries in a document and restores the relationships that determine which header each cell belongs to. Because it restores the grid structure and reads text based on it, it can maintain the linkage between headers and values even when merged cells or multi-level headers are present. <\/p>\n\n

To restore a damaged table, you must first find the table region in the document and then restore the row\/column relationships within the table. DLA (Document Layout Analysis) identifies the table region, and TSR restores the cell boundaries and row\/column relationships within that region. Generally, TSR is performed after DLA, and the two technologies serve different roles. <\/p>\n\n

Identify the table region with DLA<\/strong><\/h3>\n\n

DLA is a technology that recognizes where elements such as text blocks, tables, images, and titles are located on a page. Using AI deep learning, it distinguishes document components and identifies their positions and relationships. <\/p>\n\n

Because the region \u201cfrom here to here is the table\u201d must be defined before restoring row\/column relationships, DLA becomes the first step in handling tables. In other words, DLA is responsible for \u201cfinding where the table is,\u201d while TSR is responsible for \u201crestoring the row\/column relationships within the table.\u201d <\/p>\n\n

Restore row\/column relationships with TSR<\/strong><\/h3>\n\n

TSR identifies cell boundaries and row\/column coordinates within a table and restores the linkage that connects each value to its corresponding header. Once DLA finds the table region on the page, TSR structures merged cells, multi-level headers, and relationships between cells within that region. <\/p>\n\n

In image or scanned documents, OCR first recognizes the text, and TSR then organizes it according to the restored row\/column structure. With this approach, data is not extracted as a simple sequence of characters; instead, it is extracted in a form that preserves header-value relationships, such as \u201cQ1 2026 revenue.\u201d <\/p>\n\n

As a result, TSR does not flatten a damaged table into plain text; it converts it into structured data with row\/column relationships intact. Only when this structure is preserved can the subsequent RAG retrieval stage search numbers together with their corresponding items and use them as more accurate evidence for answers. <\/p>\n\n

<\/div>\n\n
\"Screen<\/figure>\n\n
<\/div>\n\n

Convert to structured data and connect to RAG<\/strong><\/h3>\n\n

Tables restored with TSR are output as structured data with row\/column relationships preserved. Rather than listing cell values as plain text, it organizes them in a way that retains the linkage between headers and values, making them easier to use in subsequent RAG processes. <\/p>\n\n

A RAG process typically proceeds in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 answer generation. When data with table structure intact is stored, the retrieval stage can find items and numbers together, and the AI can answer based on more accurate cell values. <\/p>\n\n

If you would like to see how TSR results differ in practice, you can upload a document and check directly in the Hancom Data Loader live demo.<\/p>\n\n

\ud83d\udc49 <\/strong>Go to the Hancom Data Loader live demo<\/strong><\/a><\/p>\n\n

<\/div>\n\n

How Hancom Data Loader handles table parsing<\/strong><\/h2>\n\n
<\/div>\n\n

Hancom Data Loader is a document parsing solution that converts HWP, HWPX, PDF, and OOXML documents into structured data that AI can use.<\/p>\n\n

Depending on the document type, it applies OCR, DLA, and TSR to extract components such as text, tables, and images. In particular, it converts tables that include merged cells and multi-level headers into structured data while preserving row\/column relationships, reducing the risk of table data being damaged during the RAG preprocessing stage. <\/p>\n\n

Technologies applied for table data extraction by format<\/strong><\/h3>\n\n

How tables are handled differs by document format. In some documents, text is stored as text data; in others, it remains only as an image; and in cases like HWP\/HWPX, accurate extraction requires reading the original document structure directly. Therefore, rather than applying a single technology, table data extraction requires a combined approach\u2014direct parsing of the source, OCR, DLA, and TSR\u2014depending on the document type. <\/p>\n\n

The key point is that you do not need to stitch these technologies together separately. If you combine OCR, DLA, and TSR as separate tools, errors can occur at integration points and the operational burden can increase. Hancom Data Loader bundles extraction functions suited to each document type into a single pipeline, reducing handoff points and instability in the table data extraction process. <\/p>\n\n

Table data extraction in practice: a customer case<\/strong><\/h3>\n\n

A representative real-world case of table data extraction is the Gyeonggi Provincial Office of Education\u2019s AI digital platform project. As the first initiative of its kind among Korea\u2019s 17 provincial\/metropolitan offices of education, Hancom supplied its in-house AI solution to the selected LG CNS consortium, and Hancom Data Loader was responsible for preprocessing public documents into AI-trainable formats. <\/p>\n\n

According to a Digital Daily report<\/a>, Hancom Data Loader converts data from approximately 2,800 school websites, around 40,000 guidance materials, and about 7,000 guidelines and legal\/regulatory documents into AI-trainable formats and integrates them with Hancompedia. Hancom Data Loader handles extraction and parsing, while Hancompedia\u2014its in-house RAG solution\u2014handles chunking the organized data and connecting it to question answering. <\/p>\n\n

You can also choose an adoption model that fits your environment. The Hancom Data Loader API is billed per page, so you can get started by paying only for the volume you actually process rather than committing to a bundled subscription. If you want to verify table data extraction quality first, you can evaluate it by using only what you need. <\/p>\n\n

\ud83d\udc49 <\/strong>Explore the Hancom Data Loader API<\/strong><\/a><\/p>\n\n

FAQ: Frequently asked questions about extracting text from image tables<\/strong><\/h2>\n
\n
\n
\n

Why does data become misaligned when extracting a table with merged cells?<\/strong><\/strong><\/strong><\/strong><\/strong><\/strong><\/strong><\/h3>\n
\n\n

Because the text extractor reads a merged cell only once, values are pulled forward by the number of cells assumed to be empty, breaking the linkage between headers and values. An official Pandas issue (#17054<\/a>) also reported header-to-column linkage breaking with merged cells (rowspan\/colspan). <\/p>\n\n<\/div>\n<\/div>\n

\n

How is TSR different from general text extraction?<\/strong><\/strong><\/strong><\/strong><\/strong><\/strong><\/h3>\n
\n\n

VLM is a multimodal AI that processes both images and text, while LLM is a model that processes only text. The key difference is that VLM incorporates a vision encoder to accept images and interpret visual information. <\/p>\n\n<\/div>\n<\/div>\n

\n

Can tables in scanned documents also be extracted accurately?<\/strong><\/strong><\/strong><\/strong><\/strong><\/h3>\n
\n\n

Hancom Data Loader supports a pipeline that converts visual information into text descriptions through VLM-based image and chart captioning. \u203b The Image Captioning feature is currently in the PoC stage, and the commercial release schedule will be announced later.<\/em><\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n\n

References<\/strong><\/h2>\n\n
    \n
  1. NVIDIA Technical Blog<\/a>, \u201cHow to Build a Document Processing Pipeline for RAG with Nemotron\u201d, 2026<\/li>\n\n\n\n
  2. NVIDIA Technical Blog<\/a>, \u201cApproaches to PDF Data Extraction for Information Retrieval\u201d, 2025<\/li>\n\n\n\n
  3. pandas<\/a>, \u201cENH: read_html to handle rowspan, colspan (GitHub Issue #17054)\u201d<\/li>\n\n\n\n
  4. Arxiv<\/a>, Kawakatsu, \u201cMulti-Cell Decoder and Mutual Learning for Table Structure and Character Recognition\u201d, 2024<\/li>\n\n\n\n
  5. Arxiv<\/a>, Ma et al., \u201cRobust Table Detection and Structure Recognition from Heterogeneous Document Images\u201d (RobusTabNet), 2022<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    If image\/table data extraction breaks during parsing: A complete guide from merged cells to multi-level headers (content thumbnail image) <\/p>\n","protected":false},"author":2,"featured_media":1654,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,10],"tags":[],"class_list":["post-1653","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ax-insight","category-10"],"_links":{"self":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/1653","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/comments?post=1653"}],"version-history":[{"count":23,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/1653\/revisions"}],"predecessor-version":[{"id":1776,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/1653\/revisions\/1776"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/media\/1654"}],"wp:attachment":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/media?parent=1653"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/categories?post=1653"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/tags?post=1653"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}