VAT Engine

EU VAT API for ecommerce, SaaS, and headless commerce

Visit Website
August 24, 2026 Opening VAT Engine to developers — looking for real-world EU VAT edge cases

I’ve been building VAT Engine as a solo founder for the past several months.

The idea started pretty simply: provide a reliable API for EU VAT calculations. But once I got deeper into it, the harder problems turned out to be historical rates, product tax classes, OSS/IOSS workflows, transaction evidence, multiple stores/channels, and being able to explain later why a specific VAT treatment was used.

The current version now includes a REST API and dashboard for VAT calculations, current and historical rates, tax classes, transaction history, OSS/IOSS workflows, multi-store reporting, and Shopify integration.

I’ve recently opened the API for free alpha access. Developers can create an account, generate an API key, and try it in a headless checkout, SaaS billing flow, internal tool, or ecommerce integration.

At this stage I’m especially interested in real-world edge cases rather than generic “looks good” feedback.

If you’ve dealt with EU VAT in a SaaS or ecommerce product, what was the part that caused you the most trouble?

https://vat-engine.app/

7 Comments

  1. 2
    The part that cost me the most was that a zero rate is not one thing. A calculation API hands back a rate and an amount, which is the half everyone builds. The half that bites downstream is that the same 0% has to arrive at the invoice as a category code, and for the non-standard categories (AE reverse charge, K intra-community, E exempt, G export, O out of scope) EN 16931 wants an exemption reason attached to it, either the text or a VATEX code. It attaches to the VAT breakdown row, not to the line, so a caller who only got a number back has to reconstruct which category produced it before the invoice will validate. Given you already do versioned rate provenance, you are most of the way there. Does the API return the category alongside the rate today, or is that left to the caller?
    1. 1
      That’s a very good point. Today the category and exemption reason are left to the caller; the calculation response returns only the rate and amounts. Since 0% cannot distinguish between zero-rated, exempt, reverse charge, intra-community supply, export, or outside-scope treatment, callers should not have to reconstruct it from the number. We’ll implement explicit VAT category and exemption-reason support soon, with the necessary context and provenance rather than deriving it from the rate alone.
  2. 1

    The strongest part is treating VAT as an explainability problem, not just a calculation problem. Historical rates, evidence, and being able to explain why a treatment was applied seem especially important once VAT decisions have to be revisited later.

    1. 1

      Exactly — that’s one of the main ideas behind VAT Engine.

      Getting the percentage right is only half the job. Months later, you may need to understand which rate, date, classification, and evidence produced that result in the first place.

      I’m pushing that further with versioned rate provenance and deterministic replay as well. Thanks for picking up on that.

      1. 1

        Would be interested in continuing the conversation beyond the thread. What’s the best email to reach you at?

        1. 1

          You can reach me out with company email. I see there is restriction for sending some links (it recognizes my mail as a link by some reason) you can find the email on the bottom of the website.

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.

About

Building VAT Engine to make EU VAT easier for developers: one API for rates, calculations, historical context, and compliance workflows across ecommerce, SaaS, and headless commerce.