Your subscription business has just renewed 10,000 customer accounts. The billing platform processed the payments, invoices went out, and recurring revenue landed as expected. But did every invoice receive the correct sales tax treatment?
A customer may have moved to another state. Another upgraded midway through the billing cycle. A third received a credit, while an enterprise account added usage-based services to an existing software subscription. Each change can affect the transaction details used to calculate sales tax.
That is what makes subscription sales tax different from a straightforward, one-time sale. The same customer may generate dozens of tax-relevant billing events over the life of an account, and the rules that apply can vary by state, product, and transaction.
Recurring revenue is predictable. Sales tax compliance is not always so simple.
For subscription businesses, the challenge is making sure every billing event reflects the correct taxability, sourcing, and transaction details. Otherwise, a small configuration error can repeat across thousands of invoices before anyone catches it.
Subscription models are built around change. Customers move between plans, add features, consume different amounts of a service, and adjust their contracts. Billing systems are designed to manage these changes, but calculating sales tax requires more than applying a percentage to the recurring charge.
The tax treatment of software and digital services varies across jurisdictions. Some states tax certain SaaS offerings, while others may exempt them or distinguish between different types of software and services. Iowa, for example, addresses SaaS and related services in its official guidance on specified digital products and software.
The challenge grows when a subscription includes multiple components, such as software access, implementation, support, data services, or digital products. The tax treatment may depend on what the customer receives and how the offering is structured.
A subscription business therefore needs to answer two questions for each relevant transaction: what is being sold, and which jurisdiction's rules apply?
A renewal may look identical to the original purchase, but the tax determination should not simply be copied forward without checking the relevant transaction details.
Taxability rules may have changed. A customer may have updated their address or exemption status. A new product feature may have changed the nature of the offering. Even if the subscription price remains the same, the facts supporting the original tax treatment may no longer apply.
Upgrades and downgrades introduce additional complexity. A customer might move from a basic software plan to a premium tier that includes additional services. Another might remove a taxable add-on but retain an otherwise exempt subscription.
If the billing system uses a single tax code for every plan, it may fail to reflect these differences.
Mid-cycle changes create another challenge. When a customer upgrades halfway through a billing period, the system may calculate a prorated charge or issue an adjustment. The correct tax treatment depends on the nature of that charge, the applicable rules, and how the billing event is handled.
The important point is that a billing event is not automatically tax-neutral just because the customer already had an active subscription.
Usage-based pricing makes revenue less predictable and tax calculation more dynamic.
A software provider might charge a base subscription fee plus additional amounts for API calls, data processing, storage, transactions, or usage above a contractual threshold. One customer pays the same amount each month, while another generates a much larger bill because usage increases.
The tax question is not simply whether the charge is recurring. It is what the usage fee represents under the relevant state's rules.
If usage charges relate to access to taxable software, they may follow the treatment of that software in a particular jurisdiction. If the charges represent a distinct service, a different analysis may be necessary. The answer depends on the actual offering and applicable law.
Businesses can run into trouble when billing systems classify every usage charge under a generic service code or apply the tax treatment of the base subscription to every additional fee.
The solution starts with product and billing governance. Each charge type should have a documented purpose, an approved tax classification, and a clear mapping to the transaction system. When pricing models change, Tax should review the change before it affects live invoices.
Credits, discounts, and bundled offerings can make an otherwise straightforward invoice harder to interpret.
A credit may correct a prior billing error, compensate a customer for a service issue, or reduce the amount due under a subscription. Its sales tax treatment depends on the circumstances and applicable rules. A system that simply subtracts every credit from the next invoice without preserving the original transaction details can make reconciliation more difficult.
Bundles create a different problem. A subscription may combine software access with onboarding, training, support, or other services. Those components may not receive identical tax treatment in every state.
If the entire bundle is assigned one generic tax code, the system may apply the wrong treatment to the charge. Separately identifying components can help, but separate invoice lines do not automatically make a charge nontaxable. The underlying facts and jurisdiction-specific requirements still matter.
Businesses should review the structure of their offerings, the way charges appear on invoices, and how credits relate to the original sale. This is especially important when product teams introduce new features or commercial teams change packaging and pricing.
For more on this issue, see CereTax's guide to SaaS bundling and sales tax.
A subscription may be sold online, but that does not make customer location irrelevant.
The applicable sourcing rules determine which jurisdiction's tax treatment and rate apply. Depending on the transaction and state rules, businesses may need to consider the customer's address, business location, place of use, or other prescribed location information.
This becomes complicated when a customer relocates, an enterprise account operates across multiple locations, or billing and service records contain conflicting addresses.
A billing address that was correct when a customer first subscribed may be outdated by the next renewal. If the system continues using the old address, it may calculate tax for the wrong jurisdiction.
The Multistate Tax Commission's guidance on sourcing digital products discusses sourcing considerations, including situations involving digital services used across multiple locations. The applicable sourcing method depends on the relevant law and transaction facts.
Subscription businesses should maintain accurate customer location data and establish a process for updating it. Address validation, consistent customer records, and transaction-level sourcing rules help reduce the risk of repeatedly calculating tax from stale information.
A sales tax holiday is usually associated with qualifying purchases of tangible goods, but businesses should not assume that every digital product or bundled offering is automatically excluded.
Eligibility depends on the state, the products covered, the applicable dates, and the specific rules. If a subscription business also sells qualifying hardware, digital products, or bundled offerings that fall within a state's holiday provisions, product classification and billing configuration may need review.
The Streamlined Sales Tax sales tax holiday resource provides state-specific information and directs businesses to consult the relevant state for authoritative guidance.
The broader lesson applies beyond holidays: temporary rules and changes to taxability need to reach the systems that process transactions. A taxability decision sitting in a spreadsheet will not help if the billing platform continues applying an outdated classification.
Managing recurring tax risk requires a process that follows the customer and the product throughout the subscription lifecycle.
Sales tax automation can connect these controls to the systems that create and update subscription invoices. A tax engine can apply configured rules to each relevant transaction, while reliable integrations ensure that product, customer, location, and billing information reaches it correctly.
That distinction matters. Automation cannot fix an incorrectly classified product or an outdated customer address by itself. The strongest approach combines accurate data, approved tax rules, integration testing, exception monitoring, and a clear process for reviewing changes.
CereTax's guide to automating subscription billing and sales tax for SaaS explores how recurring billing events, changing product offerings, and customer locations affect sales tax operations.
Subscription businesses cannot treat sales tax as a decision made once when a customer signs up. Renewals, upgrades, downgrades, usage charges, credits, bundles, and location changes can all affect the information used to calculate tax.
The more frequently a business bills customers, the more opportunities it has to repeat an error. Accurate product classifications, reliable customer data, and tax calculations integrated into the billing workflow help prevent those errors from becoming recurring compliance problems.
Ready to make recurring billing more reliable? Talk to CereTax about automating sales tax calculations across subscription invoices, usage charges, and billing adjustments while maintaining the transaction detail your finance and tax teams need.
“We’ll fix sales tax next quarter.”
It sounds reasonable when the team is busy with an ERP migration, a product launch, a new market, or month-end close. Sales are moving, invoices are going out, and the tax process seems good enough for now.
But sales tax has a way of making “later” expensive.
A missed registration can leave a business with unaddressed filing obligations. An incorrect product classification can affect thousands of invoices. An outdated exemption record can create exposure across multiple reporting periods. And once someone identifies the problem, the business still has to determine what happened, calculate what is owed, correct its records, and establish a reliable process going forward.
The real cost is not limited to the tax bill. It includes penalties and interest where applicable, potential customer credits, audit preparation, employee time, and the disruption of fixing historical errors while keeping current operations running.
The question is not simply whether your business has a sales tax problem. It is how much that problem could cost if you leave it unresolved.
The financial impact depends on the state, the type of error, the periods involved, and whether the business collected tax from customers. However, several costs commonly deserve attention.
These costs often overlap. A single underlying error can affect the amount of tax reported, the documentation available to support the return, and the time required to correct the problem.
That is why early intervention matters.
Sales tax deadlines are not simply administrative reminders. Missing them can have direct financial consequences, and the rules differ by state.
For example, the Texas Comptroller states that a $50 penalty applies to each late sales tax report. If tax is paid 1 to 30 days after the due date, a 5% penalty applies; payments more than 30 days late are subject to a 10% penalty. Texas also charges interest on past-due tax beginning 61 days after the due date.
California has its own rules. Under California Revenue and Taxation Code Section 6591, late payment can trigger a 10% penalty plus interest, subject to the statute's provisions and applicable exceptions.
These are state-specific examples, not a nationwide penalty formula. The important point is that a business should not assume that a delayed correction will be cost-free.
The longer an error remains unresolved, the more reporting periods may require review. If the problem affects multiple states or recurring transactions, the total exposure can become harder to estimate and budget for.
Consider a company that expands into several states but does not review whether its activities create new sales tax registration obligations. Months later, the tax team discovers the gap.
The business now needs to establish when obligations began, determine which transactions were taxable, calculate potential liabilities, assess registration and filing requirements, and decide how to address prior periods. If transaction data is spread across billing, ERP, and ecommerce systems, the investigation can take considerable time.
The same pattern appears when a product code is wrong or an exemption is applied incorrectly. A problem that takes minutes to correct in a current transaction may require a much larger effort when it has affected thousands of historical invoices.
Remediation may involve:
The work is not just about correcting the tax amount. It is about proving what happened and ensuring the same issue does not continue into future periods.
CereTax's sales tax automation checklist offers a useful starting point for identifying weaknesses in tax processes, data, exemption handling, and reporting.
Discovering a compliance gap internally gives a business an opportunity to investigate and evaluate its options before responding to an external inquiry. An audit can change that timeline.
When a tax authority requests records, the business may need to produce invoices, exemption certificates, transaction details, returns, and supporting documentation. If those records are incomplete or difficult to reconcile, responding can consume substantial time across Tax, Finance, IT, and external advisers.
California's Sales and Use Tax Records guidance generally requires businesses to retain required records for at least four years, with additional retention considerations for ongoing audits and disputes. Recordkeeping requirements vary by jurisdiction, so businesses should confirm the rules that apply to them.
An audit can also reveal patterns rather than isolated mistakes. Unsupported exemptions, inconsistent taxable-sales figures, or gaps between collected and remitted tax may lead to further questions about the reliability of the business's process.
That does not mean every discrepancy leads to an assessment or that every audit produces penalties. It does mean that incomplete records and unresolved errors can make an examination more difficult to manage.
For practical preparation guidance, see CereTax's Year-End Audit Readiness: Your Sales and Use Tax Compliance Checklist.
In some circumstances, yes. But the right response depends on the issue and the jurisdiction.
For businesses that discover potential obligations in states where they have not been filing, a voluntary disclosure agreement may be worth evaluating. The Multistate Tax Commission's Voluntary Disclosure Program provides a coordinated process for eligible taxpayers to address certain multistate tax liabilities.
Depending on the state and agreement, a voluntary disclosure may limit the periods covered and provide penalty relief. However, eligibility rules apply, and interest may still be due. Prior contact with a state about the relevant tax obligation can affect eligibility. Collected but unremitted sales tax can also receive different treatment.
Voluntary disclosure is not a blanket solution for every historical error. Businesses should assess the facts and obtain appropriate tax advice before approaching a state, because the order and timing of that contact can matter.
Whatever the route, the goal is to address the historical exposure while correcting the underlying process. Paying an outstanding balance without fixing the cause leaves the business vulnerable to repeating the same problem.
The most effective approach combines regular reviews with clear ownership and reliable systems. Start by identifying the areas where an unresolved issue could have the greatest impact.
Even a sales tax holiday deserves attention before the event begins. Eligibility often depends on state-specific dates, qualifying product categories, price limits, and other conditions. Waiting until after the promotion to check product classifications or configure the tax treatment can create avoidable corrections and customer service issues.
Sales tax automation can help by applying configured rules consistently, maintaining transaction-level detail, and reducing manual work. But the technology must be supported by accurate data, sound configuration, and a process for investigating exceptions. Automation is most valuable when it helps prevent problems, not merely process them faster.
Delayed compliance can turn a small oversight into a much larger financial and operational burden. Back taxes may be only the beginning. Penalties, interest, customer adjustments, audit preparation, and remediation can all compete for budget and employee attention.
The better approach is to identify exposure early, understand the applicable state requirements, correct historical issues carefully, and strengthen the controls that prevent them from recurring.
If your team is spending more time explaining past sales tax discrepancies than preventing new ones, it may be time to reassess the process.
Ready to take control of sales tax compliance? Talk to CereTax about building a more reliable, scalable approach to sales tax calculation, compliance, and audit readiness.
A customer checks out, an invoice is generated, and the sales tax engine returns a result in milliseconds. The transaction looks routine. But what if the customer’s address points to the wrong jurisdiction, the product carries an outdated tax code, or an exemption certificate is no longer valid?
The calculation can be technically correct and still produce the wrong tax.
This is an important distinction for businesses managing sales tax across multiple states, local jurisdictions, sales channels, and product lines. Tax engines apply tax rules to the transaction data they receive. If that data is incomplete, inaccurate, or incorrectly mapped, automation can produce an incorrect result just as efficiently as a correct one.
The consequences go beyond an invoice. Incorrect tax can lead to undercollection, overcollection, filing discrepancies, customer disputes, and additional work during an audit.
So, where should tax teams look when the engine appears to be working but the numbers do not add up?
Most input-related errors fall into a handful of categories. Each can affect the tax outcome differently, depending on the transaction and the applicable state and local rules.
These problems are easy to overlook because the transaction can still process successfully. A successful response from the tax engine confirms that a calculation was returned. It does not, by itself, confirm that every input was correct.
Sales tax rates and jurisdictional rules can vary across state, county, city, and special taxing districts. In destination-based transactions, the delivery location can be particularly important. A ZIP code alone may not identify the correct jurisdiction, especially in areas where boundaries overlap.
Consider a business shipping products to customers across several counties. If its billing system supplies an outdated or incomplete delivery address, the tax engine may apply a valid rate for the wrong location. The calculation can look perfectly reasonable while the amount collected is incorrect.
The problem can also surface when systems treat billing and shipping addresses as interchangeable. A customer's headquarters may be in one jurisdiction while an order is delivered somewhere else. The correct sourcing treatment depends on the applicable rules and transaction facts, not simply on which address is easiest to retrieve.
Illinois offers a concrete example of why location data deserves attention. Effective January 1, 2026, Illinois introduced a 15% tax rate for certain destination-based sales when taxpayers fail to provide sufficient information to determine the proper location. The rule applies to specified Illinois transactions, not to every address error nationwide. See the Illinois Department of Revenue's guidance on destination-based sales tax changes.
For tax teams, the takeaway is straightforward: validate addresses before calculation, preserve the transaction's relevant location details, and investigate records that cannot be mapped confidently.
A tax engine cannot reliably determine the tax treatment of a product if the product is incorrectly classified in the first place.
Imagine a company introducing a new subscription that combines software access, support, and implementation services. If the ERP assigns the entire offering a generic software code, the engine may not receive enough detail to apply the appropriate treatment to each component. Depending on the jurisdiction and how the offering is structured, the components may not all receive the same tax treatment.
The same issue arises when product catalogs change but tax classifications do not. A new SKU might inherit an old code, a bundle might be treated as a single product when its components require separate consideration, or a service might be classified based on its name rather than what the customer actually receives.
This is especially relevant during a sales tax holiday. Eligibility may depend on the product category, price threshold, timing, and state-specific requirements. If an item is mapped to the wrong category, the business could incorrectly exempt an eligible purchase or collect tax on an item that qualifies for the holiday.
The Streamlined Sales Tax Taxability Matrix is a useful reference for reviewing adopted product definitions, sales tax holiday definitions, and state-specific treatment. It should be used alongside the relevant state's current guidance and applicable law.
The operational fix is to make tax classification part of product governance. When a new product launches or an existing offering changes, Product, Finance, and Tax should review the description, functionality, pricing structure, and relevant components before the item begins generating transactions.
Absolutely. Customer exemption data is another common source of inaccurate calculations.
A customer may qualify for an exemption, but that does not mean every purchase they make is automatically exempt in every jurisdiction. The exemption may depend on the customer's status, the nature of the purchase, how the item will be used, and the documentation required by the state.
Problems emerge when an exemption certificate is missing, incomplete, associated with the wrong customer record, or no longer reflects the customer's circumstances. The reverse can also happen: a customer who is not entitled to an exemption may remain marked as exempt in the billing system.
Minnesota's Department of Revenue guidance on nontaxable sales explains that sellers may need a completed exemption certificate to support certain nontaxable transactions. Requirements vary by state, so a process that works for one jurisdiction should not automatically be applied everywhere.
Tax teams should review certificate documentation, customer entity details, applicable jurisdictions, and the rules governing each exemption. They should also make sure changes to customer status flow correctly into the system used for tax calculation.
An exemption field marked “active” is only useful when the underlying eligibility and supporting records justify that status.
Sometimes the address and product classification are correct in their respective systems, but the information does not reach the tax engine as intended.
This is a transaction-mapping problem. An integration might pull the billing address instead of the ship-to address, omit an exemption indicator, map a product to a generic category, or fail to transmit a relevant line-item detail. The tax engine then works with an incomplete or distorted version of the transaction.
This risk grows when businesses introduce new sales channels, migrate ERPs, change billing systems, or modify how products and services are bundled. A field that was mapped correctly for the original workflow may no longer represent the transaction accurately after a process change.
CereTax's guide to automating sales tax inside NetSuite explains how transaction-level tax determination depends on information such as seller and ship-to addresses, items or services, customer entities, and exemption data.
That is why integration testing should go beyond confirming that a tax amount appears on an invoice. Test whether the correct fields are being passed, whether line items retain their intended classifications, and whether changes to relevant transaction details trigger the expected recalculation.
A more reliable process starts before the tax engine calculates anything. Tax teams need clear ownership of the data that determines tax treatment, along with controls that identify errors before they spread across thousands of transactions.
These controls work best when ownership is clear. Product teams should communicate changes to offerings. Finance and billing teams should maintain accurate transaction and customer records. Tax teams should define classifications, validate jurisdiction-specific treatment, and establish review requirements. IT and implementation teams should ensure that the right data reaches the engine.
Automation supports this process by applying configured rules consistently and reducing manual intervention. It does not eliminate the need to govern the information those rules depend on.
For businesses reviewing their current setup, CereTax's sales tax automation solution provides more detail on how address validation, product taxability, sourcing, and exemption handling fit into the broader calculation workflow.
When a tax amount looks wrong, the instinct may be to question the rate table or the calculation logic. Sometimes that is the right place to investigate. But it is not the only place.
Start by tracing the transaction from its source. Was the correct address supplied? Was the product classified appropriately? Was the exemption valid? Did the ERP transmit the right fields? Did the engine apply the expected rules to those inputs?
That review helps distinguish a calculation-rule issue from an upstream data problem. It also makes recurring errors easier to prevent instead of correcting them one invoice at a time.
The bottom line: Accurate sales tax depends on more than a capable engine. It depends on accurate inputs, reliable integrations, clear ownership, and a process for reviewing changes before they affect live transactions.
If your team is seeing recurring discrepancies across invoices, jurisdictions, or filing periods, it may be time to examine the entire calculation workflow rather than just the final tax amount.
Ready to pressure-test your sales tax setup? Talk to CereTax about building a more reliable, data-driven approach to sales tax calculation.
A customer clicks Buy Now. Your system has moments to determine whether the product is taxable, which jurisdiction applies, whether the customer qualifies for an exemption, and how much sales tax to collect.
Now multiply that transaction across thousands of customers, multiple sales channels, different product categories, and jurisdictions with different rules.
That is where sales tax complexity becomes a data problem.
The United States has more than 12,000 state and local sales tax jurisdictions, a figure commonly cited in the sales tax industry. Each transaction needs the right combination of location data, taxability rules, applicable rates, and customer-specific information. A ZIP code that points to the wrong jurisdiction, a product mapped to the wrong tax category, or an exemption that was never updated can throw off the result.
And these problems rarely stay isolated. An incorrect product code can affect thousands of invoices. An address issue can misassign tax across an entire customer base. A missing transaction attribute can make an otherwise correct tax rule impossible to apply.
The answer is not simply to maintain more rate tables. It is to build a sales tax process that treats data as a core compliance control.
Because a rate is only one part of the calculation.
A reliable sales tax determination needs to establish at least four things: where the transaction is sourced, what is being sold, whether the sale is taxable, and which rules apply to the customer and transaction.
Consider the information a tax engine may need:
These elements need to work together. A correct rate applied to the wrong jurisdiction is still wrong. A correct product classification does not help if the system receives the wrong customer exemption status.
CereTax explains this transaction-level approach in its guide to sales and purchase transactions, including the role of addresses, products, quantities, discounts, shipping costs, and other transaction attributes.
Absolutely. Local sales taxes can vary within the same state, county, or postal code area. That makes address quality more than a customer experience issue.
A ZIP code is useful for mail delivery. It is not a guarantee that a transaction has been assigned to the correct tax jurisdiction.
For businesses shipping products, the relevant destination may determine the applicable tax treatment under state sourcing rules. Other transaction types can follow different sourcing rules, so the correct location must be identified based on the transaction rather than a single universal assumption.
Illinois offers a particularly important example of why location data matters. Beginning January 1, 2026, the Illinois Department of Revenue states that certain destination-based sales may be taxed at a 15% undetermined-location rate when a taxpayer fails to provide the information, schedules, or supporting documents needed to determine where those sales occurred. The department also notes that this rate may be used during audits for periods under audit, including periods before January 2026.
That makes location data a direct compliance concern, not simply a technical detail.
See the Illinois Department of Revenue's guidance on keeping complete and accurate records.
For businesses processing high transaction volumes, address validation and accurate jurisdiction mapping help prevent one bad input from becoming a recurring billing problem.
Your product catalog may contain hundreds or thousands of SKUs. Each one needs to be mapped to a tax category that reflects what the business actually sells.
That becomes more complicated when products include digital components, services, bundled offerings, installation, support, or recurring subscriptions. A marketing name does not automatically establish a product's tax treatment, and the same category can receive different treatment across states.
Consider a bundle containing software, implementation, and ongoing support. If the billing system sends the entire charge as one generic product code, the tax engine may not have enough information to apply the intended tax treatment to the individual components.
The same challenge appears in retail. Two products that look similar in a product catalog may have different tax treatment because of their characteristics, intended use, or applicable state rules.
The Streamlined Sales Tax Taxability Matrix illustrates the importance of product-level detail. Participating states document taxability treatment, product definitions, statutory references, and other relevant information. The matrix also addresses sales tax holidays, demonstrating that product classification and special tax rules need to work together.
The practical takeaway is straightforward: your tax engine cannot compensate for product information that is missing, outdated, or incorrectly mapped.
Product data should be reviewed when offerings change, not only when the tax team discovers a problem.
A transaction can have accurate address and product information and still be taxed incorrectly if other attributes are missing.
Exemptions are a good example. A customer may qualify for a particular exemption, but the business still needs the appropriate supporting documentation, a valid exemption status, and rules for applying that status to eligible transactions. If exemption information sits in a spreadsheet instead of the customer or transaction workflow, the billing system may not apply it consistently.
Sourcing creates another challenge. A shipped ecommerce order, an in-store sale, and a transaction involving a different fulfillment location may require different treatment under the applicable rules. Systems need enough information to distinguish those transactions.
Then there are sales tax holidays.
A qualifying product may be exempt during a specified period, subject to state rules, product definitions, and price limits. A system that cannot identify the product, transaction date, selling location, and applicable holiday conditions may calculate tax incorrectly even if its standard rates are current.
The Streamlined Sales Tax resource on sales tax holidays provides state-reported information and directs businesses to state authorities for confirmation.
These scenarios show why sales tax data cannot be managed as disconnected fields. Customer, product, exemption, location, date, and transaction information must come together at the moment of calculation.
Start by examining the inputs that reach your sales tax engine. The goal is to identify errors before they spread across transactions.
The most effective approach connects these controls to the systems your business already uses. Your ecommerce platform, billing system, ERP, customer records, and tax engine should not operate as separate versions of the truth.
This is where sales tax automation with CereTax can help. CereTax validates transaction inputs, applies jurisdiction-specific rates and product taxability rules, incorporates exemption logic, and returns transaction-level tax results. Its approach also supports detailed calculation records, giving teams visibility into how a result was reached.
Automation does not eliminate the need for sound data governance or tax judgment. It helps apply established decisions consistently at scale.
As your business adds products, customers, states, and sales channels, the number of data points involved in each tax calculation grows with it.
The biggest risk may not be a missing rate. It may be an unvalidated address, an outdated product code, an expired exemption, or a billing system that does not pass the information the tax engine needs.
That is why sales tax accuracy should be treated as a data-quality discipline as much as a tax function.
Start with the transaction. Verify the location. Confirm the product classification. Validate the exemption. Apply the correct sourcing and tax rules. Then preserve enough detail to explain the result later.
One checkout may look simple to your customer. Behind it, accurate sales tax depends on getting every important data point right.
Ready to make your sales tax data work harder? If your team is relying on manual address checks, scattered exemption records, or product mappings that are difficult to maintain, it may be time to rethink the process.
👉🏻 Book a Strategy Call with CereTax to explore how precise jurisdiction sourcing, product-level taxability, exemption logic, and real-time sales tax automation can help your business calculate tax with greater consistency and confidence.
A new product is ready for market. Pricing has been approved, Finance has configured billing, Product Marketing has finalized the name, and Engineering has added the offering to the catalog.
Then Tax gets involved.
Someone wants to know whether the new product is taxable, and the team starts piecing together answers from product specifications, contracts, billing records and conversations with other departments.
What looked like a simple question has become an investigation.
Sales tax treatment depends on more than the name assigned to a product. The analysis can involve what the customer receives, how the offering is delivered, where it is used, whether it includes other products or services, and the rules of the relevant state and locality.
For example, New York generally treats prewritten computer software as taxable, including certain software accessed online. Separately stated, reasonable charges for qualifying services, such as custom programming or training, may receive different treatment under applicable rules. The outcome depends on the actual offering and the facts of the transaction.
The same complexity can surface during a sales tax holiday. A product that qualifies for an exemption in one state may not qualify in another, and eligibility can depend on the item's definition, price and other conditions. The Streamlined Sales Tax Taxability Matrix provides state-specific information on adopted product definitions, tax treatment and sales tax holiday rules.
In each case, the challenge begins before the tax calculation.
When product details, billing decisions and tax rules are handled in isolation, the business can end up calculating tax on incomplete or incorrectly classified information.
Each department has a legitimate responsibility, but those responsibilities do not always connect.
The issue is not that one department is failing to do its job. It is that each team sees a different part of the transaction.
Product understands the offering. Finance knows how it is billed. Sales knows what the customer agreed to buy. Engineering determines how those details flow through business systems.
Tax needs the relevant information from all of them to make a defensible determination.
Without a defined process for sharing that information, a product can move from development to invoicing without a documented decision about its sales tax treatment.
The risk grows when the same classification is reused across thousands of transactions. A mistake in a product catalog can become a recurring reporting problem rather than an isolated error.
A product label is a starting point, not a tax classification.
Terms such as “Digital Platform,” “Managed Services,” “Subscription,” “Implementation,” “Support” and “Data Services” describe how a business markets or organizes its offerings. They do not necessarily explain how the underlying transaction should be treated for sales tax purposes.
Tax needs a clearer picture of what the customer is purchasing.
That typically includes:
These details may sit in different systems or belong to different teams. A product requirements document might explain functionality, while a contract describes the customer's rights and an ERP record contains only a generic SKU and price.
Taxability decisions become harder to maintain when those records do not tell a consistent story.
The Streamlined Sales Tax Taxability Matrix can help teams research adopted definitions and state treatment for products covered by the agreement. It should be used alongside the relevant state's statutes, regulations and guidance, rather than as a substitute for a complete taxability analysis.
Bundled offerings make the information gap particularly visible.
Consider a monthly subscription that includes:
The billing system may treat the entire offering as one SKU with one monthly charge. Tax may need to evaluate the components, how they are supplied, and whether the applicable jurisdiction allows different treatment for any of them.
New York illustrates why the details matter. In Advisory Opinion TSB-A-24(8)S, the state determined that charges for access to a web-based software portal were taxable, while reasonable, separately stated charges for certain optional custom programming, data entry and training services were not taxable under the facts presented.
That conclusion does not mean that separating a charge automatically makes a service exempt. The nature of the service, the reasonableness of the charge and the applicable rules all matter.
Other bundles may receive different treatment. If taxable software and other offerings are sold for one combined price, the full charge may be taxable in certain circumstances. The treatment must be evaluated against the relevant jurisdiction's rules and the actual transaction.
For Tax, the question is therefore more specific than “Is this product taxable?”
It may be: Which components are being sold, how are they priced, and how should the transaction be treated under the applicable rules?
This distinction matters for SaaS providers, communications companies and enterprise businesses that package software, services and ongoing support into a single commercial offering.
A taxability determination reflects the facts available when the decision is made. If those facts change, the original analysis may need another look.
Consider a few common changes:
None of these changes automatically makes a product taxable or exempt. They do, however, give the business a reason to check whether its existing classification still fits.
The same principle applies when a product is renamed or repositioned. A new marketing name does not necessarily change the tax treatment if the underlying offering remains the same. Conversely, retaining the same name does not guarantee that its tax treatment remains appropriate after a meaningful change in functionality or billing.
A useful process connects product change management to tax review. When a change could affect the facts behind an existing determination, the relevant teams should reassess the treatment before the new configuration is used for customer transactions.
That is easier to manage when the business knows which changes require review, who makes the determination and where the approved result is recorded.
The gap often becomes visible when product information reaches the ERP or billing system.
Imagine a new SKU called “Enterprise Platform Bundle.” Finance knows its price and revenue treatment. Product understands the features included. Sales knows what was promised in the contract.
But the tax calculation receives only the generic SKU, a transaction amount and limited information about the underlying components.
The system may not have enough information to apply the intended tax treatment consistently.
This is where product data quality becomes a tax compliance concern.
A tax engine applies configured tax rules to the transaction information it receives. It cannot reliably distinguish between materially different offerings if the source data does not preserve the relevant differences or the required classifications have not been established.
That does not mean every error originates in the ERP or tax engine. Incorrect tax rules, incomplete jurisdictional data, sourcing issues and exemption handling can also cause problems. The point is that the entire process depends on accurate information moving between systems.
Reliable sales tax calculations require both sound tax logic and transaction data that represents what the business actually sold.
The goal is not to bring Tax into every product discussion. It is to identify the changes that could affect tax treatment and make sure the right information reaches the people responsible for the decision.
A practical workflow connects common business events to a defined review.
The review should produce more than an informal email or a note in a spreadsheet. The approved determination needs enough context for another team member to understand what was assessed and how the result should be implemented.
At a minimum, the record should capture:
Once approved, the classification and any required transaction attributes must flow into the relevant systems. Changes to the product catalog or billing structure should also have a defined route for notifying Tax when the existing determination may no longer apply.
This creates a repeatable process without requiring Tax to participate in every routine business decision.
Most importantly, it gives the organization a record of why a taxability decision was made, rather than leaving future teams to reconstruct it after an issue surfaces.
Tax should own the tax determination. The wider business should own the quality and timely delivery of the information that supports it.
That division makes accountability clearer:
Product provides accurate information about functionality, packaging and customer-facing features.
Finance documents pricing, billing structures, discounts and how charges appear on invoices.
Sales and Legal provide relevant contract terms, negotiated arrangements and customer-specific commitments.
Engineering ensures approved classifications and necessary transaction attributes can flow through product catalogs, billing platforms, ERP systems and tax integrations.
Tax evaluates the facts, determines the applicable treatment, documents the rationale and identifies the conditions that require reassessment.
This ownership model connects the stages of the process:
Product information → Tax determination → Approved classification → System configuration → Transaction calculation → Filing and reconciliation
Each stage has a distinct responsibility. A breakdown at any point can affect the final result, so the process needs clear handoffs and a way to identify discrepancies.
The model also makes reviews more efficient. Instead of repeatedly asking Tax to interpret incomplete product descriptions, teams can provide a consistent set of details before a determination is requested.
Automation can help apply approved tax decisions consistently across high transaction volumes, but it works best when the underlying product and transaction data is reliable.
A well-designed process gives the tax engine the information it needs to evaluate transactions under the configured rules. Depending on the business and its systems, that can include product classifications, transaction amounts, customer and location details, exemption information, and attributes that distinguish one type of offering from another.
Automation can then help businesses apply tax rules across transactions, reduce manual intervention and support more consistent processing. It does not remove the need to establish correct classifications, maintain accurate data or review changes that may affect tax treatment.
For growing businesses, this distinction matters. Adding more products, entering more states and introducing more billing variations can increase the number of decisions that must be maintained. A documented workflow, supported by appropriate systems, helps those decisions remain consistent as the business scales.
The objective is not to automate an incomplete process. It is to create a dependable process that automation can execute.
Product taxability is rarely a decision that can be made from a product name alone. It depends on the characteristics of the offering, the way it is sold, the transaction details and the rules that apply.
When Product, Finance, Sales, Engineering and Tax work from different versions of that information, the business creates avoidable uncertainty. The consequences may appear in incorrect calculations, inconsistent invoices, difficult reconciliations or returns that require additional review.
A more reliable approach starts with clear ownership, accurate product data and a defined process for reviewing meaningful changes. Tax makes the determination, the business supplies the necessary facts, and the approved treatment reaches the systems that calculate and report tax.
That is how organizations can reduce the distance between what they intend to sell and how the transaction is ultimately taxed.
Because the best time to resolve a taxability question is before the product reaches the invoice, not after the transactions have already accumulated.
Is your product data ready for accurate sales tax calculations? If new SKUs, bundled offerings and billing changes are creating uncertainty for your Tax team, it may be time to review how product data flows into your tax engine.
👉🏻 Book a Strategy Call with CereTax to explore how your product classifications, ERP data and tax rules work together, and where gaps in that process could lead to inconsistent tax treatment.
Your revenue is up. Great.
Then someone on the finance team asks the less exciting question: Did our sales tax exposure grow with it?
That question is harder than it sounds.
Sales tax nexus is no longer just a matter of watching whether you crossed a $100,000 sales threshold. A new remote employee, inventory sitting in a fulfillment center, a contractor visiting a customer site, or a trade show appearance can change your sales tax obligations depending on the state and the activity involved. Washington, for example, identifies employees, inventory, representatives, installations, services, and certain trade show activities among its physical presence nexus triggers.
Even a sales tax holiday can make this more complicated. A holiday itself does not automatically create nexus, but a surge in sales during a holiday can matter when a state's economic nexus threshold is calculated using gross or retail sales. The Streamlined Sales Tax guidance makes clear that states use different definitions for threshold calculations, with some counting exempt or otherwise nontaxable sales.
The bigger issue is that growth rarely happens in one neat line.
Your revenue grows. Your people spread out. Your fulfillment model changes. Your sales team attends more events. Customers ask for installation or training. A related company starts operating in a new state.
Suddenly, your nexus profile looks very different from the one you reviewed six months ago.
Here are seven hidden triggers worth checking.
Inventory is one of the easiest nexus triggers to overlook because the sales team may never see it.
Your company might not have opened a warehouse. Instead, you could be using a third-party logistics provider, marketplace fulfillment program, or another partner that stores your products in multiple states.
That physical inventory can matter for sales tax nexus.
Washington, for example, identifies having a stock of goods in the state, including inventory held by a marketplace facilitator or third party, as a physical presence nexus activity.
The same issue can arise when your fulfillment strategy changes as revenue grows. A business that once shipped every order from its own facility may move to distributed fulfillment without realizing that its inventory footprint has expanded.
Check:
Do not assume that because a third party owns the warehouse, the inventory is irrelevant to your sales tax obligations.
Remote work created a sales tax nexus problem that many companies did not have on their radar before.
An employee working from a home office can create physical presence nexus in a state, depending on the state's rules and the employee's activities.
And it is not necessarily limited to salespeople.
Washington explicitly lists having an employee working in the state as a physical presence nexus activity.
That means a finance team tracking sales tax nexus should not rely solely on the company's office locations.
Check:
The important point is not simply where someone lives. It is what the person is doing in the state and how that state's nexus rules treat the activity.
Contractors can be just as important as employees.
As businesses scale, they often outsource installation, implementation, repair, training, delivery, sales support, or other customer-facing work.
That can create a physical connection to a state even when the contractor is not technically on your payroll.
Washington, for example, identifies activities performed by agents or third-party representatives, including installation, repair, maintenance, services, and market solicitation, as potential physical presence nexus activities.
Texas guidance similarly identifies employees, independent representatives, contractors, agents, services, installation, training, technical assistance, and other in-state activities when evaluating nexus.
So when procurement adds a new contractor, tax should be asking one more question: Where will they perform the work?
This is where product growth can quietly become nexus growth.
Imagine you sell equipment nationwide. The sale itself happens online, and your economic nexus dashboard shows that a particular state is still below its threshold.
Then your customer asks you to send someone to install the equipment.
Or conduct onsite training.
Or repair it.
Or provide technical support at the customer's location.
That activity may change the nexus analysis.
Washington specifically lists installing or assembling goods, constructing or repairing property, and providing services such as product training as physical presence activities.
California has also published guidance involving an out-of-state software company whose employee conducted a two-day seminar at a customer's location. The California Department of Tax and Fee Administration concluded that the activity constituted a physical presence related to the sale.
The takeaway is simple: do not review nexus based on sales alone when your business model includes people performing work in customer locations.
Trade shows can look like marketing expenses on the P&L.
For sales tax purposes, they may deserve a closer look.
States do not all treat trade shows and conventions the same way. Some provide specific exceptions, while others treat certain attendance, exhibiting, solicitation, or sales activities as nexus-creating.
Washington, for example, provides a specific exception for qualifying trade conventions under certain conditions, but that exception does not apply universally. Selling at a qualifying event or participating in a public trade show can change the analysis.
California also has specific rules and exceptions for convention and trade show activity.
So before your marketing team books the next 12 events, ask:
One state's exception should never become your national assumption.
Your company's legal entity chart may not look like a sales tax document.
It should still be part of your nexus review.
Affiliate nexus can arise when an out-of-state business has qualifying relationships with entities operating in a state. The exact rules vary significantly, and some states have changed or repealed particular affiliate nexus provisions as economic nexus rules have expanded.
That makes corporate restructuring particularly important.
A new subsidiary.
An acquisition.
A sister company sharing facilities.
A related entity providing services.
A brand operating through an affiliated company.
None of these automatically means you have sales tax nexus everywhere the related company operates.
But they are signals that your tax team should investigate.
When your corporate structure changes, update your nexus analysis with it.
Economic nexus is the trigger most businesses know to monitor.
It is also one of the easiest to calculate incorrectly.
The problem is that there is no single universal definition of what counts toward an economic nexus threshold.
Some states use gross sales or gross receipts. Others use retail sales or taxable sales. Some count exempt transactions. Some use transaction counts. Others have different measurement periods or rules.
The Streamlined Sales Tax guidance specifically distinguishes between thresholds based on gross sales, retail sales, and taxable sales. For a threshold based on gross sales, for example, exempt and nontaxable transactions may still count.
Washington provides a useful example. Its remote seller threshold is based on more than $100,000 in combined gross receipts sourced or attributed to the state, and the calculation includes exempt sales.
So your nexus dashboard should not simply show:
State sales = $98,000 → No nexus
It should show:
Which sales count under this state's rule? What measurement period applies? What other nexus triggers exist?
That is a much more useful question.
Revenue growth should trigger more than a sales forecast review.
It should trigger a nexus review.
The goal is not to assume that every business change creates nexus.
The goal is to stop assuming that it does not.
Revenue growth is good news.
But if your tax team is monitoring only sales by state, it may be looking at just one piece of the sales tax puzzle.
A stronger nexus process connects revenue data with the operational events that can change your tax footprint: employee locations, inventory movements, contractors, customer-site activity, trade shows, affiliates, marketplace relationships, and changes in how you sell and deliver products or services.
That is where sales tax automation becomes useful.
CereTax can help tax teams monitor nexus across the business, connect transaction data with jurisdiction rules, and maintain the documentation needed to support sales tax compliance as the company grows.
Because the question is not simply, "Where did we sell more?"
It is: "Where did our business change?"
Most businesses think of a sales tax audit as starting when the audit notice arrives.
The research can start earlier.
The Texas Comptroller's Auditing Fundamentals Manual describes pre-audit research as the phase in which an auditor becomes familiar with the taxpayer's account and business before contacting the taxpayer. The auditor may review the audit file, reporting history, prior audits, account information, business activities, and other available information.
Pennsylvania's Sales and Use Tax Audit Manual similarly describes an initial research process that includes reviewing filing information, sales and sales tax reported, taxable-to-gross sales ratios, use tax reported, credits, fluctuations, and late returns.
That means your filed sales tax returns are already telling a story before anyone asks you to explain them.
The question is whether that story is consistent.
If your sales tax returns reconcile to your financial records, your exemption documentation supports exempt sales, and your use tax reporting reflects your actual purchasing activity, you have a stronger foundation when an audit begins.
Audit selection is not necessarily random.
State audit programs can use different selection methods, and those methods vary by jurisdiction. Texas, for example, says audits may be generated through audit selection programs, special division requests, prior audit results, leads from other audits, and computerized random selection.
California's current audit-selection reporting also describes a continuous selection process designed to identify accounts for audit and says the agency uses external agency data together with its own data to identify potential tax deficiencies.
The practical takeaway is simple: audit selection can be influenced by patterns in the information available to a state.
Those patterns may include:
Not every unusual number is a red flag. A legitimate business change, seasonal pattern, acquisition, new product line, or change in customer mix can produce significant fluctuations.
The important part is being able to explain the numbers and support them with records.
The exact process varies by state, but the Texas and Pennsylvania manuals provide useful examples of what can happen before the first substantive audit examination.
Texas says auditors review the audit file, prior audit results, taxpayer reporting history, account background, business information, and potential industry problem areas. The auditor also establishes preliminary objectives for the audit.
Pennsylvania's audit manual identifies several items for initial research, including sales and tax reported, taxable-to-gross sales ratios, use tax, credits, fluctuations, and late returns.
In practical terms, an auditor may be looking for patterns such as:
The important distinction is that a ratio or fluctuation does not automatically mean there is an error.
It can simply tell the auditor where to look more closely.
A pre-audit questionnaire is not a universal process across every state, but Texas provides a detailed example of how one can be used.
The Texas Comptroller says its Audit Questionnaire and Notice of Routine Audit Letter are sent when an audit is generated or assigned. The questionnaire collects information about authorized representatives, business activities, computer systems, records, and the taxpayer's operations.
The questionnaire can help the auditor understand:
The Texas manual also states that the completed questionnaire becomes part of the audit package and is used during pre-audit research and the audit examination.
That makes accuracy important.
Your business description should match what the company actually does. Your description of products, customers, locations, systems, and records should be precise rather than overly broad.
For example, saying that a company simply sells "software" may not give an auditor enough information to understand the actual products or services involved. A more precise description of the business model gives everyone a clearer starting point.
Not necessarily.
The questionnaire is one source of information used to plan the audit. Texas guidance indicates that the audit reason, questionnaire, taxpayer history, and other information contribute to the audit planning process.
The auditor may also request additional records as the examination progresses.
So the best approach is straightforward: answer accurately, completely, and consistently with your underlying records.
One of the clearest themes in state audit guidance is reconciliation.
An auditor needs to understand how the amounts reported on sales tax returns were calculated and how those amounts connect to the company's underlying records.
The Texas Comptroller's audit guidance identifies records that may include:
The exact records requested will vary by business and state.
For a finance team, the goal should be to establish a clear chain:
Transaction data → accounting records → sales tax calculation → sales tax return
If those pieces do not reconcile, an auditor is likely to ask why.
You do not need to wait for an audit notice to test the areas most likely to create questions.
Start with three practical checks.
Review the relationship between your gross sales and taxable sales across filing periods.
If the relationship changes significantly, document why.
Possible explanations include:
The goal is not to force a consistent ratio. It is to make sure significant changes are explainable and supported.
An exemption is only as defensible as the documentation supporting it.
Review whether exemption certificates are:
This is particularly important when your business has a large volume of exempt sales.
Sales tax compliance is not limited to tax collected from customers.
Use tax can arise when a business purchases taxable goods or services without paying the applicable sales tax to the vendor.
Review purchases from out-of-state vendors and other transactions where use tax may apply. Compare your purchasing activity with the use tax reported on your returns.
A recurring pattern of significant taxable purchases with little or no use tax reporting deserves investigation before an auditor raises the question.
Pre-audit research eventually leads to taxpayer contact and the entrance conference.
Texas describes the sequence as audit selection, assignment, questionnaire and audit notice, pre-audit research, taxpayer contact, and then the entrance conference.
At that point, the auditor may ask questions about:
The auditor may also request additional records.
The Texas manual specifically notes that the initial records request is preliminary and that additional records may be requested once fieldwork begins.
That is why preparing only the documents listed in an initial request is not enough. Your broader sales tax records should be organized and internally consistent before the audit begins.
The pre-audit research phase is controlled by the state once an audit has been selected.
What you can control is the quality of your sales tax records before that happens.
A practical pre-audit review should include:
Review your filing history.
Look for unusual fluctuations, late filings, amended returns, and periods that do not reconcile.
Test your sales tax calculations.
Confirm that taxable sales, exempt sales, tax collected, credits, and adjustments tie back to your source data.
Review exemption certificates.
Identify missing, incomplete, or outdated documentation.
Review use tax.
Compare purchasing activity with use tax reported.
Review prior audit findings.
If a previous audit identified errors, confirm that the underlying process has actually been corrected.
Document unusual business changes.
Keep support for acquisitions, new products, major customer changes, business closures, and other events that may explain significant changes in reported figures.
Make your records traceable.
A finance team should be able to start with a sales tax return and work backward to the supporting data and transactions.
This is an area where businesses need to be careful about broad generalizations.
Voluntary disclosure programs are state-specific. Eligibility, lookback periods, penalty relief, and application requirements vary.
For example, the Multistate Tax Commission's Multistate Voluntary Disclosure Program states that prior contact with a participating state concerning a tax type generally disqualifies a taxpayer from participation for that tax type. The program also notes that lookback periods vary by state.
That means businesses that discover an unregistered sales tax obligation should assess their options before contacting the state.
Do not assume that every state offers the same VDA terms or that the opportunity automatically disappears after any form of state contact.
California provides another example of why state-specific analysis matters. California generally applies a three-year limitation for deficiency determinations when required returns have been filed, while an eight-year limitation can apply when a required return was not filed, subject to statutory exceptions.
The broader lesson is more useful than any single lookback period: if you discover a potential historical sales tax liability, evaluate voluntary disclosure and statute-of-limitations considerations before taking action.
Sales tax audit preparation is easier when your compliance process already produces an audit trail.
Instead of trying to reconstruct months or years of decisions after receiving an audit notice, finance teams can build controls around:
The goal is not to predict whether your business will be audited.
It is to make sure that if an auditor asks, "How did you arrive at this number?", your team can answer without reconstructing the entire process from scratch.
The pre-audit research phase gives state auditors a structured way to understand a taxpayer before the examination begins.
For businesses, it offers a useful lesson in reverse.
Review the information an auditor is likely to see: your filing history, sales tax reporting patterns, exemption documentation, use tax activity, prior audit results, and supporting records.
If those pieces tell the same story, you are starting from a much stronger position.
CereTax helps finance and tax teams bring those pieces together with real-time nexus monitoring, transaction-level audit trails, reconciled sales tax returns, and exemption certificate management.
The end of Q3 creates a natural checkpoint for finance teams. But while you are closing the quarter, sales tax rules and your sales footprint are still moving.
You may have entered a new state. Local rates change on October 1, 2026 in Texas and California, and Philadelphia and Allegheny County move to destination sourcing the same day. A new product or service may have changed your taxability profile. A marketplace may have taken over collection for some transactions while leaving others with you. Or your tax engine may still be using outdated rates or rules.
A practical Q3 sales tax review can help you spot what changed, fix the gaps, and head into Q4 with a cleaner compliance process.
Here are the 10 questions worth asking.
Start with the question that can trigger everything else: Where do we now have sales tax nexus?
Review Q3 sales by state and compare them with each state's current economic nexus rules. Do not automatically assume that the threshold is based only on taxable sales. Some states use broader measures of gross receipts or include exempt and marketplace sales in their calculations.
Washington is a good example. Its Department of Revenue says remote sellers must register when they exceed $100,000 in combined gross receipts sourced or attributed to Washington in the current or prior year. The calculation includes sales through marketplaces, sales through the seller's own website, and exempt sales.
Your Q3 review should therefore ask:
A new nexus obligation can affect registration, collection, filing, and reporting. Finding it before Q4 transactions begin is much easier than discovering it after several months of sales.
October 1 is a common effective date for sales tax rate changes, making the end of Q3 a good time to check what is changing.
California's voter-approved district tax changes take effect October 1, 2026, under CDTFA special notice L-1037. The Los Angeles County countywide rate rises from 9.750% to 10.250%, the City of Perris goes from 7.750% to 8.750%, and the City of Red Bluff from 7.500% to 8.500%. Each change applies only within the named city or county limits.
Texas publishes local rate changes each quarter. In the Comptroller's October 1, 2026 rate changes, Beckville, Ellinger, and Frost adopt or raise a city sales tax, and the City of Shoreacres merged into the City of La Porte and abolished its sales tax.
Before Q4 starts, check whether your sales tax system has the latest:
A rate change that takes effect October 1 needs to be reflected in transactions from October 1 onward. You do not want to discover the change while preparing your Q4 return.
Sourcing rules change too. Starting October 1, 2026, any vendor that collects Pennsylvania's 6% sales tax must source Philadelphia's 2% and Allegheny County's 1% local sales tax to the delivery address under Act 21 of 2026; see Philadelphia and Allegheny County destination sourcing for what to test. And on January 1, 2027, California SB 122 makes prewritten software accessed remotely taxable, sourced first to the purchaser's California billing address, which changes taxability and sourcing for every SaaS seller with California customers.
Your product catalog may look similar to what you had in January. That does not mean your sales tax profile is unchanged.
New SKUs, bundled offerings, digital services, subscriptions, implementation fees, warranties, and other charges can introduce new taxability questions.
Review anything launched or materially changed during Q3.
The key question is not simply: "Is this product taxable?"
It is: "Is this product or service taxable in each jurisdiction where we sell it, and is our system applying the correct treatment?"
That distinction matters particularly for businesses selling software, digital products, services, and bundled offerings, where taxability can vary significantly by state.
If a product changed, the tax code attached to it may need to change too.
An exemption is only as useful as the documentation supporting it.
Before Q4, review customers currently receiving sales tax-exempt treatment. Check whether certificates are:
California, for example, requires exemption certificates to meet specific requirements in applicable circumstances, and sellers generally need to take certificates in good faith to obtain the protection they provide.
This is also a good time to identify customers whose exemption status changed during Q3.
For finance teams, the goal is simple: the exemption applied to the transaction should match the documentation your business can produce during an audit. That is the job of exemption certificate management.
Your sales tax filing frequency is not necessarily permanent.
States can change filing frequency based on sales volume, taxable receipts, tax liability, or other criteria.
New York, for example, generally classifies vendors as quarterly filers when taxable receipts and related taxable amounts remain below $300,000 for the relevant quarter. Businesses meeting the $300,000 threshold can be required to file monthly. Businesses with sufficiently low annual tax liability can qualify for annual filing.
Before Q4, confirm:
| Q3 Review Area | What to Check |
|---|---|
| Filing frequency | Monthly, quarterly, annual, or other |
| Filing deadlines | Current due dates |
| Returns | Required forms and schedules |
| Payment | Payment method and deadlines |
| Account status | Open, active, delinquent, or changed |
Do not assume last year's filing calendar still applies.
A sales tax return is only as reliable as the transaction data feeding it.
Compare your sales tax reports with your financial system and look for differences in:
This is not just an accounting exercise.
New York's Department of Taxation and Finance specifically advises taxpayers to report taxable activity in the correct taxing jurisdiction and maintain adequate records.
California also assigns sales tax filing frequency based on reported sales tax or anticipated taxable sales at registration.
If your sales tax report and general ledger do not reconcile, Q4 is a good time to find out why.
Marketplace transactions can make sales tax reporting more complicated because the marketplace may collect and remit tax on certain transactions while your business remains responsible for other sales.
The important question is not simply: "Does the marketplace collect sales tax?"
Ask: Who is collecting? Who is reporting? What is our business still responsible for?
Texas provides a clear example. A marketplace provider can certify that it will collect and remit sales and use tax on behalf of a marketplace seller. If the seller receives that certification, the seller generally does not collect Texas sales tax on those marketplace transactions. However, the seller still has recordkeeping obligations, and direct sales outside the marketplace remain the seller's responsibility.
Do not let marketplace sales disappear from your sales tax review simply because the platform is collecting the tax.
Q3 is also a good checkpoint for transaction reversals.
Review how your systems handle:
The sales tax treatment should follow the underlying transaction and the applicable state rules.
The operational question is whether your ecommerce platform, ERP, payment system, and sales tax engine all handle these events consistently.
If a customer receives a refund but the associated sales tax remains in your reporting data, you can end up with a reconciliation problem that only becomes obvious when the return is prepared.
An audit-ready sales tax process is not just about producing a return.
Your team should be able to trace reported amounts back to transaction-level data and supporting documentation.
Ask: If a state auditor asked us tomorrow how we calculated this return, could we show them?
That means retaining transaction records, exemption documentation, tax decisions, and supporting information for adjustments.
Texas, for example, requires sellers, including remote and marketplace sellers, to maintain required records such as gross receipts for at least four years.
The exact retention requirement varies by jurisdiction, so finance teams should follow the applicable state rules rather than relying on one company-wide assumption.
Finally, step back from individual states and look at the system itself.
If your team still updates rates by hand, checks nexus thresholds in spreadsheets, reconciles tax calculations between systems, or corrects tax codes after transactions occur, the Q3 review will show where the process breaks.
Sales tax automation should connect the critical pieces:
Transaction data → taxability → nexus → jurisdiction → rate → exemption → calculation → reporting
The goal is not simply to calculate sales tax faster.
It is to create a process where the right sales tax is calculated consistently and the supporting data is available when finance needs it.
That is a good thing.
The best outcome of a Q3 sales tax review is not finding a dramatic problem. It is entering Q4 knowing where you have nexus, which rates are changing, how products are taxed, whether exemptions are supported, what returns are due, and whether your systems are ready for the next quarter.
Sales tax compliance becomes harder when finance teams treat every quarter as a fresh start. A better approach is to use the quarter close as a control point, identify what changed, and fix the underlying process before the next transaction hits.
Q4 should be about running the business, not discovering last quarter's sales tax problems.
Ready to make sales tax compliance easier to manage? CereTax helps finance and tax teams automate sales tax calculation, economic nexus thresholds, taxability, exemptions, and reporting across complex, multistate operations.
Book a Strategy Call with CereTax to review your sales tax setup before Q4 is far along.
Omnichannel growth makes sales tax harder because each channel changes the obligations of the others. A store creates nexus for your online sales into that state, marketplace sales can count toward a state's threshold, and a buy online pickup in store order needs its own sourcing.
A retailer can have a physical store in Texas, an ecommerce site shipping across the country, and products listed on Amazon or another marketplace. Each channel generates sales differently, but the sales tax obligations do not stay neatly separated.
The marketplace may collect tax on transactions it facilitates. Your ecommerce site may still have direct sales tax obligations in the same state. A physical store may create a separate physical presence that changes your obligations altogether. And a customer who orders online and picks up the product at a store creates a transaction that does not fit neatly into a standard "ship-to" workflow.
The channels interact.
In California, marketplace sales count toward the $500,000 economic nexus threshold even though the marketplace collects the tax. A physical location creates nexus without regard to sales volume. And sourcing rules vary by state and by how the transaction takes place.
For a retailer growing across channels, sales tax needs one sales tax calculation process across every channel rather than three separate checklists.
A physical retail location generally creates physical presence nexus in the state where it operates. Unlike economic nexus, this does not depend on reaching a particular sales threshold.
That matters beyond the four walls of the store.
Once a retailer has physical presence in a state, its online sales into that state need to be evaluated under that state's rules as well. The retailer cannot simply treat its website as a separate business with a separate sales tax footprint.
The sourcing rules can make this even more complicated.
Texas, for example, has origin-based sourcing rules for certain intrastate sales. But that does not mean every Texas ecommerce transaction is automatically sourced to the seller's location. Remote seller and destination-based rules can apply depending on how the transaction is structured and where it is consummated.
That distinction matters when a retailer has stores, warehouses, and ecommerce operations spread across different locations.
The takeaway is simple: opening a store can change the sales tax picture for your entire business in that state.
Your POS, ecommerce platform, ERP, and tax engine need to reflect that reality.
For many shipped ecommerce transactions, the customer's delivery location determines the applicable sales tax jurisdiction.
That sounds straightforward until customer address data gets messy.
Billing address and shipping address are not interchangeable. A customer may have a corporate billing address in one state, ship an order to another state, and maintain multiple delivery locations. Your sales tax calculation needs to know which address matters for the transaction being processed.
The delivery address also determines the local jurisdictions that apply, the taxability of the transaction, and the evidence you need to support the calculation in an audit. Shipping and delivery charges carry their own taxability rules by state; see our sales tax on shipping state-by-state guide.
Illinois is the example to study, effective January 1, 2026. Under Illinois Department of Revenue guidance (Informational Bulletin FY 2026-12), retailers making destination-based sales need enough information and documentation to establish the destination of the transaction. When a retailer fails to supply that location data, the department assesses tax at a 15% undetermined-location rate.
That turns something as basic as capturing a complete delivery address into a sales tax control.
For omnichannel retailers, address data is tax data.
Marketplace facilitator laws move collection on facilitated sales to the marketplace. In California, the Marketplace Facilitator Act made the marketplace facilitator the retailer responsible for collecting and paying the tax on sales it facilitates for delivery to California customers, beginning October 1, 2019. Texas requires marketplace providers engaged in business in the state to collect, report, and remit state and local sales and use tax on all sales made through the marketplace, and to certify to their sellers that they do so.
But "Amazon collects the tax" does not mean "sales tax compliance is handled."
Your business may still need to:
The important distinction is between collection responsibility and your overall sales tax obligation.
Whether marketplace sales count toward your own threshold depends on the state. California counts them: its $500,000 test includes sales made on your own behalf and sales facilitated through a marketplace. Texas does not require a remote seller that sells only through a marketplace provider that certifies it collects the tax to hold a Texas permit, though every seller must keep records of marketplace sales for at least four years. Check each state's rule rather than applying one nationwide assumption.
Thresholds also differ in amount, measurement period, and the sales they include. Texas sets its remote seller safe harbor at $500,000 of total Texas revenue in the preceding 12 calendar months, counting taxable and nontaxable sales, including sales for resale and sales to exempt entities. California's $500,000 test covers sales of tangible personal property for delivery into the state in the preceding or current calendar year.
This is why marketplace volume needs to be part of your sales tax monitoring, even when the marketplace is doing the collecting.
Buy online, pick up in store sounds like one transaction to the customer.
For your systems, it can be two different worlds.
The customer places the order online. Your ecommerce system captures the order. But instead of shipping it to the customer's home, the customer takes possession at a physical store.
That means you cannot automatically treat every BOPIS order like a standard shipped ecommerce transaction.
Depending on the state's sourcing rules and the facts of the transaction, the pickup location may be relevant to determining the applicable sales tax. The exact treatment should therefore be evaluated under the rules of the state involved rather than hard-coded as a universal BOPIS rule.
This is where system configuration matters.
If your ecommerce platform assumes every order is shipped to the customer's home, but your customer actually takes possession at a store, the tax engine needs enough transaction data to recognize that difference.
A BOPIS order should not be an exception your tax team fixes manually after the fact.
Bring the transaction data from every channel into one sales tax process.
| Compliance Area | In-Store | Online Direct | Marketplace |
|---|---|---|---|
| Potential nexus trigger | Physical presence | Economic nexus or other nexus factors | Marketplace activity plus other nexus factors |
| Sourcing | Depends on state and transaction | Destination-based in many states | Marketplace applies applicable rules |
| Who collects | Retailer | Retailer | Marketplace where facilitator rules apply |
| BOPIS | Store pickup may affect sourcing | Requires transaction-specific logic | Marketplace and state rules determine treatment |
Every channel has to feed the same sales tax logic.
Your tax engine should know whether a transaction happened in a store, shipped from your ecommerce operation, was facilitated by a marketplace, or was ordered online and picked up at a store.
It should also be able to connect that transaction to the correct customer location, product taxability, exemption status, and applicable jurisdiction. Want to see that on your own transactions? Book a strategy call with CereTax.
Start with nexus.
Instead of monitoring your Shopify, Amazon, and physical stores separately, look at the business as a whole. Understand which states have physical presence, where economic activity is approaching a threshold, and which marketplace sales may be included in the calculation.
Then look at sourcing.
A shipped order, an in-store purchase, and a BOPIS order may require different treatment. Your systems need to recognize those transaction types rather than applying one default rule.
Finally, reconcile everything.
Your sales tax return should tie back to the underlying transaction data across your POS, ecommerce, ERP, and marketplace channels. Marketplace-collected sales should be identifiable. Direct sales should be distinguishable. Adjustments should have a clear audit trail.
That is where many omnichannel programs fall apart. The individual systems work, but nobody has connected the dots.
Take a state-by-state look at your three sales channels.
Ask:
If answering those questions means pulling data from five systems and stitching it together by hand, that is a sales tax risk.
Selling across channels? Your sales tax logic needs to keep up. CereTax brings sales tax calculation, jurisdiction sourcing, exemption logic, and transaction-level tax determination into one automated workflow, helping retailers manage the complexity that comes with selling in stores, online, and through marketplaces.
Book a Strategy Call with CereTax and see how a unified sales tax approach can simplify your omnichannel operation.
California SaaS companies have until January 1, 2027.
SB 122 was signed into law on June 29, 2026, and its digital product provisions become operative January 1, 2027. The law expands California's definition of taxable tangible personal property to include qualifying digital products, including prewritten computer software transferred electronically or accessed remotely. For SaaS businesses that have treated many California subscriptions as outside the sales tax base, that changes the billing equation.
Deciding whether to charge tax is the first step, and the shorter one.
Finance and operations teams have to translate the law into product rules, customer data requirements, contracts, exemption procedures, billing configurations, tax registration, and sourcing logic. The California Department of Tax and Fee Administration (CDTFA) published draft emergency regulations on September 1, 2026, held an interested parties meeting on September 10, 2026, and took written comments through September 24, 2026. The regulations were not final as of September 30, 2026.
January 1 is a tax deadline. For your billing system, it is a systems deadline.
The starting point is understanding what has changed.
SB 122 defines a digital product to include prewritten computer software that is transferred on tangible storage media, transferred electronically, or accessed remotely. "Accessed remotely" includes access, for consideration, to prewritten software residing on the vendor's server or a third-party server. That brings many SaaS arrangements directly into the new framework.
At the same time, the law contains important exclusions and exemptions. Custom computer software remains outside the definition of taxable digital products, while certain digitally delivered services involving primarily human effort can qualify for an exemption. The law also excludes categories such as digital books, digital audio works, digital audiovisual works, digital visual works, digital video game products, digital assets, and digital infrastructure from its definition of digital product.
That means your first operational task is not "turn on California sales tax." It is to classify what you actually sell.
Pull your complete California-facing product catalog and identify every revenue stream that could fall within the new definition.
That should include:
| Review area | What to examine |
|---|---|
| SaaS subscriptions | Products accessed through a browser, API, or other interface |
| Prewritten software | Electronically delivered or remotely accessed software |
| Custom development | Separately identified custom software and modifications |
| Implementation | Determine whether charges relate to taxable software or qualifying services |
| Support and maintenance | Review how each charge relates to the underlying software |
| Bundles | Identify whether taxable and nontaxable components are combined |
| Add-ons | Review separately billed features and functionality |
| Usage charges | Determine whether usage represents access to taxable software |
This exercise should produce a taxability matrix that your billing system can actually use, rather than a policy document that sits with the tax team.
That distinction matters. If your product catalog says one thing and your billing system applies another tax treatment, SB 122 compliance will break at the transaction level.
Possibly, and this is where finance, tax, legal, and sales operations need to work together.
Review customer agreements, order forms, pricing pages, and renewal templates for language around taxes. California rules already recognize that whether a retailer can add sales tax reimbursement depends on the terms of the agreement of sale.
For SaaS businesses moving into California sales tax collection, review whether contracts:
The objective is not to add generic "plus applicable taxes" language and move on. Your commercial terms should align with how your billing system will actually calculate and present tax.
A new taxable product category also means more customers may ask for exemptions.
Your exemption process should be ready before January, ahead of the first customer who sends your tax team a certificate.
California's new law specifically provides an exemption for certain digital products purchased solely for use outside California or in interstate or foreign commerce. The seller generally carries the burden of proving that the exemption applies unless it obtains the appropriate certificate from the purchaser in the form and manner prescribed by the CDTFA.
Your workflow should therefore answer:
Who can claim an exemption? What documentation is required? Where is it stored? How is it validated? Which transactions does it apply to?
Those answers need to make their way into the billing and customer master data process.
If your newly taxable California sales create an obligation to collect California sales or use tax, registration needs to be part of the implementation plan.
The CDTFA states that businesses required to collect California sales tax generally need a seller's permit, while out-of-state retailers engaged in business in California must register and collect California use tax on applicable sales.
Do not leave registration until December. Determine your obligation, gather the required business information, and establish the accounts and filing processes your finance team will need.
This may be the most technically important part of the project.
California does not operate with one single sales tax rate. The applicable rate can include the statewide rate, local tax, and district taxes. The CDTFA provides address-based rate lookup tools, and SB 122 specifically applies its sourcing rules to local and district taxes for qualifying digital products.
For remote SaaS transactions, SB 122 sources the sale to the purchaser's known California address in the seller's records, kept in good faith in the ordinary course of business (Revenue and Taxation Code section 6010.5). When the purchaser gave more than one address, the law sets the order: the billing address first, then the shipping or delivery address, then the mailing address tied to the purchaser's payment instrument, then the purchaser's mailing address. If the seller holds no California address for the purchaser, and the sale did not take place in person at the seller's California location, the statute deems the sale to take place outside California.
Multi-location customers get one more document. The CDTFA's draft Regulation 1600.2, published September 1, 2026, would let a purchaser whose users access the software both inside and outside California give the seller a multiple points of use (MPU) certificate. A seller that takes the certificate in good faith is relieved of tax on the share of use outside California, and the purchaser reports the California share using a reasonable, consistent method, such as a count of users by location. The draft is not final, so plan a field on the customer record for the certificate rather than a hard rule.
Your billing system therefore needs more than a California yes/no tax flag.
It needs reliable customer address data, a rule for the no-address case, jurisdiction determination, effective-dated tax rates, a place to store MPU certificates, and sales tax calculation that applies the right state and district tax to each transaction.
The tax moves to the buyer. Under Revenue and Taxation Code section 6052, a retailer is relieved of sales tax on digital products transferred electronically or accessed remotely once its gross receipts from those sales to one purchaser exceed $5,000,000 in the aggregate in the calendar year. Section 6201.55 applies the same threshold to use tax. The purchaser then self-assesses and pays use tax directly to the CDTFA on the transaction that crossed the threshold.
The CDTFA's draft Regulation 1600.1, published September 1, 2026, would require that purchaser to hold a use tax direct payment permit or to obtain a waiver from the CDTFA. With a waiver, the retailer stays liable for the tax. The draft is not final.
For billing, that means three things: track cumulative digital product receipts per customer per calendar year, be ready to stop charging sales tax on the transaction that crosses $5 million, and be ready to accept and store a use tax direct payment exemption certificate or a waiver from that customer. Our earlier post covers the $5 million rule in more detail.
A practical implementation can be organized into five workstreams:
| Workstream | Action before January 1 |
|---|---|
| Product taxability | Classify SaaS, software, services, bundles, and custom work |
| Commercial terms | Review contracts, pricing, invoices, and tax language |
| Customer data | Validate addresses, exemption status, MPU certificates, cumulative receipts against the $5 million threshold, and documentation |
| Registration | Determine CDTFA registration and filing requirements |
| Billing technology | Configure taxability, sourcing, rates, exemptions, and effective dates |
The important point is that these workstreams cannot operate independently.
A product classification decision affects billing. Billing depends on customer data. Customer data affects sourcing and exemptions. Registration affects reporting. And all of it ultimately flows into the sales tax return.
Start with the transaction.
Take a representative sample of your California invoices and trace each one through every system: product classification, customer location, exemption status, tax calculation, invoice presentation, general ledger posting, and eventual sales tax reporting.
Then ask a simple question:
If this transaction occurred on January 1, 2027, would our systems calculate and document the right California sales tax without someone manually intervening?
If the answer is no, you have identified your implementation backlog.
The CDTFA's rules are not final. On September 1, 2026, the agency published a discussion paper with draft emergency regulations covering digital product taxability, custom software, the $5 million tax liability threshold, multiple points of use, and purchases solely for use outside California. It held an interested parties meeting on September 10, 2026, and took written comments through September 24, 2026. The agency has also said that some questions will need an industry guide and later rulemaking.
That makes early preparation even more important. Your systems should be designed around the enacted law while remaining flexible enough to accommodate final administrative guidance.
The companies that wait until December to address California SaaS sales tax will be trying to solve tax policy, contracts, customer data, exemption management, registration, billing configuration, and reporting at the same time.
A better approach is to work backward from the January 1 transaction.
Classify the product. Validate the customer. Determine the jurisdiction. Apply the right tax. Document the decision. Feed the result into reporting.
That is what turning SB 122 into an operationally ready sales tax process looks like.
Ready to make your California sales tax implementation easier? CereTax helps SaaS and technology companies automate sales tax calculation, product taxability, exemption management, jurisdiction sourcing, and compliance across complex transaction environments.
Book a Strategy Call with CereTax to review your billing systems and prepare for California's January 1, 2027 sales tax changes.
Note: This article reflects SB 122 (Chapter 23, Statutes of 2026) and the CDTFA discussion paper of September 1, 2026, whose comment period closed September 24, 2026. The emergency regulations were not final as of September 30, 2026, so details may change.
Pennsylvania Act 21 of 2026 moves the local sales tax in Philadelphia and Allegheny County from what was generally the point of sale, where the vendor is located, to the point of destination, where the product or service is delivered. The Pennsylvania Department of Revenue says the change became law on July 12, 2026, with a retroactive effective date of tax years after December 31, 2025, and that the department will not begin enforcing the new rules until October 1, 2026.
Philadelphia's combined sales tax rate stays 8%: Pennsylvania's 6% state tax plus Philadelphia's 2% local tax. Allegheny County's local tax is 1%. What changes is the sourcing of the local component.
For any vendor outside those counties, a tax calculation that once depended on the seller's location now needs the customer's delivery address. Billing systems, tax engines, and customer records need that address from October 1, 2026.
Before Act 21, the Pennsylvania Department of Revenue generally based local sales tax on the point of sale, meaning where the vendor was located. Local sales tax is now based on the point of destination, meaning where the product or service is delivered. The same rule covers Philadelphia's 2% tax and Allegheny County's 1% tax. State sales tax rules have not changed, and use tax rules have not changed: if sales tax is not collected at the time of purchase, the purchaser still owes use tax when taxable items or services are used in Philadelphia or Allegheny County.
Consider a simple example.
A company operates outside Philadelphia and sells a taxable product to a Philadelphia customer. Before the change, the seller's location decided the local portion of the tax. Under destination sourcing, the Philadelphia delivery address decides it, so the seller collects the 2% Philadelphia local tax if it is already required to collect Pennsylvania's 6% state sales tax. A delivery into Allegheny County works the same way at 1%.
Across thousands of transactions, the systems processing them need to know where the customer receives the product or service and apply the local tax consistently.
The rule applies to vendors already required to collect and remit Pennsylvania's 6% sales tax. For Philadelphia, the City of Philadelphia says that includes businesses outside Philadelphia that already collect the 6% tax.
The Pennsylvania Department of Revenue states that vendors already required to collect and remit the Commonwealth's 6% sales tax must also collect and remit Philadelphia's 2% local sales tax on taxable sales made to Philadelphia customers.
For remote sellers, that makes the first question less about Philadelphia and more about Pennsylvania:
Are you already registered and collecting Pennsylvania sales tax?
Pennsylvania's economic nexus rule applies to businesses that made more than $100,000 of gross sales into the Commonwealth in the previous 12 months (Sales and Use Tax Bulletin 2019-01). The measure is gross sales on all channels, including taxable and nontaxable sales, with no transaction count.
If you already have that Pennsylvania obligation, Philadelphia's new local sourcing requirement should be on your implementation list.
If you do not currently collect Pennsylvania sales tax, the Philadelphia change is not, by itself, a reason to assume you have a new collection obligation. Your broader Pennsylvania nexus and taxability position needs to be evaluated first.
Because "Philadelphia customer" is not a sufficient tax calculation input.
Your systems need to distinguish between customer records, billing addresses, shipping addresses, delivery locations, and the actual location relevant to the transaction. That becomes especially important for businesses with multiple sales channels, distributed customers, complex fulfillment, or automated recurring billing.
A ZIP code alone may not provide the precision your tax calculation requires.
And the issue is not limited to checkout.
A destination-based change can touch the entire transaction flow:
| Area | What to review |
|---|---|
| Customer data | Confirm complete and accurate customer and delivery addresses |
| ERP | Review tax codes and local tax treatment |
| Billing | Confirm Philadelphia and Allegheny County tax is calculated at transaction time |
| E-commerce | Test Philadelphia and Allegheny County delivery scenarios |
| Tax engine | Validate destination-based sourcing logic |
| Exemptions | Make sure valid exemption treatment continues to flow correctly |
| Returns | Confirm Philadelphia tax is separately captured for reporting |
| Audit records | Retain the location and tax determination data supporting each transaction |
A rate table update covers part of this change. The system also needs the delivery address to decide when the 2% or 1% rate applies.
The City of Philadelphia itself recommends that businesses review their sales and delivery information, update point-of-sale and online checkout systems, and review tax collection and filing processes ahead of the enforcement date.
A practical implementation should go further.
Pull recent Pennsylvania transactions and identify which customers and deliveries go into Philadelphia or Allegheny County.
Do not rely on customer state alone. You need enough address information to separate those destinations from other Pennsylvania locations.
The new law does not change which products and services are taxable. It changes how Philadelphia's local tax applies to taxable transactions.
That means your existing product taxability decisions should remain the starting point. The new question is whether your sourcing logic correctly identifies a Philadelphia destination.
Run transaction scenarios before you rely on the new logic.
At minimum, test:
Verify that the 6% state component and the 2% Philadelphia or 1% Allegheny County component are determined, recorded, and reported correctly, not only that the invoice total is right.
Philadelphia's local sales tax is collected and remitted through the Pennsylvania Department of Revenue, not directly to the City.
Your finance team should therefore confirm that the additional local tax flows correctly into the Pennsylvania filing and reconciliation process.
This is also a good opportunity to make sure transaction-level reporting can explain how the Philadelphia amount was calculated.
When an auditor asks why your Philadelphia tax treatment changed, "the system was updated in October" is not much of an answer.
Maintain documentation showing:
That creates a defensible trail from the law to the invoice.
Enforcement starts October 1, 2026. A sourcing error repeats across every qualifying transaction until someone finds it, which is what makes destination sourcing a systems issue.
If your tax calculation still assumes that the seller's location determines Philadelphia's or Allegheny County's local tax, it is automating an outdated rule.
Philadelphia's 2% local tax and Allegheny County's 1% local tax are not new. The delivery address now decides when a vendor collects them.
For businesses already collecting Pennsylvania sales tax, that calls for a focused review of customer location data, destination sourcing, billing logic, tax engine configuration, and reporting.
The best time to find a sourcing problem is during testing, not after hundreds or thousands of invoices have gone out.
Ready to put Philadelphia and Allegheny County destination sourcing to the test? CereTax helps businesses automate transaction-level sales tax calculation with destination sourcing, jurisdiction logic, rate updates, and audit-ready documentation.
When customers can choose their electricity supplier, the company selling the electricity and the utility delivering it may be different entities.
The U.S. Energy Information Administration describes the structure clearly: in retail choice markets, a customer can purchase electricity from a competitive supplier while the local distribution utility continues to deliver that electricity to the customer's meter.
That separation matters for sales tax.
The customer may see supply, delivery, and other charges on the same bill, but those charges do not necessarily have the same sales tax treatment. The applicable rules can also depend on where the customer receives the service, how the electricity is used, and whether the customer has a valid exemption.
That creates a sales tax environment where a seemingly small configuration decision can repeat across thousands of invoices.
The four traps below are where that complexity creates the most operational risk.
One of the easiest mistakes is treating the customer's entire energy bill as one taxable item.
In a competitive market, the electricity itself can come from a retail supplier while delivery remains the responsibility of the local distribution utility. EIA also distinguishes between the rate for electricity itself and rates for delivery and other services or charges.
That distinction matters when a billing system applies sales tax.
Consider a consolidated bill that contains:
The sales tax treatment may not be identical across those components.
Texas provides a useful example. The Texas Comptroller treats the furnishing of electricity as a sale of tangible personal property and provides specific exemptions based on how the electricity is used. Local sales taxes can also depend on where the customer receives the service.
For the full Texas rules, including the residential-use city list, the reimbursement lines, and a worked bill, see our Texas utility tax guide. The utility tax by state hub tracks the other states.
For suppliers and utilities, the lesson is straightforward:
Do not let the billing format determine the sales tax treatment.
The tax engine needs to understand what each charge represents.
Energy exemptions are often about how the electricity is used, not simply who the customer is.
That makes exemption management particularly difficult for industrial and commercial accounts.
Texas, for example, provides sales tax exemptions for qualifying electricity and natural gas used in manufacturing and certain other activities. When electricity is supplied through a single meter for both taxable and exempt purposes, a predominant-use study may be required. The Texas Comptroller says the study must document the uses of the utility, including the exempt and taxable uses.
Kansas takes a similar documentation-focused approach, but with its own rules. A customer claiming an exempt utility use must provide Form ST-28B, and the form identifies the percentage of exempt use. Kansas also requires a separate form for each qualifying meter, with supporting worksheets documenting the exempt percentage.
This is why a customer-level flag such as "manufacturing customer = exempt" can be dangerous.
The customer's business classification may tell you something about eligibility, but it does not necessarily tell you how much of the electricity is exempt.
For sales tax teams, the better question is:
What percentage of this meter's usage actually qualifies for the exemption, and do we have the documentation to support it?
That distinction becomes critical during an audit.
Energy sales tax also has a location problem.
The customer's ZIP code is not necessarily enough to determine the correct sales tax jurisdiction. Local boundaries can cross city, county, and special district lines, while the location where electricity is delivered can determine which local taxes apply.
Texas makes this particularly clear. Its guidance for electricity retailers states that city, county, transit, and special-purpose district sales taxes are generally based on where the customer receives the service.
For an energy provider, that means jurisdiction assignment needs to be tied to the actual service location, not simply a generalized customer record.
This becomes especially important when a supplier operates across multiple deregulated markets.
A customer can have:
If the billing system applies one tax jurisdiction to the entire customer account, it can produce the wrong result across multiple invoices.
Sales tax accuracy in energy starts with knowing exactly where the taxable transaction occurs.
Deregulated energy markets can create another challenge: the supplier and distribution utility may have separate billing responsibilities.
The customer may receive separate bills, or a supplier may participate in a consolidated billing arrangement. Either way, the entities involved need to understand which charges they are responsible for taxing and reporting.
The risk appears when tax logic is designed around the bill rather than the underlying transaction.
For example, a supplier may correctly calculate sales tax on its electricity supply charge but fail to account for how related charges are treated. Alternatively, two systems may apply different sourcing or exemption logic to transactions that should be evaluated consistently.
The result is not necessarily one dramatic error. It can be thousands of small discrepancies that accumulate over time.
That is why synchronized sales tax logic matters.
Supply, delivery, customer location, exemption status, and applicable rates need to work from the same underlying rules.
The four traps have something in common.
They are difficult to manage when sales tax rules live separately from the systems processing energy transactions.
For utilities and retail energy suppliers, accurate compliance requires four capabilities:
| Sales Tax Requirement | What It Needs to Handle |
|---|---|
| Jurisdiction assignment | Determine the applicable jurisdiction from the customer's actual service location |
| Component-level taxability | Distinguish electricity supply, delivery, and other taxable charges |
| Exemption management | Connect exemptions to customer use, meter information, certificates, and supporting studies |
| Rate and rule management | Keep state and local sales tax rules current as jurisdictions change |
This is where sales tax automation becomes particularly valuable.
A static rate table can tell you a rate. It cannot necessarily determine whether the transaction is taxable, whether the customer's meter qualifies for an exemption, or whether the charge should be treated differently from another component on the same bill.
The sales tax engine needs to make those decisions using the transaction data available to it.
Energy providers are dealing with a combination of factors that make manual sales tax processes increasingly difficult to scale.
Customer locations change. Local rates change. Exemption documentation expires or needs to be updated. Customers can have multiple meters with different uses. And supply and delivery can be handled by different entities.
The challenge is therefore not simply keeping a rate table current.
It is connecting customer, meter, location, product, usage, exemption, and transaction data before the sales tax calculation happens.
That is the difference between automating sales tax calculation and simply automating a rate lookup.
Start with the transactions creating the most exposure.
Review a sample of invoices across residential, commercial, and industrial customers. Then trace each transaction through the sales tax process:
Service address → jurisdiction → charge type → customer use → exemption → rate → sales tax calculation
Look for places where someone still has to make a manual decision.
If the tax team is maintaining exemption spreadsheets, if billing is using ZIP codes instead of precise service locations, or if supply and delivery charges are being treated as one taxable category, those are signals that the sales tax process needs a closer look.
The objective is not to make energy billing more complicated.
It is to make the sales tax logic match the way energy is actually sold and delivered.
Ready to close the gaps in your energy sales tax stack? Deregulated energy markets require more than a standard sales tax setup. CereTax helps utilities and retail energy suppliers automate sales tax calculation across complex jurisdiction, product, exemption, and billing scenarios.
From service-location sourcing to component-level taxability and exemption management, CereTax helps bring the sales tax process together in one automated workflow.
👉🏻 Book a Strategy Call with CereTax to see how you can simplify sales tax compliance across your energy operations.
Published September 16, 2026
CereTax for Rillet is live. Companies that run their general ledger in Rillet can now calculate accurate, audit-ready sales tax or VAT on every invoice and credit memo in real time, with the tax lines written back into Rillet before the invoice goes out.
Rillet is the accounting platform for finance teams that closed the books in days and want to close them in hours. Revenue recognition, consolidation, and the close itself run inside one system. Tax has usually been the exception: calculated somewhere else, pasted in, and reconciled at month end by whoever owns the spreadsheet.
Every one of those manual steps is a place for the number to drift. A rate expires. A new state starts taxing software. A credit memo reverses an invoice at today's rate instead of the rate that applied when the invoice was issued. None of these show up until an auditor, a customer, or a controller finds them.
CereTax for Rillet puts the calculation inside the invoice event. The tax on the invoice in Rillet is the tax CereTax calculated for that customer, that product, and that address, at that moment.
Setup runs through two admin screens and takes no code. Create an API key in Rillet, log in to the CereTax connector with your CereTax Portal credentials, enter both keys, set your defaults and ship-from address, and paste the connector's webhook URL into Rillet's webhook settings for invoices and credit memos. Rillet's sandbox pairs with the CereTax Cert environment and Rillet production pairs with CereTax production, so you can test before a live invoice sees a rate. Invoices post to CereTax as quotes when created and as posted transactions when paid, which keeps your CereTax reporting tied to cash.
This is the same CereTax platform that more than 200 companies rely on across software, manufacturing, retail, ecommerce, energy, and more. CereTax integrates with platforms that move more than $4 trillion in transactions each year, and Rillet is now on that list.
The engine behind the connector maintains 98k+ active tax rates, 67M+ taxability decisions, and 5.9M exemption decisions, researched and kept current by our in-house tax team. Every one of them is available on a Rillet invoice through a product and service code. When your catalog grows past a single subscription, into usage-based fees, bundled services, digital goods, and products that one state taxes and the next does not, the calculation already knows what to do. Behind it all sits rooftop-level precision and real people who answer the phone when you call.
If your team closes in Rillet and still fixes tax after the invoice goes out, we should talk. Request a demo to talk to a sales tax expert.
Vertex fits large, multinational enterprises with a tax team to run a broad indirect tax platform. CereTax fits growing U.S. manufacturers that need multi-plant, multi-entity sales and use tax, manufacturing exemption logic, and a deployment that runs in under 90 days.
Manufacturing tax complexity does not wait until you become an enterprise.
A growing manufacturer can have multiple plants, entities, warehouses, vendors, exemption certificates, ERP environments, and thousands of transactions long before it has the tax department or IT resources of a Fortune 500 company.
That creates a specific buying problem.
You need a sales tax engine capable of handling manufacturing complexity, but you may not need an enterprise tax transformation project to get there.
For the feature-by-feature table, see CereTax vs. Vertex. This post covers the manufacturing questions: plants, entities, use tax, and exemptions.
Vertex has spent decades building a broad indirect tax platform and has deep manufacturing experience. Its manufacturing content covers complex supply chains, procurement, production, distribution, exemption management, ERP integration, and enterprise-scale tax data management. Vertex says it works with 1,200+ manufacturing customers and that 91% of Fortune 100 manufacturers trust it for indirect tax.
CereTax takes a different approach: cloud-native architecture, API-first integrations, configurable exemption logic, transaction-level sales and use tax, and deployments that run in under 90 days.
The question for a mid-market manufacturer: which platform fits the business you are building?
Applying a rate to an invoice is the easy part of manufacturing tax for a sales tax engine.
The taxability of machinery, equipment, software, supplies, production inputs, repairs, and other purchases can depend on how and where those items are used.
California, for example, grants a partial exemption of 3.9375% from the sales and use tax rate, through June 30, 2030, on qualified machinery and equipment that a qualified person buys and uses primarily in manufacturing or research and development. Eligibility turns on the buyer's business, the type of property, and how the property is used (Revenue and Taxation Code section 6377.1).
Texas exempts tangible personal property used directly in manufacturing that makes a chemical or physical change to the product, property used for quality control that tests products for sale, and certain pollution control equipment. The exemption depends on how the property is used in the process.
That is why a manufacturing tax engine needs more context than product and invoice data alone.
CereTax's manufacturing offering uses inputs such as GL accounts, item type, vendor data, usage, and ship-to location to determine tax. It also covers vendor overcharges and use tax, exemption certificates, and multi-entity, multi-plant, and multi-state environments.
Vertex positions its manufacturing solution around procurement, production, distribution, exemptions, sourcing, and centralized tax determination.
Both platforms understand manufacturing. The difference is how much infrastructure, implementation effort, and staff time each one needs around that capability.
For a manufacturer evaluating both platforms, the practical differences look something like this:
Feature-by-feature comparison: CereTax vs. Vertex.
| What matters to you | Vertex | CereTax |
|---|---|---|
| Best fit | Large, complex enterprises with heavy indirect tax overhead | Growing and mid-market businesses seeking modern, frictionless tax automation |
| Architecture | Enterprise indirect tax platform built for large, global tax operations | Cloud-native, multi-tenant architecture |
| Implementation | 12 to 18 months | Under 90 days |
| ERP and API integration | ERP integration and enterprise-scale tax data management, per Vertex | Flexible, API-first: ERP, billing, ecommerce, and more |
| Manufacturing | Procurement, production, distribution, exemptions, and sourcing, per Vertex | Built for manufacturing: usage, GL, vendor, and location context |
| Exemption management | Included in its manufacturing solution, per Vertex | Real-time alerts, no scripting (SmartExempt) |
| Growth model | Built for large organizations running many tax types across many countries | Built for organizations that want speed, flexibility, and a light implementation |
Vertex implementations run 12 to 18 months. CereTax deployments run in under 90 days. Both are vendor-reported figures, so check them against your own implementation scope. The full feature table is on CereTax vs. Vertex.
That gap matters for mid-market manufacturers because implementation cost goes well beyond the software license.
It includes internal IT time, consulting fees, data cleanup, testing, ERP changes, product mapping, and the cost of keeping a tax project open for months.
This is where the buying decision should move beyond today's transaction volume.
Maybe you have two plants today. Could there be five in three years?
Maybe you operate in eight states today. Are acquisitions or new distribution locations likely to push that number higher?
Maybe your ERP is relatively straightforward today. What happens when you add another entity or integrate a second system?
A tax engine should accommodate that growth without forcing every expansion to become another major implementation project.
This matters for manufacturers because tax complexity usually grows out of operating changes, not tax decisions. A new warehouse, vendor arrangement, product line, acquisition, or production process can change the tax analysis.
Even temporary rules such as a sales tax holiday can introduce another layer of product and transaction logic that needs to be configured correctly.
The platform needs to adapt as the business changes.
Not necessarily.
Vertex's scale is a legitimate advantage if your organization needs a broad enterprise tax ecosystem, extensive global indirect tax capabilities, and infrastructure designed around highly complex multinational operations. Its manufacturing resources clearly emphasize that market.
But if your priority is modern sales tax automation for a growing U.S. manufacturing business, the decision may look different.
You may value:
That is the segment CereTax is built for.
Start with the operating model, not the vendor checklist.
If your business is becoming a large, globally complex enterprise and needs a broad indirect tax architecture across multiple tax types and jurisdictions, Vertex may be the more natural fit.
If you are a growing manufacturer that needs U.S. sales and use tax automation without a transformation program around it, CereTax deserves a serious look.
Buy the engine that gives your finance and IT teams the capability, flexibility, and control the business you are building needs, whatever the length of its feature list.
Ready to compare the two against your manufacturing environment? CereTax helps manufacturers automate sales and use tax across plants, entities, vendors, products, exemptions, and jurisdictions, and deployments run in under 90 days.
Book a Strategy Call with CereTax to see whether a modern tax engine fits where your manufacturing business is going.
Published September 9, 2026
CereTax for Salesforce is live in two apps: one for Salesforce CPQ and Order Management, and one for Salesforce B2C Commerce storefronts. Companies that quote, take orders, or sell online in Salesforce can calculate accurate, audit-ready sales tax on every quote, order, and checkout in real time, without leaving the platform.
Salesforce holds the moment a price becomes a commitment. In CPQ (configure, price, quote), that moment is the quote a rep sends. In B2C Commerce (Salesforce's business-to-consumer storefront platform, once sold as Commerce Cloud), it is the checkout page. When the sales tax on that screen is wrong, someone downstream finds out: a buyer who disputes the invoice, a controller who rebooks the order, or an auditor who asks why the quote and the invoice carry different rates.
Most teams cover the gap with estimates. Tax gets approximated at quote time and corrected at billing, or a storefront runs on ZIP code rates and finance trues it up at month end. Each fix is small. The count grows with every new state, product line, and storefront.
CereTax for Salesforce removes the estimate. The calculation engine runs inside the Salesforce record itself, so the number on the quote or in the cart is the number on the invoice.
CereTax for Salesforce ships as two apps that share one calculation engine and one set of tax rules:
Run one or both. The rules, product codes, and reporting behind them are the same, so a company that quotes in CPQ and sells online through B2C Commerce gets one tax answer across both channels.
Both apps install through Salesforce: the CPQ package into a production or sandbox org, the B2C cartridge into your active code version through Business Manager. Your Salesforce admin or implementation partner installs the app, enters the CereTax key and profile, and maps the objects you calculate on. The CereTax team supplies the package, the credentials, and the product codes, and works through setup with your team until the first quote or order calculates.
This is the same CereTax platform that more than 200 companies rely on across software, manufacturing, retail, ecommerce, energy, and more. CereTax integrates with platforms that move more than $4 trillion in transactions each year, and Salesforce sits on that list.
The engine behind both apps maintains 98k+ active tax rates, 67M+ taxability decisions, and 5.9M exemption decisions, researched and kept current by our in-house tax team. Every one of them is available on a Salesforce quote or storefront order through a product and service code. When your catalog grows past plainly taxable goods, into bundled digital and physical products, configured hardware with installation, or items with state-by-state exemption rules, the calculation already knows what to do. Behind it all sits rooftop-level precision and real people who answer the phone when you call.
If your team quotes in Salesforce CPQ or sells through B2C Commerce, and sales tax still gets fixed after the fact, we should talk. Request a demo to talk to a sales tax expert.
CereTax deployments run in under 90 days. The first month connects your ERP or billing system and sets the nexus baseline, the second maps products and migrates exemption certificates, and the third validates every calculation in a parallel run before your filing partner or accountant takes the first return.
CFOs evaluating sales tax automation ask the same question: how long before this works?
The answer depends on what happens before go-live. Product data has to map to the right tax categories. ERP and billing systems have to send the right transaction fields. You need to know your sales tax nexus footprint and account for every existing exemption certificate. Skip those steps and sales tax automation makes existing errors happen faster.
CFO spending plans for 2026 show why this matters. The Grant Thornton Q1 2026 CFO survey found that 68% of respondents expect IT and digital transformation costs to rise over the next 12 months. In Deloitte's Q4 2025 CFO Signals survey, 50% of CFOs named digital transformation of finance as their top priority for 2026, and 52% listed improving data quality, access, and usability among their top finance transformation priorities.
Sales tax automation is no different.
A tax engine can calculate sales tax automatically, but it needs accurate inputs to produce accurate outputs. A product mapped to the wrong tax category, an outdated exemption certificate, or an incorrect customer location can result in the wrong tax being calculated on every transaction.
The first 90 days build the foundation for accurate, scalable sales tax automation. CereTax connects sales tax calculation, compliance, and reporting to the systems your finance team already uses, so that foundation works from day one.
The first month is the foundation phase, and the work falls into two parallel tracks: technical integration and compliance baseline.
On the technical side, CereTax connects to your existing billing, ERP, or commerce environment. This may include systems such as NetSuite, SAP, Oracle, Microsoft Dynamics, Stripe, or ecommerce platforms handling direct customer transactions.
The API-first architecture sends transaction data into CereTax, returns the calculated sales tax to the source system, and records each calculation with the inputs that produced it.
For standard integrations, the connection goes live in the first month.
At the same time, the compliance baseline establishes where your business currently stands. CereTax can help you review sales by state against current economic nexus thresholds.
The result is a clearer sales tax registration picture: where you are registered correctly, where additional registration may be required, and where prior-period exposure may need to be addressed.
By the end of the first 30 days, your team should have two outputs: a working sales tax integration and a clear view of its current sales tax footprint.
The second phase focuses on product taxability mapping, one of the most important steps in any sales tax automation implementation.
Every product or service in the catalog needs to be assigned the appropriate tax category so CereTax can apply the relevant sales tax rules in each jurisdiction.
For a business selling physical products, this can be simple. For SaaS and other complex businesses, it can involve per-seat plans, usage-based pricing, bundled services, implementation fees, and professional services.
The mapping process can also expose problems in how products are structured and billed. For example, a taxable SaaS product and a potentially exempt professional service may be combined into one line item, creating a different sales tax outcome than if they were separately identified.
Fixing those issues during implementation is far easier than finding them after the wrong tax has gone out on invoices and returns.
This phase also includes exemption certificate migration. Existing certificates can be imported, validated against applicable requirements, and flagged where renewal or additional documentation is needed.
For a CFO, this step builds the record an auditor will ask for: which customers are exempt, on what certificate, and through what date.
Days 61 through 90 are the validation phase.
Before CereTax becomes the system used for live sales tax calculation, its outputs are tested against the existing process for a complete billing cycle. Calculated tax is compared with what the previous method would have produced, and material differences are investigated.
This parallel run is designed to catch three common issues:
| Issue | What Validation Identifies |
|---|---|
| Product mapping | Products assigned to the wrong sales tax category |
| Tax sourcing | Transactions being assigned to an unexpected jurisdiction |
| Exemption gaps | Customers whose exemption status was not migrated correctly |
These issues are much easier to fix before the first return is due than after the wrong tax has been reported.
The final phase also sets up the handoff to your filing partner or accountant. CereTax does not file returns. Your filing partner or accountant prepares and submits them from the calculation records and reports CereTax produces for each period and jurisdiction.
By day 90, live sales tax calculation is validated and your filing partner or accountant has what it needs for the first return.
A CFO does not need to manage the implementation day to day. Two decisions do need executive ownership.
The first is prior-period sales tax exposure. If the nexus review identifies states where an obligation existed before registration, the business may need to decide how to address that exposure.
The second is ambiguous product taxability. Bundled offerings, custom development, professional services, and usage-based products can require a business decision on how to bill and tax them.
CereTax's implementation team provides the tax and regulatory context. The business decides how to handle the ambiguous positions.
The rest of the implementation is a technical and operational process between the CereTax team and your finance or accounting team.
By day 90 your business should run a controlled sales tax operation, with every calculation recorded and every exemption on file.
| Phase | Primary Deliverable | What Your Team Contributes |
|---|---|---|
| Days 1 to 30 | ERP or billing integration and nexus baseline | Sales data and IT access |
| Days 31 to 60 | Product taxability mapping and exemption migration | Product catalog, certificates, classification decisions |
| Days 61 to 90 | Parallel validation and filing-partner handoff | Output review and sign-off on the data your filing partner or accountant receives |
The CFO question at day 90 has three parts: is sales tax calculation now consistent, is compliance easier to manage, and does the business see its tax obligations clearly?
That is the value of a well-executed sales tax automation implementation.
A successful implementation should move sales tax from a recurring manual burden into an automated finance process.
By day 91, your ERP, billing, and commerce systems are connected, products are mapped, exemptions are organized, tax calculations are validated, and your filing partner or accountant is ready to file the first return. Your team also understands how CereTax calculates each transaction and where the business stands on compliance.
See what your first 90 days with CereTax could look like. CereTax connects to your existing billing, ERP, and commerce systems, and deployments run in under 90 days. If you are replacing Avalara, CereTax vs. Avalara covers how the switch runs. The strategy call is where we map your systems, your nexus footprint, and your timeline.
Book a Strategy Call with CereTax to map your sales tax environment, your systems, and your implementation timeline.
Most B2B sellers treat exemption certificates as a formality. A customer claims they are buying for resale, the rep collects a form, the deal closes. That works fine until an auditor arrives and asks to see the certificate behind every untaxed transaction in the audit period.
The liability sits with the seller, not the buyer. If a certificate is invalid, the seller owes the uncollected tax plus interest and penalties, regardless of what the customer told them. And the way auditors calculate that liability is what makes certificate problems so expensive: they sample your records, find the error rate, and project it across the full audit period. A 15% error rate in a 100-transaction sample, applied to $3 million in exempt sales over three years, means $450,000 of sales lose their exemption. The auditor assesses tax on that amount, which is $31,500 at a 7% combined rate, plus interest and penalties. A handful of paperwork gaps becomes a five-figure tax bill through that extrapolation alone.
Missing certificates are the most straightforward. A sale was coded exempt in the system, but there is nothing on file to support it. This happens most often when a customer verbally claims exempt status, the rep overrides the tax, and the paperwork never follows.
Expired certificates are the most avoidable. Florida's Annual Resale Certificate (Form DR-13) expires every December 31, and the Florida Department of Revenue issues a new one each year to registered dealers. Florida exemption certificates, such as the Consumer's Certificate of Exemption (Form DR-14), expire five years after issuance under Fla. Stat. §212.084. Other states have no hard expiration but expect periodic re-verification. A certificate that was valid when collected can be worthless at audit time if it lapsed midway through the period under review.
Incomplete certificates are defective on their face: missing buyer name, blank address, no tax ID, unsigned, or no stated reason for exemption. These defects are easy to catch at intake and almost impossible to fix years later.
Wrong form for the wrong state scales as a problem with geographic expansion. The MTC Uniform Certificate is accepted in 36 states with varying conditions. The SST certificate covers 24 member jurisdictions. States outside those frameworks require their own forms. Using the MTC certificate for a Texas customer when Form 01-339 is required is the same as having nothing on file.
Certificate-to-transaction mismatch is the failure auditors find in sophisticated operations. A resale certificate does not cover manufacturing, nonprofit, government, or project exemptions. If a customer's certificate claims resale but the items were used in production, the exemption fails even if the certificate itself looks complete.
Because expiration rules differ by state, a seller operating in multiple jurisdictions cannot apply a single renewal schedule to their entire certificate library.
| State / Certificate | Validity and Key Rule |
|---|---|
| Florida | Annual Resale Certificate (DR-13) expires each December 31 and is reissued yearly. Exemption certificates (DR-14) expire 5 years after issuance (Fla. Stat. §212.084). |
| Texas | No statutory expiration if buyer info unchanged. Form 01-339 required. |
| New York | Valid while circumstances unchanged. Form ST-120. Validate buyer's Certificate of Authority number. |
| California | Valid until revoked or circumstances change. Buyer must hold active seller's permit. |
| Washington | Reseller permits from the Department of Revenue are generally valid four years (two years for contractors and businesses open under 12 months). Out-of-state buyers without a Washington permit may use the SST or MTC uniform certificate. |
| MTC Uniform Certificate | Accepted in 36 states with varying conditions. Verify current acceptance before relying on it. |
| SST Certificate | Accepted in 24 SST member jurisdictions. One form covers all member jurisdictions. |
Sellers who accept an invalid certificate in good faith are generally protected from liability, but good faith has real requirements. It means the certificate appeared valid on its face and was collected at or near the time of the sale, from a buyer whose business plausibly supported the exemption claimed.
It does not protect a seller who accepted a certificate with visible defects. It does not protect a certificate collected after the audit notice arrived. Texas, for example, gives a seller 90 days from the comptroller's written notice to produce certificates (Tax Code §151.054), but a certificate obtained after the audit begins does not earn good-faith protection. And in states that require it, failing to verify the buyer's registration number can strip the good faith defense even if everything else looks correct. SST member states apply a relaxed good faith standard, giving sellers a somewhat lower bar for acceptance in those jurisdictions.
Four things separate a certificate library that survives an audit from one that generates an assessment.
If a review of your current library reveals gaps, proactive remediation before an audit opens is significantly cheaper than addressing them after. Some states allow certificates collected during an open audit to be considered before the final assessment is issued. Texas gives 90 days from the comptroller's written notice. That window is narrower and less reliable than acting before the auditor arrives.
Do you know what an auditor would find in your certificate library today? Most certificate gaps are invisible until an auditor samples them and projects the error rate across years of exempt sales. CereTax SmartExempt manages the full exemption certificate lifecycle: collection at point of sale, validation, expiration tracking with renewal alerts, and an audit-ready library that connects every certificate to its transactions. If you are comparing tools, start with how to choose exemption certificate management software.
Published September 2, 2026
CereTax for Stripe Billing is now available. Companies that invoice through Stripe can calculate accurate, audit-ready sales tax on every invoice in real time, without leaving the Stripe dashboard.
Stripe runs billing for companies at every stage, from early startups to multi-entity enterprises. Sales tax follows that growth: new states, new jurisdictions, new product lines, and new exemption certificates, each with its own rules. Most billing teams keep up with manual adjustments and a standing plan to fix it properly later. Every manual fix adds audit exposure, and the volume of fixes grows with the business.
This integration puts the CereTax calculation engine directly in the invoice flow. Tax gets calculated correctly at the moment the invoice is created, so there is nothing to clean up after.
Connect the CereTax for Stripe app to your Stripe account, enter your license key, and add the webhook endpoint in your Stripe dashboard. Sandbox and production environments are both supported, so your team can test before anything touches a live invoice.
This is the same CereTax platform that more than 200 companies rely on across communications, energy, fuel, software, manufacturing, retail, ecommerce, and more. CereTax integrates with platforms that move more than $4 trillion in transactions each year, and Stripe Billing now joins that list.
The engine behind this connector maintains 98k+ active tax rates, 67M+ taxability decisions, and 5.9M exemption decisions, researched and kept current by our in-house tax team. Every one of them is available on a Stripe invoice through a product and service code. When your catalog grows past plainly taxable goods, into communications services, energy charges, bundled digital and physical products, or items with state-by-state exemption rules, the calculation already knows what to do. Behind it all sits rooftop-level precision and real people who answer the phone when you call.
If you bill through Stripe and sales tax has become a line item on someone's calendar, we should talk. Request a demo to talk to a sales tax expert. Existing customers can connect today using the setup guide.
