What document parsing is: a complete guide to moving a document's skeleton into data

Document parsing identifies each element that makes up a document — headings, body text, tables, lists, figures — restores the hierarchy and reading order they form, and converts the result into structured data a machine can work with directly.

Why document parsing is needed

Turn a document into text and the skeleton disappears.

When an organization that has adopted generative AI connects its document assets to a model, the usual first move is to pull the text out of the files and feed it in. It is quick and simple. The problem is that the document flattens at that moment.

Sentences that were headings stop being distinguishable from body text, tables scatter into a list of cell values, and footnotes wedge themselves into the middle of a paragraph. Unfold a multi-level table splitting national and provincial funds into balance and interest into prose, and there is no telling which account applies under which condition. A large share of the cues a person uses to understand a document lives in arrangement and hierarchy rather than in characters, and extracting text alone throws all of that away.

Document parsing carries the skeleton across as well. It is also why retrieval and generation quality is decided here rather than by the model.

What document parsing actually is: how it differs from OCR

OCR and document parsing across three axes

First, the target differs. OCR works on characters in an image. Document parsing works on every element that constitutes the page. In practice the elements identified run to headings, section headings, body text, tables, figures, charts, formulas, list items, captions, page headers, page footers, footnotes, and flowcharts.

Second, the objective differs. OCR aims to transcribe the characters accurately. Document parsing aims to produce data shaped like the document. The outputs differ accordingly: one yields strings, the other yields markup or structured data with the hierarchy intact.

Third, the metrics differ. OCR is measured on character accuracy. Document parsing is measured separately on whether every element was found, whether each element's position is correct, and whether table structure matches the original. In one public-sector evaluation, all 302 assessed elements were detected for 100 percent detection accuracy with 100 percent positional accuracy, while table structure similarity stood at 79.18 percent. Finding an element and rebuilding its interior are problems of different difficulty.

The two are not alternatives. If character recognition is inaccurate, however well the structure is restored the content is wrong. Structuring goes on top of recognition.

Six conditions for putting document parsing into production

Six conditions that hold in real operations

First, no element can be missed. Anything overlooked becomes content that does not exist for retrieval or any later use. Confirm detection accuracy separately from table restoration accuracy.

Second, reading order has to be established precisely. Multi-column layouts and tables inside tables confuse people too. A wrong order scrambles sentences and changes meaning.

Third, tables have to move across with their structure intact. Merged cells and multi-level headers must survive for a value's field to be identifiable. This condition needs its own metric.

Fourth, several output formats have to be available. Markup suits retrieval and generation, structured data suits system entry, and screen display needs something else again. Analysing once and producing several artefacts means the source never has to be reprocessed when the use changes.

Fifth, varied formats have to be accepted as they are. Real document estates are not only PDFs and images. Korean word processor files, office documents, spreadsheets, and text files accumulate alongside them. Structure lost during conversion cannot be recovered.

Sixth, each element's position has to be returned. Without knowing where in the source a structured result came from, neither review nor citation of grounding is possible.

How document parsing is applied in practice

Decide the artefacts first

The opening decision in design is what to produce. Retrieval, system entry, and screen display each require a different format.

The combination used most often in practice generates three: a markup form that expresses hierarchy, structured data that programs handle easily, and a form that represents tables accurately. One municipal deployment separated text, tables, and images, then produced several formats along with chunks and keywords for loading into a knowledge store.

Separate element identification from content recognition

Splitting the pipeline into two stages makes improvement far easier. First identify the type, boundary, and reading order of elements on the page; then recognise the content of each element.

That split narrows the cause when something goes wrong. A missing table is an element identification problem; a table found with wrong values is a content recognition problem. Combined into one process, the distinction disappears and there is no clear direction for improvement.

Read performance field by field

Summarising document parsing performance into a single number hides the actual state. Confirm element detection, positional accuracy, text recognition, table structure restoration, and figure detection separately.

Real evaluations show these moving independently. On one public document set, element detection, positional accuracy, and figure detection all reached 100 percent with text recognition at 98.8 percent, while table structure restoration stood at 79.18 percent. On another, element detection reached 100 percent and body text 99.2 percent with table structure restoration at 86 percent, and validation against filing forms confirmed table structure restoration above 99 percent. Which measure holds the result back depends on the character of the documents.

Document parsing in the Korean environment

A large share of Korean public and financial document estates sits in Korean word processor format. Whether that format can be processed natively is the first gate, and merge information lost while converting to another format cannot be recovered downstream.

The composition of the documents is a condition too. Official correspondence, manuals, statutes, and reports coexist in one store, each with a different hierarchy. Government forms place multi-level tables, circled line numbers, and completion instructions inside the same table. Failing to distinguish an instructional cell from a data cell contaminates the structured output.

On top of this, in a network-separated environment the entire pipeline from conversion to structuring has to run inside the internal network. Configurations that call an external conversion service drop out at this point.

Frequently asked questions