I built a small deterministic VAT playground — looking for broken edge cases
I started building a small deterministic VAT decision playground focused on UK → EU SaaS invoicing.
The original goal was simple:
given a seller country, buyer country, VAT number status, and evidence, determine:
- whether VAT applies,
- which regime applies,
- and explain WHY.
What surprised me is how quickly things become messy once you hit edge cases:
- invalid or conflicting evidence,
- reverse charge ambiguity,
- OSS vs non-Union OSS,
- unsupported flows,
- mixed B2B/B2C signals,
- incomplete customer information.
Most existing tools compute a result, but don’t clearly expose the reasoning path.
So I intentionally narrowed the scope and started treating “unsupported scenario” as a first-class outcome instead of pretending to support everything.
Curious how other founders/devs handle this today.
Especially interested in:
- tortured edge cases,
- contradictory evidence situations,
- and examples where compliance logic became hard to explain.
Playground:
https://vatguard.ifriqa.com
This is a stronger problem than it may look at first. VAT logic is not just “calculate the right tax.” The real value is explainability: why a regime applies, what evidence was used, where the uncertainty is, and when the safest answer is “unsupported scenario” instead of pretending the system knows.
That is exactly the kind of trust layer SaaS founders need when compliance logic gets messy. If this grows beyond a playground, I’d position it less as a VAT calculator and more as a deterministic compliance reasoning engine for SaaS invoicing.
One thing I’d watch is the VatGuard name. It is clear, but also locks the product tightly into VAT only. If you later expand into broader tax/compliance decisioning, a harder infrastructure-style name like Davoq.com could age better.