A network marketing business in India does not simply move money to members. It withholds tax, issues documents, verifies identity and keeps records that must still make sense when someone asks about them a year later. Software that ignores this works right up until your first real payout cycle, and then becomes your accountant's problem.
This is not tax advice — your chartered accountant sets the rates, thresholds and treatment for your specific business. What follows is what the platform has to be able to do once they have told you.
Withholding has to happen at calculation time
The common mistake is treating tax deduction as a reporting step: calculate payouts, pay them out, work out the tax afterwards. That produces two sets of numbers that never quite agree.
Deduction belongs inside the payout calculation. For every credit the system should record the gross amount, the deduction applied, the rate used and the net amount paid. Members see the net figure, but you retain the full breakdown — and when a member asks why they received less than the plan implied, the answer is on the screen rather than in a spreadsheet.
Rates change, and they change with effect from a date. Your software needs to apply the rate that was in force for the cycle being paid, not the rate configured today. A platform that stores only a single current rate cannot correctly recalculate last quarter.
Thresholds are stateful
Most withholding rules involve a threshold — an amount below which nothing is deducted, above which it is. That makes deduction dependent on a member's cumulative earnings across the financial year, not just the current payout.
So the system has to track running totals per member per financial year, know when the financial year rolls over, and handle the cycle where a member crosses the threshold mid-payout. None of that is difficult, but all of it has to be designed in. Retrofitting cumulative tracking onto a platform that only ever looked at one cycle at a time is genuinely painful.
KYC gates the money, not the signup
Verification exists to answer one question at payout time: are we paying the person we think we are paying?
Practically, that means the platform needs document capture, a review queue where a human approves or rejects with a reason, a clear status on every member, and a rule about what an unverified member can and cannot do. Most networks let people join and build without verification, but block withdrawal until it is complete. That is a sensible default, and it has to be enforced by the system rather than by an admin remembering.
Rejections need a reason the member can act on. "Rejected" with no explanation generates a support ticket every single time.
Invoicing is part of the product
If you sell products — a repurchase store, joining kits, anything with GST — invoices are not an afterthought. Every order needs a compliant invoice with the right tax breakdown, and members expect to download theirs without asking anyone.
The detail that catches people out is that the tax treatment can depend on where the member is. A platform that applies one flat rate regardless of state will produce invoices your accountant has to correct by hand, every month, forever.
Withdrawals need a workflow, not a button
A withdrawal request touches the ledger, the tax calculation, the KYC status and eventually a bank transfer. It needs states — requested, approved, processing, paid, failed — and every transition needs to be recorded with who did it and when.
The failure case matters most. When a bank transfer bounces because of a wrong account number, the money has to return to the member's wallet, the request has to show as failed with a reason, and the member has to be able to correct their details and try again. Platforms that model withdrawal as a single irreversible action turn every failed transfer into manual reconciliation.
What to ask for
If you are specifying a platform, ask for these explicitly:
- Gross, deduction, rate and net stored on every payout row
- Deduction rates that are effective-dated, not a single current value
- Cumulative per-member, per-financial-year tracking for thresholds
- A KYC queue with reasons on rejection, gating withdrawals
- State-aware tax on invoices, downloadable by the member
- Withdrawals as a state machine, with a defined failure path
None of this is exotic. All of it is much cheaper to build in at the start than to add once real money has moved through the system.