

When the buyer pays, as with retail sales and use tax, the seller collects it on every sale. Sundry works it out transaction by transaction: whether the product is taxable under the statute that controls it, and where the sale legally happened.
When the business pays, as with B&O, city B&O and excise taxes, the tax falls on the business, not the sale. Sundry classifies each business activity and each product line, and measures it on the base the law sets: gross receipts, or liters, units and the other measures excise taxes use.
Sales tax is the hardest of these, because the buyer owes it and the seller has to get it right on every sale. The others carry their own complexity: different agencies, forms, bases and cities. Sundry prepares each Washington state and local return from the same classified transactions, and the Sundry Worksheet mirrors each return line for line.
| Standard approach | Sundry | |
|---|---|---|
| Taxability | Product mapped to a code, codes harmonized across jurisdictions | Bound to the controlling statute in each jurisdiction |
| Situs | Point-in-polygon: address interpolated to a point | Polygon-in-polygon: parcel tested against the boundary |
| Bisected parcel | Point lands on one side; no indication anything is wrong | Detected, and the jurisdiction's own rule applied |
| Coverage | Where a rate table exists | Washington state and local returns, read from the statute |
| Basis for a figure | A rate table entry | The statute, retained with the return |
The standard approaches are approximations.
The person who designed them is the one replacing them.
Every engine on the market maps products to a taxability code, then harmonizes those codes across independent jurisdictions with different statutes and different vocabulary for the same thing.
That harmonization is interpretation. Interpretation is a judgment call made once, centrally, and then applied to jurisdictions that never agreed to it.
Sundry doesn't harmonize. For every administering jurisdiction, taxability is bound to the statute, regulation, or decision that actually controls it. Not a code that approximates the statute.
Why nobody did this
Cost.
Reading the controlling law for every product against every jurisdiction is unbounded manual work.
Sundry checks every transaction line in the period. Nothing is sampled.
It works the same whether Sundry calculated the tax as each sale happened, your client's books were imported in full, or a mix of the two.
Each line gets its taxability decision for the product and each authority, its business activity and where it is sourced, and lands on the right line of the right return.
A line Sundry can't classify is held, and the close waits until a person decides it. The result is the Sundry Worksheet your client signs off on.
In an audit, your client has to prove every exempt sale.
An exempt sale without proof is a taxable sale.
The determination says why a sale is exempt. The proof shows it. Sundry keeps the proof for every client.
Customers come from your client's books.
Pick the customer and the proof. Sundry emails the customer a link that works for seven days. You can send it again or cancel it.
The customer fills in the state's own form and signs it.
Sundry reads it against the form's requirements. A bad copy goes back to the sender for a clearer one.
A sale is exempt on the return only when a verified proof is in date at the sale.
Reading statutes at that scale requires a language model. Language models are probabilistic, which is disqualifying for tax. The same product, the same statute, and two different answers on two different days is not a determination.
It is a guess with a citation attached.
Sundry's patent-pending classification system makes the output deterministic. The same product, the same statute, the same answer, every time, bound to the citation rather than generated alongside it.
That is the invention.
Not that a model can read a statute, but that the reading is reproducible.
A single transaction can be governed by as many as five addresses, because sourcing rules decide which one applies.
Interpolate a latitude and longitude for the address, then compute which jurisdiction polygon contains that point. It works until a legal boundary runs through a parcel. Then the point lands on one side of the line, the rate is wrong, and nothing about the answer indicates that anything went wrong.
We resolve the address to the actual cadastral parcel and test the parcel polygon against the jurisdiction polygon: inside, outside, or bisected. Where it is bisected, we apply that jurisdiction's own rule for a bisected parcel.
That is what parcel-accurate means.
Our founder designed point-in-polygon two decades ago. It is still what the industry ships.
Nobody maintains a rate table for a county business-privilege return.
That is the whole reason most software stops at sales tax. A rate table has to be built and kept current by someone, so coverage goes where the volume is, and the further a return sits from sales tax, the less likely anyone has built the table.
Reading the statute has no such limit. The same method that determines a sales tax rate determines a business and occupation rate. The statute exists for every one of them.
Sundry covers Washington today: the state combined excise return and city returns: B&O tax returns and each city's own taxes.
The methodology and the coverage are the same fact.
2005
The approximation
Rory Rawlings, lead inventor of four, filed the original AvaTax architecture under Avalara's founding corporate name. Point-in-polygon situs resolution and code-based taxability. It became the industry standard.
2026
The answer
Deterministic Statute-Bound Tax Determination with Cadastral Situs Resolution.
Patent pending, U.S. 64/097,002.
“2005, I published the approximation. 2026, I invented the answer. It's patent pending.”
Rory Rawlings