Marketplace numbers disagree
Orders, settlement, Ads, fees or payout reports produce different totals and the team cannot explain the variance quickly.
D2 Technology · Commerce Control
A commerce control layer for numbers that need to be explained before they are acted on.
D2 Commerce Control is a marketplace reconciliation and contribution reporting layer for TikTok Shop and Shopee across Orders, settlement, Ads, platform fees, COGS, SKU mapping, payout and exceptions.
Direct answer
What does Commerce Control actually do?
It turns marketplace exports into an explainable operating model. Orders, settlement, Ads, fees, COGS and SKU mappings are normalized and reconciled first; revenue-period, contribution and payout views are produced only after the system can state which sources, formulas and exceptions sit behind the number.
Core principle: a metric is decision-ready only when its source coverage, identifiers, formulas and unresolved exceptions are visible.
Reporting depends on spreadsheets
Recurring commerce reporting requires manual exports, joins, mapping and cleanup before management can trust the numbers.
GMV is visible, contribution is not
The team can see sales and ROAS but cannot consistently connect platform fees, Ads, COGS and other verified costs to commercial contribution.
Payout needs its own control view
Revenue-period performance and settlement cash realization are being mixed together even though they answer different operating questions.
Control architecture
The dashboard is the last layer. Trust is built underneath it.
Commerce Control is designed around data control before visualization. If a source, mapping or formula cannot be explained, the system should surface that limitation instead of making the dashboard look complete.
Source coverage
Register the marketplace, advertising, settlement and cost sources required for the operating model and make missing coverage visible.
Normalization
Standardize dates, currencies, order identifiers, transaction identifiers, SKUs and source-specific fields before calculations are compared.
Canonical mapping
Connect platform SKUs, internal products and stable business identifiers so revenue and cost lines can resolve to the same commercial object.
Reconciliation
Compare expected and observed records across Orders, settlement, Ads and cost inputs and surface unmatched or conflicting records as exceptions.
Contribution model
Build management views from verified inputs such as recognized revenue, Ads, platform fees and COGS without presenting unverified assumptions as profit.
Exception & action layer
Move unresolved mappings, payout variance, missing source data and commercial anomalies into an explicit review queue rather than hiding them in totals.
Separate operating views
Revenue, contribution and payout should reconcile — not collapse into one number.
Revenue-period view
Answers what commercial activity belongs to the reporting period using the defined revenue and order rules.
Contribution view
Shows the operating contribution model after verified Ads, platform fees, COGS and other approved cost inputs are applied.
Settlement & payout view
Tracks cash realization and settlement status separately from revenue-period performance, then reconciles the two through stable transaction or order keys.
Management boundary
Commerce Control is an operating-management system. It does not automatically replace statutory accounting, tax reporting or audited financial statements. Contribution is shown only to the extent that the required cost inputs and formulas have been verified.
Decision states
Every reporting cycle should end with a data decision before a commerce decision.
Trust
The required sources are present, mappings resolve and reconciliation checks fall within the accepted operating rules.
Investigate
A variance or missing record needs source-level review before management treats the related number as decision-ready.
Correct
A mapping, formula, source import or business rule must be repaired and the affected records reprocessed or reconciled.
Act
The data is sufficiently trusted to support a commerce decision such as Scale, Hold, Fix or Retest.
Trust the data
Commercial review
Scale / Hold / Fix / Retest
Operating cadence
Collect → Normalize → Reconcile → Model → Decide.
Collect
Orders · settlement · Ads · fees · COGS · mappings
Normalize
Periods · IDs · SKUs · fields · currencies
Reconcile
Missing · duplicate · unmatched · conflicting records
Model
Revenue · contribution · settlement · payout
Decide
Trust · Investigate · Correct · Act
Implementation & knowledge
The control layer sits inside a wider commerce reporting system.
Commerce Reporting & Reconciliation Automation
The implementation service for source mapping, reconciliation logic, reporting formulas, exceptions and recurring operating delivery.
ExploreTikTok Shop Report Files
How different marketplace report files answer different questions and why one export should not be treated as the entire source of truth.
ExploreTikTok Shop Fees & Settlement
Why fee, settlement and payout data must be separated from headline GMV before reconciliation is meaningful.
ExploreTikTok Shop: GMV vs Profit
Why marketplace GMV is an operating signal rather than a complete profitability measure.
ExploreGMV Max: ROAS vs Profit
How paid-media signals connect to contribution economics after the rest of the commerce cost stack is verified.
ExploreCommerce Profitability
The commercial logic behind contribution reporting, cost inputs and decision-ready marketplace economics.
ExploreFAQ
Commerce Control, explained directly.
What is the D2 Commerce Control Dashboard?
It is a commerce operating control layer that brings marketplace Orders, settlement or income data, advertising spend, platform fees, verified COGS and SKU mapping into an explainable model for reconciliation, contribution reporting, payout visibility and exception handling.
What data sources does Commerce Control use?
The exact source set depends on the marketplace and operating scope. Typical inputs include order-detail data, settlement or income reports, payout data, advertising reports, product and SKU mapping, and verified cost inputs such as COGS. Missing sources are treated as coverage gaps rather than silently estimated.
Does Commerce Control replace accounting software?
No. Commerce Control is designed for marketplace operations, reconciliation and management decision support. Its contribution model is not automatically a statutory accounting statement, tax ledger or audited financial report.
Why are revenue, contribution and payout separated?
They answer different questions. Revenue-period reporting describes commercial activity in a defined period, contribution applies verified operating costs to that activity, and payout describes cash realization through marketplace settlement. The views can be reconciled without being collapsed into one number.
How does the dashboard handle missing or conflicting data?
Missing mappings, unmatched transactions, duplicate records, settlement variance and unavailable source coverage are surfaced as exceptions. The goal is to make uncertainty visible before a number is used for a commercial decision.
Can Commerce Control show SKU-level performance?
Yes when source data and canonical SKU mapping are sufficient. Revenue, advertising and verified costs can then be resolved to the same product object so SKU-level contribution and commercial signals can be reviewed consistently.
Does the dashboard calculate true profit automatically?
Only to the extent that the required cost inputs and formulas are verified. D2 does not treat unknown costs as zero or present incomplete contribution data as final profit. The model should state which inputs are included and which remain unavailable.
How is this different from a normal dashboard?
A normal dashboard may visualize whatever data is available. Commerce Control is designed around source coverage, canonical identifiers, reconciliation checks, explicit formulas and exception states before a metric is treated as decision-ready.
Implementation service