Sales and Indirect Tax Compliance Software: What It Costs to File Across Thousands of Jurisdictions Without Missing a Nexus Trigger or an Expired Certificate

Why indirect tax breaks the moment your order source is not standard

It is the tenth of the month. The indirect tax manager has an export from the billing platform, a trial balance from the accounting system, and a returns workbook. The three do not tie. The billing export shows 41,208 invoice lines. The general ledger shows a tax liability that is 9,140 dollars higher, and nobody yet knows whether that is a timing difference on credits, a set of transactions that were taxed at the point of sale (POS) but landed in a different revenue account, or a genuine error. Meanwhile a state has sent a notice about a period that closed fourteen months ago, and the person who filed it has left. Returns are due in eleven days across dozens of jurisdictions and somebody has to decide what to file.

The tools around this are real and mostly good. Avalara and TaxJar calculate rates and file returns competently. Vertex and Sovos serve larger enterprises with deep rate and rule content. Anrok is built for software sellers and understands digital taxability. What they all assume is a clean transaction source with a stable schema, one order per document, a customer with an address and a product with a code. The moment your revenue comes from metered usage rated at period end, or from bundles where one SKU contains taxable and non-taxable elements, or from a homegrown billing platform where a credit is modelled as a negative line on a future invoice, the assumption breaks. Then the connector becomes a mapping exercise that somebody maintains in a spreadsheet, and the spreadsheet becomes the compliance function.

Problem 1: nexus is a calculation you have to run, not a status you have

After South Dakota v. Wayfair in 2018, states adopted economic nexus rules based on sales or transaction volume into the state, commonly around 100,000 dollars or 200 transactions, with several states since dropping the transaction count and others using different bases and measurement periods. What that means operationally is that nexus is a rolling calculation over a moving window, per state, on a base that is not always your gross revenue, and it can be triggered by a good quarter in a state you have never thought about.

The failure mode is silence. Nobody notices the threshold was crossed in March until an accountant spots it in November, and by then eight months of uncollected tax is a liability you owe whether or not you charged the customer. Packaged tools offer nexus dashboards, and they work when the transaction feed matches their model. A custom build computes the threshold from your own normalised transaction ledger, on the correct base for each state, with an alert at a percentage of the threshold rather than at the crossing, so you have time to register before you have an exposure. It should also track physical presence triggers that no transaction feed knows about: a remote employee hired in a new state, inventory placed in a third party warehouse, a trade show with sales activity. Those are calendar and HR (Human Resources) events, and the reason they are missed is that nobody connected them to tax.

Problem 2: taxability of what you actually sell

Rate lookup is the easy half. The hard half is deciding whether the thing you sold is taxable in that jurisdiction, and that depends on how it is characterised. Software delivered electronically, software as a service, a data service, a digital good, a professional service bundled with a licence, training, support: these are taxed differently across states and the distinctions can hinge on whether the customer has possession, whether the service is separately stated on the invoice, and how your contract describes it.

Tax engines maintain taxability content per product category, and it is good content. The gap is the mapping from your catalogue into those categories, particularly when a single SKU bundles elements with different treatment. If a plan includes hosted software, an onboarding service and an optional hardware device, the correct answer is often to unbundle on the invoice, which is a billing change before it is a tax change. A custom layer holds the taxability decision as versioned, documented mapping with the reasoning attached, so when a state auditor asks why a product was treated as non-taxable in 2024 you can produce the determination and its date rather than a current setting. Store the decision, not just the outcome. Auditors ask about the decision.

Problem 3: exemption certificates expire quietly

A resale certificate collected in 2021 by a salesperson, emailed as a phone photograph, saved to a shared drive folder named by customer, covering one state, with a validity period that has since ended. Multiply by several thousand customers. Nothing in your systems knows it exists, and nothing tells you when it lapses. This is the single most common source of assessment in a sales tax audit, because the auditor samples exempt sales and asks for the certificate, and any sale you cannot support becomes tax plus interest plus penalty.

The build treats a certificate 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. Invoicing checks it at the point of sale, not at audit. Expiry produces a renewal campaign automatically, and a customer whose certificate has lapsed either supplies a new one or gets charged tax, which is an uncomfortable conversation your finance team should be having proactively rather than an assessment your CFO discovers later. Document extraction is a legitimate use of machine learning here: certificates arrive as photographs and PDFs in dozens of state formats, and an extraction pass that reads the state, the type, the identification number and the dates for human confirmation removes a large amount of clerical work.

Problem 4: the return has to reconcile to the ledger

Filing a number you cannot tie to your accounts is how a small error becomes a multi-year exposure. Between the billing platform and the return sit credits and rebills, partial refunds, bad debt write-offs, intercompany transactions between entities that must be eliminated or treated, foreign currency, and revenue recognised in a period different from the one the invoice was raised in.

The design that works is a single normalised transaction ledger sitting between source systems and everything downstream. Every source document lands there with its original identifiers preserved, tax determination is attached to the line, and both the return and the general ledger posting are produced from that one place. Then reconciliation is a report rather than an investigation: liability per jurisdiction per period from the ledger, compared to what was filed and what was accrued, with variances explained at line level. Build the drilldown from the filed figure back to the invoice line before you build anything else, because that is the artefact an auditor asks for and the thing your own team needs at eleven o'clock on the tenth of the month.

Problem 5: registrations, calendars and notices are the unglamorous half

Every registration carries a filing frequency that a state can change. Some jurisdictions require prepayments. Local returns exist in home rule states that do not follow the state administration. Notices arrive by post, are scanned by whoever opens the mail, and have deadlines measured in days. Failing to respond to a notice is frequently worse than the underlying issue.

Custom systems win here by being boring. A registration record per jurisdiction with its account number, frequency, due dates, login custodianship and prepayment rules. A calendar that generates the period's work automatically. A notice log where every letter is scanned, classified, assigned an owner and a due date, and closed with the response attached. Nobody demonstrates this in a sales pitch and it is often the part that pays for itself first, because the recurring cost of missed notices and late filings is real money that never appears in a business case until it does.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A focused first release covering transaction normalisation from your billing platform, taxability mapping, nexus threshold monitoring with alerting, and reconciliation from filed liability back to invoice line runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding certificate lifecycle management, return preparation and filing workflow, registration and notice management, and VAT or GST handling for other regimes runs $200,000 to $450,000 phased over 6 to 12 months.

What drives the price up: the number of source systems, because each billing or order platform is its own normalisation problem. Usage based and bundled pricing, since the taxability mapping becomes genuinely difficult rather than clerical. Multi-entity structures with intercompany flows, which change the reconciliation model. International scope, because value added tax with its own OSS and IOSS regimes, and country e-invoicing mandates such as those in Italy and India, are separate projects rather than extensions. What keeps price down: keeping the calculation with an existing engine and building only the layer around it, which is the right answer more often than people expect.

Build versus buy, and when the engine is enough

Buy, and do not call us, if you sell physical goods or straightforward digital products through one storefront running on a mainstream ERP or ecommerce platform. Avalara or TaxJar connected properly will handle calculation, certificate storage and filing, and a custom build would be pure cost. Anrok is a sensible answer for a software seller with reasonably standard subscription billing. Vertex or Sovos fit larger enterprises with content depth requirements and an ERP they already run.

The strong case for building is a hybrid, and this is our opinion rather than a neutral survey: keep a commercial engine for rates and rules, because maintaining rate content yourself is a bad use of money, and build the layer that your business actually breaks on. That layer is transaction normalisation from your own billing platform, taxability determination for your own bundles, nexus monitoring on your own base, certificate lifecycle tied to your own customer records, and reconciliation to your own ledger. Build when two or more of these are true: your revenue comes from a homegrown or heavily customised billing system, your pricing is usage based or bundled, you operate multiple legal entities with intercompany flows, you have already received an assessment or a nexus questionnaire, or your team is maintaining a mapping spreadsheet that the connector cannot express.

How to choose a developer for indirect tax software

Ask them to explain how a credit memo issued in a later period against an invoice in a closed period should flow to the return. If they have done this work they will talk about the state's rules on adjusting a prior period versus taking a credit in the current one, and they will know the answer differs by jurisdiction. If they say the system will just net it off, they have not filed a return.

Ask how they store a taxability determination. You want the decision, the reasoning, the effective date and who approved it, not a current flag on a product record. Auditors examine history, and a system that only knows today's setting is useless in an examination of 2023.

Ask what they will do with the tax engine you already have. A developer who wants to rebuild rate content is proposing an expensive and permanently stale product. The right instinct is to keep the engine and own the layer around it.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. Tax positions have long tails, and being unable to inspect the system that produced a filed number is not a position you want when a state opens an audit four years later.