Questions FOB Origin vs Destination Tax Calculations

A customer moving from Sage 500 (MAS 500) to Acumatica?  👍 👍 👍 👍 👍 👍 👍 👍 

As far as taxes are concerned, I remember the FOB affecting taxes in Sage 500, but I still don't know taxes in Acumatica very well. Hopefully someone else on here does.

Greg,

Like Tim, I'm no expert on taxes but I will share what I know.

Based upon the few implementation I have done involving sales tax, nexus is determined based upon the tax zone assigned to the ship-to address associated with the sale.  I have looked for intelligence in the system to address the difference between states that are origin based versus those that are destination based.  So far, the only two ways I have been able to work around this is to set the tax zone based upon how you want to the transaction taxed (ie for destination locations, use the tax zone based upon where it will be received. For origin based locations, use the tax zone to that of the selling warehouse.

This works the same way with use tax in AP.

The only other option is to implement Avalara or another tax service. Their service will determine the proper jurisdiction based upon the details of the sale passed through the API.

It isn't the same as how you did things in Sage 500 but it gets the job done. I hope this helps.

Thank you both for the reply!  Shawn, when you inform for Origin based locations, use the Tax Zone to that of selling warehouse... I'm unable to determine how this would be setup.  As far as I can determine, Tax Zones are set up against the Customer / Customer Location or Vendor / Vendor Location. Also seeing it can be setup at Branch level (not warehouse) so maybe this will work.   At the time of transaction, how would I trigger the Branch Location Tax Zone to be used as opposed to the Customer Tax Zone for example.   Within the Tax Schedule setup, I'm not seeing option to choose Origin vs Destination?

Greg,

Don't over-think or over-engineer what I said. If a customer typically buys from a warehouse that is subject to taxes in an origin-based jurisdiction, set the customer's tax zone value to that of the shipping location. If they later purchase from another warehouse that changes their taxability, either manually override the tax zone on the transaction or create a second ship-to location for the customer with a different default tax zone but with the same address.

It isn't a fool-proof of fully automated process.  For that, you need to subscribe to a tax service.

If you find a better way, I would love to hear about it.

Got it! Thanks so much for clairfying Shawn. Though I was missing something.  Your response is much appreciated.  Volume is pretty low for customer for theses occurrences, otherwise Avalara would be the way to go. 

If you make sales out-of-state, be sure to keep an eye on the cases before the Supreme Court this year. They could have a huge impact on how states can expand their nexus into the digital marketplace. If SCOTUS sets aside the Quill ruling or allows the concept of 'economic nexus', I think you will see a lot more multi-state jurisdiction collections and enforcement.

I'm not that knowledgeable about Avalara, but doesn't Avalara charge per transaction? Wouldn't that allow them to make sense even in low-volume situations?

Tim, it's been a while since I looked at the pricing for Avalara. There are at least 3 services that can be implemented (calc, filing, and certificate tracking). I don't know if they have an intial fee or are only on a per transaction basis.

Speaking of Avalara, how about that IPO? Incredible (suspiciously so) timing with the supreme court announcement happening right afterwards.

Now Tim, let's not let our imagination run free with conspiracy theories.

Just say'in, a company whose entire value depends on government legislation (taxes)? Seems like a good candidate for some hands in the cookie jar 🙂