Shopify refunds and credit notes
A refund becomes a posted credit note against the invoice that order was billed as. The part worth reading carefully is the restock rule: a refund only puts goods back into your warehouse when goods actually came back. Money and stock are treated as separate facts.
Last reviewed against the implementation on
At a glance
- Trigger
- A refund created in Shopify
- Becomes
- A posted Credit Note
- Restock
- Only when the refund carries return lines
- Money-only refund
- No stock movement at all
- No invoice yet
- Waits, then becomes replayable
What starts it
A refund created in Shopify. There is no toggle for refunds and no import of historical ones — the integration listens for the event and acts on it. Refunds only travel inward; Bizmitra does not issue refunds to your store.
A refund of zero or less is ignored outright. It carries no money and would post an empty document.
How the amount is worked out
Bizmitra adds up the refund's successful money transactions. If there are none — which happens on a restock-only refund, where goods come back but no money goes out — it falls back to the sum of the returned line subtotals.
Why the fallback exists
Without it, a return processed as "restock, no refund" would compute as zero and be discarded — and the goods would never come back into your stock.
Finding the invoice to credit
A credit note has to be raised against something. Bizmitra looks up the invoice that this order was billed as — keyed on the order, never on the refund or payment.
That is what makes refunds behave identically regardless of how the invoice came into existence. Whether it was raised at order time, at payment, or by you pressing Convert, the same link is recorded, so the refund finds it either way.
What the credit note posts
A posted credit note — the same document the ERP writes when you raise one by hand:
- A debit to the customer and a credit to your sales account.
- One line per returned item, where the refund carries them.
- A narration recording which store order and which invoice this reverses, plus the reason if one was given.
It inherits the invoice's sales ledger and warehouse, so the reversal lands where the original sale did rather than in some default account.
Like the invoice it reverses, the credit note is one of the documents that can be pushed onward into TallyPrime — see how that works.
The restock rule
This is the part of the integration most worth understanding, because most tools get it wrong and the consequence is silently corrupted stock.
A refund only puts goods back into your warehouse when goods actually came back. Money and stock are separate facts, and a refund is not automatically a return.
| Refund type | Credit note | Stock restored |
|---|---|---|
| Carries returned line items | Yes, itemised | Yes — one movement per returned line |
| Money only (no line items) | Yes, as a value-only credit | No stock movement at all |
A goodwill discount after delivery, a partial refund for a damaged item the customer keeps, a shipping refund — none of these should increase your stock, and none of them do. The credit note is still posted, so your books and your GST position are right; only the warehouse is left alone.
One more condition on restock
A returned line only restocks if its product can be resolved to a Bizmitra stock item. A line for something that was never mapped is recorded on the credit note for its value, but cannot move stock it cannot identify. Keeping SKUs clean — see the product guide — is what prevents this.
Refunds that arrive early
A refund webhook can outrun the invoice it needs. Bizmitra treats this as "not ready yet" rather than as a failure, and retries.
In manual invoicing mode the wait can be genuinely long — the invoice does not exist until you convert the order, which might be days. Rather than retry forever, the refund eventually stops and is held as replayable work. Convert the order, replay the refund, and the credit note posts against the invoice that now exists.
Nothing is lost
A refund that cannot post yet is held, not discarded. This is the most common
reason to see a job in the dead state, and it is recoverable —
see job states.
Two worked examples
A — customer returns one of two items
B — goodwill refund, customer keeps the goods
Those two refunds look nearly identical in Shopify. They produce deliberately different results in Bizmitra, and that difference is the whole point.