Does anyone else have an issue with how Shopify treats refunds in so far as the negative effect on sales and reduction in tax liability is treated as if the return occurred on the same day as the order it self? So if you have a December sale and a January return Shopify will not reduce your sales or tax liability in January; instead they will go back in time and reduce your results from December. So if you gave your accountant your book you need to redo your work for any return on a last year sale. My accountant says this is simply wrong accounting treatment and while Shopify has the metadata as to the date of the actual return that date is not used in any way by Shopify. I have raised several times with Shopify and the answer from guru's is always that is just how we do it but never an explanation/accounting logic as to why they make this assumption. The assumption forces users to track returns by hand to make sure they do not over pay taxes for instance. This just seems crazy. Agree or disagree?
Thanks Ray but the question remains of how will any App be able to reconcile such data if Shopify itself does not? Since Shopify does not utilise the metadata associated with the date of refund then there is logically no basis for any app to draw out such data in order to apply correctly. Fits within the standard garbage in garbage out analysis. Thanks again Ray
More on your query Jason...
The app cannot do the accounting, but it can input the data to an accounting package to handle the transaction. So consider this approach:
Dec sale $10
Dec tax $1
Dec bank receipt $11
Bank reconciles to sales
Then, Jan refund $11 (recorded as Dec in Shopify, but forget that date)
You then create a credit memo in your acct. package dated Jan. that reverses the sale, corrects the tax liability, returns your merchandise to inventory, and refunds the money to the customer
Your records, -$11
Bank refund - $11
Bank reconciles to sales
The sticking point is Shopify does not record the date of the refund, so the above work-around is necessary.
Hence my point. A work around should not be necessary at all. Shopify went to the programming effort to allocate the date of a refund to the order date so why not simply stop doing that and refer to the also available in the metadata date of the actual return. Doing so will likely mean the creation of another invoice or invoice#-2 but then at least no work around is required. Its not no programming went into the current version and so even though Shopify likes to say as you rightfully also pointed out that Shopify does not do accounting, they made an accounting assumption is setting it up the way it is now and that accounting assumption is wrong and now requires a 'work around' which defeats the point of having such a system. My point is simply that Shopify is in control of the front line data and that data needs to be handled appropriately so that merchants don't have to do stuff by hand thus negating the value.
If you look at the competition like Lightspeed this is how they explain their programming/treatment:
"Before processing returns, it is important to understand how Lightspeed OnSite handles returns and refund payments. The original sale Invoice isn’t simply cancelled or removed. Instead, the return is processed on a second Invoice, which appears like a “reverse sale.”
It is important that Lightspeed OnSite track sales and returns on separate documents so that you can accurately determine when a return was performed, or by whom. Lightspeed OnSite might also need to track the store credit which results from an un-refunded return Invoice.
Return: inventory comes back into stock.
Refund: a payment returning the customer’s money.
Exchange: one or more Products are returned to stock, other Products are sold at the same time.
A line item with a positive Qty indicates it is leaving your inventory.
A line item with a negative Qty indicates it is being returned to your inventory."
Alena - please email me and I will reply with my Skype name.