I’m coming from Quickbooks and evaluating Manager to see if it will fit our needs.
In the US sales tax is charged at different rates depending on location (state/city). We have several tax locations we collect sales tax for each with their own rate.
In quickbooks sales tax is handled by flagging an item as either “taxable” or “non taxable” (not with a specific tax code) and then tax locations are set up.
Then on the invoice, the customer is tied to a tax location. (e.g. Mike is tied to the PA tax location). When you assign a customer to an invoice, it changes the tax rate to match their location (with the option to override, say for exempt). Then any items that are flagged as taxable are summed up and they tax rate is applied.
I have set up tax for a single location (which includes multiple tax entities). But seems like tax rates are handled at the item level, not the invoice level. This makes having to update the tax location for every item very tedious and prone to error.
There is also an exception to the rule in things like shipping charges, some states charge sales tax on shipping, some do not.
Is there no way to default the item’s tax rate to the customer’s location? It seems not since location is not a field in customer.
This would be a show stopper for us. Seems like this software focused on non US users.
You are correct that tax codes are tagged to the item, not to the customer. However, both inventory items and non-inventory items, which could be things like shipping charges, can have default tax codes set for them. The typical situation would be to set the default tax codes to match your normal selling location. All default tax codes can be edited as a transaction is created, however.
You are correct that manager is not ideal for multiple sales tax rates at different locations. This is especially problematic for the emerging situation in the United States of needing to charge sales tax for Internet sales to remote locations.
Thank you. Yes, this is exactly the issue. We sell through Amazon so we don’t really have a default tax location. Amazon has started to collect sales tax for us for certain states whether we have to or not and it’s creating a HUGE issue… If you can get Manager to be able to deal with this issue (it’s only going to get worse), you will have a gold mine on your hands as there are few packages that actually handle this well.
I think in the near future, all states will jump on the affiliate seller bandwagon and require everyone to collect tax everywhere… But it’s going to be a HUGE burden on small businesses. States like WA have over 300 different tax locations that you have to figure out what rate you have to collect based on their specific town. It’s insane.
It’s worse than you say. Not only do you have the thousands of tax jurisdictions, contributing their various percentages to an overall applied rate wherever the sale is consummated, but you have to deal with items exempt from one sales tax component but not another, customers exempt from only some components, and so on. The entire underpinning of Manager’s tax structure needs to be recreated to handle this. It was originally created for a simple offsetting VAT scheme (admittedly fine in well over a hundred countries). But things are getting more complex everywhere. Tax reporting is also inadequate for multi-component schemes, leaving you to do a lot of algebra at tax filing time (for each jurisdiction).
For a purchaser, Manager is great under sales tax regimes. Just include tax in the entered prices. But for a seller, it’s getting tougher and tougher.
I first raised these issues with @lubos years ago, but so far there has been no improvement on this front.
This subject is about more than a default tax code for a customer. In jurisdictions with multi-component sales taxes—which is most jurisdictions these days, a customer can be subject to different components depending on a) where delivery occurs, b) where the seller has a physical nexus, c) what the purchased good or service is, and d) whether the customer has an exemption status (for each category of good or service purchased). The possibilities are complicated because jurisdictions overlap or have geographic gaps. It’s literally possible for me to apply 3 or 4 different tax codes for the same items to two customers who are next door to one another, or to the same customer depending on whether they pick up or have goods delivered.
I agree it’s confusing. Things used to be much simpler, because you only had to apply sales tax for your jurisdiction on items delivered within it. But recent legal decisions are forcing sellers to collect and remit for every jurisdiction. All this is to level the playing field for internet versus brick-and-mortar sales. This complexity will probably drive many merchants out of business.
If I were writing the code this is what I would do… (Keep in mind I don’t have any knowledge of how VAT/GST works so my ideas may break that).
Items would be assigned a tax class, not a rate. This would typically be “taxable” and “non taxable”, but you would need custom classes as well for like “service” and “shipping” as those classes of goods may have different tax rates or may/may not be taxable in certain jurisdictions.
There would be a list of sales tax payables (entities that we collect and remit sales tax to. e.g. “Arizona Sate Dept of Revenue”, and “City of Phoenix Dept of Revenue”)
There would be a list of high level tax rates which could include one or more sub rates/payables and the classes they apply to
“Arizona tax” = AZ DOR @ 6.2% and Phoenix DOR @ 2.4%; applies to Taxable, Services, but not shipping tax classes; for anyone in AZ state.
“Arizona Tax” would need a tax rate for all defined tax classes so it’s a little more complex than this. But say “Clothing” tax class gets a different rate, you would need to be able to define that under the “Arizona Tax” parent.
The sales tax on the invoice/sales order/receipt should not be locked into those rates. i.e. if you select Arizona Tax, it would put the tax at 8.6% but allow you to change it manually and through the API, or supply a dollar amount for tax instead of a rate.
And of course customers need to be have their city/ state/ zip as separate fields so they the software can automatically select the proper tax rate.
The USA just needs to modernise. Most countries who now use VAT/GST use to be sales tax regimes.
Take Australia, another multi state country, they discarded the individual state based sales tax regimes for a national system. The VAT/GST income still goes directly to the states, even though it’s collected federally.
I understand that for the USA to contemplate such a change is probably a “wall” to far.
I’d be okay with something a little simpler and/or adjustable. I’m in the USA and do sell across states. I end up setting tax rates like IN , IN Exempt, KY, KY Exempt, etc. Because of this I don’t actually set any tax codes on products at . In some cases I end up with invoices with many items and going through all of them to set the tax code takes time. If I could set the customer initially to Exempt or not (we deal with a lot of churches, schools and government agencies, all of which are exempt it would make my life much easier. You could still show the individual line item tax codes so if something needed to be changed, I can go back and do that on an item by item basis. It would still require checking and possibly editing lines but, in the end, would be much faster for most invoices. Complicated custom tax codes could also be set up and assigned to customers in this way as well.
That hits the nail right on the head. Even within a single country, you will have many special considerations for tax.
Because of all that Manager’s implementation – like most other popular software – has to remain simple and robust to accommodate for different tax regimes as well as for special considerations. More like a blank page approach, if you like.
This would mean that a certain amount of skill and effort will be required from users to setup their taxes properly.
@KrisK If you don’t have the sufficient time or skills, there’s at least three US based accountants listed on Manager’s Accountants Page that I am sure will get you sorted out.
I’m not having trouble at all setting up various Tax Status items. I was just trying to limit the amount of clicking I have to do every single time I have to do an invoice. the more things I have to click, the more likely I (and any other human) is to make a mistake. In my particular business saving time and making things easier is a huge plus.
The thing is you select a customer before selecting a line item. If you prefill your tax codes in the lines before selecting a customer and keep it editable, then it will be overwritten once the item has been selected.
The other option is to completely lock the tax code field if the customer has a tax code. But this means that tax codes in lines are no longer editable by the user. But this would create another problem, which is when you have special considerations for the item or supply place where the exemption doesn’t apply, then your only solution would be to create a new customer account for that particular instance because manually editing tax codes for that particular customer isn’t an option.
It’s not an end-all-be-all solution but I see how it can be useful in some circumstances but it all depends on whether it fits the vision of the developer.
Where default tax codes are set (COA, Inventory item, etc), add a tax code holder “Contact’s tax code”
Add a default tax code to contacts (customer, supplier)
When creating an item with a default tax code “Contact’s tax code”, substitute the default set for that contact if a contact has been defined.
In addition Multiple rate tax codes consisting a set of single rate tax codes would enable practical country specific localisations and electronic reporting in jurisdictions with multiple levels of taxation on goods and services / value added.