By Park Ji-Hoon
The POS system and the carrier settlement report are recording the same event: a handset or SIM activation at your store. They record it from different vantage points, in different formats, at different times, using different identifiers as their primary keys. The daily reconciliation problem is fundamentally about aligning these two views of the same transactions into a single coherent ledger.
Getting this alignment right is not conceptually difficult. But there are enough structural differences between POS output and carrier settlement format that the alignment regularly fails in practice, and the failure mode is almost always silent: you end up with unmatched records that look like missing commission rather than a data alignment problem.
The Timing Gap Between POS and Settlement
The most important structural difference between POS data and carrier settlement data is timing. Your POS records an activation at the moment the sale closes and the portal submission is made. The carrier's settlement report reflects that same activation two to five business days later, after the carrier's internal processing, fraud screening, and settlement batch cycle has completed.
SKT processes activations submitted before its daily cut-off time (typically 6:00 PM for same-day credit) and includes them in a settlement file that is available to channel partners the following business day. KT's timeline is similar but the settlement file structure updates at a different time. LG Uplus has a slightly longer lag on some plan types, particularly multi-line family plan activations where the account-level verification adds processing time.
This timing gap means that if you try to reconcile your Tuesday POS records against the Tuesday carrier settlement file, you will always have a mismatch: Monday's late submissions are appearing in Tuesday's settlement, and Tuesday's late submissions will appear in Wednesday's file. Any reconciliation approach that uses a rigid date-to-date match will produce false discrepancies that are actually just timing differences.
The correct matching approach is to match within a rolling window rather than a fixed date: for each activation in your POS, look for a corresponding record in the carrier settlement within a five-business-day window centered on the activation date. Activations that do not match within that window are the true discrepancies that warrant investigation.
Primary Matching Keys and Why IMEI Is Not Always Enough
For device activations, IMEI is the strongest primary matching key. It is globally unique, present in both the POS record and the carrier settlement record, and does not change between the time of sale and the time of settlement. IMEI-based matching produces the highest match rate with the lowest false-positive rate for standard new activations.
But IMEI matching fails for several transaction types that represent a meaningful fraction of the monthly volume in a Korean telecom retail store.
SIM-only activations have no IMEI. The matching key here is the USIM ICCID combined with the activation date. ICCID is present in both the POS record (if configured to capture it) and the carrier settlement. If your POS is not capturing ICCID at the time of SIM sale, you will have a structural gap in your reconciliation coverage for all SIM-only activations.
Plan changes and fee plan upgrades for existing subscribers also have no IMEI. The matching key for plan change transactions is the subscriber identifier (가입자번호 or equivalent) plus the plan product code plus the transaction date. This requires your POS to capture the carrier's subscriber identifier at the time of the plan change, not just the customer's name and phone number. Customer name is not a reliable matching key because Korean carrier systems use their own subscriber identifier that may not correspond to any field your POS stores by default.
Number portability (번호이동) activations are complex because they involve records in two carrier systems simultaneously: the losing carrier's record of the subscriber departing and the gaining carrier's record of the new activation. The POS records the gaining carrier's activation. The settlement comes from the gaining carrier. But the IMEI may be the same device the customer brought from the previous carrier, so the IMEI may appear in both the losing carrier's records and the gaining carrier's. This usually does not cause a problem in practice, but it creates edge cases when you are trying to build a complete activation history across carriers.
Format Differences That Cause Silent Match Failures
Beyond timing and key mismatches, format differences between POS and carrier settlement records cause match failures that are invisible without explicit data cleaning steps.
IMEI formatting is the most common culprit. Your POS may store IMEIs as 15-digit strings with or without spaces. SKT's settlement export includes IMEI with no spaces. KT's export sometimes uses a format with dashes. If you are matching on string equality rather than normalized numeric value, a POS record with IMEI "354893 10 123456 7" will not match a settlement record with IMEI "354893101234567" even though they represent the same device.
Date formats are the second common source of silent failures. POS exports may use YYYY-MM-DD. Carrier settlement reports use various formats: some use YYYYMMDD, some use YYYY/MM/DD, some localize the date field to Korean date conventions. A matching function that does not normalize both date fields to a common format before comparison will fail on legitimate matches that differ only in date formatting.
Plan product codes are a third issue. Your POS may record a plan using an internal nickname or a human-readable description ("75,000 Basic Plan"). The carrier settlement uses the official plan product code ("SKT-5G-BASIC-75"). These two strings will never match on string equality. You need a translation table that maps your POS's plan labels to the carrier's official product codes. This table needs to be updated when carriers introduce new plans or rename existing ones, which happens several times per year.
Building the Daily Reconciliation Workflow
A functional daily reconciliation workflow between POS and carrier settlement has three stages: data normalization, matching, and exception handling.
Data normalization converts both inputs to a canonical format before any matching occurs. For POS data: strip spaces and dashes from IMEI, convert all dates to YYYY-MM-DD, normalize plan codes using your translation table, and standardize null values (empty strings and actual nulls should be treated equivalently). For carrier settlement data: apply the same IMEI normalization, convert dates to YYYY-MM-DD, and verify that the plan codes in the settlement match the expected codes for the current promotion period.
Matching applies the primary key logic in order: IMEI first for device activations, ICCID for SIM-only, subscriber identifier plus plan code for plan changes. Each matched pair gets a confidence flag: a direct IMEI match within the timing window is high confidence. A match that required falling back to a secondary key is medium confidence and should appear in a separate review queue. Unmatched records after the full matching pass are the exception queue.
Exception handling is where the human work lives. Not every exception is a genuine discrepancy: some are timing lags that will self-resolve when the next day's settlement file arrives. Some are format issues that the normalization step missed. And some are genuine commission discrepancies that require documentation and, if the carrier's record is wrong, a dispute submission through the carrier's channel partner portal.
The value of running this daily rather than monthly is that genuine exceptions surface within days of the originating transaction, when the details are still fresh and the documentation is accessible. A discrepancy caught on Wednesday from a Monday activation is trivial to resolve with the channel manager. The same discrepancy caught at month-end settlement review, thirty days after the transaction, requires reconstruction of context that may no longer be available.
What This Requires From Your POS Configuration
Effective POS-to-settlement integration requires capturing several fields that some POS configurations omit by default. The fields that matter most for reconciliation are: IMEI (mandatory for device activations), USIM ICCID (mandatory for SIM-only activations and highly recommended for all activations), carrier subscriber identifier (for plan changes), official plan product code (not just a nickname), portal submission timestamp, and portal submission confirmation number.
If your current POS configuration is missing any of these fields, the gap will show up as a structural coverage hole in your reconciliation: a category of transactions that you cannot reconcile reliably regardless of how good your matching logic is. Fixing the POS configuration is a prerequisite, not an optional optimization.