9 digit zip code (zip + 4) for Tax Calculation

[natecroy]

I am attempting to use s2Member Pro to perform Tax Rate Calculations (s2Member > Paypal Options > Tax Rate Calculations). Unfortunately I live in one of those states (Washington) that has recently adopted a destination based sales tax.

The Tax Rate Calculations within s2Member look like a perfect solution for me although it appears I need to use 5 digit zip codes. Since zip codes within Washington state have varying tax rates, will 9 digit zip codes work with the s2Member Tax Rate Calculations?

I plan on copying data from the Zip + 4 category on the following page:
http://dor.wa.gov/content/FindTaxesAndRates/SalesAndUseTaxRates/stdownloads.aspx

Here's an overview page for the destination based sales tax:
http://dor.wa.gov/Content/FindTaxesAndRates/RetailSalesTax/DestinationBased/default.aspx

Any help would be greatly appreciated. Thanks!

Nate

[Cristián Lávaque]

Hi Nate.

I sent Jason an email asking him if 9 digit codes would work, but why don't you just go try and see if they do?

[natecroy]

Ha! That's too logical of a response, Cristián! I assumed a hypenated zip would conflict with the zip code range option.

I've tested the 9 digit codes and they work, with and without hypens! As long as the user types in the code as you've entered it into the Custom Tax Calculator within the admin, you're good to go (if you entered the zip in the admin with a hyphen, the user has to type in a hypen or it won't work.)

Now I've uncovered a new problem though...No one is going to know what the +4 digits are of their zip code. I have no idea what mine is. Any thoughts?

I appreciate the help and the quick response, Cristián. You and Jason are always incredibly helpful to users on your forum.

Thanks,

Nate

[natecroy]

Alright, I have an idea, Cristián. Here are the tax rate codes by county/city in Washington state:
http://dor.wa.gov/Docs/forms/ExcsTx/LocSalUseTx/LocalSlsUseFlyer_Quarterly.pdf

Here's my idea, I just don't know how to pull it off:
1. Create a Custom Registration Field (drop-down) called "WA_Counties" that only appears in checkout forms.
2. Enter all county tax codes COUNTY/CITY = percentage. Ex:) ADAMS/UNINCORPORATED=7.7%. There appears to be text files that the Two character Country Code and Two character states are drawing from, so I could probably make one for counties.
3. Create a conditional statement in the form that says if " %%state_value%% " = WA, then show the "WA_Counties" drop-down list. Only the counties within the specific city the user entered (" %%city_value%% " I believe) will appear in the drop-down. When the user selects a county, the Ajax Tax Calculator will show the taxed total.

I'm not a programmer, but I know where to find things for the most part within s2Member. Do you think this is a viable solution and would you know how to go about doing this?

My most ideal option would be to tie the following in to s2Member, but I would have no idea where to start:
http://dor.wa.gov/Content/FindTaxesAndRates/RetailSalesTax/DestinationBased/ClientInterface.aspx

Thanks, Cristián.

P.S. If you can solve this one, it may help many other s2Member users as these are other states that have been hit with the same Destination Based Sales Tax:

Arkansas
Indiana
Iowa
Kansas
Kentucky
Michigan
Minnesota
Nebraska
Nevada
New Jersey
North Carolina
North Dakota
Oklahoma
Rhode Island
South Dakota
Vermont
West Virginia
Wyoming

[Cristián Lávaque]

Thanks for reporting back that it works!

I don't know AJAX but I know you could implement a dynamic thing with it for this. My solution, though, would probably be to simply give a link next to the ZIP code box that takes them to a page where they can find theirs (there must be one online).

Does that help?

[natecroy]

Is it possible to use custom registration fields like I outlined above within s2Member? The html link would work, but we're looking for a bit more of an automated process.

Thanks again for your help,

Nate

[Jason Caldwell]

Thanks for the excellent question.
~ and thanks for the note Cristián.

I suggest using zip code ranges for this. Generally speaking, ZIP+4 would be an absolute nightmare to configure for tax calculations. Way too many possibilities, and unless I'm mistaken, there is no state in the US that bases taxes ( i.e. cities/counties/parishes ) on the +4 add on.

Is there a specific reason why you are attempting to use ZIP+4 on this? Most people would not know this, or even if they did, would not type that in. Please correct me if I'm wrong, but I don't think any state uses ZIP+4 to determine a location that would change the tax percentage. I know that some states have separate taxes by county, but the 4 digit add on is not designed to designate a specific county.

Taken from the Wikipedia.

A ZIP+4 code uses the basic five-digit code plus four additional digits to identify a geographic segment within the five-digit delivery area, such as a city block, a group of apartments, an individual high-volume receiver of mail or any other unit that could use an extra identifier to aid in efficient mail sorting and delivery. Initial attempts to promote universal use of the new format met with public resistance,[citation needed] and today the plus-four code is not required.

---

Instead, I recommend using s2Member's ability to calculate taxes based on a range of zip codes.

For instance, if your s2Member Tax Configuration File is:

Code: Select all

32000-34999/US=7.5%
83200-83999/US=6.0%
32601/US=6.5%

So now, when a Customer enters...

Zip code: 32626 = 7.5% tax
Zip code: 83200 = 6.0% tax
Zip code: 83384 = 6.0% tax
Zip code: 32601 = 6.5% tax

Will that work for you?

[natecroy]

Thanks so much for the response, Jason. I think the zip code ranges would be ideal, although a single 5-digit zip code can have multiple tax rates as far as I can tell.

Here's the data from our State's website:
http://dor.wa.gov/content/FindTaxesAndRates/SalesAndUseTaxRates/stdownloads.aspx
I've been looking at the ZIP + 4 data about halfway down the page.

It appears that I could also choose to use counties/cities according to this:
http://dor.wa.gov/Docs/forms/ExcsTx/LocSalUseTx/LocalSlsUseFlyer_Quarterly.pdf
The Combined Sales Tax data is what I would need on this form.

Unfortunately zip codes are not exclusive to a specific county/city. King County is a good example of a county with very different tax rates per each city. There are also unincorporated areas within each county that have their own tax rate as well.

Well, there you have it! Kind of a joke if you ask me! Am I missing something? We're days away from launching our product we've spent over 6 months on and this destination based sales tax issue has us stopped in our tracks. Thanks so much to both you and Cristián for your help.

Nate

[Jason Caldwell]

Thanks for the follow-up Nate.

I don't recommend going by City and/or County ( at least, not by name ).
Using ZIP codes is the way to go for states that have different combined tax rates for a city + county or parish. In other words, a ZIP code is going to hone in on a specific area of each city, so using ZIP code ranges maximizes your ability to charge tax accurately, based on exact location within the city. As long as you compile your ZIP code ranges based on the data provided in those files broken down by ZIP code, you should be fine.

a single 5-digit zip code can have multiple tax rates as far as I can tell

Sorry, I don't see how that's possible. I just glanced over a couple of the files, but I don't see any instance where that is the case. If you have a file you can point me to though, and tell me which line numbers to reference, I'll be happy to take a look for you.

[Jason Caldwell]

Unfortunately zip codes are not exclusive to a specific county/city. King County is a good example of a county with very different tax rates per each city. There are also unincorporated areas within each county that have their own tax rate as well.

I just noticed this.

OK. So how does the website you pointed me to break tax rates down by ZIP code then? Am I wrong? If tax rates are broken down by ZIP, then that should work. The +4 code should not affect the tax rate, because those are used for mail sorting and delivery only ( according to the Wikipedia ). Thus, it's not needed in the equation, only the 5 digit ZIP code. Isn't that correct?

[natecroy]

Thanks again for the help, Jason.

Here's an example of differing combined tax rates per zip code.

Go to:
http://dor.wa.gov/content/FindTaxesAndRates/SalesAndUseTaxRates/stdownloads.aspx

- Scroll about halfway down to Zip + 4 and download the 2011 Quarter 2 (Apr 1 - Jun 30) Long - All 9 digit zip codes (http://dor.wa.gov/downloads/Add_Data/ZIP4Q211E.zip)

- Look at the Descriptions for ZIP +4 fields - Long as well
(http://dor.wa.gov/Content/FindTaxesAndRates/ZIPFldDescripLong.aspx

- Unarchive the zip and you should have a TXT file. Do a search for "98225" in the TXT file.

- You'll see that the combined tax rate moves back and forth between 8.5% and 8.7% for 98225.

I know, it makes no sense!

[Jason Caldwell]

Gotchya. Thanks for pointing me in the right direction.

I see what you're referring to now. Yea, that's a little odd I think.
Well, I guess the next question is, how would anyone configure a Tax Calculation for this exactly? You would have to include every possible variation of the ZIP+4 ( there must be thousands within each state in the US ). No way, not gonna happen. That's way too complex for a site owner to configure. Plus, you really can't depend on a Customer to enter a full ZIP+4 for you. Even if you tried to require that type of input, you would just lose Customers over it I think.

So I see your train of thought. Going the City/County route might work in one state ( with lots of data input on your part ). That's not possible with s2Member though. I don't see that being an easy hack either.

So, from a professional standpoint,
I'll see what we can do about this in a future release. I wonder if the IRS has something like this that works with any state in the US, not just WA? http://dor.wa.gov/Content/FindTaxesAndR ... rface.aspx

Hmm. The only problem with this though, you would still need the Customer to provide a ZIP+4. You could probably skip that and pass in a full street address and 5 digit zip, but then you really can't trust a Customer to be accurate with the street address at all times. Any little typo could throw off tax calculation. You'd really need the ZIP+4 to be accurate.

From a personal standpoint. Heck, I would just use the 5 digit ZIPs and call it a day. The differences in that file are very small, and who knows ( they might even be related to a computer glitch ). This is the way all PayPal® Standard Users do it too, see attached screenshot.

I'm NOT a CPA though. So I can't offer any official advice in that capacity. If you have any ideas that would work well for all s2Member Pro site owners, I'm more than happy to hear them. Would the ability to enter both 5 and +4 digit ranges be viable? Hmm. I don't know. Seems like too much work for a site owner.

The County name might be helpful as an option. I'll give that some thought.

[Cristián Lávaque]

In the end, whether the customer lives on the left or the right side on the street with different tax rates, you can't go visit each one to make sure they entered the right address, right? If the difference the "side of the street" makes on his tax is so important to the customer, then he'll be careful to enter the right data.

As long as you charge the right tax according to the customer's input, aren't you safe?

I'm not giving advice, am not a CPA, but I'm talking out of common sense, which is not a common sense in this subject...

[natecroy]

Jason and Cristián,

Thank you so much for spending the time with me on this issue. I appreciate both your site owner and personal perspectives. I agree that calling 5 digit zips makes the most common sense although it does not work for our accounting team. I also agree that from a data entry standpoint, entering multiple zips and tax rates (that change each quarter mind you) is quite a feat for us. I'll have to keep scratching my head on this one. Thank you both for all of your help, I really appreciate it.

Nate

[Jason Caldwell]

Very welcome Nate.
We'll continue to look at this issue and see what we can do to improve things.