How Stripe Rebuilt Its Accounting Engine for Global Tax Compliance

Lucas: Stripe processes well over a trillion dollars in payments every year, and every single one of those payments has a tax question attached to it - sales tax, VAT, GST, you name it. Luna: Right, and the rules aren't just different per country. They change at the state level in the US, and even at the city level in some cases. Lucas: Exactly.

Stripe's old system handled that by running a nightly batch job. After a payment settled, a cron job would wake up, pull the transaction, apply the correct tax rule, and update the ledger. That worked when Stripe was processing millions of payments. But when you're at a trillion dollars and growing, a nightly batch means you're always a day late on your tax liability.

Luna: So they decided to rebuild the entire accounting engine to be real-time. What was the trigger? A specific compliance issue? Lucas: The trigger was the EU's 2025 VAT in the Digital Age reforms.

That regulation requires digital platforms to report transaction-level tax data within 24 hours, not days. Stripe's batch system couldn't meet that without a major redesign. So the engineering team started a multi-quarter project to build a streaming tax engine. Lucas: The core decision was to move from a relational ledger to an event-sourced system built on Apache Kafka.

Every transaction becomes a stream of events - checkout started, payment authorized, tax calculated, settlement completed. Tax rules are applied as events flow through a state machine. Luna: That sounds like a massive architectural shift. How do you maintain audit-grade accuracy when you're processing events asynchronously?

Lucas: That's the fascinating part. Stripe built a custom finite state machine, or FSM, specifically for tax events. Each transaction goes through a defined set of states - pending tax calculation, tax computed, tax reconciled. The FSM enforces that no state transition can happen unless the previous one was logged and confirmed.

So even if Kafka delivers events out of order, the FSM buffers them and replays in sequence. Luna: So it's like a deterministic workflow engine but purpose-built for tax. How many distinct tax rules does this engine actually run? Lucas: The team told me they maintain around 47,000 individual rules across 130 jurisdictions.

And on an average transaction, the engine evaluates a subset of those rules in about 12 milliseconds. The trick is that they precompile the rules into a decision tree at deployment time, so each transaction only traverses the branches that are relevant to its geography and product type. Luna: 47,000 rules is a lot. Who writes those?

Is it Stripe's tax team or engineers? Lucas: Both. There's a dedicated tax content team of around 15 people - former tax accountants and lawyers - who write the rules in a domain-specific language that Stripe built. Then engineers review the DSL for performance and deploy it.

The DSL compiles down to a binary format that the FSM can evaluate without any database lookups. Luna: No database lookups at runtime? That's impressive. So the entire tax decision is embedded in the compiled code?

Lucas: Yes. The only database query during a tax event is to verify the customer's tax exemption status, which is cached. Everything else - rate lookups, nexus rules, product taxability - is encoded in the compiled decision tree. The FSM just traverses the tree in memory.

Luna: What happens when a rule changes? Say a city raises its sales tax rate overnight. How do they roll that out without pausing transactions? Lucas: They use a blue-green deployment strategy for the rule set.

The FSM can hold two versions of the decision tree at the same time. Incoming transactions are tagged with a timestamp. For any transaction, the FSM uses the rule set that was active at the transaction timestamp, not the current one. That way, a rule change doesn't retroactively affect older transactions.

Luna: That's clever. So the event sourcing approach actually makes retroactive tax adjustments cleaner, not harder. Lucas: Exactly. And the audit trail becomes a first-class citizen.

Every tax event is logged to a separate immutable Kafka topic. Auditors can replay the entire tax history of any transaction by reading the event stream from the beginning. No more reconciling spreadsheets. Luna: I want to push back on the cost here.

Maintaining 47,000 rules, a DSL, a custom FSM - that's a huge engineering investment. Why not buy an off-the-shelf tax engine from a company like Vertex or Avalara? Lucas: Great question. Stripe actually evaluated those vendors.

The problem was latency. Off-the-shelf tax engines typically require an API call that takes 50 to 100 milliseconds. For Stripe, adding 50 milliseconds to every checkout flow was unacceptable - especially for large marketplaces where a single checkout can involve dozens of sub-transactions. The custom FSM does it in 12 milliseconds end to end.

Luna: So the latency budget forced them to build. But once you have that engine, why not expose it as a separate product? Stripe Tax already exists, but it's more of a reporting layer. Do you think they'll open up the real-time engine as an API?

Lucas: I think it's inevitable. In fact, Stripe has already started rolling out a new API called Tax Engine that lets marketplace platforms pass transaction data and get real-time tax breakdowns. It's in beta with a few large customers. If they can abstract the complexity, they could turn this compliance burden into a revenue stream.

Luna: And that's exactly the kind of infrastructure play that makes Stripe more than a payments company. Lucas: It's a pattern we're seeing more broadly. The companies that treat compliance as a first-class engineering problem - not just a legal checkbox - end up building moats. Tax, identity verification, fraud detection - these are all becoming platform layers.

Luna: Before we go further, I wanted to touch on something related to how we do this show. We deliberately keep these episodes ad-free. No sponsors, no mid-roll interruptions. It's a choice we made because we want the conversation to be as dense and uninterrupted as possible.

If you find value in that, and you want to support it, there's a simple way - buy me a coffee dot com slash fexingo. No obligations, just a way to keep this model sustainable. Lucas: Yeah, that's exactly right. And it's not about asking for much - it's just that the ad-free format lets us go deep on topics like this without worrying about cramming in a commercial break.

If the episodes help you think about your own architecture, that's the goal. Luna: Alright, back to Stripe. One thing I haven't asked is how they tested this new engine. You can't exactly A/B test tax compliance - if the old system says you owe $100 in VAT and the new one says $95, which one is right?

Lucas: They built a replay framework. They took six months of historical transaction data and ran it through both the old batch engine and the new streaming engine. Then they compared the output line by line. Any discrepancy was flagged and investigated.

They found about 0.3 percent of transactions had differences, mostly due to rounding or timing edge cases. Each discrepancy got a manual review by the tax team. Luna: Six months of data.

That's a lot of compute. Did they have to build a special infrastructure for that replay? Lucas: They spun up a separate Kafka cluster and ran the replay in parallel. The whole process took about three weeks of wall-clock time.

And they published the results internally - every discrepancy was documented in a shared spreadsheet with a root cause. That level of transparency helped get the engineering and tax teams aligned. Luna: So after the replay, they cut over. How did they handle the transition?

Did they run both systems in parallel for a while? Lucas: For the first month, they ran a shadow mode. The new engine computed tax in real-time but didn't actually post to the ledger. The old batch job still ran at night.

Every morning, the compliance team compared the two outputs. After 30 days with zero material differences, they flipped the switch and turned off the batch job. Luna: That's a textbook cutover strategy. I'm curious about one more thing: the latency distribution.

You said 12 milliseconds average. What's the p99? Lucas: The team shared that the p99 is around 45 milliseconds. The tail latency comes from transactions that involve multiple line items with different tax treatments - like a bundle of goods where some are taxable and some aren't.

The FSM has to traverse multiple branches for each line item. But 45 milliseconds is still well under the 50-millisecond threshold that Stripe set as acceptable. Luna: Last question: do they plan to extend this engine to other compliance domains? Like income tax withholding for gig economy platforms?

Lucas: That's exactly the roadmap I've heard. The FSM and event-sourcing pattern are general enough to handle any rules-based computation. Income tax withholding, insurance premium tax, even carbon offset calculations - the same architecture applies. Stripe is positioning this as a compliance infrastructure layer, not just a tax engine.

Luna: And that's where the real value lies. Not in saving milliseconds on tax lookup, but in creating a platform that every fintech will eventually need. Lucas: Exactly. The companies that build the pipes for regulation - those are the ones that become indispensable.

Stripe is doing it for payments and now for tax. I wouldn't be surprised if in five years, every major fintech runs some version of this architecture. Luna: Which raises the question: should other companies build or buy? We've seen a few startups trying to offer a Stripe-like tax engine as a service.

Do you think the market is big enough for a standalone player? Lucas: I think there's room for both. Large enterprises with complex product catalogs will likely build, because tax is too close to their core revenue. But small and mid-sized businesses will buy.

The key is whether the standalone engines can hit that 12-millisecond latency point. If they can't, they'll be relegated to batch processing for smaller players. And the winner in real-time compliance will be whoever can combine low latency with broad jurisdictional coverage. Luna: Well, it's a space to watch.

Thanks for breaking down how Stripe rebuilt the engine. I learned something. Lucas: Always a pleasure. Next time, we'll look at how a completely different industry is tackling real-time compliance: healthcare billing.