The problem and decision criteria
The order screen shows KRW 190,000, but only KRW 135,800 has reached the bank account. Placing the order file beside the payment gateway settlement file for the same date still does not reconcile the totals. First distinguish cancellations, additional fees, and money that has not arrived yet. We will work through these numbers using fictional data below.
Reconciliation should use linked records of the same transactions, rather than the total shown on one screen. Connect orders to approvals and cancellations, select the transactions included in this settlement, and compare the payout statement with the bank deposit. A difference between order value and deposits is not necessarily an error; matching totals do not establish that every transaction was recorded correctly.
In practice, separate the questions. The order system answers how much should have been collected; gateway transaction records answer how much was approved or canceled; the settlement statement explains which items produced the payout; and the bank record establishes what actually arrived. Start by keeping answers to these different questions in separate columns.
This article uses Toss Payments as a concrete Korean payment gateway example, based on official documentation checked on September 26, 2026. The linking structure and exception handling below are implementation design proposals. They do not establish accounting revenue recognition or tax treatment.
Matching files by the same date can misalign the scope
First make the meaning of the comparison table's date column explicit.
| Date | Event it identifies | Reconciliation use |
|---|---|---|
| Order creation date | When the order was created | Selecting the order population |
| Approval or cancellation date | When each payment event was processed | Collecting approval and cancellation history |
| Settlement reference date | The gateway's basis for grouping items for settlement | Identifying the settlement to which an item belongs |
| Scheduled payout date | When the statement says payment is due | Checking expected deposits and delays |
| Bank deposit date | When the receiving account records the deposit | Confirming actual receipt |
Check settlement cycles and fee terms against the contract. Toss Payments also explains that the settlement sales date does not always match the payment date. Subtracting results selected by order period from results selected by deposit period can therefore compare different transaction populations. Settlement concepts and cycles.
Toss Payments transaction queries use transactionAt and can retrieve today's records. Settlement queries are available from the following day; dateType defaults to soldDate, while payout-date queries use paidOutDate. Distinguish a settlement record that is not yet queryable from an actual omission. Core API: transaction and settlement queries.
Record the collection cutoff time alongside the query conditions. Setting the end date to today does not cover the whole day if collection finished in the morning. Without query boundaries, time zones, and confirmation that every page was collected, mismatch alerts can confuse collection problems with transaction problems.
Turn transaction data into closing evidence — Reconcile orders, authorizations and deposits using shared keys, then carry exception records through closing.
Do not reduce an order to a single transaction row
The model must accommodate an order paid in two installments and a payment canceled partially several times. Toss Payments describes an approval and each full or partial cancellation as separate transactions. Retaining only the order's current balance makes it difficult to trace which settlement included a cancellation. Transactions and transaction records.
The following linking table is recommended. Internal identifiers on the right are values your system manages, not fields automatically issued by the gateway.
| Records to connect | Identifiers | Relationship to design |
|---|---|---|
| Business order → payment request | Internal order ID ↔ order ID sent to the gateway | A mapping for each split payment request |
| Payment request → gateway payment | Gateway order ID ↔ payment identifier | Distinguish failures and retries from successful payments |
| Payment → approval or cancellation event | Payment identifier ↔ individual transaction identifier | Allow multiple events for one payment |
| Transaction → settlement item | Transaction identifier ↔ original settlement row | Preserve the basis for linking adjustments and corrections |
| Settlement item → payout batch | Gateway payout reference or verified batch mapping | Preserve batch membership and net payout |
| Payout batch → bank deposit | Payout reference ↔ bank transaction ID and deposit reference | Allow several items in one deposit |
In Toss Payments, paymentKey identifies the payment and transactionKey identifies the approval or cancellation transaction. The cancellation array also contains individual transaction keys. Core API, Cancel a payment.
Include provider, merchant ID, and test or production environment in stored keys. Do not connect transactions across merchants or environments merely because internal order numbers match. If one business order produces several payment requests, manage its business order ID separately from each request's order ID sent to the gateway.
An explicit settlement batch ID may be unavailable. The public Toss Payments Settlement schema does not document a common payout batch ID or bank deposit reference. Settlement object. Rows with the same payout date are therefore not automatically confirmed members of one bank deposit. Confirm the merchant, currency, payout statement, and deposit notification before finalizing the mapping; retain a candidate batch when evidence is insufficient.
If you also process international payments, preserve provider differences. Stripe's Payout reconciliation report describes transaction batches around automatic payouts and directs manual payouts to a separate Balance report. It does not establish that the same batch structure applies to Korean gateways. Stripe payout reconciliation report.
Align the meaning of amounts and statuses before linking
Combining source CSV files in one sheet is different from producing data that can be reconciled. Put the following items into collection rules first.
Amounts, currencies, and signs. Confirm the provider's units and currency and preserve the original values. This article's examples use integer amounts in KRW won; do not force that unit onto other currencies or reports. PostgreSQL documentation also recommends exact numeric types instead of floating point when exact monetary calculations are required. Choose integers with sufficient range or an explicit decimal precision, and define rounding separately according to the provider's actual rules. PostgreSQL numeric types.
Check whether cancellations are positive or negative in the source before converting them to internal signs. Avoid subtracting an already negative cancellation again, or deducting the cancellation once more from a post-cancellation balance. For currency conversion, distinguish payment currency, settlement currency, exchange rate and timing, and conversion-related items. Keep won and dollar totals separate when no conversion basis exists.
Transaction, settlement, and deposit statuses. Do not merge these into one completed state. In Toss Payments Payment.status, DONE means payment approval; card acquireStatus describes acquisition status. Neither does paidOutDate replace bank deposit evidence. Core API status and settlement fields.
The following separate internal columns are proposed. These names are not official gateway status codes.
| Internal dimension | Example values | When not to finalize automatically |
|---|---|---|
| Transaction verification | Approval confirmed / cancellation confirmed / unconfirmed | A cancellation was requested but completion is unproven |
| Settlement inclusion | Scheduled / included / held / needs review | Classifying a hold without supporting gateway evidence |
| Bank reconciliation | Not yet due / matched / difference / needs review | Only amounts match, or the deposit reference is unclear |
Fees, duplicates, and corrections. Separate the total settlement deduction from its components. Toss Payments documentation distinguishes fees, supplyAmount, vat, and payOutAmount. Settlement object. Multiple fields are not necessarily independent costs to add together: check how totals include components. This article does not specify VAT rates or journal entries.
Also distinguish transaction linkage keys from source-row deduplication keys. Manage transaction and settlement files separately. If one transaction expands into several settlement rows for fees or adjustments, retain the provider's row ID or item and sequence fields. Do not delete distinct settlement rows just because their transaction keys match, or repeatedly sum the payment principal for every linked row.
A renamed file does not represent new transactions. Preserve source file hashes and collection history, and check duplicates using that format's row identity rules. Identical content under the same key is recollection; changed amounts or statuses under the same key are correction candidates. Do not overwrite history with a rule that the latest file is always correct.
Work through how KRW 190,000 becomes KRW 135,800
This is a design example, not actual customer data, a gateway response, contractual fees, or a settlement schedule. Assume one fictional merchant, integer KRW amounts, and data collected through September 21, 2026, 23:59:59 Korea time. Initial order amounts represent the final charges, and all orders were approved. Apart from the cancellations and fees below, the example has no additional tax deductions, holds, currency conversion, adjustments, or chargebacks.
O-A was paid for KRW 100,000 and then partially canceled for KRW 20,000. O-B split KRW 60,000 into two payments. O-C's KRW 30,000 is outside this payout batch and must be checked in a later settlement.
| Business order | Order date | Initial order amount | Request-specific gateway order ID → payment ID |
|---|---|---|---|
| O-A | September 14 | KRW 100,000 | PG-A01 → P-A |
| O-B | September 14 | KRW 60,000 | PG-B01 → P-B1, PG-B02 → P-B2 |
| O-C | September 21 | KRW 30,000 | PG-C01 → P-C |
| Total | KRW 190,000 | 3 business orders, 4 approved payments |
The next table expands those orders into individual transaction events. Fee deductions are positive for amounts taken from the payout and negative for amounts returned. The KRW 600 fee reversal on cancellation is also an assumption specific to this example.
| Transaction ID | Order / payment | Processing date and type | Transaction change | Fee deduction | Payout batch |
|---|---|---|---|---|---|
| T-A1 | O-A / P-A | September 14 approval | +KRW 100,000 | +KRW 3,000 | B-01 |
| T-A2 | O-A / P-A | September 15 cancellation | −KRW 20,000 | −KRW 600 | B-01 |
| T-B1 | O-B / P-B1 | September 14 approval | +KRW 40,000 | +KRW 1,200 | B-01 |
| T-B2 | O-B / P-B2 | September 14 approval | +KRW 20,000 | +KRW 600 | B-01 |
| T-C1 | O-C / P-C | September 21 approval | +KRW 30,000 | Unconfirmed | Outside this batch |
B-01 is an internal batch ID assigned after checking the four transaction rows in the original settlement. Assume a fictional statement with September 14 and 15 settlement reference dates and a September 21 scheduled payout. Items with different reference dates can be reconciled together when the statement confirms they belong to the same batch.
| B-01 settlement row | Calculation | Net payout contribution |
|---|---|---|
| T-A1 | 100,000 − 3,000 | +KRW 97,000 |
| T-A2 | −20,000 − (−600) | −KRW 19,400 |
| T-B1 | 40,000 − 1,200 | +KRW 38,800 |
| T-B2 | 20,000 − 600 | +KRW 19,400 |
| Total | Transaction change 140,000 − net fee deduction 4,200 | KRW 135,800 |
The bank record is deposit transaction D-01 on September 21 for KRW 135,800. Assume the gateway deposit notification and bank record share a usable reference REF-01, and the responsible person has verified the REF-01 to B-01 mapping.
The cross-check is therefore:
All orders KRW 190,000 − confirmed cancellations KRW 20,000 = net payments KRW 170,000
Net payments KRW 170,000 − transactions outside this batch KRW 30,000 = batch transaction change KRW 140,000
Batch transaction change KRW 140,000 − net fee deductions KRW 4,200 = payout KRW 135,800
Payout KRW 135,800 − corresponding bank deposit KRW 135,800 = reconciliation difference KRW 0The KRW 34,200 difference between net payments and the bank deposit consists of KRW 4,200 in fees and KRW 30,000 in principal outside this batch. That KRW 30,000 is transaction principal not yet included in this payout, not the amount of the next deposit itself. Later fees and settlement records still need checking. Do not treat this equation as a universal settlement formula for every period and gateway.
There is another trap. Omitting both T-A2's −KRW 19,400 and T-B2's +KRW 19,400 leaves the payout total unchanged at KRW 135,800. A totals-only check misses an omitted cancellation and approval. Check that B-01 contains all four members, T-A1, T-A2, T-B1, and T-B2, and that each key and amount corresponds to the source.
From transaction alerts to response and provider review — Follow symptom-based checks to establish transaction status and handle incidents, refunds and recurring issues.
Separate automatic matches from items requiring human review
Limit automatic matches to records that pass both identity checks and amount reconciliation. Confirm the same provider, merchant, and currency; linkage through transaction keys; correct interpretation of approvals and cancellations; and no assignment of one row to multiple batches. The bank stage also needs verified payout references and membership.
If the sender and amount match but two statements could correspond, there are two candidate matches. Do not choose the first row found or finalize a combination merely because its total fits. Amounts and dates narrow candidates; they do not establish identity. Human confirmation must also record the selected originals, supporting evidence, reviewer, and time.
Do not use tolerance as a way to erase every difference. Specify the item, currency, rounding basis, and limit to which it applies, and report differences accepted within tolerance separately. An unexplained KRW 1 difference should remain unexplained.
| Difference type | Evidence to check first | Handling and owner |
|---|---|---|
| Not yet reflected | Collection cutoff, query reference date, contractual schedule | Operations records the next query time; investigate delay after the deadline |
| Fee difference | Itemized statement, applicable contract, rounding and total/component relationships | Settlement owner checks the formula and period; do not force a match with an arbitrary average fee rate |
| Cancellation timing difference | Original payment and cancellation keys, processing status, later settlements | Operations retains cancellation as a separate event and tracks inclusion |
| Missing, duplicate, or corrected collection | File hash, pagination records, previous values for the same key | Engineering recollects and reprocesses sources without deleting or overwriting history |
| Hold or release | Gateway-provided reason, amount, and release details | Classify only with evidence; settlement owner sets a review deadline and contact route |
| Adjustment, chargeback, or dispute | Provider item code, original transaction, adjustment or dispute records | Distinguish from ordinary cancellation and follow a separate operating procedure |
| Unconfirmed deposit or duplicate assignment | Payout statement, bank original, payout reference, existing allocations | Settlement owner checks gateway and bank evidence; equal amounts alone remain unconfirmed |
Handle cancellations after settlement separately. Toss Payments' cancellation guide explains offsetting them against a later settlement. Instead of replacing a past deposit with a post-cancellation value, link the original payment, cancellation, and subsequent inclusion to explain both historical records and later changes. Cancel a payment.
The hold, adjustment, and chargeback categories above do not mean every gateway offers identical fields. Stripe, for example, separately describes balance transaction categories for disputes, dispute reversals, and reserves. Map Korean gateway records only to items verified in their contracts, statements, or notices. Leave unknown codes as unclassified exceptions, rather than miscellaneous fees. Stripe reporting categories.
Explain earlier decisions even after retrieving a file again
Keeping only reconciliation results makes it difficult to explain a previous close when the source file is corrected. Manage collected originals, calculation results, and human exception decisions separately.
Collection records should contain source, merchant, period, query conditions, collection time, file hash, and completeness. Calculation records should join source version, transformation rule version, reconciliation rule version, and processing run ID. Exception records should retain owner, review deadline, rationale, reprocessing history, and whether the case reopened. If the same originals and rules produce different results, investigate processing before transaction differences.
Preserve a correction as a new source version and use provider documentation and verification results to identify which earlier rows it replaces or adjusts. Retain past confirmed results, recalculate only affected batches, and define when closed exceptions reopen. Adding the entire corrected file to the previous file confuses recollection with new transactions.
Preserving originals does not mean retaining credentials and personal information indefinitely. Minimize collection and specify access permissions and retention periods. Prefer read-only permissions for reconciliation and separate permissions for refunds, payout requests, and finalizing accounting entries. A reconciliation program finds differences; discovering a difference should not automatically move money.
A small team can start with a spreadsheet
With few data sources, stable keys, and an owner able to resolve exceptions, organize original records, mapping tables, and difference categories before purchasing a new system. First explain the calculation for one merchant, one currency, and one payout batch. Automating link rules before you can explain the result also repeats incorrect matches faster.
Consider automating collection and history when corrected files recur across merchants and channels, past results are difficult to reproduce, or ownerless exceptions accumulate. Do not judge success only by a higher automatic match rate. Also track unclassified differences, overdue payouts, records without keys, duplicate assignments, and exceptions past their handling deadline.
The existing Payment reconciliation rules and operating runbook template provides a structure for shared keys, mismatch handling, and a runbook. Use this article's example to understand the connections, then record actual operating rules in that resource.
Ultimately, answer four questions: Which transaction is this, which settlement included it, did the money actually arrive, and who will investigate the remaining difference? Only then does a zero difference have meaning. Settlement amounts are not accounting revenue or profit, and reconciliation records do not replace the accounting ledger.
When data sources, linkage keys, and exception handling need to be designed together, review the scope of IXC's reconciliation automation service.
