Sales tax automation is one of the few tax department investments that pays for itself quickly and visibly. A good tax engine calculates rates across thousands of jurisdictions in milliseconds, keeps every filing deadline, and stores exemption certificates at a scale no spreadsheet can match. But automation has a boundary, and most overpayments live on the other side of it. Software executes decisions; it does not make them. When the logic behind a configuration is wrong, or has quietly gone out of date, the engine applies that error consistently, at volume, for years. It is a pattern that shows up in nearly every sales tax audit: the company believed its technology had compliance covered, and the technology believed the company.
This article is a companion to the Revving with Revenew episode Human Oversight in an Automated World, a 26-minute conversation between Richard Van Komen and Jeff Laplante about where automation ends, where judgment begins, and what it costs when no one is watching the machine.
What sales tax automation does well
Sales tax automation excels at high-volume, rule-based work: looking up rates across thousands of jurisdictions, assigning the correct jurisdiction to each transaction, managing filing calendars and remittance deadlines, and storing exemption certificates. For these tasks, software is faster, cheaper, and more consistent than any manual process, and a multi-state business cannot realistically operate without it.
The scale argument alone is decisive. There are more than 11,000 sales tax jurisdictions in the United States, according to the Tax Foundation, each with its own combination of state, county, city, and district rates. No team tracks that manually. Indirect tax automation also produces something auditors respect: a complete trail in which every calculation is logged, timestamped, and reproducible.
None of this is in question. If you operate in multiple states without a tax engine, you have a different and more urgent problem than the one this article describes. The question is not whether to automate. It is what remains for people to do once you have.
The decisions sales tax automation cannot make
Tax engines cannot exercise judgment. They apply the taxability answer someone configured, so any decision that depends on interpretation falls outside their reach: ambiguous purchases, exemptions that turn on how an item is used, multi-state edge cases, and intercompany or drop-ship transactions. In every one of these, the software executes a human’s earlier decision, right or wrong.
Start with taxability judgment. Is a bundled software subscription a taxable digital good, a nontaxable service, or partly both depending on the state? Is a repair part consumed in manufacturing or affixed to real property? The engine does not weigh these questions. It reads the product mapping someone assigned, often years ago, often by a person who never saw the contract.
Exemptions add a second layer. Manufacturing exemptions in most states turn on how an item is used, not what it is. The same motor can be exempt on a production line and taxable in the warehouse next door, and the invoice never says which one happened. State variation compounds the difficulty: only 24 states have harmonized definitions under the Streamlined Sales and Use Tax Agreement, and the largest economies, including California, Texas, New York, and Florida, are not among them.
Then come the structural edge cases. Drop shipments involve three parties and competing certificate requirements, with outcomes that change by state. Intercompany transfers, tooling transactions, and services performed in one state for benefit received in another all require a determination before the engine can do anything useful. The software sits downstream of that determination. It cannot flag a judgment it was never asked to make.
Configuration drift: right at go-live, wrong today
Configuration drift is the gap that opens between how a tax engine was set up and how the business and the law operate now. The system was correct at implementation. Then products changed, entities were added, states rewrote rules, and nobody updated the mappings. The engine keeps running, confidently applying yesterday’s logic.
The pace of change guarantees drift. Vertex counted 681 sales tax rate changes and new rates in 2025 alone, plus 335 newly created city, county, and district taxing jurisdictions, the highest total in more than a decade, per its 2025 end-of-year rates and rules report. Rate changes are the manageable part; engine content updates absorb most of them automatically. Taxability and rule changes are harder, because they interact with your specific mappings, and no vendor update can know that the SKU you launched in March belongs to a category a state redefined in June.
Business change is the other half. Acquisitions bring in entities with different registrations and different mapping conventions. ERP migrations translate item masters imperfectly. Product lines shift from goods to services to subscriptions while the tax codes assigned at go-live sit untouched. Sales tax technology behaves exactly as configured, which is precisely the problem when nobody owns the configuration.
How automation failures become overpayments
Automated systems overpay more often than they underpay, because caution is built into their defaults. Unmapped items default to taxable, stale matrices keep taxing purchases that qualify for exemptions, and vendor-charged tax passes through unquestioned. Each individual error is small; across millions of transactions they compound into material overpayments.
Default-to-taxable is the most common mechanism. When an engine cannot match a purchase to a mapping, most implementations tax it, because underpaying carries penalties and overpaying does not. That is a rational setting, and it silently converts every mapping gap into an overpayment. Stale taxability matrices do the same: a purchase that qualified for an exemption in 2022 keeps getting taxed in 2026 because nobody revisited the matrix. On the purchasing side, vendors overcharge tax, accrual logic double-accrues, and the engine has no reason to object to any of it.
The asymmetry is what lets the problem grow. Underpayments eventually announce themselves through a state audit, with interest and penalties attached. Overpayments generate no notice from anyone. They surface only when someone goes looking, typically in a reverse sales tax audit that re-examines paid transactions against actual taxability. Refund statutes of limitation run in the meantime, generally three to four years depending on the state, so every quarter of delay permanently forfeits a quarter of recoverable tax.
The human-in-the-loop model
A human-in-the-loop model pairs the tax engine’s speed with human review at the points where judgment matters: new products and entities, exemption determinations, high-dollar or unusual transactions, and periodic testing of the configuration itself. The machine handles volume, people handle interpretation, and a defined cadence keeps the two aligned.
The review points are predictable. New products, new entities, and new state registrations need a taxability determination before they reach the engine, not after. Exemption certificates need substantive review, not just storage, since a certificate can be current, complete, and still wrong for the transaction. High-dollar and unusual purchases deserve individual attention before tax is paid or accrued. And the engine’s own content updates deserve a reader, because a vendor’s rule change only helps if someone confirms it maps to your items.
Cadence turns intention into control. A workable baseline: reconcile engine output to the general ledger monthly, sample transactions quarterly, and re-test the full taxability matrix annually or after any major change. These loops belong inside a documented internal sales tax compliance program with a named owner. Newer machine learning tools can help triage exceptions and flag anomalies, and the same oversight logic applies to them; see AI for indirect tax: what’s real, what’s noise, and what’s next for where those tools genuinely help. None of this argues against automation. It argues that automation changes the job from performing calculations to supervising them.
Validating an automated system
Validating an automated system means testing its output, not its settings. Pull real transactions, determine the correct tax treatment independently, and compare the two. A configuration review tells you what the engine intends to do; transaction testing tells you what it actually did, and the difference is where refunds hide.
Internal teams can and should run this test on a sample basis. An independent review adds two things: fresh eyes with no attachment to the original configuration, and pattern knowledge from testing how many other engines are set up and where they typically fail. Independent validation also measures both halves of exposure at once, because the same transaction testing that finds overpayments finds underpayment risk before a state auditor does. Companies that make this a standing practice tend to walk into sales tax audits already knowing what the state will find.
About the author: Richard Van Komen, VP, Sales Tax Recovery. Richard has spent more than 25 years in state and local tax, including service as a tax auditor for the Utah State Tax Commission, and leads Revenew’s sales tax recovery practice.
An automated system that has never been independently tested is an untested system, no matter how long it has run. Revenew’s sales and use tax recovery services validate your engine’s output against actual taxability and complement the software and the team you already have. Request a No-Risk Review to see what your automation has been missing.