What an extraction schema is: a complete guide to the specification that defines what to extract from documents and in what format

An extraction schema is a specification that defines which fields to extract from a document and under what names, formats and conditions, and it is the standard that aligns extraction results into a data structure business systems and downstream automation can use directly.

Why extraction schemas became necessary

Each department called the same value by a different name.

Even as the technology for extracting values from documents improves, the results often cannot be used as they are. One department calls a field representative name and another calls it name of representative, dates mix dots and hyphens, and amounts arrive in a mix of won and thousands of won. If people have to reformat values before entering them into business systems, the effect of automation shrinks.

The fields to extract also differ by document. A business registration certificate needs the registration number and opening date, while a corporate registry extract needs officer names and change dates. If what to extract from which form lives only in staff experience, there is no standard for verifying the results either.

An extraction schema fixes this agreement in writing. Extracting only the required fields according to defined fields and normalising them into field and value pairs makes the result the foundation for downstream processing and automation.

What an extraction schema actually is: how it differs from a coordinate template

Coordinate templates and extraction schemas across three axes

First, the reference point differs. A coordinate template defines which value sits at which position on a form. An extraction schema defines which value, by meaning rather than position, is received in which format.

Second, the impact of a form change differs. A coordinate template has to be rebuilt when a box moves even slightly. An extraction schema can be used as it is after a form revision, provided the meaning of the fields is unchanged.

Third, the scope of information held differs. A coordinate template holds only how to find a value. An extraction schema also holds the field name, value format, whether the field is required and the validation conditions, making it the standard for checking results.

As extraction based on vision language models has spread, values can be found by meaning without specifying positions. That has increased the weight of the schema that defines what to receive and in what format. Models have become better at finding values, but how the business receives the values found is still for the organisation to decide.

The five elements that make up an extraction schema

Five elements recorded when defining a field

First, the field name. Match it to the field name in the business system and unify the names different departments used. Even if the same field appears as trade name, corporate name or company name depending on the form, the result receives it under one name.

Second, the value format. Define the format the result must follow, such as the order of year, month and day and the separator for dates, the unit and use of commas for amounts, and whether hyphens are included for numbers.

Third, whether the field is required. Separate fields that go to exceptions when empty from fields that may be left blank. Also record whether a missing required field triggers a request for supplementary material or a search in another document.

Fourth, normalisation rules. Record the rules that convert source notation into standard form, such as turning amounts written in Korean words into numbers or removing corporate designations around a trade name.

Fifth, validation conditions. Include the conditions for checking that a value is right, such as the number of digits in a business registration number, the order of dates, and fields that must match other documents.

The output that sets out these five elements in one table is what is commonly called a field definition document. That document is the starting point for developers and business staff to look at results against the same standard.

How an extraction schema is applied in practice

Work backwards from the input fields of the business system

Rather than extracting every field visible in the document, first check which fields the business system receiving the results has. Extracting fields the system does not accept only increases what has to be verified.

Conversely, fields that the system does not have but that judgment needs should be marked separately so they are not missed at the condition checking stage. A table mapping each system field to a schema field, line by line, lets format errors be found before the integration stage.

Split by form and group common fields

Build a schema for each form, but let fields that appear across several forms, such as business registration number or representative, share one definition. Only with a shared definition can comparison between documents be turned into rules.

Changing the definition of a common field affects every form that uses it, so check the scope before the change.

Manage it by version

When a legal revision or a change in business criteria adds fields or changes formats, the schema changes too. Record by version what changed and when, compare the revised schema against the existing one on the same evaluation documents, and then apply it to operations. Record who requested and who approved the change together with the version.

Only with versions retained can it be explained which standard produced results processed in the past.

Extraction schemas in the Korean environment

Korean documents frequently contain numbers with fixed formats, such as resident registration numbers, business registration numbers and corporate registration numbers, as well as amounts written in Korean and dates separated by dots. For these fields, normalisation and validation rules have to be stated in the schema for results to be consistent.

For fields that count as personal information, such as resident registration numbers, whether to de-identify at the moment of extraction or retain the original has to be decided at the schema stage, so that storage and access control do not waver.

Frequently asked questions