If you already sell software in the United States (or are thinking of doing so) you're probably painfully aware of the South Dakota v. Wayfair ruling of June 2018 . Practically overnight, the burden that is placed on ‘remote’ companies changed and made them responsible for remitting sales tax against any sale made across the USA. This means that wherever you sell from and whatever your level of experience with the American market, you now have to think about tax there.
For those who sell SaaS products outside platforms like Paddle, this is an undeniable and unavoidable headache. For our customers, though, the nature of our Merchant of Record operating model means this burden falls on Paddle’s metaphorical shoulders and leaves them free to think about how to grow their business instead of the strangely complex consequences of Supreme Court decisions.
In this blog post I will explain how we were dealing with sales tax prior to this point and how this decision changed the game.
How we were handling sales tax before
If we take most European countries as an example, the rate is reasonably consistent - at least where something like SaaS or software is concerned - with a rate of 20% in the UK or 19% in Germany. Once we’ve approximated a buyer location by IP, or by them specifying it as part of the checkout journey, then we can apply the tax relevant to that geography. This is either inclusive of the sale price or made as an exclusive addition to the base price, depending on how a seller on our platform has set their account to manage this.
Previously, we were able to handle this really easily: Once we had verified the buyer location it was a case of looking up the sales tax rate for that country against a table in our database. If the rate in a country changed, which happens every now and again, we would manually change the relevant table entry to reflect it. How this rate is used for any given transaction would be recorded elsewhere, but these core rates had a very small overhead to maintain and could be used easily across the Paddle platform.
It’s worth noting that all of the logic that we previously used to calculate sales tax had become distributed over the life of the company and increasing breadth of the product, while tax rate tables and entries also had some degree of replication. However, with clear documentation around those different entries the very occasional changes in rates had such a limited overhead that it was never really an issue for us.
Why handling sales tax in the US is different
We realized early on that in the case of the United States this approach wasn’t scalable. There are over 12,000 different tax jurisdictions in the States and various ways in which any number of these can interact with one another. Take, for example, a buyer in a state with a standard sales tax, who then lives in a city with another, and perhaps even a locality that voted to introduce a temporary additional rate to fund some kind of initiative. These rates will sum to one another to create a rate that might be wildly different to one the next town over.
Our underlying problem in addressing the change in US sales tax was that this scenario plays out continuously and differently every time someone from the United States loads a Paddle checkout. With so many separate jurisdictions, rates and changes to these rates, the potential administrative overheads in maintaining a series of tables in our database was going to become problematic very quickly, if we introduced the concept. We needed something that could handle these changes and scale with the growth of companies who use the Paddle platform.
What we did to address the US sales tax complexity
We decided to centralize our tax logic and calculations into the aptly named ‘Tax Service’, an internal micro-service product. Whenever an area of the Paddle platform, most often the checkout, needs a tax rate it can call this service and receive the right sales tax data back to be handled as required. The service is deliberately agnostic in this respect, returning a rate based on the parameters it is given and ensuring that it doesn’t presuppose what that could be used for.
To do this, we're communicating with the Tax Service in PHP, while the service itself is written in Go. It's an AWS Lambda, built using AWS SAM. A call will hit Cloudflare, which then calls CloudFront, then making a request to API Gateway. The gateway passes the request onto the Lambda which processes it and sends it back up the chain. Voila, a tax rate!
With this new approach to sales tax in the USA, we’ve been able to expand the native tax compliance that Paddle offers as a platform to sell SaaS and software. We’re now looking at supplementing this with additional features to further reduce the pains of being tax compliant in different countries concurrently. At the moment, tax ‘inclusive’ or ’exclusive’ settings are global per account, so we want to evolve this into a per-geo setting. Buyers in the US have a general expectation that any sales tax will be added to their purchase, for example, so we want to meet that on our platform.
I’m absolutely certain that they’ll be more use cases for us to pick up beyond this one, so we’ll be continuing to think about sales tax around the globe so that you don’t have to. Ultimately, it’s solving these types of problems for our clients that gives me and the team real job satisfaction. Having experienced first-hand the complexity that’s inherent to sales tax as a concept for SaaS, I’m extremely pleased to know that the thousands of companies on our platform don’t have to go through the same learning curve.
If you’re thinking of expanding internationally, or struggle with tax or compliance matters in the markets you’re already active in, feel free to get in touch to see how we can help you.