Vendor settlement is the part of a marketplace that turns a software platform into a finance operation. Every order creates a payable, every refund changes it, and every payout cycle tests whether the vendor trusts your numbers. If the statement cannot be reconciled, the vendor will call; if the calls are frequent, they will leave.
The goal is not a clever formula. It is a statement that shows exactly how the payout was calculated and a process that pays on time.
The settlement equation
Vendor payable = food subtotal + vendor delivery share + approved adjustments − commission − platform-funded discounts − refunds charged to vendor − taxes/withholding.
Every line needs a source. If the platform funded a discount, the vendor should not absorb it. If the vendor caused a refund, the treatment should be defined in the contract. Ambiguity is the enemy of trust.
| Line | Example | Who bears it |
|---|---|---|
| Food subtotal | $1,000 | Vendor revenue |
| Commission (15%) | −$150 | Vendor |
| Platform-funded discount | −$50 | Platform |
| Vendor-funded discount | −$30 | Vendor |
| Refunds (vendor fault) | −$40 | Vendor |
| Delivery fee share | +$60 | Vendor (if self-delivery) |
| Net payable | $840 | — |
Illustrative. Tax, withholding and delivery terms vary by country and contract.
Choose a payout cycle you can operate
Weekly payouts are a strong trust signal but require clean reconciliation. Biweekly or monthly cycles are easier on finance but can make vendors feel exposed, especially small restaurants. Whatever you choose, pay on the same day every cycle and publish the cut-off.
Hold a reserve only if the contract allows it. A rolling reserve for refunds is common in marketplaces, but it must be explained and capped. An unexplained hold looks like a cash-flow problem.
Refunds, cancellations and disputes
Define fault before the first order: restaurant rejected after preparation, rider failed delivery, customer claimed missing item, platform cancelled due to no rider. Each scenario needs a default treatment and an appeal path. The vendor should be able to see the order, the reason and the evidence.
Do not let support agents adjust settlements without a reason code and an audit trail. Small manual adjustments are how finance loses control.
The statement vendors need
- Order-level detail: order ID, date, food subtotal, discount, refund, commission.
- Summary totals by category.
- Opening balance, payouts and closing balance.
- Reason codes for every adjustment.
- Downloadable CSV and a printable PDF.
- A named contact for disputes and a response deadline.
Reconciliation before payout
- Lock the period and freeze late adjustments.
- Match orders, refunds and chargebacks to the ledger.
- Check negative balances and carry them forward according to policy.
- Approve the batch and export the bank file.
- Send statements before or with the payment.
- Log every dispute and resolve it in the next cycle.
What to test in the software
Run a test order with a discount, a partial refund and a self-delivery fee. Check that the vendor statement matches your manual calculation to the cent. Then run a second order with a platform-funded promotion. If the software cannot separate platform and vendor funding, finance will spend every payout cycle fixing it.
See the management software, the COD reconciliation guide, or restaurant onboarding.
Settlement mistakes that destroy trust
- Mixing platform-funded and vendor-funded discounts in one line.
- Changing a payout without a reason code or audit trail.
- Paying late without telling the vendor before the due date.
Send the statement before the money moves. A vendor who can reconcile the numbers will call less and stay longer.
