01
Capture order evidence
Preserve the order ID, SKU, quantity, status, created timestamp and the revenue basis used for sales-period reporting.
← Commerce insights
D2 Commerce Knowledge · TikTok Shop Settlement
TikTok Shop Orders explain sales. Settlement explains cash and deductions.
An order can belong to one sales period and settle in another. Treat Orders and Settlement as two evidence layers connected by stable identifiers, then preserve pending balances, recorded deductions and unresolved exceptions instead of forcing both sources into one revenue number.
Direct answer
How should TikTok Shop fees and settlement be reported?
Use Orders to describe what sold and when the customer transaction occurred. Use Settlement or Income evidence to describe what the platform paid, deducted, refunded or adjusted. Reconcile the two with stable identifiers, but keep sales-period performance and cash realization as separate views. A pending settlement is a timing state until evidence shows it is a genuine exception.
Reconciliation model
Order evidence → settlement evidence → timing bridge → exceptions.
02
Classify commercial state
Separate valid, cancelled, refunded or otherwise adjusted order states according to the declared reporting rule before calling the sales number final.
03
Load settlement evidence
Preserve payout references, settlement timestamps, recorded deductions, commissions, refunds, adjustments and payable or paid amounts.
04
Normalize identifiers
Standardize order IDs, currencies, timestamps and any platform settlement keys before attempting to reconcile the two source layers.
05
Match and classify
Connect settlement rows to the relevant order or commercial event and classify each amount as settled, pending, adjusted or unresolved.
06
Build the timing bridge
Explain why sales-period revenue and settlement-period cash differ without rewriting one timeline to imitate the other.
07
Surface exceptions
Keep unmatched orders, unknown deductions, duplicate mappings and stale pending states visible until an owner resolves them.
Reconciliation formula
Expected payout = settled order value − recorded fees − commissions − refunds/adjustments ± platform settlement adjustments
Use this as an operating reconciliation model, not as a universal platform fee formula. The actual line items and labels should come from the relevant settlement evidence for the reporting period.
Source layers
One source should answer one financial question.
Orders
What sold in the commercial period?
Order ID · SKU · quantity · status · created date · order-period revenue
Sales performance, SKU mix, cancellation/refund state and valid-revenue analysis
Settled Income / Settlement
What has the platform financially realized?
Settlement reference · realized payout · recorded fees · commission · refunds · adjustments
Cash realization, actual deductions and reconciliation to underlying orders
On-hold / unsettled state
Which valid commerce amounts have not realized yet?
Pending reference · expected amount · state · relevant dates
Timing bridge between sales activity and payout without misclassifying pending cash as missing revenue
Exception register
Which items cannot yet be trusted or matched?
Original reference · amount · error class · last investigation · owner
Recovery, auditability and decision boundaries for unresolved financial evidence
Timing states
Pending cash is not the same state as missing revenue.
StateMeaningReporting treatment
Order created
Commerce event exists
Use the order timestamp for sales-period analysis, subject to the reporting rule for validity and later adjustments.
Valid but unsettled
Commercial activity exists; cash is pending
Keep the order in the sales view and a separate pending-settlement state rather than removing it from revenue because cash has not arrived.
Settled
Platform has recorded payout and deductions
Use settlement evidence to explain realized fees, commissions, adjustments and payable/paid amounts.
Adjusted after initial settlement
Cash history has changed
Preserve the later adjustment as a new financial event and reconcile it to the original business context instead of rewriting the historical source row silently.
Refunded / reversed
Commercial and financial state changed
Apply the declared revenue rule and connect the corresponding refund or adjustment evidence when it appears in settlement.
Unmatched
Evidence exists without a reliable bridge
Keep it as an exception. Do not fabricate an order relationship or fee category to close the report.
Reconciliation controls
The bridge needs identity, time, amount semantics and raw evidence.
Stable order identity
Use the platform order ID or another stable business identifier as the primary bridge between commercial and financial evidence. Display names, buyer names or product titles are not reliable reconciliation keys.
Normalized time basis
Keep created, settled, paid and adjustment timestamps as distinct fields. Normalize time zones for comparison, but do not replace their business meaning with one generic date.
Currency and amount semantics
Declare the currency and whether a field represents gross order value, valid revenue, deduction, payable amount or paid cash before comparing totals.
Raw-source traceability
Preserve enough original evidence to trace every reconciled or exceptional amount back to the platform source that produced it.
Exception layer
Do not force unresolved settlement evidence into a clean total.
Order has no settlement yet
May be a normal timing difference
Keep pending until the expected settlement lifecycle completes or another state proves intervention is needed.
Settlement has no matched order
Financial evidence lacks a reliable commercial parent
Investigate identifiers, adjustment type and timing before assigning it to revenue or fees.
Unknown fee / adjustment
Amount exists but classification is unresolved
Preserve the platform label and source row; classify only when the business meaning is supported.
Duplicate financial mapping
One deduction or payout may be counted more than once
Resolve the join or unique-reference rule before rolling the amount into shop totals.
Currency / timestamp mismatch
Rows can appear unmatched or ratios can be distorted
Normalize format and declared reporting time zone before retrying reconciliation.
Refund appears in a later period
Sales and cash periods diverge
Keep the later financial event visible and apply the chosen sales-period restatement or adjustment policy explicitly.
Decision rules
A settlement gap should trigger diagnosis, not an automatic business conclusion.
Sales-period revenue is healthy; payout is temporarily lower
Check pending settlement and recorded deductions before treating the gap as revenue loss.
Payout drops while order volume is stable
Inspect fee, commission, refund and adjustment mix as well as settlement timing before changing commercial strategy.
A fee line increases materially
Compare the recorded settlement evidence across compatible periods and commercial contexts; do not assume the cause from one aggregate percentage.
Unmatched settlement grows
Prioritize reconciliation quality before using payout-derived metrics for SKU or campaign decisions.
Orders and Settlement totals differ on the same calendar month
Check whether the comparison is mixing order-created date with settlement or paid date; the mismatch can be structural rather than erroneous.
A valid order remains pending unusually long
Escalate the specific order or settlement state as an exception rather than changing the whole P&L rule to make the totals match.
Settlement checklist
Before reporting payout, verify the bridge back to commerce evidence.
Define the sales-period revenue rule separately from the settlement-period cash rule.
Preserve raw Orders and Settlement/Income evidence before transformation.
Use stable order and financial references rather than names or row position for reconciliation.
Normalize currencies, identifiers and time zones while preserving created, settled, paid and adjustment timestamps separately.
Use actual recorded deductions where settlement evidence exists instead of one assumed fee percentage.
Keep creator or Affiliate commission visible as its own deduction when the source provides it.
Track on-hold or unsettled amounts as a timing state rather than automatically treating them as missing revenue.
Preserve refunds and later adjustments as financial events that may occur after the original sales period.
Keep unmatched orders, unmatched settlement lines and unknown deductions in an exception layer.
Do not silently drop duplicate or unresolved mappings just to make aggregate totals reconcile.
Report sales performance and cash realization as two views connected by a reconciliation bridge.
End each reconciliation review with an owner and next action for every material exception.
Related paths
Connect settlement to shop operations, profitability and source files.
TikTok Shop Operations
Return to the broader operating model that separates GMV, valid revenue, contribution and payout across the shop.
OpenTikTok Shop GMV vs Profit
Connect sales-period revenue and actual deductions to Ads, commission, COGS and contribution profit.
OpenTikTok Shop Files Required for P&L
See the minimum evidence set for Orders, Settlement/Income, Ads and SKU-level COGS reporting.
OpenTikTok Shop reconciliation
Need Orders, deductions and payout reconciled into one traceable operating view?
D2 can structure sales-period reporting, settlement reconciliation and exception handling so finance and commerce teams can explain why revenue, pending balances and realized cash differ.
Discuss reporting & reconciliationFAQ
TikTok Shop fees and settlement questions
What is the difference between TikTok Shop Orders and Settlement data?
Orders explain the commercial activity: order identifiers, SKU, quantity, status, created date and the sales-period revenue basis. Settlement or Income data explains realized payout, recorded platform deductions, commissions, refunds and adjustments. The two should reconcile through stable identifiers, but they answer different questions and should not share one forced date basis.
Why can TikTok Shop payout be lower than sales-period revenue?
A lower payout can reflect settlement timing, pending balances, recorded fees, creator or Affiliate commission, refunds, adjustments or other platform deductions. Investigate the bridge between Orders and Settlement before treating the difference as lost revenue or a reporting error.
Is pending settlement the same as missing revenue?
No. A valid order can remain unsettled at the end of a reporting window. Pending settlement is a timing state between commerce activity and cash realization. It should stay visible until it settles, is adjusted or becomes a genuine reconciliation exception.
Should TikTok Shop fees be modeled as one fixed percentage?
Not when settlement evidence is available. Fee names, fee structures, commissions, promotions and adjustment rules can change by period or commercial context. Use the recorded deductions in the relevant settlement evidence and keep any estimate or planning assumption explicitly separate from realized reporting.
What keys should be used to reconcile Orders and Settlement?
Prefer stable platform or business identifiers such as order ID and the most granular settlement reference available, then normalize format, currency and timestamps before joining. SKU can support product analysis, but it should not replace the order or settlement identity used to prove the financial relationship.
How should unmatched settlement lines or unknown deductions be handled?
Keep them in an exception layer with the original reference, amount, date, classification state and recovery owner. Do not silently drop unmatched lines or force them into a convenient fee category merely to make the reconciliation total.