An operator running a platform where other people sell picks up obligations that a direct seller does not have. Under GST there is a collection requirement on the value of supplies made through the platform; under income tax there is a deduction requirement on payments to participating sellers. Both are computed by the operator and both are reported by the operator.
The consequence for software is that the payout calculation is no longer commission and settlement. It is gross order value, less commission, less tax collected, less tax deducted, plus adjustments for returns and cancellations — and each of those components needs to be stored separately, because each is separately reported.
Returns are where implementations break. Tax collected on a sale that is subsequently returned must be adjusted, and the adjustment lands in a different period from the original transaction. Systems that compute tax from a live view of orders rather than from an immutable transaction ledger produce numbers that change retrospectively, which makes filed returns impossible to reconcile.
Sellers need visibility. Every participating seller has to reconcile what you collected and deducted against their own books, and they will ask. A downloadable statement per seller per period, matching exactly what you filed, prevents a support burden that otherwise arrives every month.
Thresholds and rates change, and they change on effective dates. Store them as dated configuration rather than constants, for the same reason tax rates need dating: a return filed last quarter must remain reproducible after the rule changes.
Get the specifics confirmed by a practising chartered accountant before going live. The structure described here is stable; the rates, thresholds and forms are not, and this is a domain where being approximately right has direct financial consequences.
