How to Extract Korean Transaction
Statements into Excel

What a Korean Transaction Statement Actually Contains

A transaction statement (거래명세서, literally "transaction detail document") is the document that travels with a shipment between Korean businesses. Unlike a tax invoice (세금계산서), which is a legally regulated document governed by Article 32 of Korea's VAT Act and transmitted to the National Tax Service, a 거래명세서 has no mandatory format. It is a private verification document (사적 증빙) — not eligible for input tax deduction, not filed with any government authority, and not required by any law.

That regulatory vacuum creates the extraction problem. Because no standard format exists, every supplier designs their own layout. A transaction statement from a packaging supplier in Incheon places the buyer information top-left and the item table bottom-center. One from a steel distributor in Pohang puts the company stamp (직인) across the header and the item rows in landscape orientation. Neither is wrong — because there is no template to be wrong against.

A typical 거래명세서 contains these fields:

The document is typically issued in duplicate: a red copy for the supplier (공급자용) and a blue copy for the buyer (공급받는자용). In the procurement workflow, it arrives with the physical shipment. The receiving team checks it against the purchase order and the actual goods — a process called 3-way matching — before authorizing payment against the tax invoice that follows later.

In Korean ERP systems like ECOUNT (이카운트), Douzone (더존), and iQuest's 얼마에요, transaction statements are typically generated automatically from sales records — a solved problem on the outbound side. The inbound side is where things break down: these same systems offer no native way to ingest data from the transaction statements you receive from your own suppliers.

Why Template-Based Tools Can't Handle 거래명세서

Most document extraction tools operate on one of two principles: coordinate-based templates or trained models. In a coordinate-based system, you draw rectangles around fields — "supplier name is at (120, 340)" — and the tool reads whatever text appears in that zone. In a trained model system, you annotate 10 to 50 sample documents so the model learns where each field usually appears.

Both approaches break on 거래명세서 for the same reason: there is no "usually." Because the document has no standard layout, coordinates and field positions are different for every supplier. Train a model on transaction statements from Supplier A, and it will fail on Supplier B's format. Add Supplier B's format to the training set, and Supplier C's layout introduces a new failure mode. This is not a training-data problem — it is a structural mismatch between template-bound extraction and a document type that was never designed to be template-bound.

The alternative is semantic extraction: instead of telling the tool where to look, you tell it what to look for. You type the column names you want — "Item Name," "Quantity," "Unit Price," "Supply Value" — and the AI reads the document visually, locating each field by understanding what it means rather than where it sits on the page. This approach, called column-name extraction, means one column definition processes every supplier's transaction statement — regardless of layout, orientation, or whether the supplier name is top-left, centered, or embedded in a header block.

This distinction matters because the alternative — maintaining a separate template for every supplier — doesn't scale. You onboard 3 suppliers, it works. You hit 30, and maintaining the template library becomes its own administrative task. Column-name extraction bypasses that maintenance entirely: the same column definition works on the first supplier's document and the 30th.

Step-by-Step: Extract 거래명세서 Data into Excel

Here is the full workflow, from receiving a transaction statement PDF to having structured data in a spreadsheet. Each step is one action — no coordinate drawing, no model training, no per-supplier configuration required.

The extraction engine reads each field by meaning — it recognizes a supplier registration number (사업자등록번호) by its 10-digit pattern with hyphens, a supply value (공급가액) by its position relative to quantity and unit price columns, and an item name (품목명) by its context in the item table. This is the difference between optical character recognition and visual language understanding: one reads text; the other reads documents.

For a deeper look at the mechanics behind this approach, see our guide on extracting specific fields by column name.

3-Way Matching: PO vs 거래명세서 vs 세금계산서

Extracting data from a transaction statement in isolation is useful. Extracting it as part of the procurement reconciliation cycle is where the real operational leverage sits. The standard Korean procurement workflow follows a predictable sequence: purchase order (발주서) is sent to the supplier → goods are delivered with a transaction statement (거래명세서) → receiving inspection is performed → a tax invoice (세금계산서) is issued and transmitted to the NTS → payment is made.

At the receiving dock, the task is 3-way matching: comparing what was ordered (PO), what was delivered (거래명세서), and what was invoiced (세금계산서). Discrepancies caught at the dock cost a phone call. Discrepancies found during month-end reconciliation cost hours of backtracking through delivery records, supplier emails, and ERP screens.

Here is the data each document type provides for matching:

The bottleneck is the middle column: the transaction statement data is almost never digital. It arrives on paper clipped to a box or as a PDF attachment buried in a delivery notification email. Until that data is in spreadsheet form — in the same format as your PO data from the ERP and your tax invoice data from the NTS system — 3-way matching cannot be automated.

Once the transaction statement data is extracted into Excel, you can use computed columns to perform the match directly in the output. Define a column like Diff: Ordered Qty vs Delivered Qty (PO Qty - Quantity) and the AI calculates the difference for every line item during extraction. Any row with a non-zero difference is flagged before the spreadsheet is even opened. If you process purchase orders through the same extraction pipeline, you can extract PO data to Excel as well — bringing both document types into the same structured format for direct comparison.

For a parallel scenario — extracting tax invoice data specifically — see our guide on extracting Korean tax invoice data to Excel, which covers the seven mandatory fields and quarterly VAT filing workflow. If you are processing large volumes of invoices for VAT reporting, the batch tax invoice processing guide covers the throughput side.

Batch Processing: Handling Daily Delivery Statements

Individual extraction solves the per-document problem. Batch processing solves the daily-volume problem — and it does so without requiring you to repeat any of the setup work.

The column definition you created in Step 2 above is not document-specific. It describes the fields you want, not where those fields appear. This means you can upload 20 transaction statements from 15 different suppliers — all with different layouts — in a single batch. The same column definition is applied to every document. The output is one consolidated spreadsheet where each line item from every statement occupies one row, with the supplier name and date populated across all rows from the same document.

For suppliers who consistently send paper statements with deliveries, a collection link (수집 링크) can shift the digitization step upstream. Generate a shareable URL — no login required for the supplier — and include it in your supplier onboarding instructions. The supplier opens the link on their phone, enters a short verification code, and uploads a photo or PDF of the transaction statement directly into your processing queue. The document arrives already digitized, and your team extracts the data instead of retyping it. This is the same mechanism described in our Korean receipt extraction guide, adapted for the B2B procurement context.

When batch processing transaction statements alongside other delivery documents, the extraction workflow is identical — define columns once, upload everything, download one spreadsheet. The delivery note extraction tool covers the same pattern for carrier-issued delivery dockets, which often accompany transaction statements on the same shipment.

FAQ

Next Steps

The gap in Korea's B2B document infrastructure is not on the issuance side — ECOUNT, Douzone, and the NTS e-Tax system have already digitized tax invoices end to end. The gap is on the receipt side: the documents your suppliers send you that were never designed to be machine-read. Transaction statements sit at the center of that gap because they touch procurement reconciliation, inventory receiving, and payment authorization — three workflows that downstream finance teams depend on.

Closing that gap does not require changing how your suppliers issue documents. It requires changing how your team processes what arrives. The same transaction statement that took 8 minutes to retype into your receiving log can be extracted in seconds — with the same column definition working on tomorrow's statement from a different supplier in a different format.