FREE TOOL
Free Nexus Calculator: see where you likely owe sales tax across all 50 states.
Try it free
Avalara is running. Transactions are calculating. Returns are filing. From the outside, everything looks like it's working, and that's exactly the problem.
The most common sales tax situation we encounter isn't a company that ignored compliance entirely. It's a company that implemented Avalara two or three years ago, assumed it was handling things, and never looked closely enough to verify. The implementation was done by an IT team, an outside consultant or whoever was handling the enterprise resource planning (ERP) project at the time. The tax logic wasn't reviewed by a tax professional. And in the months and years since, the business changed. New products, new states, and new customers. But the Avalara configuration didn't.
This article is for the finance leader who has that quiet instinct that something might be off. It explains how misconfiguration happens, what it actually costs and what to do about it. Not as a criticism of the software. As a practical guide to getting it right.
This is the reframe that matters before anything else.
Avalara is a calculation and filing engine. It takes inputs from your billing system or ERP, applies tax logic based on those inputs and produces a tax amount. It then files returns in the states you tell it to file in.
What it does not do: determine whether those inputs are correct.
Avalara doesn't know if you mapped your products to the right tax codes. It doesn't know if you should be registered in states where you're not currently registered. It doesn't verify that the exemption certificates in your system are valid and current. It doesn't audit its own outputs.
Avalara's own terms of service make this explicit: compliance is the customer's responsibility. The software executes the logic it's given. If the logic is wrong, the outputs are wrong. Consistently. Automatically. At scale.
This is not a knock on Avalara. It's how every enterprise software tool works. The problem isn't the engine. It's the assumption that implementation equals configuration equals ongoing accuracy. Those are three different things, and most companies only did one of them.
None of these are proof of a problem on their own, but any of them are worth investigating. If you recognize more than one, it's time to take a closer look.
Your product catalog has items mapped to P0000000 or U0000000. These are Avalara's generic placeholder codes for unmapped items. Unmapped items get taxed at the full rate by default. That means you're either overtaxing or undertaxing every transaction that runs through those codes, depending on what the item actually is.
You launched new products or product lines after implementation and nobody updated the tax codes. Taxability rules are product-specific and state-specific. A new software as a service (SaaS) tier, a new services bundle or a new physical product that got added to the catalog without a corresponding mapping update is calculating on default logic that may not be correct.
You have customers with exemption certificates on file in Avalara, but nobody has audited whether those certs are current, complete and state-appropriate. Certificates expire. States have different form requirements. An expired or wrong-state certificate is, from an auditor's perspective, the same as no certificate at all.
You expanded into new states but Avalara is only filing where you were registered at implementation. Maybe you hired remote employees. Perhaps you attended trade shows. Maybe you crossed economic nexus thresholds (the point where your sales volume or transaction count legally requires you to collect tax in a given state). Avalara files where you tell it to file. If you haven't added new states to your registration and filing list, those transactions are uncovered. Use our nexus calculator to get a quick read on where you might have exposure.
You've had an ERP migration, a replatform or an application programming interface (API) update since implementation, and nobody confirmed the Avalara integration still passes all the right data fields. Address handling, transaction types and product codes can all drift during a systems change. The integration may be "working" in the sense that it's not throwing errors, while silently miscalculating tax on every transaction.
Your effective tax rate as a percentage of taxable revenue has been flat for years, even as you've expanded geographically or changed your product mix. This is a soft signal, but it's real. A correctly configured system in a growing, changing business should produce some variation in rates as the mix shifts.
You've never had a third party review your configuration. If the only people who have ever looked at your Avalara setup are the people who set it up, there's no independent check on whether it's right.
Avalara misconfigurations tend to cluster around a few recurring failure modes. Understanding which category you might be in helps prioritize where to look first.
| Misconfiguration Type | What It Looks Like | Why It Happens |
| Wrong product tax codes | Items taxed at full rate when they should be exempt or reduced, or exempted when they should be taxable | Implementation team didn't map all stock keeping units (SKUs); new products added post-go-live without tax review |
| Missing nexus states | No filing happening in states where the business has crossed economic nexus thresholds or has physical presence | Nexus footprint was set at implementation and never updated as the business grew |
| Exemption certificate failures | Exempt sales going through without valid supporting documentation; expired or wrong-state certificates accepted | Certificates weren't validated at collection; no renewal tracking in place |
| Address/sourcing errors | Tax calculated based on wrong origin or destination address; local jurisdiction taxes missed entirely | ERP integration passing incomplete or incorrectly formatted addresses; local tax jurisdictions not mapped |
| Uncommitted transactions | Transactions calculated but not committed in Avalara; not included in returns | Integration issue or user error; returns filed with incomplete data |
| Filing frequency drift | Business grew, state changed filing frequency requirement, Avalara schedule not updated | No one monitoring state notices about frequency changes; software doesn't self-update to required schedule |
| New entity or acquisition not integrated | Acquired company or new legal entity processing transactions outside of Avalara entirely | Mergers and acquisitions (M&A) or new entity setup didn't include Avalara scope |
The compounding problem: most of these errors don't produce error messages. Avalara calculates something for every transaction. If the inputs are wrong, it calculates the wrong thing confidently and quietly, at whatever volume your business runs. A misconfiguration that started two years ago has been repeating itself on every single transaction since.
Sales tax is a gross revenue tax, not an income tax. It's calculated on what you sell, not what you profit. That means exposure isn't buffered by losses or margins.
Consider a business doing $10M in annual revenue. Suppose it has misconfigured taxability on 20% of its product mix for three years. That business isn't looking at a small correction. It's looking at years of transactions where the wrong amount was charged, collected and remitted. Or where nothing was collected at all on sales that should have been taxable.
Most states limit their audit reviews to the past 3-4 years if you have been filing returns. However, if you haven't filed at all, states can look back as far as they want.
Add penalties (often 25-50% of the base tax owed) and interest (which accrues monthly), and the exposure on a seemingly minor misconfiguration compounds quickly into a material number. The audit risk compounds alongside it: states increasingly cross-reference third-party data to identify non-compliant businesses, and a company filing in 8 states that should be filing in 18 is increasingly visible.
The good news: catching and correcting misconfiguration before a state does gives you options. Catching it after doesn't.
An Avalara configuration review by a sales tax specialist isn't a software audit. It's a tax analysis that uses your software setup as the starting point. Here's what it typically covers:
Cross-referencing where you're actually registered and filing against where you have physical and economic nexus based on current operations. This is the first step because everything else builds on knowing where you should be filing. Learn more about how we approach nexus and taxability analysis.
Going through your item catalog and validating that each product or service is mapped to the correct Avalara tax code for what it actually is, in the states where you sell it. This is where most dollar-value errors live.
Reviewing the certificates on file for completeness, currency, state appropriateness and whether the exemption type matches the customer's actual status. Flagging anything that wouldn't survive an audit.
Checking whether the fields being passed from your billing system or ERP to Avalara are complete and correct. Address format, transaction type, entity code, product code. Each one affects what Avalara calculates. For a deeper dive on getting this right, see our guide on making Avalara AvaTax work with your ERP.
Comparing what Avalara reported in returns against what was actually transacted, by state. Looking for gaps, unusual patterns or filing frequency mismatches.
The output: A clear picture of where the configuration is correct, where it's wrong, and what the estimated exposure is for any period where errors have been compounding. That number becomes the basis for deciding what to remediate, how and in what order.
Finding a misconfiguration isn't the end of the story. It's the beginning of a manageable process, and the earlier you find it, the more options you have.
For wrong tax codes, missing states and certificate issues, these get corrected going forward immediately. The Avalara setup is updated. The nexus footprint is adjusted. The certificate files are cleaned up. Future transactions calculate correctly.
For periods where the wrong amount was charged or where you weren't filing, the options depend on the nature and size of the error.
If the company was undercharging or not filing in certain states: Voluntary Disclosure Agreements (VDAs) are often available and are almost always the preferred path. They offer limited look-back, penalties waived and a clean resolution that closes the period.
If the company was overcharging customers (overtaxing): The options include refunding customers, taking a credit against future remittances in that state, or in some cases filing amended returns. This is less common but does happen with product mapping errors.
In either case, having a clear, quantified analysis of what went wrong and over what period is essential before any state conversations happen.
The worst version of this: the state finds it first, opens an audit, and you're reconstructing years of transactions under audit conditions with no VDA option available. That's the scenario that a proactive configuration review prevents.
The businesses that get into trouble with Avalara aren't the ones that ignored sales tax. They're the ones that automated it and stopped thinking about it.
That's not a criticism. It's human nature. You solved a problem, checked a box, and moved on to the next fire. The software kept running. The returns kept filing. Everything looked fine.
But the software does what it's told. If it was told the right things at setup and the configuration has kept pace with how the business has changed, it's probably fine. If not, the errors have been running on autopilot for months or years, compounding quietly in the background.
By catching configuration issues early, you give yourself options. Voluntary Disclosure Agreements (VDAs). Clean remediation paths. Manageable exposure. If you wait for a state notice or audit letter, you have fewer options and face bigger numbers.
A configuration review doesn't take long. A few hours of analysis can tell you whether your Avalara setup is actually doing what you think it's doing. What it finds might change what you do next. Or it might give you genuine peace of mind that the system is working correctly. Either outcome is worth having.
If you've been running Avalara for a year or more and nobody with sales tax expertise has ever looked under the hood, now is a good time. Not because something is definitely wrong. Because knowing for certain is better than hoping it's fine.
Ready to find out where you stand? Schedule a free What's Next consultation and talk through your situation with a real sales tax expert. No pressure, no commitment. Just clarity on whether your configuration is solid or whether it's time to take a closer look.
No — and Avalara's own terms of service make this explicit. Avalara is a calculation and filing engine: it takes inputs from your billing system or ERP, applies tax logic based on those inputs, and produces a tax amount. What it does not do is determine whether those inputs are correct. Avalara doesn't verify that your products are mapped to the right tax codes, that you are registered in every state where you have nexus, or that the exemption certificates in your system are valid and current. It doesn't audit its own outputs. Compliance is the customer's responsibility. The software executes the logic it is given — if the logic is wrong, the outputs are wrong, consistently, automatically, and at scale. This is how Avalara works, and how every enterprise software tool works. The problem is not the engine. It is the assumption that implementation equals ongoing accuracy.
The most common Avalara misconfiguration types fall into seven categories. Wrong product tax codes — items taxed at the full rate when they should be exempt or reduced, or exempted when they should be taxable — are where most dollar-value errors live. Missing nexus states occur when the nexus footprint is set at implementation and never updated as the business grows and crosses new thresholds. Exemption certificate failures happen when certificates expire or were collected on the wrong state form and nobody flagged them. Address and sourcing errors result from incomplete or incorrectly formatted addresses being passed from the ERP, causing local jurisdiction taxes to be missed entirely. Uncommitted transactions occur when Avalara calculates tax but the transaction is never committed, so it never appears in a return. Filing frequency drift happens when a state changes a business's required filing frequency and Avalara's schedule is never updated. And new entity or acquisition gaps occur when a merged company or new legal entity processes transactions entirely outside Avalara.
P0000000 and U0000000 are Avalara's generic placeholder codes for unmapped items — products or services that were added to the system without being assigned a specific Avalara tax code. Unmapped items default to being taxed at the full applicable rate for each state, regardless of whether that is actually correct for what the item is. This means every transaction running through a placeholder code is either overtaxing or undertaxing the customer depending on the item's true taxability. Finding P0000000 or U0000000 codes in your Avalara item catalog is one of the clearest signals that a product taxability mapping review is needed. These codes typically appear on items that were added to the product catalog after implementation — either because nobody knew to assign a tax code at the time or because the item was migrated from another system without a corresponding mapping update.
Your business is. Avalara's terms of service explicitly state that compliance is the customer's responsibility — the software executes the logic it is given, and the business is accountable for ensuring that logic is correct. When a state audits your returns and finds that you have been filing incorrect amounts — whether because of wrong tax codes, missing nexus states, invalid exemption certificates, or any other configuration error — the liability for the unpaid tax, plus penalties and interest, falls on your business. Avalara does not cover penalties or interest resulting from misconfiguration. This is true of every sales tax automation platform: the software automates the calculation, but the business owns the compliance outcome. This is why a periodic independent review of Avalara's configuration by a sales tax specialist — not just by the team that set it up — is one of the most important risk management steps a business using automation can take.
Several warning signs suggest a configuration review is warranted. Items mapped to P0000000 or U0000000 placeholder codes indicate unmapped products taxing at default rates. New products or product lines launched after implementation without a corresponding tax code update are calculating on logic that may not reflect their actual taxability. Exemption certificates on file that have never been audited for expiration, completeness, or state-appropriate form are a certificate liability waiting to surface. States where you have hired remote employees, attended trade shows, or crossed economic nexus thresholds but where Avalara is not currently filing represent unregistered exposure. A flat effective tax rate as a percentage of taxable revenue that has not varied despite geographic or product mix changes is a soft signal that the system may not be reflecting reality. And if the only people who have ever looked at your Avalara setup are the people who set it up, there is no independent check on whether it is correct.
An Avalara configuration review by a sales tax specialist is a tax analysis that uses the software setup as the starting point — not a software audit in isolation. It typically covers five areas. First, nexus footprint verification: cross-referencing where the business is registered and filing against where it actually has physical and economic nexus based on current operations. Second, product taxability mapping review: going through the item catalog and validating that each product or service is mapped to the correct Avalara tax code for what it actually is, in the states where it is sold. Third, exemption certificate audit: reviewing certificates on file for completeness, currency, state-appropriate form, and whether the exemption type matches the customer's actual status. Fourth, integration data validation: checking whether the fields passed from the billing system or ERP to Avalara are complete and correctly formatted. Fifth, returns reconciliation: comparing what Avalara reported against what was transacted, by state, looking for gaps, unusual patterns, or filing frequency mismatches.
The financial exposure compounds quickly because sales tax is a gross revenue tax — calculated on what you sell, not what you profit. A misconfiguration that started two or three years ago has been repeating itself on every single transaction since go-live. The resulting exposure is quantified by calculating the correct tax liability for each affected period in each affected state, comparing it against what was actually remitted, and applying the applicable penalty rate — typically 25 to 50 percent of the base tax owed — plus interest that accrues monthly from the original due date. The good news is that catching and correcting a misconfiguration before a state does gives you options: Voluntary Disclosure Agreements that limit the lookback period and waive penalties are available in most states, and proactive remediation is always less expensive than defending an audit. The worst version of this scenario is a state finding the error first, opening an audit under conditions where the VDA option is no longer available, and reconstructing years of transactions under audit pressure.
We care about your data – privacy policy
