50 Korean Delivery Statements, One Spreadsheet: Batch Without Typing

Every Korean ERP can generate a transaction statement (거래명세서) from a sales record in one click. Not a single one can read one back. The document that accompanies every physical shipment between Korean businesses — listing items, quantities, unit prices, and supply values — enters your procurement workflow through a keyboard, one field at a time. When you receive fifty of them from fifteen suppliers at month-end, that asymmetry stops being a curiosity and becomes the reason your receiving team is still in the office at 10 PM.

If you're new to Korean transaction statements, start with our guide to extracting Korean transaction statement data into Excel, covering field structure, 3-way matching, and the template failure problem. This article focuses on what changes when you scale from one document to fifty — from one supplier's format to fifteen.

What Batch Processing Actually Means for Korean Procurement

The difference between processing one transaction statement (거래명세서) and fifty is not just about time. It is about a completely different class of problem.

Process a single 거래명세서 — one supplier, one shipment, one document — and your workflow is straightforward. Open the PDF. Read the supplier name (공급자), the transaction date (거래일자), the item table. Type each row's item name (품목명), quantity (수량), unit price (단가), and line amount (금액) into your receiving spreadsheet. Copy the supply value (공급가액) and VAT amount (세액) into your reconciliation file. Done. Three minutes per document, maybe five if the supplier's layout is dense or the scan quality is poor.

Now do it fifty times — from fifteen different suppliers, each with their own layout, their own item code system, their own printing quality. The problems that emerge at scale are invisible in single-document processing:

Format traversal. Supplier A's 거래명세서 is a crisp PDF generated by Douzone iCUBE, with the item table in a standard grid layout. Supplier B's is a mobile photo of a handwritten form, with the quantities scrawled in the margin. Supplier C's is an Excel-printed document with merged cells. One extraction approach that works for Document 1 fails on Document 2. By Document 50, you have encountered every format variation the Korean B2B supply chain has to offer — and you have typed through all of them manually.
Naming conventions. You need to know which row came from which file. "거래명세서_20260430.pdf" tells you nothing about the supplier. If you receive three invoices from the same supplier across the month, you need to trace each line item back to its original document — and file names alone cannot carry that traceability.
Exception handling. In 50 documents, you will encounter blank fields. A supplier forgot to print the unit price. Another left the VAT cell empty. A phone photo cut off the bottom rows of the item table. In single-document processing, you notice these immediately and resolve them. In batch processing, the exceptions are buried inside a stack — and finding them requires scanning every completed row.
Output merging. Even if you could extract each document perfectly, you would have fifty separate spreadsheets. The actual deliverable — the one your receiving team needs — is a single table with all line items from all suppliers, sorted and filterable by date, supplier, and PO number.

Single-document processing tests your typing speed. Batch processing tests your system design. The bottleneck shifts from "how fast can I type" to "how do I handle every document at once without losing track of what came from where" — and that is a fundamentally different question.

Why Douzone, ECOUNT, and iQuest Don't Solve Inbound Extraction

Korea's ERP market has invested decades in perfecting outbound document generation. The results are genuinely impressive. Douzone Bizon (더존비즈온) — Korea's largest ERP provider, acquired by Swedish PE firm EQT for 1.3 trillion KRW in 2025 — lets its ~20,000 corporate clients generate 거래명세서 from sales records with one click, automatically populate supplier and buyer fields from the customer database, and batch-print or batch-email hundreds of statements at once through WEHAGO and iCUBE.

ECOUNT (이카운트), serving over 80,000 corporate clients at a flat 40,000 KRW/month, follows the same model: sales entry → automatic 거래명세서 generation → multi-channel delivery (email, KakaoTalk, SMS, fax). Its purchasing module lets you record incoming purchase data — but the data entry is manual. There is no upload-document → auto-extract-fields path for documents you receive.

iQuest (아이퀘스트), maker of 얼마에요 ERP, is the only major Korean vendor to offer OCR-based 거래명세서 data extraction — take a photo of a received 거래명세서 with the mobile app, and AI extracts the supplier information and item list into the ERP. This is a genuine step forward, and in some ways the closest local analogue to what ImageToTable.ai does for single documents. But the design assumption is one document at a time: photograph, review the AI extraction on screen, correct any errors, confirm, repeat. For a field salesperson capturing one receipt from one lunch meeting, this works. For a procurement team receiving fifty 거래명세서 from fifteen suppliers on the last day of the month, it doesn't — because the bottleneck is not the per-document extraction accuracy, it's the per-document human review loop that prevents true batch processing.

경리나라 and 경영이지 — popular among smaller Korean businesses for their simplicity — handle 거래명세서 issuance competently but offer no inbound extraction at all. Neither do the major ASP platforms: Popbill (팝빌), with 373,000+ registered businesses and 324 million+ cumulative documents, and Barobill (바로빌) provide APIs for bulk issuance and HomeTax integration, but their retrieval functions pull data from your own issued documents — not structured data extracted from supplier documents you have received in PDF, scan, or photo format.

The pattern is consistent across every Korean ERP and accounting platform: outbound automation is a solved problem. Inbound data extraction is not even on the product roadmap. The assumption — implicit but uniform — is that the buyer will type the data in.

The Month-End Reality: Why This Problem Has a Deadline

Korean B2B payment cycles amplify the batch processing pressure. Two settlement patterns dominate: 월말결제, where payment is settled at the end of the month in which goods were delivered, and 익월결제, where payment is settled at the end of the following month. In both cases, the 거래명세서 received during the month accumulate into a stack that must be reconciled before payment can be authorized.

For a mid-size Korean manufacturer or distributor with 10–30 active suppliers, a typical month produces 50–200 incoming transaction statements. These arrive throughout the month — a few per day — but the reconciliation happens in a compressed window: the last 3–5 working days before payment authorization. The receiving department needs every line item from every 거래명세서 in the system to verify against purchase orders and to prepare the payment schedule for the finance team.

The arithmetic of that window, for a conservative 50-document batch:

Task	Per document	× 50 documents
Open and read supplier/buyer header fields	1 min	50 min
Extract line items (avg. 8 rows per document)	3 min	2.5 hours
Cross-check supply value against PO	1 min	50 min
Cross-check against tax invoice (세금계산서)	1 min	50 min
Total manual processing		~5.5 hours

Five and a half hours is nearly a full working day — and this assumes every document arrives as a clean, legible PDF. In practice, the batch will include ERP-generated PDFs printed on standard A4, handwritten forms from smaller family-run suppliers who have never used invoicing software, mobile photos taken by delivery drivers and sent via KakaoTalk, and scanned copies with skewed alignment. Each format variant adds friction — and the friction compounds when you are working against a deadline.

This is why "just type faster" stops being an answer around document twenty. The real question is not how quickly you can type individual fields — it is how you handle every document at once, in one workflow, with one output, and with a clear audit trail back to each source file.

How Batch Extraction Works: One Column Definition, Every Supplier

The core mechanism that makes batch 거래명세서 processing possible is column-name extraction: instead of telling a tool where to find each field on a document (by drawing rectangles around coordinates or training a model on sample layouts), you tell it what to look for by typing the field names you want. The AI reads the document visually, locates each value by understanding what the field name means semantically, and populates the output table — regardless of where the supplier placed the field on the page.

This distinction between coordinate-based extraction and semantic extraction is what makes batch processing viable. A coordinate-based tool needs a separate template for each supplier's layout — because Supplier A's "Quantity" field is at pixel position (400, 320) while Supplier B's is at (380, 450). With fifty documents from fifteen suppliers, you would need fifteen templates, and any template breaks when a supplier changes their form layout. A semantic extraction tool needs one column definition — a list of field names like "Supplier Name," "Transaction Date," "Item Name," "Quantity," "Unit Price," "Supply Value" — and applies the same definition to every document in the batch, regardless of layout.

Batch processing in ImageToTable.ai works on this principle. You upload all fifty 거래명세서 files at once — PDFs, JPG scans, PNG screenshots, WebP photos, all in a single upload. You define the columns you want extracted into your output spreadsheet. The AI reads every document, finds every field by meaning rather than position, and compiles all results into one merged Excel table. Each document becomes a row (or multiple rows if it contains a multi-line item table), each requested field becomes a column, and you download a single spreadsheet — not fifty separate ones.

JPG/PNG/PDF AI Extraction

Files are processed securely and not stored.

The efficiency multiplier emerges from eliminating the per-document setup. You do not configure anything per supplier. You do not build templates. You do not train models. You define your columns once — "Supplier Name (공급자)," "Supplier Registration Number (사업자등록번호)," "Transaction Date (거래일자)," "Item Name (품목명)," "Specification (규격)," "Quantity (수량)," "Unit Price (단가)," "Line Amount (금액)," "Supply Value (공급가액)," "VAT Amount (세액)," "PO Reference Number" — and the same column set processes every 거래명세서 from every supplier. Fifty files, fifteen suppliers, one output.

At 5–10 seconds per page versus 3 minutes of manual entry per document, the batch workflow compresses 5.5 hours of typing into roughly 15 minutes of processing — an 18× efficiency gain — but the real win is not the time saved. It is that the output arrives as a single merged spreadsheet, with every line item traceable back to its source document, ready for 3-way matching against POs and tax invoices.

Three-Way Matching at Scale: PO → 거래명세서 → 세금계산서

For Korean procurement teams, extracting 거래명세서 data into a spreadsheet is not the end goal — it is the middle step. The actual deliverable is the 3-way match: purchase order (발주서) → transaction statement (거래명세서) → tax invoice (세금계산서).

Under Korea's VAT framework, the tax invoice (세금계산서) is the legally regulated document — governed by VAT Act Article 32, carrying mandatory fields including supplier and buyer registration numbers, supply value, VAT amount, and date of preparation. It is the document that entitles the buyer to input VAT deduction (매입세액 공제) and must be accurately reflected in quarterly VAT returns (due January 25, April 25, July 25, October 25). The transaction statement carries no such legal weight — it is a private verification document (사적 증빙), not eligible for tax deduction — but it is the document that actually arrives with the goods and carries the item-level detail that the tax invoice often omits.

The 3-way matching workflow at scale:

PO → 거래명세서: verify what was delivered against what was ordered

Compare the items, quantities, and unit prices on each supplier's 거래명세서 against the original purchase order. Discrepancies here — a quantity mismatch, an unapproved substitution, an incorrect unit price — must be flagged and resolved before the tax invoice is even processed. Extract 거래명세서 data into a column structure that includes the PO reference number for each line.

거래명세서 → 세금계산서: verify that the billed amounts match the delivered amounts

The tax invoice arrives separately — often days after the goods, sometimes attached to a monthly consolidated billing cycle. Its supply value (공급가액) and VAT amount (세액) must match the totals on the 거래명세서. This is where the merged spreadsheet pays off: one column from the 거래명세서 extraction, one column from the tax invoice extraction — a simple side-by-side comparison replaces manual cross-checking across separate documents.

세금계산서 → NTS return: verify VAT reporting accuracy

The tax invoice data — once verified against the 거래명세서 — feeds into the quarterly VAT return. A discrepancy between what the NTS has on file from the supplier's electronic filing and what you report triggers a cross-verification flag. The 3-way match is your audit trail: it proves that what you paid matches what you received and what the supplier reported.

The pairing of 거래명세서 extraction and tax invoice extraction is what makes this a complete procurement reconciliation system. Each document type carries different fields, serves a different purpose, and arrives through a different channel. But both feed the same spreadsheet — and both need to agree.

The Naming Problem: Why Batch Processing Needs Source Traceability

There is a problem that does not exist in single-document processing and becomes critical in batch workflows: knowing which extracted row came from which file.

A typical month-end batch might include these files:

거래명세서_20260430.pdf — from Donghae Steel, ERP-generated
거래명세서_20260430.pdf — from a different supplier, same filename, different folder
KakaoTalk_20260502_143021.jpg — photo of a handwritten 거래명세서, supplier unknown from filename alone
scan001.pdf — scanned paper form, supplier name embedded in the image but not in the filename
2026-04-30_거래명세표_대한포장.pdf — clean, identifiable filename — the exception, not the rule

When fifty extracted rows land in your output spreadsheet, you need to know which row corresponds to which supplier's original document. Without that traceability, you cannot resolve a quantity mismatch — you cannot go back to the source document to verify whether the extraction was correct or whether the supplier made an error.

The batch extraction workflow in ImageToTable.ai preserves this traceability by including the source filename as a column in the output. Every extracted row carries the original filename, so you can trace any data point back to its source document instantly. For documents with ambiguous filenames like KakaoTalk_20260502_143021.jpg, rename them before upload — even a simple prefix like DonghaeSteel_20260430.pdf provides the traceability you need.

This is one of those batch-specific challenges that single-document tutorials never mention. When you process one document, you know where the data came from because you just looked at it. When you process fifty, you need the system to remember so you don't have to.

The naming convention you establish before upload is your audit trail. A consistent pattern — [SupplierCode]_[Date]_[DocumentType].pdf — takes ten seconds per file and saves hours of forensic filename investigation when a discrepancy surfaces during reconciliation.

Handling Format Diversity: From Handwritten to ERP-Generated

The format diversity problem in Korean B2B procurement is a function of supplier size and industry. A large chemical supplier in Ulsan ships goods with a Douzone iCUBE-generated PDF — printed on laser paper, professionally formatted, every field in a predictable grid. A small packaging supplier in Incheon writes a 거래명세서 by hand on a pre-printed carbon-copy form, tears off the blue buyer copy (공급받는자용), and hands it to the delivery driver. A mid-size food distributor uses an Excel template that looks professional on screen but prints with merged cells that overlap field boundaries.

Conventional OCR — which expects text in predictable positions — fails on the second and third categories. Handwritten Korean characters on carbon-copy forms are already low-contrast before you factor in the driver's handwriting. Excel-printed forms with merged cells produce text blocks where field labels and values bleed into each other. Template-based systems require you to build a separate template for each format — and with fifteen suppliers using five different format types, the template maintenance alone becomes a recurring task.

Column-name extraction handles format diversity by design — because it does not depend on layout. Whether "Quantity (수량)" is in the third column of a grid table on a PDF, scribbled in a margin on a handwritten form, or embedded in a merged Excel cell, the AI locates it by reading the document the way a human would: scanning for semantic meaning, not pixel coordinates. The same column definition that works on the Douzone PDF works on the handwritten carbon copy and the Excel printout.

There is a practical limit: a photo so blurry that a human cannot read the text will fail for AI as well. But the bar for "readable" is substantially lower than what template-based OCR requires — because blurry-but-legible text is still semantically legible, even if its pixel coordinates are too imprecise for a template to match.

Handling Exceptions in a Fifty-Document Batch

In any batch of fifty documents, a few will have problems. A supplier left the VAT field blank because they are a simplified taxation business (간이과세자) and do not separately charge VAT. Another typed the supply value in the wrong cell, so the extraction returns an unexpected number. A phone photo cut off the last two rows of a ten-row item table.

In single-document processing, you notice these instantly — because you are looking at the document and the data simultaneously. In batch processing, the document and the extracted data are separated by the extraction step, and the exceptions can hide inside a merged table of 400 rows.

The workflow for handling exceptions in batch mode:

Scan for blanks in mandatory columns

After extraction, filter the output spreadsheet for empty cells in critical columns — Supplier Name, Supply Value, Quantity. A blank in Quantity usually means either the item row was missed or the document did not contain a quantity field. Either way, you need to know.

Spot-check totals against document-level sums

The supply value (공급가액) on the 거래명세서 is the sum of all line amounts. If your extracted line amounts do not sum to the extracted supply value, either a line was missed or the supply value was misread. This cross-check catches extraction gaps without requiring you to re-read every document.

Re-process individual problem documents

If a specific document produced unreliable results — flagged by blank mandatory fields or a totals mismatch — re-upload it individually for a second extraction pass. The batch workflow does not force you to reprocess the entire batch to fix one document's errors.

The key insight: batch processing does not eliminate exceptions — it changes how you find them. Instead of discovering errors one document at a time as you type, you run structured checks on the complete output and isolate the problem documents. The shift from reactive error discovery (finding mistakes as you make them) to proactive error detection (scanning the complete output for anomalies) is what makes batch processing not just faster but more reliable.

Integrating Batch Extraction into Your Existing Procurement Workflow

Batch 거래명세서 extraction does not replace your ERP — nor should it try to. The ERP handles sales records, outgoing invoice generation, NTS transmission, and financial reporting. Batch extraction handles the data ingestion step that the ERP leaves to your keyboard.

The integration point is the Excel output. Extract all incoming 거래명세서 data into one spreadsheet, reconcile against POs and tax invoices, and then import the verified data into your ERP through its standard Excel import function. Every major Korean ERP supports this: Douzone's Smart A and iCUBE offer Excel batch import for purchase records. ECOUNT provides Excel bulk import for 거래명세서 and other transaction documents. iQuest 얼마에요 supports Excel upload for 매입거래명세표 data. The extracted spreadsheet becomes the import source — clean, structured, and verified before it ever touches your ERP.

For teams that also process documents from overseas suppliers, the same workflow applies. A delivery note from a Chinese component supplier or a packing list from a European equipment vendor follows the same extraction logic — define columns, upload, get a spreadsheet. The document language and format change, but the column-name extraction principle does not.

This is fundamentally different from the all-in-one ERP promise. You are not replacing your financial system. You are filling the one gap every Korean ERP leaves open: the moment when a supplier's document — in whatever format it arrives — needs to become a row in your spreadsheet before it can become a record in your ERP.

FAQ

Can batch processing handle both handwritten and printed 거래명세서 in the same upload?

Yes. The AI reads each document independently, recognizing handwritten Korean characters (including varied handwriting quality) and printed text using the same semantic extraction logic. The same column definition processes both formats. The practical limit is legibility: if a human cannot read the handwriting, the AI likely cannot either.

What happens when a supplier's 거래명세서 uses non-standard field names?

Column-name extraction does not match text strings — it locates values by semantic understanding. A supplier whose form labels the quantity field as "출하수량" (shipment quantity) instead of "수량" (quantity) will still be correctly extracted because the AI understands that both labels refer to the same concept. This is the fundamental difference between template matching (which would fail) and semantic extraction (which adapts).

How does the system handle multi-page 거래명세서 with item tables spanning multiple pages?

Multi-page PDFs are processed as a single document. The AI reads all pages and extracts all line items from the item table, regardless of page breaks. The output consolidates all rows from all pages into the same document's record in the spreadsheet.

Can I extract only specific line items — for example, only items matching a particular PO number?

The extraction step extracts all data from all documents. Filtering by PO number, supplier, date range, or any other criterion is done in the output spreadsheet after extraction — which gives you the complete data set to work with and filter as needed, rather than restricting the extraction to a subset upfront.

Is 거래명세서 data extraction compliant with Korean tax record-keeping requirements?

거래명세서 itself is a private verification document (사적 증빙) — it has no legally mandated format and is not filed with any government authority. There are no specific compliance requirements governing how you extract or store its data. The tax invoice (세금계산서), governed by VAT Act Article 32, is the document with legal compliance obligations — and is handled separately. For tax invoice extraction, see the batch tax invoice processing guide. As a practical matter, the Framework Act on National Taxes (국세기본법) Article 85-3 recommends retaining transaction records for five years — and a structured Excel file with source filename traceability serves this purpose better than a stack of paper forms.

Does this work for batch Korean tax invoices (세금계산서) as well?

Yes — the same batch extraction workflow applies. For batch tax invoice processing, define columns like Business Registration Number (사업자등록번호), Supply Value (공급가액), VAT Amount (세액), and Approval Number (승인번호), and process 100–200 tax invoices in one upload. The extraction principle is identical; only the field names change.

Every Korean ERP can generate a transaction statement from a sales record. The gap — and the opportunity — is on the receiving side. Batch extraction fills it with one column definition, one upload, and one spreadsheet. Try it on your next month-end batch. See if 5.5 hours of typing becomes 15 minutes of verification.