DEV Community: Cranius Maximus

The same $100 sale, three different tax answers

Cranius Maximus — Wed, 12 Aug 2026 00:33:12 +0000

Engineering post, not tax advice. I am a developer, not your accountant. Everything below is about where the branch points are in your checkout code — confirm the actual numbers with someone qualified before you invoice anyone.

You sell a $100 digital product. Same product, same price, same Stripe account. Three different buyers, three completely different correct answers — and only one of them is "add tax."

Buyer one: a person in Germany

You are an Irish company. They are a consumer in Berlin.

GET /decide?seller_country=IE&buyer_country=DE&product_type=digital

{
  "chargeVat": true,
  "mechanism": "standard",
  "rate": 19,
  "buyerType": "consumer",
  "invoiceNote": "Charge DE VAT at 19% (customer's country) and report via the One-Stop Shop (OSS).",
  "legalBasis": "B2C electronically supplied services taxed where the customer belongs (Art. 58)"
}

Note the rate is German, not Irish. For digital goods sold to EU consumers, the place of supply is where the customer is. Your own country's rate is irrelevant. This is the one most homegrown checkouts get wrong — they apply the seller's rate because that is the single number someone hardcoded.

That also means you do not need one VAT rate. You need twenty-seven, and they change.

Buyer two: a company in Germany

Same country. Same product. They type a VAT number into your checkout.

GET /decide?seller_country=IE&buyer_country=DE&buyer_vat_id=DE811907980&product_type=digital

{
  "chargeVat": false,
  "mechanism": "reverse_charge",
  "rate": 0,
  "buyerType": "business",
  "vatId": { "valid": true, "country": "DE", "prefix": "DE" },
  "invoiceNote": "No VAT charged. Reverse charge applies — the customer accounts for VAT in their country."
}

One field in a form moved the tax from 19% to zero, and changed what has to be printed on the invoice. If your checkout has no VAT-number field, every EU business customer is being overcharged and every invoice you send them is wrong.

Worth knowing: format-checking a VAT number is not the same as verifying it is real and active. That needs a VIES lookup. Treat the format check as a cheap first gate, not proof.

Buyer three: a person in the United States

GET /decide?seller_country=IE&buyer_country=US&product_type=digital

{
  "chargeVat": false,
  "mechanism": "out_of_scope",
  "rate": 0,
  "invoiceNote": "No EU VAT charged — the customer is outside the EU (place of supply is where the customer belongs)."
}

Not zero-rated. Out of scope — a different thing, and it lands differently on your return. "Zero" in your database is hiding at least three distinct states: taxed at 0%, exempt, and never in scope to begin with. If your schema stores a rate and nothing else, you have thrown away the reason, and the reason is what an audit asks for.

The one that surprises people

Ask for the digital-goods rate in California:

GET /rate?country=US&region=CA&product_type=digital

{
  "country": "US", "region": "CA",
  "taxType": "sales_tax",
  "rate": 0,
  "taxable": false,
  "notes": [
    "Digital goods are generally NOT taxed...",
    "State-level rate only; local/city/district rates are out of scope. Confirm nexus and local rules with the state Department of Revenue."
  ]
}

California — the state everyone assumes is the aggressive one — generally does not tax digital goods. Meanwhile plenty of smaller states do. There is no rule of thumb here; product type and state interact, and guessing produces confident wrong answers in both directions.

And note the second caveat, which is the one that actually bites US sellers: state rate is not the whole rate. Local and district rates stack on top, and whether you owe anything at all depends on nexus — a question about your business, not about the buyer.

What this means for your code

The useful takeaway is not a number, it is a shape:

Tax is a decision, not a lookup. The inputs are seller country, buyer country, buyer region, product type, and whether the buyer produced a valid business ID. A function that takes only "country" cannot be correct.
Store the reasoning with the amount. mechanism: "reverse_charge" and a legal basis are what let you answer a question a year later. A bare 0.00 is unfalsifiable.
Generate the invoice line at decision time. The wording differs between reverse charge and out of scope, and reconstructing it later means re-deriving the decision.
Rates rot. Whatever you use, know when it was last reviewed.

The thing I built

I kept rewriting this branch logic, so it is now a small self-contained API: EU-27 + UK VAT, US state-level sales tax, Canada GST/HST/PST, Australia GST. Runs on Cloudflare Workers, pure compute, no external calls, and returns the legalBasis and invoiceNote shown above.

Free to hit, no key — every response in this post is a live call you can run right now:

Disclosure, since it is mine: if you would rather run tax logic inside your own infrastructure than call someone else's service — a very reasonable thing to want for something this load-bearing — the source kit is $49: https://craniusmaximus.gumroad.com/l/zxnvil. The hosted API stays free regardless, and nothing here depends on buying anything.

Whatever you use, including your own code: make it return why. The rate is the easy half.

Related: the same question answered for all 27 EU countries and all 50 US states — B2C rate, B2B reverse charge, and which states tax digital goods at all. Generated from live API calls, not written from memory.

Adding three business days is harder than it looks

Cranius Maximus — Wed, 12 Aug 2026 00:29:03 +0000

Every codebase I have worked in eventually grows a function called something like addBusinessDays. It usually starts as four lines, and it is usually wrong in a way nobody notices until a customer complains.

Here is the four-line version:

function addBusinessDays(date, n) {
  const d = new Date(date);
  while (n > 0) {
    d.setDate(d.getDate() + 1);
    if (d.getDay() !== 0 && d.getDay() !== 6) n--;
  }
  return d;
}

It skips Saturdays and Sundays. It is fine until December.

The part that bites

Ask that function for three business days after Christmas Eve 2026 and it says 28 December, because it has never heard of Christmas. The real answer is 30 December.

GET /add?date=2026-12-24&days=3&jurisdiction=US

{
  "date": "2026-12-30",
  "skipped": [
    { "date": "2026-12-25", "type": "holiday", "name": "Christmas Day" },
    { "date": "2026-12-26", "type": "weekend" },
    { "date": "2026-12-27", "type": "weekend" }
  ]
}

Two days off is not a rounding error when it is an SLA, a settlement date, or a promised delivery window.

The part that bites even after you add a holiday list

This is the one I want to convince you about, because bolting a list of holidays onto the naive loop feels like a fix and is not.

US federal holidays move. When a fixed-date holiday lands on a weekend, the observed day shifts. In 2026, 4 July falls on a Saturday, so the holiday is observed on Friday 3 July — a day that is not on anyone's "holidays are these dates" list, and a day your loop will happily count as a working day.

One business day after 2 July 2026:

GET /add?date=2026-07-02&days=1&jurisdiction=US

{
  "date": "2026-07-06",
  "skipped": [
    { "date": "2026-07-03", "type": "holiday", "name": "Independence Day" },
    { "date": "2026-07-04", "type": "weekend" },
    { "date": "2026-07-05", "type": "weekend" }
  ]
}

The answer is the following Monday. A naive loop with a hardcoded 07-04 in it returns Friday 3 July — a federal holiday, and a day the banks are shut.

Thanksgiving has the opposite shape: it is not a fixed date at all, it is the fourth Thursday, so any hardcoded date is wrong every year.

GET /add?date=2026-11-25&days=2&jurisdiction=US

{
  "date": "2026-11-30",
  "skipped": [
    { "date": "2026-11-26", "type": "holiday", "name": "Thanksgiving Day" },
    { "date": "2026-11-28", "type": "weekend" },
    { "date": "2026-11-29", "type": "weekend" }
  ]
}

Note what is not in that list: 27 November is not skipped. The Friday after Thanksgiving is not a federal holiday, even though half the country behaves as though it is. If your rule says otherwise, that is a business policy and you should encode it deliberately rather than discovering it by accident.

Return the reasoning, not just the answer

The thing I would push hardest on, whatever you end up using: make the function explain itself.

A date on its own is unfalsifiable. When support asks why a customer's refund landed on the 30th and not the 28th, "2026-12-30" gives you nothing, and you end up re-deriving the calendar by hand in a Slack thread. A skipped[] array answers the question in one paste, and it makes your tests readable — you assert on why a day was excluded, not merely that the output changed.

It is also the difference between a bug you can find and a bug you cannot. If a holiday list is stale, a plain date looks perfectly reasonable while being wrong. A reason array shows you the day it thought was Christmas.

Things worth deciding on purpose

Whose calendar? Federal, NYSE and your own office are three different answers. NYSE closes on Good Friday; the federal government does not.
Half-days. Markets close early on Christmas Eve and the day after Thanksgiving. If you are computing settlement, that may matter.
Which end counts. Is "three business days from Monday" inclusive of Monday? Both conventions exist. Pick one, write it down, and put it in the function name if you can.
Time zones. A "date" that is really a UTC timestamp will silently be the wrong day for anyone west of Greenwich. Business-day math should take a plain calendar date.

If you want to skip writing it

I got tired of re-implementing this, so I built it as a small self-contained API. It runs on Cloudflare Workers, computes offline with no upstream holiday service, and returns the skipped[] reasoning shown above. It has endpoints for business-day add, diff, next, holiday lookup, T+N settlement, and batch.

It is free to hit and needs no key — the examples in this post are live calls you can run right now:

Disclosure, since it is mine: if you would rather run it inside your own infrastructure than call somebody else's service — which is a very reasonable thing to want for date math this load-bearing — the full source kit is a paid product at $49: https://craniusmaximus.gumroad.com/l/sijflxg. The hosted API above stays free either way, and nothing in this post depends on buying anything.

If you take one thing from this: whatever you use, make it return the reasons. The date is the easy half.

Related: public holiday tables for 17 jurisdictions, each generated from the same live API — useful if you want to eyeball the dates your own implementation should be skipping.

I wanted to leave Claude Code running without trusting a green checkmark

Cranius Maximus — Tue, 11 Aug 2026 19:13:36 +0000

Unattended Claude Code runs are tempting. They are also how you wake up to a fabricated "done" and a burned token budget.

I built the Autonomy Pack because I wanted to see

What is in it

Hooks and operator tooling so an unattended run is less likely to invent success, skip checks, or quietly do the expensive wrong thing. Pair it with session-tax if you also care what the session costs before it starts.

I will not pretend this makes agents safe. It makes my unattended runs less stupid. Your mileage will depend on how you work.

Where to get it

GitHub README (trusted link for forums that filter Pages URLs):
github.com/CraniusMaximus/claude-code-autonomy-pack

Paid pack is $29. Bundle with session-tax is $39. Free session-tax plugin is listed there too if you only want the cost report.

Honest question

Do you guys spend too many tokens on overtooling? Is it a concern you guys have?

Claude Code already shows what I spent. I optimized the spending.

Cranius Maximus — Wed, 05 Aug 2026 14:09:29 +0000

Claude Code already has /usage (same as /cost). On a Pro or Max plan it will show session cost estimates, plan bars, and a recent breakdown of usage by skill, subagent, plugin, and MCP server.

But, I wanted to optimize Claude, or have it optimize itself, rather than tell me. Skills I installed months ago were sitting idle, and contributing tokens each turn. /usage is good at showing what ran and what counted against the plan. It does not answer: what is installed, still loads, and has not fired once across the last stretch of my own transcripts?

That is what session-tax is for.

What it actually measures

It reads your Claude Code session transcripts off disk on your machine. No network calls in the free script. Imports are fs, path, and os.

Across a window you choose (default 90 days) it reports:

how many tokens a session typically opens with, excluding your input (median and the worst tenth)
installed skills versus skills that actually got invoked
how many of those skills look dead (installed, not wired to an event, older than a fortnight, zero invocations in the window), and how many tokens their listings cost on every open
counts for custom agents, connected servers, and hooks

The dollar line is a rough guide. It prices opening context using the cache-read / cache-write mix it sees in your transcripts, and it says so. On a subscription you mostly pay this in overhead.

Free vs paid

Free edition: the totals above. It will tell you how many skills look dead and what that listing tax adds up to. It does not print the names.

Paid ($19, one seat): names the dead skills, points at cold servers (connected but almost never called), machine-readable --json, and --home so you can audit a different profile. Shop link lives in the GitHub README on purpose. Some forums quietly filter *.pages.dev URLs.

Repo: github.com/CraniusMaximus/claude-code-autonomy-pack

What I want to know

Does it help? Is it a waste of time? Any inaccuracies?