# agent's tax jurisdiction cache went stale: wrong VAT on new invoices

## TL;DR
The agent's cached tax jurisdictions no longer match reality: rates changed, boundaries moved, or new rules took effect, and new invoices got the old VAT. Invalidate the cache, recalculate tax for affected invoices, and give the cache a TTL plus a version check against the tax provider. Tax data rots; caches of it must expire.

```text
agent's tax jurisdiction cache went stale: wrong VAT on new invoices
```

## Steps

1. Confirm staleness: compare the cached jurisdiction data against the tax provider's current data. Success check: you can name what changed and when.
2. Invalidate the cache everywhere the agent runs, including workers and edge caches. Success check: every process fetches fresh jurisdiction data.
3. Identify invoices issued with the wrong VAT during the stale window. Success check: the affected invoice list is complete.
4. Correct them: issue credit notes or adjustments per your tax advisor's guidance. Success check: filed tax matches what was actually charged.
5. Set a TTL on the cache and a version check that refreshes when the provider publishes new data. Success check: the next rate change flows through without human action.

## When this applies

- New invoices carry wrong VAT because jurisdiction data was cached too long.
- Tax rates changed and the agent kept using old ones.
- You need cache invalidation tied to tax data updates.

## When it doesn't

- Wrong VAT from a wrong customer address; fix the address data.
- Tax engine misconfiguration; that is wrong rules, not stale rules.
- One-off manual invoice errors; those are human mistakes.

## Tool + version compatibility

Avalara, TaxJar, or any tax provider with jurisdiction data; agent invoice pipelines.

### "stale tax cache wrong vat"
Invalidate everywhere, fix affected invoices, add TTL plus version check.

### "tax jurisdiction cache invalidation"
Tie refresh to the provider's publish cycle, not just a timer.

### "vat rate changed cache"
Rate changes are silent until you check; make the check automatic.

## Why it happens

Tax jurisdictions change constantly: rates move, boundaries shift, product taxability rules update. Caching this data is sensible for performance, but an agent that caches it indefinitely invoices against last quarter's law. The failure is silent: invoices look fine, totals compute, and the error only surfaces at filing time or in an audit. A cache without a TTL on tax data is a time bomb with a quarterly fuse.

## Edge cases / pitfalls

- Correcting issued invoices may need credit notes, not edits; check local invoicing law before touching them.
- Address changes on existing customers can change jurisdiction; re-derive tax when the address changes.
- Version the cached data so you can prove which rules applied to each invoice; auditors ask exactly this.
- Do not set the TTL longer than the provider's update cycle; a yearly TTL on quarterly data is the same bug.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pxuNJxmszAd3HJ9lbgsBRA