SoftbooqAccounting handoff / United States
US sales tax is not a VAT, and treating it like one is a liability
A VAT system charges everyone at a rate set by the seller. US sales tax does neither: you only collect in states where you have nexus, and the rate comes from where the buyer is. Software built for VAT gets both halves wrong, and over-collecting is not the safe error.
What the file actually is
- 1First: do you have to collect at all?A seller collects only in states where it has nexus, meaning physical presence or economic presence above that state’s threshold. No nexus means no obligation, and collecting anyway means holding money you were never entitled to charge.
- 2Then: whose rate applies?The ship-to address, not the seller’s. This is destination sourcing, and it is the opposite of the VAT habit of applying the seller’s national rate to everything.
- 3Finally: is the item even taxable?Taxability is per state and per category. Groceries, clothing, digital goods and professional services are treated differently in different states, so "we charge tax on everything" is its own kind of wrong.
The five things that go wrong
None of these are exotic. Each one is a default that is correct almost everywhere else in software, and wrong here.
It is not safer. Tax collected in a state where you have no nexus is money taken from a customer under a legal authority you do not have, and it does not become correct by being remitted somewhere. The gate has to run before the rate is even looked up.
A VAT-shaped system stores one rate on the seller and applies it to every sale. US sales tax is destination-based, so a seller in Texas shipping to Colorado charges Colorado, not Texas. Same product, same seller, different tax.
Five do not levy one at state level: New Hampshire, Oregon, Montana, Delaware and Alaska. Alaska is the trap, because it has no STATE tax while its localities do levy their own, so "Alaska is tax free" is true of the state and false of the invoice.
What a customer actually pays is the state rate plus county, city and special district rates, and it varies by full address - in places, by ZIP+4. A state base rate is a floor, not an answer, and software that presents it as final is understating the tax.
The real failure is not being approximate. It is being approximate without saying so, because nobody can then tell a state-base figure from a rooftop one. Every result here carries whether local rates were included and why tax was or was not applied.
Why the nexus gate has to come first
It is tempting to treat nexus as a filter applied to the answer: work out the tax, then decide whether to charge it. That ordering produces a system where the rate lookup runs for every sale and someone eventually surfaces the number in a total.
Nexus is a question about the SELLER and the state, and it is answered before any rate is relevant. If there is no obligation, there is no rate to apply and nothing to show the customer, which is a different outcome from a rate of zero.
What a rate service actually buys you
Rooftop accuracy is a data problem, not a logic problem. Combined rates change, districts overlap, and boundaries do not follow postcodes, so exact address-level rates come from a maintained service such as Avalara or TaxJar.
The parts that do not need that data are the parts that decide whether you owe anything: the nexus gate, taxability, sourcing and the arithmetic. Those are correct regardless of where the rate comes from, which is why they belong in the ERP rather than behind somebody else’s subscription.
Economic nexus is why this stopped being a large-company problem
Physical presence used to settle it: a warehouse or an office created an obligation and nothing else did. Economic nexus changed that, and a business can now cross a threshold in a state it has never visited, purely on sales volume.
Practically, that means the nexus list is a thing a growing seller REVISITS, not a setting configured once. It is a configuration value here for exactly that reason.
Out of the box this uses published state base rates. That is enough to be right about whether tax applies and roughly what it costs, and it is not enough to be exact on an invoice, because local and district rates sit on top.
Every result says which it gave you. Softbooq does not yet connect to a rate service such as Avalara or TaxJar, so where you need address-level precision, check the local rate before you invoice. Which items are taxable you mark per line, as taxable or exempt.
Common questions
Can I just charge sales tax in every state to be safe?
No, and it is not the safe option. Collecting in a state where you have no nexus means charging a customer under an authority you do not have. The correct behaviour is to charge nothing where there is no obligation, which is different from charging zero.
Which rate applies, mine or my customer’s?
Your customer’s. US sales tax is destination-based, so the ship-to address sets the rate. A seller in Texas shipping to Colorado charges the Colorado rate. This is the main thing VAT-shaped software gets wrong, because a VAT rate belongs to the seller.
Are there states with no sales tax?
Five have no state-level sales tax: New Hampshire, Oregon, Montana, Delaware and Alaska. Alaska still has local sales taxes, so an Alaskan sale can carry tax even though the state levies none.
Do I need Avalara or TaxJar?
Only for rooftop-exact rates, and Softbooq does not connect to one yet. Whether you owe tax at all - nexus and destination sourcing - does not depend on a rate service, and Softbooq decides it without one. Every result tells you when only the state base rate was used.
Softbooq exports this file directly from posted journal entries, with the encoding, the sign convention, the date format and both decomposition shapes handled explicitly. The behaviour is covered by automated tests that run before every release.
See the Finance module