Why Stripe decided to build a tax engine

When Stripe asked users last January what would improve the platform most, tax management came out on top. That answer didn't surprise the team—it reflected years of feedback from businesses wrestling with a problem that only gets harder as they grow.

Stripe's own research underlined the scale of the pain. In surveys and interviews with more than 1,000 users, roughly one in five said they weren't charging tax at all. Of those who did collect it, 49% found it hard to understand and keep up with obligations, and 59% paid third parties to navigate the complexity. The underlying difficulty is stark: an online business selling into the US alone faces over 11,000 potential tax jurisdictions, roughly 600 rate changes in 2021, and thousands of boundary adjustments. European VAT rates shifted widely in the same period as governments responded to COVID-19's economic damage.

The product that emerged, Stripe Tax, applies the same philosophy Stripe used for payments: abstract away the hard parts so merchants don't have to become experts in tax rules or rates. That meant solving three distinct problems: knowing where a customer is, calculating the correct tax for a product at checkout, and making filing and remittance practical.

Pinpointing the customer's location

Every tax calculation starts with jurisdiction, and in the physical world that was simple—the store's location. Online, it's neither simple nor uniform. The US has thousands of jurisdictions, including special-purpose districts whose boundaries don't follow ZIP codes or municipal lines. Stripe's own Seattle office is a case in point: four separate rates apply there (state, city, and two district-level taxes). The EU is often simpler by country, but even then there are excluded territories such as Spain's Canary Islands with their own VAT treatment.

Building a location resolver meant answering three questions in order:

  1. What information can we use? Both explicit inputs like shipping or billing addresses, and implicit signals like IP address or payment method.
  2. What does a jurisdiction require? Ireland is fine with country-level, but Texas needs rooftop-level precision to catch city, county, and district taxes.
  3. What's sufficient given the tradeoffs? Collecting extra fields hurts conversion, so Stripe wanted to ask only what was really needed.

Because Stripe already handles payments, it could pull from data businesses already supply rather than ask merchants to collect and forward additional tax-specific fields. That's why enabling the product takes only one parameter: automatic_tax[enabled]=true.

One concrete win came from address resolution. Many merchants collect just a 5-digit ZIP code, and Stripe's initial geocoder resolved only about 60% of US ZIP codes to the right tax jurisdictions. The team built a fallback so that when the geocoder returned nothing—say, for a PO Box—a ZIP-to-jurisdiction mapping took over. That lifted coverage above 99% and reduced the address detail a buyer must provide at checkout.

The resolution logic was built around five principles:

  • Accurate. Given the inputs, the system reaches district-level precision and a defensible tax rate.
  • Consistent. The same kind of input—a country code (IE) or a ZIP (US, 94103)—always behaves identically.
  • Explainable. Merchants can see whether a location came from a precise address or a postal-code fallback.
  • Forgiving. Partial success is useful; a PO Box that isn't in the address database still resolves to the right street.
  • Reliable. Resolution has high uptime and low latency so tax lookup never slows checkout.

Getting the rate right, product by product

Once the location is known, the tax itself varies by product. And tax law isn't always written with modern commerce in mind. The team's favorite example: a gingerbread man with two chocolate eyes is legally a biscuit in the UK and therefore exempt; add chocolate pants or a shirt and it's taxed as sweets at the standard 20%. That quirk could push an API toward a is_a_gingerbread_man_wearing_pants boolean—a path Stripe consciously rejected.

The deeper issue is that no catalog of products can map cleanly onto thousands of jurisdictional rules. A SaaS sale to an individual in the EU, for instance, is taxed in the customer's country unless the seller's turnover is under €10,000, in which case the seller's home rates apply. Businesses must also be ready to defend their interpretation of such rules in an audit.

Stripe's approach was to build an internal taxonomy that collapses most of that complexity into three broad product categories:

  • General–Tangible Goods. Physical products, taxed at the standard rate where a tax exists.
  • General–Electronically Supplied Services. Digital goods and services, using each jurisdiction's standard digital rate.
  • General–Services. In-person services, using the standard services rate where one applies.

Three categories, though, don't cover millions of products from millions of businesses. Internally Stripe now supports more than 2,000 product distinctions, but only 150 tax codes are exposed to users—enough granularity to be accurate without overwhelming merchants who just want to pick the right code. The next step is automatic product classification so users don't have to choose at all.

Making filing feasible

Early adopters wanted more than calculation; they wanted the full compliance loop: file the returns and remit the funds. What Stripe found was that reports alone wouldn't cut it, and that the administrative burden varies wildly by region. Each country and US state has its own reporting format, submission practice, and timing. Some parts of the process—responding to notices, amending a return—still require human intervention.

Facing a build-versus-buy decision, Stripe chose to buy. In February 2021 it approached TaxJar, a longtime partner that had helped businesses file and remit sales tax automatically since 2013. TaxJar joined Stripe in June 2021, and the two teams integrated TaxJar's filing product with Stripe Tax in short order. Stripe estimates the acquisition delivered a complete solution about two years earlier than an in-house build would have.

Where Stripe Tax goes next

The product today combines tax content with the infrastructure Stripe's enterprise customers expect, while keeping the developer experience simple. The stated roadmap is broader: a standalone tax platform spanning registration, calculation, filing, and remittance, with end-to-end automation. Stripe frames the work as part of its mission to increase the GDP of the internet—removing the friction that keeps businesses from selling across borders. For merchants, the practical takeaway is that tax compliance is now a configuration problem rather than a research project.