Destination-Based Sales Tax Needs a Destination

US sales tax is destination-based. The rate is set by the state, and usually by a county or a city underneath it, and which one applies turns on where the customer takes delivery. So the rate is a property of the destination, and the destination is a property of the customer record. That single sentence is the whole design constraint, and it is the one that a system built for value-added tax will not satisfy — not because it is missing a feature, but because it is keyed on the wrong thing.

Nothing here is tax advice, and nothing here will tell you where you have an obligation to collect. That is a legal determination about your own activity and it belongs to your adviser. What follows is about data modelling, and we are going to use our own schema as the specimen because it is the one we can open up.

The customer record, as it actually is

Here is the tax-relevant half of our customer table. Read the last two rows before the first four.

We can place a customer precisely enough to identify a loading dock, and we cannot say which state they are in. Those two facts sit in the same row of the same table.

It is worth saying why the coordinates are not a solution dressed as a joke. A point can be resolved to a taxing jurisdiction — that is what boundary datasets are for, and it is a real product that real companies maintain. It is not a thing you get for free by having stored two decimals, and it is not something we have built or would claim. What we will not do is the cheap version: a regular expression over a free-text address line, deciding real tax on real money, failing silently on every address that does not fit the pattern.

Four places the question gets asked

This is the part that surprised us. The expectation going in was that the customer's jurisdiction would simply be absent from the model — a thing nobody had thought about. What we found instead was the question asked in four places and discarded in all four. Every row below is checkable by reading the file named in it.

1. A resolver that takes three things it does not read

   Our tax context resolver accepted a customer id, an item id and a category name, and read none of them — the rate came from the organization, the tax type and a default flag. Fixed: it reads the customer now, and the other two parameters are gone rather than newly honoured. There is no behaviour behind them, and a signature that accepts an argument it discards is a promise to every caller that it matters.

2. A resolver with a customer parameter and no callers

   A second method took a customer id and returned a "customer exempt" value. That value was set to false as a literal, with a comment beside it describing it as a placeholder, and the method was called from nowhere in the product. Fixed by removal: the parameter and the key are gone, and the method keeps the one job it was really doing.

3. A jurisdiction column that selects nothing

   Our rate table has a jurisdiction region column alongside a jurisdiction country column. It is written by the settings screens. Rate selection filters on organization, tax type and default flag — the jurisdiction is never part of the query.

4. A whole table nothing read, half of which now does

   There is a per-customer tax settings table: registration status, registration number, registration date, an exemption flag, an override rate, an international-trade flag. It was written by the customer form, shown on the customer page, and read by no tax calculation at all. Half fixed: the exemption flag is read now. The override rate still is not.

Why four asks and no answers is more interesting than an absence

A missing capability tells you what to build. A capability whose shape is already present in the code — parameters, columns, a table, a return value — and which resolves to the organization every time tells you something more useful: that somebody understood the requirement, started the plumbing, and stopped before connecting it. That is not a criticism of whoever wrote it. It is the ordinary result of a product growing up in a market where the country-level answer is correct.

It also changes the estimate. "We do not support destination-based tax" sounds like a rewrite. "There is a jurisdiction column that nothing selects on, a customer table nothing reads, and two resolvers that accept a customer id and ignore it" is a list of connections, plus one genuinely new field on the customer record. Those are very different quotes, and the second is the honest one — and it proved to be the accurate one too, because three of those four turned out to be wiring and were done the day this was written.

The general lesson, which is not about tax

Parameters that are accepted and not read are a specific kind of debt, and they are worse than a missing parameter, because they are indistinguishable from a working one at every call site. Somebody passing a customer id to that resolver has every reason to believe it matters. The signature is a promise, and it was not being kept.

What we would build, and the one thing we would decline

The buildable sequence is short and specific: a jurisdiction field on the customer and on the sale; the override rate on that same customer record, which is the last piece of it still inert; and the interface a specialist tax service plugs into, so the rate comes from something that does nothing but rates. What we would decline is maintaining a US rate table ourselves. Thousands of jurisdictions with rules that move is not a side line, and the responsible answer is an integration rather than a table we keep.