The Hidden Coding Work Behind Sales Tax Registration and Voluntary Disclosure Agreements

When most people think about sales tax compliance, they picture a finance or tax team filling out forms and filing returns. What they don't see is the technical work happening underneath: the configuration, mapping, and code that has to be built into a tax engine before a single return can ever be filed correctly. For companies expanding into new states — or cleaning up historical exposure through a Voluntary Disclosure Agreement (VDA) — that technical setup is often the hardest and most overlooked part of the process.

Setting Up Sales Tax Registrations in a Tax Engine

Tax engines like Avalara, Vertex, or Sovos don't automatically know how a business operates. Once a company registers for sales tax in a new jurisdiction, someone has to translate that registration into the engine's configuration so it calculates, collects, and reports tax correctly going forward. That typically involves:

• Jurisdiction setup — activating the new state (and any relevant local jurisdictions) inside the engine so it starts calculating tax on transactions tied to that registration.

• Effective dating — making sure the engine only applies tax as of the correct registration or nexus date, not before and not after.

• Filing calendar configuration — aligning the engine or a connected filing service with the actual due dates and frequency (monthly, quarterly, annual) assigned by the state.

• Exemption certificate logic — confirming exemption and resale certificate rules are mapped correctly for the new jurisdiction, since exemption rules vary significantly state to state.

• System integration testing — validating that the ERP, e-commerce platform, or billing system is actually passing the right data (ship-to address, product codes, customer type) to the tax engine so the new registration is used correctly.

None of this is automatic. It's manual configuration work, often done jurisdiction by jurisdiction, and a mistake in any one of these steps can mean tax is either over-collected, under-collected, or misreported — creating a new compliance problem instead of solving one.

Where It Gets More Complex: Multi-Product and Multi-Service Companies

The setup above is relatively manageable for a company selling one type of product. It gets significantly more complicated for businesses with a mixed portfolio — say, a company selling physical goods, digital products, and professional services all in the same transaction flow.

That's because taxability isn't uniform. A state might tax tangible personal property but exempt certain digital goods. Another might tax software-as-a-service but not custom software. Professional services might be exempt almost everywhere, except in a handful of states that tax specific service categories. Multiply that by 45+ taxing states and thousands of possible product lines, and the coding burden grows fast.

This is where taxability codes come in. Each product or service SKU has to be mapped to a tax code that tells the engine how that item should be treated in every jurisdiction. Getting this mapping right requires:

• Auditing the full product and service catalog to identify categories with different tax treatment.

• Researching and assigning the correct taxability code for each category, jurisdiction by jurisdiction.

• Building logic for bundled transactions (e.g., a hardware sale that includes an installation service) so the engine doesn't apply a blanket tax treatment to a mixed transaction.

• Maintaining that mapping over time, since new products are added and tax rules themselves keep evolving.

The VDA Layer: Taxability Coding Gets Retroactive

A Voluntary Disclosure Agreement lets a company come forward proactively to a state, admit unregistered historical sales tax exposure, and settle it under favorable terms — typically a limited lookback period and penalty abatement, in exchange for registering and becoming compliant going forward.

The catch is that a VDA doesn't just require registering in the tax engine on a go-forward basis. It requires a retroactive taxability review. The company has to reconstruct what it should have been collecting during the lookback period, which means:

• Applying historical taxability rules — not current ones — to determine what was actually taxable during each year of the lookback period, since rates and rules change over time.

• Coding transactions from that historical window by product or service category so an accurate tax liability calculation can be produced for the disclosure.

• Reconciling that historical taxability coding against the taxability codes ultimately built into the tax engine, so the go-forward setup and the historical liability calculation are consistent with each other.

• Documenting the methodology used, since states reviewing a VDA submission will often ask how the liability was calculated and expect that logic to hold up.

For a single-product company, this retroactive coding exercise might be straightforward. For a company with a complex mix of products and services, it can mean re-categorizing years of transaction history across multiple states, each with its own historical taxability rules — real technical and analytical work, not just paperwork.

Why This Matters

It's easy to think of sales tax compliance as a legal or administrative function, but a huge amount of it lives in configuration and code. Getting the tax engine setup wrong — whether for a new registration or a VDA — doesn't just create a compliance headache. It can mean applying the wrong tax on live transactions, misstating a VDA liability, or creating new exposure in the very process meant to resolve old exposure.

For companies with diverse product and service lines especially, sales tax compliance is as much a data and systems project as it is a tax project. Treating the engineering side of tax compliance with the same rigor as the legal and financial side isn't optional — it's what makes the compliance program actually work.