One of the first things an operator managing stores across multiple Korean carriers notices is that SKT, KT, and LG Uplus each produce settlement reports that are structured differently enough to be effectively incompatible with each other as-is. Column headers use different Korean terminology for the same underlying financial concept. The activation identifier field is named differently across the three. The order in which line items appear differs. In some cases, what is a single column in one carrier's report is split into two separate columns in another's.
This is not a design failure or an oversight by the carriers. Each carrier's settlement system was built independently over time, and the export format reflects the internal accounting logic of that system rather than any cross-industry standard. For an operator managing a single carrier, it is a non-issue: you learn the format once and you work with it. For an operator with stores across all three carriers, it means building and maintaining three separate reconciliation workflows, or building a normalization layer that maps all three formats to a common schema before any actual matching logic runs.
What the three formats actually look like
Each carrier's dealer portal provides a settlement report download, typically in Excel or CSV format. The column structure differs in several important ways.
SKT exports use the column header "개통일자" for activation date and "장려금" as the general label for sales incentive. The device subsidy is listed separately as "공시지원금" and the plan incentive as "요금제장려금" in adjacent columns. The activation identifier is an internal sequence number unique to SKT's system; it does not directly correspond to the ICCID or IMEI. To match an SKT settlement row to a POS record, you typically need to join on ICCID after resolving the ICCID from SKT's identifier. SKT's export also includes a clawback summary at the bottom of the file as a separate section rather than inline with the activation rows, which means a naive row count will undercount the financial adjustments for the period.
KT exports use "개통날짜" for the same activation date concept (a different Korean label for the same field), and the incentive columns are structured as a single "판매수당" total with a companion "차감내역" column for deductions including clawbacks. This means the net incentive per activation is KT's 판매수당 minus 차감내역, whereas for SKT you sum two incentive columns without a deduction column. The KT activation identifier is listed as "회선번호" (subscriber line number), which is a stable external identifier that maps more directly to the customer account. KT includes the IMEI in the export; SKT does not by default (it requires a separate portal download in many configurations).
LG Uplus uses a fiscal cutoff on the 25th rather than calendar month end, which affects how you attribute activations to periods. The export column for activation date is "가입일" in LG Uplus's format, and the incentive structure is presented as a total "인센티브" without the subsidy breakdown that SKT provides separately. Uplus includes both ICCID and IMEI in the standard export, which makes it the most directly usable for ICCID-based POS matching. Uplus's report also includes an explicit "정산상태" (settlement status) column per activation row, which SKT and KT do not include inline.
The normalization problem in practice
When you try to build a multi-carrier reconciliation in a spreadsheet, the column mapping step is where most operators spend the most time. Taking the three exports and aligning them into a common format requires decisions like: which carrier's subsidy terminology do you use as your canonical term? How do you handle SKT's bottom-of-file clawback section versus KT's per-row deduction column? Do you calculate net incentive before or after bringing the rows into your combined view?
There is no universally correct answer to any of these. What matters is that your normalization is consistent from month to month and that you document which transformations you applied, because if a dispute arises, you need to be able to explain how you derived the number you filed the dispute on.
We have seen operators maintain their normalization logic in a spreadsheet template with manual column-remapping steps. This works for one person who built the template and runs it every month. It breaks down when that person is absent, when a carrier changes a column header in a portal update, or when a new store location is added under a carrier that was not in the original template. The fragility is proportional to the number of manual steps in the normalization process.
The date field problem
The date field inconsistency deserves separate attention because it affects not just formatting but period attribution. All three carriers represent dates differently in their exports, and Excel's automatic date interpretation will silently misparse dates from at least one carrier format on most locale settings. A date like "20260115" (SKT's compact format) will be interpreted by Excel as the number 20,260,115 rather than as January 15, 2026, unless the column is pre-formatted as text or you use a specific import option.
KT's format uses "2026-01-15" (ISO-like), which Excel typically handles correctly. LG Uplus's standard export uses "2026.01.15", which Excel's Korean locale handles correctly but international locale settings may not.
This sounds like a minor formatting detail. It becomes consequential when you are trying to filter activations by date range for a period reconciliation and your combined view has silently incorrect dates for a subset of rows. You will count the period's activations correctly but attribute them to the wrong month for accounting purposes. In the context of LG Uplus's 25th-of-month cutoff, a date parsing error of even one day on an activation near the cutoff date changes which settlement period it belongs to.
Clawback and adjustment representation
Carrier clawbacks (early termination adjustments, plan downgrade deductions) are handled differently across the three carriers' exports. SKT consolidates them at the end of the file. KT includes them inline as a deduction column. LG Uplus flags them with a status code in the settlement status column and uses a separate adjustment export that must be downloaded separately from the main settlement file.
The practical consequence: if you build your multi-carrier reconciliation by combining the main settlement exports from all three carriers, you will systematically miss Uplus clawbacks unless you also pull the adjustment file, and you will have to handle SKT's footer clawbacks as a separate parsing step. Forgetting either step means your calculated settlement expectation will be higher than what the carrier actually pays, and you will spend time investigating a gap that is not a carrier error but a format misunderstanding on your side.
What a normalized schema looks like
A minimal normalized schema for multi-carrier settlement matching needs these fields per activation row, regardless of source carrier: a unique activation identifier, an activation date in a common format, a subscriber identifier (ICCID or line number), a device identifier (IMEI where available), the activation type (신규, 번호이동, 기기변경), the gross incentive amount, the deduction or clawback amount (zero if none for this period), and the net incentive amount. Carrier name and the source period should be included as columns for audit trail purposes.
Building to this schema from three carrier formats requires carrier-specific parsers that know where each field lives in each source format and how to transform it. Once you have the normalized output, the actual reconciliation logic runs against a consistent structure regardless of which carrier the activation came from. Adding a fourth carrier later means writing one new parser, not rebuilding the reconciliation.
This is the architecture we work from at Unsoft. The parsing layer is the ugliest part of the problem and the part that requires the most maintenance as carriers update their portal exports. But it is also the part that makes everything downstream cleaner and more reliable. The time you spend on format normalization is time you are not spending chasing false-positive discrepancies caused by column mapping errors.