1. Find the customer's country.

2. Look up the VAT rate.

3. Multiply the price by that percentage.

4. Done.

That works until the first real edge cases arrive.

What product was sold? Was the displayed price VAT-inclusive? Which country actually has taxing rights? Was this transaction created today or six months ago? Is it a refund of an older sale? Which rate was used when the original transaction happened?

At that point, a VAT integration stops being a percentage lookup and starts becoming a data and decision-traceability problem.

A country does not have one VAT rate

A basic VAT table might look like this:

{
  "DE": 19,
  "FR": 20,
  "IT": 22
}

Useful, but incomplete.

EU member states can apply standard, reduced, zero, and other rates depending on the type of supply. Books, accommodation, food, pharmaceuticals, and other categories may receive different treatment.

So the more useful question is not:

What is Germany's VAT rate?

It is closer to:

Which VAT rate applies in Germany to this product category for this transaction?

That means a useful API needs product tax context, not only a country code.

The transaction date matters

Using today's rate for every calculation creates another problem.

Imagine processing:

• a refund for an order placed last year,

• an imported historical transaction,

• an audit of an older sale,

• a correction to previously recorded data.

The rate that is active today is not necessarily the rate that was used for the original transaction.

A VAT API therefore benefits from accepting an explicit transaction or supply date:

{
  "country": "DE",
  "tax_class": "standard",
  "date": "2026-01-15"
}

The response can then identify the recorded rate window used for that lookup.

One important distinction: a recorded historical window and a legally verified effective date are not automatically the same thing.

If the underlying source data does not prove legal applicability for a historical period, the API should make that limitation explicit rather than pretending to know more than it does.

Failing clearly is much safer than silently returning a convenient number.

VAT-inclusive and VAT-exclusive prices are different calculations

There is also a basic arithmetic distinction that often gets buried inside tax code.

If €100 is VAT-exclusive at 20%, the total is:

Net:   €100
VAT:    €20
Gross: €120

But if €100 already includes 20% VAT, the VAT portion is not €20.

It is:

VAT = 100 - (100 / 1.20)

which is approximately €16.67.

An API should therefore require the caller to make the price basis explicit instead of guessing.

For financial calculations, I also prefer integer minor units rather than floating-point money:

{
  "amount": 10000,
  "currency": "EUR",
  "price_includes_vat": true
}

Here 10000 represents €100.00.

That avoids a whole class of floating-point rounding problems.

Returning the correct number is only half the job

Suppose an API returns this:

{
  "vat_rate": 0.19,
  "vat_amount": 1597
}

Six months later, someone asks:

Why did this transaction use 19% VAT?

The number alone cannot answer that.

A more useful calculation record may also retain:

• country,

• product tax class,

• transaction date,

• VAT-inclusive/exclusive basis,

• input amount,

• rate used,

• source/store identity,

• calculation timestamp,

• relevant rate-data version or provenance where available.

This turns the VAT result from a disposable API response into something that can actually be reviewed later.

Source identity matters in multi-store commerce

The problem becomes more visible when a business has several sales channels.

An order might come from:

• Shopify,

• a custom checkout,

• another marketplace,

• an imported CSV,

• an internal billing system.

For reporting purposes, simply storing "transaction 12345" may not be enough.

The system also needs to know which source owns that transaction.

That is why I think source profiles are useful as a first-class concept rather than just another string attached to an order.

They make it possible to group and reconcile records without losing where those records originally came from.

Compliance workflows need committed data

There is another important boundary between a calculator and a compliance system.

Someone calling a VAT calculator ten times should not automatically create ten filing records.

Reporting workflows need a defined population of committed business transactions, not every exploratory API request ever made.

That separation becomes important for OSS/IOSS preparation, accountant review, exports, and reconciliation.

Calculation and compliance can share the same data model, but they should not be treated as the same action.

What I am building around these ideas

These problems are what pushed VAT Engine beyond a simple VAT-rate endpoint.

The current direction combines:

• EU VAT calculation,

• TEDB-backed rate data,

• product tax classes,

• date-aware rate lookup,

• transaction records,

• source profiles,

• SME VAT threshold data,

• OSS/IOSS preparation workflows,

• ecommerce integrations.

There is still more work to do, particularly around stronger rate provenance, immutable source evidence, and deterministic replay.

The long-term goal is not just to answer:

What VAT rate should I use?

It is to make it possible to answer:

What information produced this VAT result, and can I understand that decision later?

For financial infrastructure, I think that second question is ultimately the more interesting one.