Sales Tax Compliance Software Problems: The 7 That Create Exposure, and How to Avoid Them

Why does the tax project turn into a rate engine rebuild?

The most common scope failure in indirect tax is deciding to own calculation. It starts reasonably. The connector between your billing platform and Avalara or TaxJar keeps producing wrong answers on bundled products, someone concludes the engine is the problem, and the project becomes a plan to compute rates yourself. Rate content across thousands of jurisdictions then absorbs the budget and is permanently one legislative session behind.

The reason this keeps happening is that the visible symptom is a wrong rate on an invoice, so the engine looks like the culprit. It usually is not. The wrong number almost always comes from what was sent to the engine: a product code that maps to the wrong taxability category, an address that arrived unvalidated, a bundle passed as a single line, or a credit modelled as a negative line on a future invoice. The engine answered the question it was asked.

The fix is to scope the layer, not the engine. Keep a commercial engine for rates and rules, and build transaction normalisation from your own billing platform, taxability determination for your own bundles, nexus monitoring on your own base, certificate lifecycle tied to your customer records, and reconciliation to your ledger. That is the work that breaks, and it is work no vendor can do for you because it depends entirely on how your revenue is shaped. A developer who opens by proposing to replace Avalara is proposing to spend your money on the part that was already working.

What goes wrong when you load historical transactions and prior filings?

You need history for two reasons: nexus thresholds are rolling calculations over a moving window, and any audit will look backwards rather than forwards. So the project loads several years of invoices, credits and filed returns, and the trouble starts immediately.

Three failures recur. Product catalogues changed, so a stock keeping unit that means one thing today meant something else in 2023, and applying today's taxability mapping to old transactions produces a historic position you never actually took. Credits and rebills were modelled inconsistently over time, particularly around billing system migrations, so the same economic event appears as a negative invoice in one period and a credit memo in another and the totals stop tying. And filed returns exist as PDFs, portal screenshots and a workbook, with no line level trace back to the invoices behind the number.

What works is treating the historical load as evidence rather than as data to recompute. Import filed figures as immutable records of what was submitted, with the source document attached, and never let the new system silently restate them. Store taxability determinations as versioned decisions with effective dates, so a 2023 transaction resolves against the 2023 mapping rather than today's. And reconcile a single closed period end to end before loading anything else, because if one month will not tie, five years will not either and you will have buried the reason.

Why do billing, ERP (Enterprise Resource Planning) and engine integrations break after launch?

They break at the seams where somebody changes something without knowing tax reads it. A product manager adds a plan with a new bundle, and no mapping exists, so it defaults to taxable or non taxable depending on how the fallback was written and nobody sees it for a quarter. An engineer renames a field in the billing platform. Finance opens a new legal entity and the intercompany flow arrives in the ledger with no tax treatment.

Usage based pricing is the sharpest edge. Revenue is rated at period end, so the taxable transaction does not exist until a job runs, and if that job is late or reruns, tax determination happens twice or not at all. Teams discover this when a month's liability doubles and nobody can explain it.

Two fixes worth insisting on. First, fail loudly rather than defaulting: an unmapped product should raise an exception that blocks the transaction from being finalised, not quietly pick a treatment. An hour of friction for a product manager is far cheaper than a year of incorrect returns. Second, make determination idempotent and versioned, so rerunning a rating job cannot double count and every determination records the rules version and inputs that produced it. Then when a number looks wrong, the answer is a query rather than an investigation.

What happens when exemption certificates and notices are not covered?

These two are the least interesting parts of the scope and they are where the money leaves. Exempt sales that cannot be supported with a valid certificate are the classic source of assessment, because an auditor samples exempt transactions, asks for the certificate, and anything missing or lapsed becomes tax plus interest plus penalty. Meanwhile the certificates you do hold are phone photographs on a shared drive, filed by customer name, covering one state, collected by a salesperson who has left.

The failure is structural rather than clerical. A certificate is being treated as a document rather than as an object with a customer, a jurisdiction, a type, an issue date, an expiry, an image and a validation status, linked to the transactions it supports. Until it is modelled that way, nothing can check it at invoicing and nothing can tell you it has lapsed.

Notices are the same shape of problem. A letter arrives by post, gets scanned by whoever opens the mail, and has a response deadline measured in days. Failing to respond is frequently worse than the underlying issue, and there is usually no owner. Build a notice log where every letter is scanned, classified, assigned an owner and a due date, and closed with the response attached. Neither feature demonstrates well and both pay for themselves before anything else in the project, which is exactly why they get cut when the budget tightens.

Should you build custom or configure what you already own?

Configure and stop reading if you sell physical goods or straightforward digital products through one storefront on a mainstream ecommerce platform or ERP. Avalara or TaxJar connected properly will calculate, store certificates and file, and a build is pure cost. Anrok is a sensible answer for a software seller with reasonably standard subscription billing, because it already understands digital taxability. Vertex or Sovos fit larger enterprises that need content depth against an ERP they already run.

The hybrid is the right answer far more often than either extreme, and it is what we recommend. Keep the engine for rates and rules. Own the layer around it. Maintaining rate content yourself is expensive and permanently stale, and no auditor has ever been impressed by a home built rate table.

Build the layer when two or more of these hold. Your revenue comes from a homegrown or heavily customised billing system. Your pricing is usage based or bundled so taxability mapping is a judgement rather than a lookup. You run multiple legal entities with intercompany flows. You have already received an assessment or a nexus questionnaire. Or somebody on your team maintains a mapping spreadsheet the connector cannot express, which is the clearest signal of all, because that spreadsheet is already your compliance function and it has no version history, no owner and no audit trail.

How do hidden costs get into the quote?

Five places, all foreseeable if anyone asks the question.

• Source system count. Each billing or order platform is its own normalisation problem, and companies routinely forget the legacy one still invoicing forty accounts.
• Bundled and usage based pricing. Taxability mapping stops being clerical and becomes a series of decisions requiring your tax adviser, which is calendar time as well as fees.
• Multi entity structures. Intercompany flows change the reconciliation model rather than adding rows to it, and eliminations have to be handled explicitly.
• International scope. Value added tax and goods and services tax regimes, and country e-invoicing mandates such as those in Italy and India, are separate projects rather than extensions of the United States work.
• Parallel running. Two full filing cycles run alongside the current process, comparing liability by jurisdiction before you rely on the new system. That is real staff time and it is not optional.

The quiet one is your own historical mess. Reconciling why billing and the ledger have disagreed for two years is discovery work that happens inside this project whether or not anybody scoped it, and it frequently takes longer than building the screens.

What separates a build that works from one that fails here?

The successful ones build the drilldown first. Before any dashboard, you should be able to take a filed liability figure for a jurisdiction and a period and walk it back to the invoice lines that produced it, with the taxability determination and its effective date attached to each one. That single path is what an auditor asks for, what your own team needs on the tenth of the month, and what proves the normalisation layer is actually correct. Teams that build reporting first ship something attractive that nobody can defend.

The second differentiator is whether determinations are stored as decisions or as current settings. A system that only knows today's treatment is useless in an examination of a prior year, and retrofitting effective dating onto years of overwritten flags is close to impossible. Insist on versioned determinations carrying the reasoning, the effective date and who approved them, from the first release.

When choosing a developer, ask how a credit memo issued in a later period against an invoice in a closed period flows to the return. Anyone who has filed will talk about the difference between adjusting a prior period and taking a credit in the current one and will say the answer varies by jurisdiction. Anyone who says the system nets it off has not done this. Ask what they intend to do with the engine you already have, and be suspicious of enthusiasm for replacing it. Then get code, infrastructure and data ownership in writing before kickoff, because states open audits years later and you cannot be locked out of the system that produced a filed number.