Vendor commission on Shopify is tracked by attributing every order line to a vendor, applying that vendor's rate to a base you have defined in writing, and adjusting the result whenever the order changes. Shopify records the vendor on the product and does none of the rest. The arithmetic looks trivial until the first refund, the first mid-month rate change, or the first product nobody assigned a vendor to.
Attribution comes before arithmetic
Every commission calculation starts from one question: whose sale was this?
Shopify answers it with the vendor field on the product, which is the right hook — but it is a free-text field, and free text drifts. "Jane Ceramics", "Jane ceramics", "Jane's Ceramics" and a trailing space are four vendors as far as any reporting is concerned. A month later somebody is reconciling four rows that should be one.
Two habits prevent most of this:
- Treat the vendor field as a key, not a label. Pick one exact string per vendor and never type it again by hand — copy it, or let the app set it.
- Never let a product save without one. An unassigned product sells and earns nobody anything. Nobody notices until a vendor asks why a sale they know happened is missing from their statement, and you have no good answer because they are right.
Automatic product-to-vendor matching — by tag, collection or title pattern — removes this class of error rather than catching it. It is worth setting up before the first vendor rather than after the first complaint. Linking products to vendors automatically covers the mechanics.
Decide what the percentage is a percentage of
"Sixty percent" is not a commission agreement. Sixty percent of what?
Each of these produces a different number on the same order, and every one of them is defensible:
- Gross sale price — the price on the product, before anything.
- After discounts — what the customer actually paid for that item.
- Excluding shipping — almost always correct; shipping is a cost you incurred, not revenue the vendor generated.
- Excluding tax — usually correct, and sometimes not, depending on who is seller of record.
- After payment processing fees — defensible, and the one vendors most often object to, because the fee is a cost of how you chose to take payment.
The discount question causes the most disputes. If you run a 20% store-wide sale, does the vendor absorb a share? If commission is on the gross price, you funded the entire discount out of your 40%. If it is on the discounted price, the vendor shared it without being asked.
Neither is wrong. What is wrong is not deciding, because then it gets decided by whatever the software happens to do, and the vendor finds out from a statement. Write it into the agreement in one sentence: "Commission is 60% of the discounted item price, excluding shipping and tax."
Three commission models
- Flat percentage per vendor. One rate across everything they supply. Easiest to explain, audit and argue about. The right default, and enough for most stores.
- Per product or per SKU. For vendors whose range spans different margins — their handmade pieces at 60%, their bought-in stock at 30%. Necessary sometimes, and every extra rate is another thing that can be applied wrongly.
- Fixed amount per unit. "£12 per piece, whatever it sells for." Common in consignment for standardised items. Its real advantage is predictability: the vendor knows what they earn regardless of what you discount, which removes the discount argument entirely.
Start with a flat percentage. Add complexity only when a specific arrangement demands it, not because the software supports it.
Rate changes and the date problem
A vendor renegotiates from 55% to 60%, effective the first of next month. Simple enough — until you realise what "effective" has to mean in the data.
Commission must be calculated with the rate that applied on the date of the order, not the rate that happens to be stored today. If the system reads the current rate at payout time, then changing a rate silently rewrites the value of every past unpaid order, and if you ever recalculate an old period you get a different answer than you did the first time.
The test for any tool: change a vendor's rate, then look at a statement for a period before the change. If the numbers moved, the tool stores rates rather than applying them, and your historical records are not stable.
The same applies in reverse. If a vendor queries a payout from four months ago, you need to be able to reconstruct it exactly. A system that only holds current state cannot do that.
What an order actually contains
Commission is calculated per line, not per order, and a single Shopify order can hold lines from several vendors. That is the normal case in a consignment store and it has consequences:
- Shipping is one charge across several vendors. Which is why excluding it from the commission base is the simple answer.
- An order-level discount has to be allocated. A £10 off code on a £100 order with two vendors is not £5 each unless their lines were equal. Proportional allocation by line value is the usual answer — and it needs to be the documented one.
- Partial fulfilment and partial refunds hit individual lines, so commission has to move at line level too.
Any system that treats an order as a single number with a single vendor will produce wrong answers the first time a customer buys from two makers at once.
Refunds change the answer after you have given it
The hardest part of commission tracking is that an order is not final when it is placed. Refunds, cancellations and partial returns all change what a vendor earned, sometimes weeks later.
The three cases that matter:
- Full refund before payout. Easy — the commission simply should not be paid.
- Partial refund. A £20 goodwill gesture on a £100 order is not a cancelled sale. Commission should reduce proportionally, not disappear.
- Refund after payout. The genuinely awkward one, and the reason to pay in arrears.
Refunds break vendor payouts deals with this in full, because it is the failure that costs real money rather than just time.
Making the calculation checkable
A commission figure a vendor cannot verify is a figure they will eventually dispute, and you will spend an afternoon reconstructing it.
Anything you produce should let a vendor get from a sale they remember to the number in their account:
- The order, dated and numbered, with the product and quantity.
- The base the rate was applied to — not just the final commission.
- The rate itself, per line, as it stood on the order date.
- Adjustments as separate lines referencing their original order.
Showing the base is the one most often skipped and the one that prevents the most questions. "£100 × 60% = £60" answers itself. "£54" invites an email.
Where the effort actually goes
Merchants moving off a spreadsheet usually expect the arithmetic to be the hard part. It is not — a spreadsheet multiplies perfectly well.
The time goes to the things around it: chasing an unassigned product, working out which rate applied in March, allocating an order-level discount across two vendors, adjusting for a refund that landed after a payout, and answering "how am I doing this month" by hand for each vendor.
That is the honest case for automating: not the multiplication, but keeping attribution clean, rates dated and refunds connected to the payouts they affect. Payvenda handles these, and the free plan covers five vendors — enough to run one period in parallel with your existing sheet and compare the two before trusting either.
Where to go next
Get attribution right first; everything downstream depends on it. Then write the commission base into the agreement in one sentence. Then decide your payout cadence with the returns window in mind — which is covered in the consignment and vendor payouts guide.
