As the internet economy grows, businesses are finding tax regulation to be increasingly complex, prohibitive to growth, and an impediment to entering new markets. In our public call for improvements to Stripe last January, the top request was help managing taxes—an ask we’ve heard from users for years. 

Before building Stripe Tax, we surveyed and spoke to over 1,000 Stripe users about how they handle taxes for their business. Their responses underscored their urgency, frustration, and desire for a “single source of truth to commit to for tax, VAT, GST.” In our survey, we found that about one in five users were not charging tax at all. Of those who did collect tax, 49% of them found it difficult to understand and keep up with tax obligations, and 59% turned to a third party to try to navigate these challenges, often at significant expense. 

Our users say that tax compliance can get so complicated that it becomes nearly impossible for startups to handle alone. To operate compliantly, online businesses must understand tax rules for thousands of jurisdictions (over 11,000 in the US alone) that they sell into—or face paying penalties and interest. Moreover, tax regulations and rates aren’t rules you can set and forget: in 2021 alone, the US will introduce around 600 tax rate changes and add thousands of boundary changes to existing jurisdictions. In Europe, many countries recently changed their VAT rates in response to the economic impact of COVID-19.   

We built Stripe Tax to help businesses manage the complexity of taxes. Stripe Payments made it easier for businesses to handle card details and accept payments without needing to go into a bank to set up a merchant account. Stripe Tax makes it easier for businesses to calculate and collect the right sales tax, VAT, and GST without needing to know the intricacies of tax rules or rates. 

This blog post lifts the hood on Stripe Tax. For online businesses, tax enthusiasts, and curious readers alike, we want to share how we built a tax engine and spotlight a few challenges we tackled along the way for users: determining their customers’ location, calculating the right tax at checkout, and speeding up filing and remittance. (If you’re looking for the mechanics of tax rules, we do have a detailed guide on sales tax, VAT, and GST compliance.) Hopefully you’ll find it useful if you run an online business or just like geeking out about tax policy (we can relate).

Determining customer location

Location, location, location. The first step to calculating tax is figuring out which tax jurisdiction rules apply. In the physical world, the answer has been pretty simple: it’s the jurisdiction of the store you walked into! Online, the rules are more complicated and the desire for precision about user location trades off revenue because every additional piece of information required to transact decreases conversion.

Tax jurisdictions are numerous and, in some cases, unexpected. In the US, there are thousands of jurisdictions, including special-purpose districts that can be arbitrary tax boundaries not linked to zip codes or existing municipal boundaries. Take Seattle, Washington. Four different tax rates apply to our Stripe office there: a Washington state tax (6.5%); a Seattle city tax (2.2%); and two district-level taxes (the Regional Transit Authority of 1.4% and the Seattle Transportation Benefit District of 0.15%). In other places, like the European Union (EU), it may be easier to determine a customer’s location, but there are excluded territories in some countries—such as the Canary Islands in Spain—where VAT rates differ.  

To help users tackle tax compliance, we had to abstract away the “location problem.” This requires not just address cleansing, but answering a few questions:

1. What location information can be used? We can use explicit information and some implicit location information, depending on the region. Explicit information is data that a customer types out, such as a shipping or billing address. Implicit location information is data we can infer from a customer, such as an IP address or the payment method.  
2. What information is needed to inform accurate location determination? The required information for address resolution depends on the tax jurisdiction in which the customer is located. For example, Ireland administers taxes at the country level, but Texas requires a full address or rooftop-level accuracy given the different city, county, and district taxes that could apply.
3. What information is sufficient? Once we determine the information that we can use and that is required by a jurisdiction, we need to decide the information that we should use—and in which sequence—to determine a customer’s location. In some jurisdictions, there are even requirements to store multiple pieces of nonconflicting evidence.

We sought to answer these questions with legal research, data analysis, and engineering efforts. With our origins as a payment provider, we knew we could use information that businesses already supplied to Stripe to calculate tax during checkout, rather than ask users to understand, extract, and apply this information themselves and then make a payment. This approach means that enabling Stripe Tax is as simple as adding one line of code (automatic_tax[enabled]=true). 

We also learned that businesses often need to optimize location accuracy to calculate tax. Many Stripe users collect minimal billing details—such as a US 5-digit postal code ("ZIP")—rather than a full address. To improve location accuracy for users, we built our own mapping to resolve pieces of information to a correct tax jurisdiction. Within the address resolution service, we implemented fallback logic, such that if the geocoder returned empty results (e.g., if a PO Box was provided), we would use a ZIP mapping to get results. By doing so, we improved our ability to resolve ZIP codes to taxing jurisdictions from covering about 60% of all ZIP codes to over 99%—reducing the amount of information a buyer may need to provide before checking out. This efficiently optimizes conversion and does not require changes or additions to the checkout flow.

After finding ways to better qualify and determine customer information, we refined our philosophy around location resolution. Our process in pinpointing location must be: 

• Accurate. Given a set of inputs, we can get an exact location at the district level, and produce a correct, expected tax rate for the buyer. Our users can confidently point tax professionals and authorities to explanations of our methodology that demonstrate they are reasonable. 
• Consistent. The behavior must be the same for a given type of address, whether that’s a country code (IE), a US ZIP code (US, 94103), or a full postal address. For example, we want to guarantee that all valid 5-digit US ZIP codes resolve to the middle of the postal code area.
• Explainable. The behavior of the address resolution can be quickly understood, either intuitively or by using the Dashboard or documentation. For example, to understand whether an address was pinpointed with address-level accuracy or whether the postal code was used as a fallback.
• Forgiving. Address resolution isn’t all-or-nothing. It can partially succeed, providing useful information or an estimated tax calculation, and indicate what was wrong with the input. For example, PO Boxes often aren’t in the USPS address database, but we can still resolve to the correct street.
• Reliable. In the most basic sense, this means that the address resolution system has a high uptime and low latency. Buyers don’t have to wait on a checkout page just so tax can be calculated, nor will calculating tax interfere with time spent to complete the payment.

Calculating the right tax at checkout

Once a business accurately determines its customers’ locations, it needs to calculate the right tax, which can vary across thousands of jurisdictions, for each of its products. Tax law is rarely clear cut and comprehensive; it does not explicitly cover every product nor related products similarly.

Consider the treatment of children’s favorite tax avoider, the gingerbread man. In the United Kingdom, if a gingerbread man has just two chocolate eyes, it is legally a biscuit (tax exempt). However, if that gingerbread man is also wearing chocolate pants or a shirt, it is now legally taxed at a standard rate of 20%. We puzzled over whether we would need to add a boolean is_a_gingerbread_man_wearing_pants to the API before rejecting this approach.

These tax nuances go well beyond bakeries: in the EU, a SaaS business selling to individuals is taxed per the customer’s country unless the business’s turnover is less than €10,000—in which case, it may be taxed according to the rates in the seller’s country. In every industry, businesses need to be ready to defend their interpretation of tax law should an audit occur, especially for products where the tax treatment is unclear or incomplete. 

To make these variances in global tax treatment more manageable for users, we created our own global categorization and hierarchy of tax codes. To support the majority of use cases for our users, we could mostly simplify tax—across the 11,000 jurisdictions we examined to start—into three broad product categories, each with distinctly different rules for tax calculation. Our goal was to help users select the right product classification by abstracting away the complexity of thousands of minute differences in tax treatments without losing any accuracy in tax calculation. 

The three product categories that most efficiently covered the majority of use cases for users are:

• General–Tangible Goods. Any physical good (e.g., a gingerbread man with pants). For jurisdictions that impose a tax, the standard rate is applied.  
• General–Electronically Supplied Services. Any electronically supplied good or service (e.g., a subscription to a health and fitness app). For jurisdictions that impose a tax, the standard rate for digital goods and services is applied.
• General–Services. Miscellaneous in-person services (e.g., a nutrition coach for when the app doesn't work). For jurisdictions that impose a tax on services, the standard rate is applied.

A three-category approach to tax calculation, however, is pushed to its limit by millions of products from millions of businesses. To better serve our users, we needed more granularity in our tax codes, but not so much as to sacrifice the usability of the product. Most of our users were unsure of which tax codes to use, so we analyzed the range and prevalence of their products to find a sweet spot for sufficient coverage. In the end, we built internal support for over 2,000 different products but only exposed 150 user-facing tax codes. Next year, we plan to add more tax codes and automate product classification so that users no longer need to seek and select the correct tax code themselves.

Speeding up filing and remittance 

Many of Stripe Tax’s initial users wanted to fully offload all of tax compliance, from calculating taxes to filing and remitting collected funds to the local jurisdictions. Businesses prefer not to move tax information to and from Stripe into other products and services; they want an end-to-end offering or better integration with other systems. 

As we built reports that mapped exactly to local requirements, we uncovered extreme administrative variances, such as differences in report formats, submission practices, and timing of filings in the US. We saw more clearly why filing is so difficult:

• Regional nuances. Each country and US state has its own unique reporting structure, and its own set of requirements around when and how money should be remitted.
• Government and private partners. To build for remittance and filing requires working with each jurisdiction’s government, and often with industry partners in each region. 
• Human intervention. Parts of compliance remain manual, such as responding to notices and amending a filing due to late returns. Stripe’s expertise is in automating processes and building APIs, and we knew we couldn't completely solve this problem through APIs alone. We’d need a team with the expertise to manage these complex filing issues.

Furthermore, users don’t just want better reports—they want full automation. We faced a build-versus-buy crossroads. If we built our own filing solution, we predicted our ownership of the experience would make integration instantly easier for businesses. If we bought a solution, we could more quickly give our users a trusted, market-tested remittance and filing product.  

We chose to bring a market-tested product quickly to our users. In February 2021, we approached TaxJar to deepen the relationship we had built for years as partners. Since 2013, TaxJar has helped businesses automatically submit tax returns to local jurisdictions and remit the sales tax collected. It had a proven track record with startups, SMBs, and midmarket businesses, as well as excellent customer service and user satisfaction. As we got to know the team and product more, we saw an opportunity to not only quickly deliver tax filing and remittance to Stripe users, but to integrate the solution seamlessly with Stripe Tax. In June 2021, TaxJar joined Stripe.

In short order, we came together to make both Stripe’s and TaxJar’s products work in concert, offering a far more complete solution two years earlier than if we had tried to develop a filing product independently. Acquisitions and product integration are rarely straightforward, but we’re encouraged by early user adoption and optimistic that as the integration continues, TaxJar and Stripe will be able to offer users even more functionality faster.

What’s next

In the same way that payments carry their own cultural and regional context as money moves around the world, taxes have their own geographical flavor and requirements. We want to demystify and automate this burden so businesses can focus on growing, instead of parsing revenues from tax funds and meeting individual jurisdictional requirements. Removing this friction for businesses is in lockstep with our mission of increasing the GDP of the internet.  

Today, Stripe Tax combines highly accurate and deep tax content with scalable and reliable infrastructure that our largest enterprise customers can rely on, with the ease-of-use, flexibility, and simplicity that developers need. Looking ahead, we plan to build a Stripe Tax that is a fully standalone platform comprising multiple tax services—from registration to remittance, enabling end-to-end automation, and including long-run options for Stripe to take on even more of the burden for our users. We will continue to work toward this goal. 

Try out Stripe Tax and tell us what to build next. If you’re interested in tackling these complex challenges, come work with us to make taxes simpler for businesses around the world.