You guys might have a bigger problem then first detected, when you print your sales tax report, are you using the order date as the criteria for this report? If you are, this report is now useless, and I will explain it to you from an accountant's perspective once you answer my question.

Many thanks

Hello shaharyar,

I wear many hats, and I'm now speaking to you as an accountant. You guys have some serious problems here and can cost anyone who uses your reports as a means to pay sales tax some severe problems.

To answer your question, yes, this is being done in the backend and will be recorded under the order lines under OrderItemTypeID as ID "4".

First let's start at the very beginning, where the issue originates, please view the 3 pictures enclosed.

#1 No Discount - please view the sales tax of $67.97 on an item subtotal of 970.99 - this is correct, and the correct amount is shown under orders, field ProductSubtotal.

#2. With Discount - sales tax is still $67.97, with an item subtotal of 870.99, this tax should be $60.96, the correct amount is shown under orders, field ProductSubtotal.

#3. Please view the sales tax report with the wrong tax of $67.97

So far, we have the individual invoices which are incorrect, customer overpaid for sales tax, and this amount is being shown in the sales tax report.

But unfortunately, this is the first of your problems. Please answer this question as this is critical, are you basing your sales tax report on the sales date? (Yes or No)

No Discount.png (137kb) downloaded 4 time(s). Report.png (132kb) downloaded 4 time(s). With Discount.png (148kb) downloaded 5 time(s).

Sales taxes are due when the order is completed, and you have collected payment for the order. This is a flawed on your system, and it can be considered a severe flawed.

At the very least, you should have a disclaimer that pops up before printing the sales tax report that reads something like this, "This report only shows sales taxes due based on order date, not the actual collection process. It is your responsibility to verify this report and pay the appropriate taxes with your state agency."

Since this is probably not clear to you because you're not an accountant, let me explain. This may not occur with all your customers, but it definitely occurs with us because we do quotes, and we accept check by mail as a valid form of payment.

An order comes send in the month of July in our state for 1,000.00. - This order turns into a quote and final approval is not given, until the next month, which is now August. Customer mail-in a check, but that check is not received until September. The order actually becomes valid in September, and the sales taxes if the order was placed in the same state doesn't become due until September.

Your report on September will not show this order, this order will only show if you re-run the report again in July. It is now the responsibility of the merchant, to go back and re-run reports to determine if there were any adjustments made. They then need to make these adjustments to the proper state authority, otherwise in the event of an audit, you can be penalized quite heavily.

What we have done to work around this:

We have created a custom field in the order table called "cf_CompletedDate". This field gets populated only when the order status becomes complete. This field is currently being populated by a trigger. When we run our sales tax report, the criteria that we use is not order date, it is completion date. Our custom report that I'm willing to share with you also list the completion date next to the order date, and if there's a discrepancy, the order date is crossed out to show this discrepancy.

We also use this custom field to lock orders after 35 days. I highly recommend on a future version that you implement a completed date field on the order header.

The good news is that your product subtotal field in the order header is functioning properly, and based on the value of that field, I can determine the proper sales taxes due.

I am more than willing to share what a proper sales tax report should look like,but I really think that AbleCommerce needs to revisit and make changes to the current situation. At the very least, a disclaimer is needed before running this report.

I hope this helps and if you require any additional information to help clarify this, you're free to reach out to me.

Many thanks,
-Ray

Edited by user Tuesday, November 30, 2021 4:48:11 PM(UTC)  | Reason: Not specified

Katie,
Based on your explanation, if the "Discount" OrderItem record that was added with "Add Other Item" was made taxable, would the tax also be recalculated with (in effect) a lower taxable total? Not sure if there is a way to do that without customization, but it seems like it should work.

Edited by user Monday, November 22, 2021 3:38:49 PM(UTC)  | Reason: Not specified

Nice tax report. I also have the task of reconciling the taxes for WA state. For this state, the tax rate is reported by zip code. I know what a pain this can be, so I hope we can find a solution that works. I need to put some thought into it because there are different ways to approach this when editing and recalculating orders.

There is already an issue report opened with the dev team. Let me discuss some ideas with them and see what they think.

RE: Reports

The date of payment instead of order date needs to be considered for reporting. Maybe this can be an option in the order status/reporting configurations. We run into this all the time because of how we create orders as invoices sometimes. For us, we have customers who might make a number of payments on the same invoice. So, yes, I understand the problem.

I will report back as soon as I can.

Thanks for your suggestions and feedback. It's always appreciated :)

You are welcome, and I appreciate you listening to our ideas.

We both know that the problem lies much deeper, when our political leaders refuse to offer guidance and pretty much every state is out for themselves.

All 50 plus states still have systems which are based on brick and mortar, and are very inflexible when it comes to Internet transactions. It is up to us to figure out a way to work around all this mess, and if we don't do it right, we get penalize.

In my case, the state of Florida can bark that one order should have been paid in August, but was actually paid in September, because of a complete partial. The bottom line is, every single penny that is due to the state, gets paid to the state, and we are not committing fraud.

Like always, the customer is left to unscramble the egg.

I just wanted to bring this up since we are on the subject of report data. There is a feature within the configuration of order statuses that will let you decide when data will appear in the reports. Just a simple checkbox to either remove or include the data. By default, the new unpaid orders should not be included in the report data.

Still waiting to hear back from the devs on recalculating taxes.

Hi Jay,

I can only go by my primary location, which is the State of Florida. In fact, in the state of Florida, it's when the money gets deposited in the bank from the sale, so what happens if you get cash on December 31, but you don't deposit the money until January 5?

Deposits = Sales

Gets a bit confusing, right.

As far as the taxes due when the sale is made can mean a lot of things.

- If no money exchanges hands, is the sale made?

- If the customer wants a quote that's approved and mails a check, is the sale made?

- What about a credit card that's gets captured on a Friday, the end of the month, but doesn't enter your bank until the next month on Monday, is the sale made?

Bottom line, any state, including the state of Florida might get a little picky, but as long as you prove to them that you're not committing fraud, everything should be okay. As I said before, every penny that's due to the state gets paid, if they want to get picky about a few days, then they get picky, but the bottom line is there is no fraud.

I wouldn't trust anything on the Internet either, that's why you need to call your state tax authority and hear from them, and after you do get it in writing from their website.

Regarding the order header, all my SKUs are taxable, so I don't have the mix-and-match situation, but a solution might be to have 2 database fields not one, one for taxable and one for nontaxable.

Either way, the order header works for me and that's what I'm going to use for now, maybe in the future I will design a more detail report in Crystal - based on line items which should be ID "0" followed by discounts which should be ID "4".

Messy topic

This obviously has to be one of the largest user viewed posts of 2021, and still climbing.

Let's continue with the can of worms, that has been open, I was thinking of maybe besides the subtotal database field that set the order level, to maybe have two more fields, that would break down taxable line items and nontaxable line items.

But even that is problematic for the example that I'm about to give below. This does not affect us, since everything is taxable down here, but I am just making a point to show that what AbleCommerce does will never be sufficient to address the needs of any merchant. All AbleCommerce can do is provide information, and it's up to the merchant to determine based on that information what is appropriate for their particular situation.

Imagine an order coming in for $200, $100 of that order is taxable and the other $100 is not. You now apply a $100 discount to the order, so how exactly are you applying the discount?

Are you applying the $100 to the taxable part, or are you applying the $100 to the nontaxable part, or are you going to split the differences? As you can see, going down the rabbit hole just gets worse and worse.

Again, bottom line, all AbleCommerce can do is provide information based on a report, and it's up to the merchant to determine how to apply that information.

Re: when you can actually charge a credit card whether an order is shipped or not. Our partial shipments consist of at least 50% of the order going out, so we will charge and capture the full amount. If the additional merchandise does not come in 30 days, we email the customer and asked them if they wish to apply a credit to the first-order, and move the remaining items to a separate order.

While it's true, depending on the merchant's bank, and for those who are not used to credit card rules, American Express is under one umbrella, and Visa and MasterCard are under multiple umbrellas. I have yet to ever have a dispute where this has been a problem. I believe, as long as you get permission from the customer to charge and capture the card, and be able to offer a credit after 30 days, and have this in writing, will be enough to satisfy any disputes with the issuing bank.

Wow, what a can of worms.

Edited by user Wednesday, November 24, 2021 3:45:01 PM(UTC)  | Reason: Not specified