Note: The Sales Tax system is not yet generally available. In the mean time, you can use our old sales tax system where you can set up rates and will file directly. We expect this system to roll out in November, 2019.
As we prepare for the roll out of our Sales Tax system, we wanted to share some of the detailed design and implementation that we have. This will be useful for the people who are starting to test both internally and externally, as well as for geeky tax software developers. We also want to help lay down a guide path to make it easier for other registration and ticket vendors to implement their own systems since we are all in the same boat of complying with the expanding Marketplace Laws compelling us all to collect and remit taxes in 35 states (and growing).
A Basic Transaction Sales Tax
In the example below a person from Phoenix, AZ is signing up for a race in McFarlane, Wisconsin (outside of Madison). The race fee is $10 and they are buying a shirt for $20 and picking it up at the race. Wisconsin charges a sales tax of 5% and Dane County charges a sales tax of 0.5% on both the race fee and the shirt – so a total of 5.5% on $30 – a sales tax of $1.65. Here are the line item details in the RunSignup report:
In addition, Arizona charges a sales tax on processing fees. Actually for people in Phoenix, they owe taxes to the state, county and city. For the $3.00, there are 3 jurisdictions that must be paid a total of $0.26:
Wisconsin does not have a marketplace law at this point, so races are paid the sales tax, and must remit that to the state. Sales tax on processing fees are always collected and paid by RunSignup. The full detail on the transaction is shown in the sales tax transaction report (sub-elements show above). The red boxes are the transaction number (this was the same transaction/checkout a person made), the green boxes highlight the total sales tax amount and who it was paid to:
Simple, right? That is how a transaction is done – each line item’s taxability and jurisdiction and payment needs to be calculated. The good news is we also provide a summary report that can be used for filing taxes. It shows a state summary for the race and a summary by jurisdiction.
In most states, you would make a single payment to the state and they will pay the localities based on the second part of the report. Of course, folks who live in Marketplace states won’t have to worry too much about this because RunSignup will be collecting and paying on your behalf. If you get audited, you can show these reports to back up the fact that taxes were paid, and if the auditor wants to get picky, give them access to the detailed reports page shown above.
What is Happening Under the Covers?
As covered above, we break a transaction into individual line items and determine the taxability and what the tax should be. There are a number of elements to this:
- Item definition – is it a race registration, a USAT membership, a shirt, an iTab, a club membership, a ticket to a nonprofit golf outing, etc.
- Item location taxability – for example a race registration is the location of the race. If a shirt is shipped to someone then the shipping address is used for tax calculation. For a virtual run taxability is the billing address of the participant.
- General taxability of the item in that jurisdiction, as well as rates.
- General exemptions for localities that are exceptions to the generally accepted rule. An example is that the law seems to read that race registration is taxable in Texas, however one of our customers provided documentation from the state tax department clarifying that races are indeed exempt.
- Customer Exemption. This is typically for exemptions of nonprofits in certain states, accompanied by documentation or proof of exempt status.
Since this list gets multiplied by the nuances of literally thousands of jurisdictions, and the unique set of offerings from the 20,000+ customers who rely on us, we had to develop a flexible, scalable and reliable sales tax system. We will dig into the various components to discuss how we did this.
Architecture & Avalara
We have partnered with Avalara (OK, we pay them a bunch of money per year) as our Sales Tax software provider. They keep track of over 1,000 types of items and the rates across 9,000 jurisdictions. They have an API that we call to get those rates that we can apply to the items that a race or nonprofit sells. We also record those sales tax payments, and for the 35 marketplace states we rely on them to do filings.
While their service does a lot, RunSignup has had to create a lot of functionality to use the raw data they provide to make it work seemlessly in our system. Here is the high level architecture:
The basic flow that happens is on the checkout page on RunSignup and GiveSignup, we send a set of API calls to Avalara for each item and the location of the item and whether there is an exemption or not. We get a set of returned data that then lets us calculate the sales tax and show it on the checkout page. We also have a local backup of the data so we can do the processing more quickly and it provides fault tolerance in the case that Avalara is down.
When the customer completes the purchase, we send another set of API instructions to Avalara to record the information in their system. For Marketplace states, this enables them to produce appropriate filing reports for those states and localities.
Let’s explore each service a bit more in depth.
Taxable Items
Avalara has over 1,000 Tax ID Codes (TIC’s) – and they get pretty specific like admissions to Billiards and Domino parlors (no, we are not starting up DominoSignup). We have been working with our tax consulting firm to map the types of things people purchase on RunSignup and GiveSignup – like race registration, clothing, athletic clothing (yes, they are different), memberships, and even donations. We have crystallized those down into 16 Avalara tax codes.
The tax code is always changing, and we will likely learn more things in the future, so we have made the mapping of items in RunSignup to Avalara flexible at both the overall system level and at the race/event level.
At the system level, we have a mapping between an Avalara Tax ID code and the appropriate items in RunSignup. Here is an example of a sports equipment tax code (the PC040400 is the code we send to the Avalara API when that item is ordered) is available for Add-Ons and Store Items:
The second level of mapping is at the race level. For things like Add-Ons we give the race or event the ability to specify the appropriate code for the item. The event director will specify the appropriate tax treatment for the item.
These codes are what are sent to Avalara on the checkout page and are used to map against their database of rules for the taxability for the location.
Location
The next part of the architecture is the location. This can be more complicated than you would think. There are different taxability rules for different item types. Here are the major rules that we code into our system so we can pass the appropriate zipcode to Avalara for each item:
- Race Registration or Event – the zipcode of the location where the event is held.
- Clothing – this is the shipping address for the clothing. If add-ons are always picked up at the race, then it is the zipcode of the race. If you ship items, then is is the shipping address. Of course this can complicate tax filings as a large race that ships to lots of states can open up tax exposure for themselves. This is one of the values of the marketplace laws in that RunSignup will collect and file for that shirt you ship to California (where shirts are taxed).
- Membership – This is typically the address of the local club. But in cases like USAT Annual Membership, then it is the address of the member. As an aside, USAT Day Licenses are taxed like the race registration since it is not a membership.
- Virtual Race – the address of the participant.
- Processing Fee – the billing address for the credit card.
Taxability
The general taxability is determined by Avalara based on the TIC and the zipcode from above. We have a tool inside RunSignup that calls Avalara so we can see a quick view of tax rates. We do not make this public because of license terms with Avalara as well as the fact it does not include the additional exemption rules we will discuss in the next sections. Here is an example showing race registration taxability:
General Exemptions
While Avalara does a good job of keeping up to date on the taxability of items, there are exemptions that are not captured in their system. The biggest example is that Race Registration seems to be classified as taxable in some states like Texas, however there are specific rulings that have made it not taxable. We count on our tax advisors and community to help us with local peculiarities. When we get proof like we recently did from a customer in Texas who forwarded us documentation from the state tax authority, we can create a general exemption for the TIC for those zipcodes. We have a system that allows us to keep track of these exemeptions and edit them. This is a dynamic list and we are not publishing this, nor should you take these as final rulings:
The sharp-eyed among you will notice that Maryland, for example, shows as taxable. The state does not tax race registration, however certain localities do charge tax. For example, Baltimore has a 6% sales tax on certain items. These types of exemptions are part of the value-add RunSignup and GiveSignup provide to our customers.
Customer Exemption
Certain customers may be exempt from some taxes – usually nonprofits. As discussed in detail in our Sales tax webinars, nonprofits do owe sales tax when they sell things in certain states.
RunSignup and GiveSignup will be requiring both proof of nonprofit status in good standing in a state, as well as specific acknowledgement and agreement to being liable if is determined that taxes are owed by your organization.
As with all things sales tax, exemptions have several layers of complication based on the state. As an example, in Georgia and Oklahoma religious nonprofits who hold events are not taxable, but other nonprofits are taxable. Another example is that in West Virginia events are taxable if the organization holds more than 6 per year.
We will be asking each customer to sign off on their exemption status when the sales tax system goes live.
Refunds
We covered this in detail in a separate blog post (yes, it is that complicated).
Fault Tolerance
As with most things at RunSignup and GiveSignup, we have designed the system to be fault tolerant. We have mirrored the Avalara tax tables (items and zipcodes) in the RunSignup database. We prime this with a big data dump from Avalara and then we update it whenever we notice a change on a transaction. For example, if the NJ sales tax went up on a signup for the Scott Coffee race, we would store the new value in our local database.
This local database allows us to achieve high performance on our checkout page, and if Avalara is down, it allows us to complete the transaction.
Summary
RunSignup has invested heavily in developing a system that is accurate, reliable and maintainable for all of our customers. That is our job – providing the technology so our customers can focus on their goals of crating amazing events and raising money for their nonprofits.
Since we are one of the first registration and ticket vendors to implement this system, we are open to sharing our information with other vendors. We are all in this together – so if you are a vendor or want your vendor to implement a system like this for you – feel free to contact Bob or Kevin.