Every platform team reaches the same fork in the road.
You are expanding into new markets, adding payment flows, building out invoicing. Tax keeps appearing as a requirement. Someone suggests building it internally. Someone else says to find a point solution.
Both answers miss the real question. The decision is not build vs buy. It is build vs embed. That distinction matters more than most engineering and product teams realize.
The build vs buy frame misses the real decision
When teams frame tax as a buy decision, they treat it like software procurement: find a vendor, sign a contract, integration done. The problem is that tax infrastructure does not behave like other software.
It is not a static tool you configure once. It is a live compliance surface that changes with every market you enter, every mandate that passes, and every tax authority that upgrades its systems. The question is not which vendor you buy from. It is who owns the ongoing responsibility for keeping that surface current.
When you build internally, the answer is your team. When you embed, the answer is the infrastructure provider. That is the real decision.
Building tax infrastructure in-house means owning an expanding compliance surface
Building tax internally means taking on a set of obligations that grow with every market you enter.
Every new country requires a new integration with a local tax authority. Every regulatory change, an e-invoicing mandate, a VAT rule update, a marketplace facilitator law, becomes an engineering ticket. Every audit requires manually assembling a trail from systems that were not designed to talk to each other.
In the early stages this feels manageable. One or two markets, a small compliance surface. It does not stay manageable.
The obligation volume is accelerating. In 2015, 12 countries had e-invoicing mandates. The estimate for 2030 is 130, and tax authorities are adopting AI to enforce them. The compliance surface is expanding faster than most engineering teams can track and faster than most roadmaps can absorb.
The platforms building tax internally are spending engineering capacity on a problem that should be infrastructure, not a product decision.
Embedding tax infrastructure means the system compounds, not your team's workload
Embedding is a different architecture decision entirely.
Instead of building a tax system, you integrate with one. One API surface that covers the full indirect tax lifecycle: validation, determination, e-invoicing, returns, and intelligence. The modules work independently, and they get stronger when connected on a shared data model.
You start where your most acute problem is. If the immediate issue is merchant onboarding, start with validation. If it is tax calculation inside payment flows, start with the tax engine. If an e-invoicing mandate is forcing the decision, start there.
As you connect more modules, each one strengthens the others. Determination feeds into e-invoicing. E-invoicing feeds into returns. Validation feeds into everything downstream. The infrastructure compounds. Your team's responsibility does not.
Jurisdiction updates, mandate changes, authority integrations: the system handles them. Your team decides what to do with the output.
There is a customer side to this too. When tax works quietly in the background, customers see fewer failed transactions, fewer surprise charges at checkout, and an invoicing flow that keeps working as your platform expands into new markets. That reliability is part of the product experience, not a backend detail, and it is one of the reasons customers stay with a platform instead of switching to one that stalls at the first new tax jurisdiction. Protecting that experience protects the revenue attached to it, and it gives you the room to add new markets and new product lines without adding tax risk along with them.
Airwallex, Intuit, and Apaleo chose to embed tax, not build it
Airwallex, Intuit, and Apaleo have made this decision.
Three different platforms, different segments, different customers. The same architecture choice: embed tax infrastructure rather than build it.
For Airwallex, embedding meant global coverage and agility so their customers can focus on growth, not decoding VAT and GST rules across markets.
For Intuit and Apaleo, it meant removing tax as a barrier to scale and keeping compliance off the product roadmap.
In each case, tax infrastructure became something the platform offers, not something it maintains.
Build vs. embed: what should platform teams choose?
The next time tax comes up on the roadmap, the question is not "should we buy a tax tool?"
It is "should we build this, or embed it?"
Building means your team owns the jurisdiction coverage, the mandate updates, the audit trails, and the engineering overhead. That overhead compounds with every market you enter.
Embedding means starting with one integration and compounding the value as you connect more. The system does the work. Your team makes the calls.
And the payoff is not just fewer engineering tickets. It is what your team can build instead: product experiences customers actually trust, new service lines you can launch without a tax integration project attached, and new revenue streams that open up because tax stopped being the blocker. For most platforms, the answer is already clear. The ones getting it right are not spending engineering cycles on tax. They are building products that grow customer value and grow revenue at the same time.
