Use Tax

Use Tax matters because finance software evaluations usually slow down when teams use the term loosely. This page is designed to make the meaning practical, connect it to real buying work, and show how the concept influences category research, shortlist decisions, and day-two operations.

Definition

A tax imposed on the use, storage, or consumption of tangible personal property or taxable services purchased from a seller that did not collect the applicable sales tax.

Use Tax is usually more useful as an operating concept than as a buzzword. In real evaluations, the term helps teams explain what a tool should actually improve, what kind of control or visibility it needs to provide, and what the organization expects to be easier after rollout. That is why strong glossary pages do more than define the phrase in one line. They explain what changes when the term is treated seriously inside a software decision.

Why Use Tax is used

Teams use the term Use Tax because they need a shared language for evaluating technology without drifting into vague product marketing. Inside tax software, the phrase usually appears when buyers are deciding what the platform should control, what information it should surface, and what kinds of operational burden it should remove. If the definition stays vague, the shortlist often becomes a list of tools that sound plausible without being mapped cleanly to the real workflow problem.

These concepts matter when tax processes need to become more measurable, less manual, and easier to defend during review.

How Use Tax shows up in software evaluations

Use Tax usually comes up when teams are asking the broader category questions behind tax software software. Teams usually compare tax platforms on coverage breadth, ERP and billing integrations, exemption workflows, filing support, and the amount of manual review that still remains after rollout. Once the term is defined clearly, buyers can move from generic feature talk into more specific questions about fit, rollout effort, reporting quality, and ownership after implementation.

That is also why the term tends to reappear across product profiles. Tools like Avalara, Vertex, TaxJar, and Anrok can all reference Use Tax, but the operational meaning may differ depending on deployment model, workflow depth, and how much administrative effort each platform shifts back onto the internal team. Defining the term first makes those vendor differences much easier to compare.

Example in practice

A practical example helps. If a team is comparing Avalara, Vertex, and TaxJar and then opens Avalara vs Vertex, the term Use Tax stops being abstract. It becomes part of the actual shortlist conversation: which product makes the workflow easier to operate, which one introduces more administrative effort, and which tradeoff is easier to support after rollout. That is usually where glossary language becomes useful. It gives the team a shared definition before vendor messaging starts stretching the term in different directions.

What buyers should ask about Use Tax

A useful glossary page should improve the questions your team asks next. Instead of just confirming that a vendor mentions Use Tax, the better move is to ask how the concept is implemented, what tradeoffs it introduces, and what evidence shows it will hold up after launch. That is usually where the difference appears between a feature claim and a workflow the team can actually rely on.

• Is the main buying trigger tax calculation accuracy, returns workflow support, certificate management, or all three?
• How cleanly does the product fit the ERP, ecommerce, and billing stack that drives the source data?
• What implementation burden stays with the internal tax team after go-live?
• Which controls matter most when auditors or regulators need cleaner documentation later?

Common misunderstandings

One common mistake is treating Use Tax like a binary checkbox. In practice, the term usually sits on a spectrum. Two products can both claim support for it while creating very different rollout effort, administrative overhead, or reporting quality. Another mistake is assuming the phrase means the same thing across every category. Inside finance operations buying, terminology often carries category-specific assumptions that only become obvious when the team ties the definition back to the workflow it is trying to improve.

A second misunderstanding is assuming the term matters equally in every evaluation. Sometimes Use Tax is central to the buying decision. Other times it is supporting context that should not outweigh more important issues like deployment fit, pricing logic, ownership, or implementation burden. The right move is to define the term clearly and then decide how much weight it should carry in the final shortlist.

Related terms and next steps

If your team is researching Use Tax, it will usually benefit from opening related terms such as Indirect Tax, Sales Tax Compliance, Sales Tax Nexus, and Tax Automation as well. That creates a fuller vocabulary around the workflow instead of isolating one phrase from the rest of the operating model.

From there, move into buyer guides like Deferred Tax Asset and Tax Software Buyer’s Guide and then back into category pages, product profiles, and comparisons. That sequence keeps the glossary term connected to actual buying work instead of leaving it as isolated reference material.

Additional editorial notes

Your company purchased $340,000 of software licenses from an out-of-state vendor last year. No sales tax was charged on any of the invoices. Your state tax advisor flagged the purchases as likely subject to use tax — meaning your company owes the equivalent of sales tax on those purchases, self-assessed, even though the vendor never collected it. Most finance teams don't track this exposure until it surfaces in an audit. Use tax is a self-assessed tax imposed by states on purchases of taxable goods and services where the seller did not collect sales tax at the point of sale. It is the mirror image of sales tax: when you buy something taxable and no sales tax is collected — because the seller is not registered in your state, or because the purchase occurred online or out of state — you are generally obligated to calculate and remit use tax directly to your state tax authority. The tax rate is identical to the sales tax rate that would have applied if sales tax had been collected. Use tax exists to prevent sales tax avoidance through out-of-state purchasing: without it, buyers could systematically purchase from out-of-state vendors to avoid the state tax that in-state purchases would incur. For businesses with significant out-of-state or online purchasing — software subscriptions, cloud services, equipment, professional services — untracked use tax exposure is one of the most common audit findings precisely because it requires proactive self-assessment rather than passive collection.

How use tax works — and why it creates an obligation even when no sales tax was charged

Use tax applies when three conditions are met: the purchase is of a type that would be subject to sales tax if bought in-state; the seller did not collect sales tax (because they lacked nexus in your state, or the transaction was coded as exempt incorrectly); and the item is used, consumed, or stored in your state. When these conditions apply, the buyer is obligated to self-assess and remit use tax equal to the applicable state and local rate for the buyer's location. The self-assessment obligation is automatic — there is no invoice, no notice from the state, and no collection mechanism that triggers it. It arises purely from the fact that taxable property or a taxable service was purchased without sales tax being collected. For software and SaaS specifically, whether use tax applies depends on whether the state taxes that type of software — which varies significantly. A state that taxes SaaS (such as New York, Texas, or Pennsylvania) will expect use tax on cloud software subscriptions purchased from out-of-state vendors who don't collect. A state that doesn't tax SaaS (such as California for most SaaS arrangements) would not impose use tax on those same purchases. Use tax also applies to tangible personal property: a company that purchases office furniture from an out-of-state vendor who doesn't collect state sales tax owes use tax on that purchase. The same applies to equipment, supplies, and materials consumed in the business.

How to assess use tax liability — and what a use tax accrual looks like in practice

Use tax assessment starts with a review of purchases: every vendor invoice for a period is evaluated for (1) whether the purchase type is taxable in the state; (2) whether sales tax was collected by the vendor; and (3) if no sales tax was collected, whether use tax applies. Purchases where sales tax was correctly collected by the vendor are satisfied — no use tax is owed. Purchases where the vendor is registered and collected the wrong rate may still create a use tax obligation for the difference. Purchases where no tax was collected and the item is taxable trigger use tax at the full applicable rate. For AP teams, this assessment is often done by flagging invoices where the 'tax charged' field is zero or below expectations and routing them for use tax review. The output of the assessment is a use tax accrual: a liability booked to the balance sheet representing accumulated use tax owed but not yet remitted. Many states allow use tax to be remitted on a periodic basis — monthly, quarterly, or annually — rather than per-transaction. Some states have a formal use tax return; others allow use tax to be reported on the sales tax return. States with voluntary disclosure programs allow businesses to come forward, report historical use tax liability (often with a limited lookback period of three or four years), and pay the tax with reduced or waived penalties — which is significantly less costly than a full audit that can look back further.

How tax automation platforms handle use tax assessment and accrual — what the workflow looks like in AP

Tax automation platforms can be configured to assess use tax in the AP workflow: when an invoice is entered and the system detects that no sales tax was charged on a purchase that appears taxable, the system calculates the use tax due and creates an accrual entry. This requires the AP system to pass product or expense category information to the tax engine (so it can determine taxability), the vendor's state of origin (so the system knows whether the vendor had nexus and should have collected), and the buyer's location (so the correct use tax rate is applied). The practical challenge is data quality: AP invoices often lack sufficient product description detail for the tax engine to make a reliable taxability determination, particularly for services and software. Categories coded as 'professional services' or 'software' are too broad for jurisdictions where taxability depends on the specific type of service or software. In practice, fully automated use tax accrual in AP works reliably for high-volume, well-categorized purchases (equipment, supplies) and requires manual review for lower-volume, high-value purchases (software licenses, consulting engagements) where the taxability determination requires more context than the invoice provides.

Questions to evaluate your use tax exposure and process

• Do you have a use tax accrual process — a systematic review of vendor invoices for potential use tax liability — or is use tax only addressed when an audit triggers it?
• Are your AP expense categories detailed enough to allow a taxability determination, or are most vendor invoices coded to generic categories that mask the use tax analysis?
• Have you assessed the taxability of your major recurring software and SaaS subscriptions in your operating states — specifically whether those states impose use tax on cloud software?
• Do you have a regular remittance process for assessed use tax, or does the accrual accumulate without periodic settlement?
• Has your company ever gone through a voluntary disclosure process in any state — and if not, has your tax advisor evaluated whether the voluntary disclosure program would be advantageous given your historical use tax exposure?
• Are purchases made on corporate cards reviewed for use tax liability, or does the review only cover invoices processed through AP?

Where use tax exposure accumulates undetected

The most prevalent failure is assuming that no sales tax charged means no tax obligation. This assumption is incorrect — it is the premise that use tax is designed to defeat. The absence of a vendor-charged sales tax on an invoice is a signal that warrants review, not a confirmation of exemption. For software and cloud services in particular, the vendor's decision not to collect sales tax may reflect their own nexus analysis rather than a determination that the purchase is exempt. If the vendor is wrong about their nexus, or if the state subsequently determines that the vendor should have collected, the obligation to pay the use tax falls to the buyer regardless. The second consistent failure is not building a use tax accrual process for significant vendor purchases. Without a formal accrual, use tax exposure sits unbooked and unremitted. When a state audit covers a three-year period and finds that none of the use tax owed was ever assessed or paid, the assessment includes the full tax amount, interest at the statutory rate for the full period, and failure-to-pay penalties. The retroactive interest alone on a significant software licensing portfolio can materially exceed what a proactive annual accrual and remittance process would have cost.