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.
The appeal of drop shipping as a fulfillment model is straightforward: the manufacturer holds the inventory, ships directly to the end customer, and the retailer never touches the goods. The logistics are simple, and the sales tax follows two separate sales.
A drop shipment creates two legally distinct sales transactions from a tax perspective, not one. The first is the sale from the manufacturer to the retailer, which should be a wholesale sale for resale and therefore exempt from tax. The second is the sale from the retailer to the end customer, which is a taxable retail sale if the retailer has nexus in the delivery state and the goods are taxable there. The problem is that these two transactions do not have the same parties, the same nexus analysis, or the same documentation requirements, and they take place simultaneously in a single shipment.
For manufacturers, the complication starts when the retailer has no nexus in the delivery state. If the manufacturer has nexus there, and the retailer cannot produce a resale certificate that state accepts, the manufacturer can become the party responsible for collecting and remitting sales tax on a sale it had every reason to treat as wholesale. California and Connecticut, for example, do not accept a resale certificate from a retailer that is not registered with the state, and Illinois presumes a sale is not for resale when the certificate carries no active Illinois registration or resale number. That combination creates ongoing exposure for manufacturers with multi-state distribution relationships.
The foundational rule in drop shipment tax is that each leg of the transaction is analyzed independently. The first leg, manufacturer to retailer, is evaluated under the rules of the delivery state. If that sale qualifies as a sale for resale, meaning the manufacturer holds a valid resale certificate from the retailer and the certificate meets the delivery state's requirements, the manufacturer owes no tax on that leg. The second leg, retailer to end customer, is a retail sale taxed based on whether the retailer has nexus in the delivery state and whether the product is taxable there.
The nexus analysis for each party runs independently. A retailer with nexus in the delivery state collects tax from the customer, provides the manufacturer a resale certificate, and the manufacturer's sale is exempt. A retailer without nexus in the delivery state owes no tax on its sale to the customer. But if the manufacturer has nexus in that delivery state, the manufacturer now faces the wholesale leg as a taxable event unless the resale certificate is valid and accepted. The question that drives the entire analysis is whether the retailer can produce documentation that the delivery state will accept.
The three key scenarios and their outcomes:
| Scenario | Who Collects from Customer | Key Condition |
|---|---|---|
| Retailer has nexus in delivery state | Retailer collects from customer; manufacturer's sale is exempt on valid resale cert | Retailer must provide valid resale certificate to manufacturer |
| Retailer has no nexus; manufacturer has no nexus | Neither party collects; customer owes use tax | No collection obligation for either party in delivery state |
| Retailer has no nexus; manufacturer has nexus | Manufacturer may become liable on wholesale leg if no valid certificate | Delivery state determines whether out-of-state certificate is accepted |
The resale certificate is the document that converts the manufacturer-to-retailer transaction from a taxable sale into an exempt wholesale transaction. The challenge is that no single certificate format is accepted everywhere, and the requirements vary significantly by state.
The Multistate Tax Commission (MTC) publishes a Uniform Sales and Use Tax Resale Certificate that 36 states have said they accept, each with its own conditions. The retailer lists its registration numbers for the states where it is registered, and one form covers those states. The Streamlined Sales Tax (SST) exemption certificate works the same way across SST member states. In those member states, a retailer can issue a resale certificate to the drop shipper even if the retailer is not registered in the delivery state, and the supplier is protected from liability as long as it received the certificate in good faith.
Some states fall outside these frameworks and require their own registration before they honor a resale exemption on a drop-shipped sale. California is the clearest example. The California Department of Tax and Fee Administration's Publication 121 on Drop Shipments states that if the true retailer does not hold a California seller's permit, the drop shipper is responsible for reporting and paying California tax on the retail selling price the retailer charges the California customer. If the retailer holds a California seller's permit, it issues the manufacturer a resale certificate, and the manufacturer is relieved of reporting and paying the tax.
Connecticut applies the same rule. Under Policy Statement 2013(3), a resale or exemption certificate issued by an unregistered seller to the drop shipper does not exempt the sale from Connecticut tax. The rule applies when the drop shipper is registered in Connecticut; when it is not, the customer owes use tax. Illinois presumes a sale is not for resale when the certificate does not carry an active Illinois registration or resale number, under the Illinois drop shipment rule (86 Ill. Adm. Code 130.225). Other evidence can rebut that presumption. An out-of-state retailer can apply for an Illinois resale number. A certification on the certificate that describes the drop shipment, in place of a number, counts as evidence that the sale is for resale, though an auditor is more likely to look behind it.
Other states accept an out-of-state retailer's paperwork in some form. The Georgia Department of Revenue says the MTC uniform certificate or the purchaser's home-state certificate bearing its resale registration number will in general serve as sufficient proof that the sale is not a taxable retail sale, so a Georgia dealer that drop ships for a purchaser with no Georgia presence and no Georgia sales tax number is not required to collect. Maine takes a middle position: under Instructional Bulletin 54, a resale certificate issued by the purchaser's home state is not valid in Maine, but the MTC uniform certificate is.
For manufacturers shipping into a strict state, every retailer in the distribution relationship either needs that state's registration or the manufacturer needs a documented process for what happens when it does not.
The default collector question is the most financially consequential issue for manufacturers in drop shipping arrangements. It arises specifically when three conditions converge: the manufacturer has nexus in the delivery state, the retailer does not have nexus there, and the retailer cannot provide a resale certificate that the delivery state accepts.
In that situation, a state that does not accept the retailer's certificate treats the manufacturer's sale to the retailer as a taxable retail sale rather than a wholesale transaction. California requires the manufacturer to charge the retailer tax based on the retail price the retailer charges the end customer, not the wholesale price the manufacturer charges the retailer. This is the rule under California Regulation 1706, which specifies that the drop shipper in this situation should charge the true retailer tax based on the retail amount and report and pay it to the CDTFA. The retailer may then seek reimbursement from the end customer, but that reimbursement is the retailer's problem to solve, not the manufacturer's.
Use tax applies when no sales tax is collected. If neither the retailer nor the manufacturer has nexus in the delivery state and no tax is collected, the end customer owes use tax on the purchase. That obligation belongs to the customer, not to either seller.
The compliance burden in drop shipping is heaviest for manufacturers who ship into many states at the direction of retailers whose own nexus footprint is not fully known. The standard that protects a manufacturer is good-faith acceptance of a valid certificate, but good faith requires that the certificate was timely received, meets the delivery state's requirements, and covers the type of property being sold.
The practical standard for a defensible process has three components. First, require a resale certificate from every retailer before the first shipment, not after, and store it in an exemption certificate management system tied to the retailer and the delivery state. Certificates obtained during an audit carry less weight than certificates obtained at the time of the transaction. Second, maintain a state-by-state matrix of which certificate formats each delivery state will accept, including whether the state requires in-state registration or will accept the MTC uniform certificate or the retailer's home-state form. The Sales Tax Institute's drop shipment FAQ and the MTC Uniform Certificate itself both provide guidance on state-by-state acceptance rules. Third, build a process for the strict-state scenario: if a retailer cannot provide a California seller's permit for California deliveries, the manufacturer's system should either flag the transaction for tax collection or require the retailer to register before orders are processed.
Certificates also expire. Florida's Annual Resale Certificate expires every December 31, and the Florida Department of Revenue issues a new one each year to registered dealers. Louisiana resale certificates are valid for one year. An expired certificate makes the supplier's sale taxable on audit even if it was valid when issued. A certificate renewal calendar tied to the delivery states in the manufacturer's distribution network is part of the ongoing compliance work, not a one-time setup task.
Post-Wayfair, economic nexus changes the drop shipment analysis in two ways that manufacturers need to track. First, a manufacturer's own economic nexus footprint determines in which states its wholesale leg is exposed when a retailer cannot produce a valid certificate. Once a manufacturer's sales into a state cross that state's threshold, more than $100,000 of gross sales in Pennsylvania and Indiana, for example, and more than $500,000 of sales for delivery in California, it has nexus there, and the default collector risk attached to that nexus applies to every unregistered retailer it ships for in that state.
Second, some states count wholesale and exempt sales toward the economic nexus threshold, not just taxable retail sales. California's test is total combined sales of tangible personal property for delivery in the state, by the retailer and everyone related to it, that exceed $500,000 in the current or preceding calendar year. Pennsylvania measures gross sales on all channels, including taxable and nontaxable sales, with no transaction count. A manufacturer that ships $400,000 of taxable goods and $150,000 of wholesale exempt goods into California in a year has passed the $500,000 threshold on total sales, even though the exempt portion generated no collection obligation on its own. Nexus can arrive sooner than a review of taxable transactions alone would suggest, which changes how the manufacturer's wholesale leg is analyzed in that state.
Drop shipping across state lines? CereTax sales tax calculation applies ship-from and ship-to rules across states and handles economic nexus thresholds and origin and destination sourcing in the calculation. CereTax SmartExempt stores and manages resale certificates for intermediaries and applies them during calculation. See how CereTax works for manufacturers.
Every generation of technology arrives faster than the tax code can absorb it. Prewritten software took decades to settle. SaaS still has no uniform treatment across the fifty states. Artificial intelligence as a commercial product is moving faster than either, and the compliance implications are landing now, not in three years when guidance catches up.
The fundamental problem is that AI products do not fit cleanly into any category that state tax law was designed to capture. A traditional SaaS subscription involves a customer accessing prewritten software hosted on a vendor's servers. AI products involve a customer accessing a model, a system that generates outputs dynamically based on training data and prompts, which may or may not constitute software in the legal sense depending on whose definition you apply. The customer is not buying a program. They are buying inference, prediction, generation, or automation. States are actively debating whether that is a sale of software, a data processing service, an information service, or an entirely nontaxable professional service, and they are reaching different answers.
For companies selling AI products, this is not a theoretical compliance question. Major AI providers are already collecting sales tax on API usage in states where they have determined a collection obligation exists. The question is whether your product is being taxed correctly in the states where your customers are, and whether your billing system has been configured for a classification framework that is actively evolving. If you have not asked that question yet, the answer is probably sitting in your billing system right now, waiting to be found in an audit.
States do not have AI-specific tax categories. They are applying existing frameworks to new products, and the framework that applies to your AI product depends on how your product is structured and how the relevant state has chosen to classify the closest analog.
Before you can answer whether your AI product is taxable, you need to know which framework a given state uses to evaluate it. That determines everything that follows. The four classification categories that appear most frequently in 2025 and 2026 rulings are prewritten software, data processing services, information services, and nontaxable professional or consulting services. Each carries different taxability consequences. Prewritten software is taxable in roughly half of U.S. states including New York, Pennsylvania, Texas, and Washington. Data processing services are taxable in Texas at 80% of the charge under Tax Code Section 151.0035. Information services occupy a complex middle category in New York, taxable if delivered electronically but exempt if the information is personal or professional in nature. Nontaxable services are exempt in states that do not tax services generally, which covers most states for most service categories.
The classification question for AI is which of these categories the product falls into, and the answer depends on a fact pattern analysis that requires examining what the customer actually receives: access to a software application, the output of a data manipulation process, a tailored informational product, or a service performed by a system that the customer never controls or owns.
The rulings issued in 2025 and early 2026 illustrate the divergence directly and show that identical products can reach opposite conclusions depending on the state.
Indiana issued Revenue Ruling 2025-02-RST in July 2025, addressing the taxability of a generative AI chatbot subscription accessed via web or API. The Indiana Department of Revenue ruled that the service is not subject to sales tax because SaaS is not taxable in Indiana when the customer accesses software remotely without any permanent ownership interest. The ruling extended this logic explicitly to AI: because the AI is accessed electronically with no permanent ownership aspect, it is not subject to sales tax. The true object of the transaction, in Indiana's analysis, is the output generated by the AI, not the software itself.
Kentucky reached the opposite conclusion. Kentucky Tax Facts issued January 20, 2026, states that SaaS is considered a taxable 'prewritten computer access service' in Kentucky, and that this classification applies even with artificial intelligence components. Kentucky is not analyzing whether the AI constitutes software in a traditional sense. It is applying its existing prewritten software access framework to AI-enabled platforms and treating the AI components as part of the taxable access service rather than as a distinct, potentially exempt category.
Illinois presents a split outcome at the state versus local level that is particularly consequential for any company with customers in Chicago. At the Illinois state level, the Department of Revenue examined an AI-powered chatbot in 2025 and ruled that because no software was transferred or owned by the customer, the service is nontaxable under Illinois's general rule that cloud-hosted software accessed without ownership is exempt at the state level. Chicago, however, has imposed its 9% Personal Property Lease Transaction Tax on charges for the use of AI platforms since October 1, 2023. A transaction that is completely nontaxable under Illinois state law carries a 9% Chicago local tax on the same facts.
New York has not issued a specific AI ruling, but the New York Department of Taxation and Finance's existing position under Tax Bulletin ST-128 treats remotely accessed prewritten software as taxable tangible personal property through constructive possession. As confirmed by Moffa Tax Law's 2025 analysis, New York extends this position to AI platforms. If the AI is used primarily to deliver information, it may also fall under New York's taxable information services category. Either way, AI products delivered to New York customers are taxable under existing guidance applied to the technology.
If you sell AI products to Texas customers and have not reviewed your configuration since April 2025, your billing system is probably wrong. Texas does not classify AI as software at all. Instead, it taxes AI inference and related services as data processing under Tax Code Section 151.0035, which covers computerized entry, retrieval, search, compilation, manipulation, or storage of data. Under the Texas Comptroller's April 2025 amendments to Rule 3.330, the scope of taxable data processing services was significantly expanded, and many AI products that were previously treated as nontaxable now fall squarely within it.
The amended rule introduced an ancillary test. If the seller's primary activity constitutes data processing, the entire bundled service charge is taxable as data processing even if other nontaxable components are included. AI inference services, meaning providing predictions, recommendations, or generated content via API, fall within this framework. The tax applies to 80% of the service charge, with a 20% exemption, and the effective combined rate reaches approximately 8.25% when local rates are added. For AI companies bundling inference with professional services or implementation, the Texas rule is clear: the entire charge is taxable unless the AI component is demonstrably ancillary and has no separate value. The burden of proving ancillarity sits with the taxpayer.
Texas's bundling rule adds an important wrinkle for AI companies that bundle inference with professional services, consulting, or implementation. Under the amended Rule 3.330, a data processing service sold for a single charge with another service is not taxable only if the data processing service does not have a separate value and is ancillary to the other service. The burden is on the taxpayer to demonstrate ancillarity. If the AI component is the core deliverable, as it typically is in an AI SaaS product, the entire charge is taxable.
The practical consequence of this divergence is that a single AI product sold to customers across multiple states requires multiple taxability determinations that cannot be resolved by a single classification applied uniformly. An AI chatbot subscription that is nontaxable in Indiana, taxable as prewritten software in Kentucky and New York, taxable as data processing at 80% of the charge in Texas, and taxable at 9% in Chicago but nontaxable at the Illinois state level requires the billing system to classify each transaction based on the customer's location and the applicable state's framework.
AI agents, systems that autonomously execute multi-step business processes, introduce a classification layer beyond subscription chatbots or inference APIs. An AI agent that handles accounts payable, manages customer service queues, or executes procurement workflows is not simply providing software access or generating a text response. It is performing a function that, if performed by a human, would be a nontaxable professional service in most states.
The EverydayCPE analysis of the Indiana ruling makes this question concrete: an AI agent that handles an entire accounts payable function is arguably performing a service, not delivering software. The true object test, which Indiana applied in its chatbot ruling, could support a nontaxable outcome in states that use it. But states that classify by the seller's activity rather than the buyer's intent, as Texas does under its ancillary test, may reach a taxable result regardless of how agentic the workflow is.
No state has issued a ruling specifically addressing AI agents as a distinct product category as of July 2026. The Snell and Wilmer analysis from November 2025 confirms that state and local tax authorities will continue to revisit these issues as AI becomes more embedded in business operations, and that continued administrative and judicial developments will shape how AI is classified across jurisdictions. For companies selling or using agentic AI products, the absence of guidance is not a green light. It is an open classification question that an auditor will resolve using the nearest applicable framework, which may or may not align with how the product is currently being taxed.
The immediate priority is classification, not rate lookup. Most billing systems for AI products were configured either by treating AI as equivalent to standard SaaS, or by applying no tax at all on the assumption that AI outputs are nontaxable services. Both approaches are wrong in a meaningful subset of states, and the state-by-state picture is becoming less favorable to the nontaxable position as more guidance is issued.
The practical steps that define a defensible current position are a state-by-state taxability analysis of your specific AI product, which requires mapping how your product would be classified under each state's existing framework for prewritten software, data processing, information services, and nontaxable services. Texas's data processing framework, Kentucky's prewritten access service classification, and New York's constructive possession standard each require a different fact pattern analysis. A product that is clearly nontaxable in one framework may be clearly taxable in another.
For companies with significant Texas revenue, the April 2025 Rule 3.330 amendments are the most urgent compliance review item. The expanded scope of taxable data processing services and the new bundling ancillary test affect AI products that were previously treated as nontaxable or partially taxable. The effective date of April 2, 2025 means that liability may already be accruing for companies that have not updated their Texas configuration. For companies with Chicago customers, the 9% Personal Property Lease Transaction Tax on AI platforms has been in effect since October 2023, predating most AI compliance reviews. If your billing system is applying Illinois state rates to Chicago transactions involving AI access, it is applying the wrong rate to a separate, higher-rate local obligation.
Does yourAI product have a sales tax problem you have not found yet? State-by-state AI taxability is actively being litigated, ruled on, and revised. The classification your billing system applies today may be wrong in three states by this time next year. CereTax tracks AI and digital service taxability changes in real time, applies the right classification at the transaction level, and gives you the audit trail to defend every decision.
A three-day sales tax holiday can create a three-week compliance headache if the rules are not built into your tax and ecommerce systems correctly.
That is particularly true for firearms, ammunition, and hunting retailers. Mississippi and Louisiana both offer annual Second Amendment sales tax holidays, but the states take different approaches to eligible products, transaction timing, returns, and reporting.
For 2026, Mississippi's holiday ran from August 28 through August 30, while Louisiana's holiday runs from September 4 through September 6. Mississippi also expanded its holiday this year to include firearm safes.
The lesson for retailers is straightforward: a holiday rule should be treated as a transaction-level tax configuration, not a promotional switch.
Both states remove sales tax from qualifying consumer purchases during their respective holiday periods, but their eligible product lists are not identical.
Louisiana's exemption covers firearms, ammunition, and a broad range of hunting supplies, including archery equipment, hunting apparel, hunting footwear, firearm cases and accessories, optics, hearing protection, holsters, slings, and other qualifying hunting gear.
Mississippi's holiday covers firearms, ammunition, and specifically defined hunting supplies. For 2026, the state also added firearm safes to the exempt category.
Neither state applies a price ceiling to qualifying items.
For Louisiana, the exemption applies to consumer purchases, not business or commercial purchases.
That distinction matters for retailers serving both individual customers and commercial buyers. A blanket "tax-free" rule applied to every customer could produce incorrect results.
The biggest risk is assuming that everything associated with hunting or firearms is automatically exempt.
Louisiana's rules, for example, specifically identify qualifying hunting products. They include archery items, hunting apparel, hunting footwear, bags, tools, firearm cases and accessories, range finders, optics, hearing protection, holsters, belts and slings, among other products. But the state also specifically excludes items such as hunting animals, animal feed, off-road vehicles, motor vehicles, heavy equipment, and certain vessels.
Mississippi similarly uses a defined list rather than a broad "anything used for hunting" standard.
That means product classification needs to happen at the SKU level.
A retailer selling both qualifying hunting gear and general outdoor merchandise should not rely on a broad category such as "hunting" or "outdoor equipment" to determine taxability.
This is one of the most important operational issues because the customer may place an order during the holiday but receive it later.
Mississippi's guidance allows qualifying mail, telephone, and internet purchases to receive the exemption when the customer orders and pays during the holiday and the seller accepts the order for immediate shipment. Eligibility can be lost if the customer requests or causes delayed shipment.
Louisiana takes a related approach. Its guidance allows qualifying property ordered for immediate delivery during the holiday to qualify even when shipment or delivery occurs later, provided the customer did not request the delay.
For ecommerce retailers, that means the tax engine needs to evaluate when the qualifying transaction occurred, not simply when the package leaves the warehouse.
Returns can create problems after the tax holiday has ended.
Mississippi distinguishes between exchanging an eligible item for the same item and returning it for credit toward a different product. A qualifying same-item exchange can remain exempt even when it occurs after the holiday. But when the customer uses the credit to purchase a different item after the holiday, sales tax applies to the new purchase.
Louisiana follows a similar distinction. An essentially identical replacement can retain the exemption, while a return followed by the purchase of a different item is taxable. Louisiana also has specific rules for refunds or credits issued within 60 days after the holiday when the customer can show that sales tax was actually paid on the original purchase.
This is exactly the kind of scenario where a simple "holiday = tax free" configuration breaks down.
Retailers also need to think beyond standard checkout transactions.
Mississippi's guidance states that when eligible and non-eligible products are bundled together, the non-eligible items need to be separately itemized and taxed. Otherwise, the entire transaction can become taxable. Mississippi also excludes layaway sales from the holiday.
Louisiana's rules are different. The state allows qualifying property to be placed on layaway during the holiday, as well as final payments on qualifying property previously placed on layaway.
That difference is easy to miss when retailers use the same ecommerce or POS logic across multiple states.
The same promotion does not mean the same tax rule.
The most effective approach is to separate the holiday into four configuration questions:
Product: Is the item specifically eligible?
Customer: Is this a qualifying consumer purchase?
Timing: Did the transaction occur within the state's holiday window under its rules?
Transaction type: Is this a standard sale, online order, layaway, return, exchange, or bundled transaction?
A retailer should test each scenario before the holiday begins rather than relying on a single tax override.
This becomes particularly important for businesses selling across state lines. A single product may be exempt in Louisiana during its September holiday, taxable in Mississippi outside its August holiday, and subject to completely different treatment in another state.
The compliance work does not end when the holiday does.
Louisiana specifically requires retailers to report exempt Second Amendment holiday sales on Schedule A-1 of Form R-1029, using exemption code 5088. Direct marketers have separate reporting requirements and use the same code for qualifying exempt sales.
Retailers should also review:
The last point is easy to overlook. A temporary exemption that remains active after the holiday can create just as much exposure as one that was never activated.
Mississippi and Louisiana may offer attractive tax savings to consumers, but the compliance rules behind those savings are highly specific.
Mississippi's 2026 holiday introduced a new exempt category for firearm safes. Louisiana's holiday covers a broader range of hunting supplies and has its own rules for layaway, returns, exchanges, and reporting. Both states also have no price cap on qualifying products.
For retailers, the safest strategy is to treat each holiday as a state-specific transaction rule.
That means identifying eligible products, configuring the correct dates, testing online and in-store scenarios, and building return and reporting logic into the same workflow.
The tax holiday may last three days.
Your compliance controls need to work before, during, and after those three days.
Ready to take the guesswork out of sales tax holidays? CereTax helps retailers manage temporary exemptions and changing state rules at the transaction level, so product eligibility, timing, customer information, and tax calculation work together.
👉🏻 Book a Strategy Call with CereTax to review your sales tax holiday configuration and reduce the risk of post-holiday corrections.
Most states that tax software and digital services draw a line somewhere: SaaS is taxable, but custom development is not, or digital goods are taxable, but services delivered primarily through human effort are exempt. Washington has never been content with those distinctions, and in 2025 it moved further than any other state to close them.
Washington has taxed SaaS, remote access software, and digital goods broadly since 2010 under its Digital Automated Services framework, treating these products as retail sales regardless of how they are accessed, downloaded, streamed, or subscription-based. The state's base sales tax rate is 6.5%, but local rates push the combined rate to between 6.5 and 10.6% depending on the customer's address, making destination-based sourcing not just a best practice but a legal requirement. On top of that, Washington levies a Business and Occupation gross receipts tax on the same transactions, meaning digital service providers face a dual obligation that no other major state replicates quite the same way.
Then on October 1, 2025, Engrossed Substitute Senate Bill 5814 took effect, and the compliance picture for digital service providers changed materially. Services that were previously excluded from retail sales tax, including IT support, custom software development, digital advertising, data processing, and any service delivered through digital automated means regardless of how much human effort it involved, became taxable retail sales. If your billing system was calibrated before October 2025, it is almost certainly applying the wrong tax treatment to at least some of your Washington transactions.
The Digital Automated Services classification is Washington's primary mechanism for taxing software and digital products, and it is broader than its name implies. Under Washington law, a DAS is any service that is delivered electronically using one or more software applications. The Washington DOR has confirmed that the access method does not change the classification: downloads, streams, subscriptions, and remotely accessed software all qualify. What matters is that the service is transferred electronically and involves software.
SaaS subscriptions, remote access software, cloud-based platforms, and digital goods such as e-books, music, video, and software downloads are all taxable under the DAS framework. A 2026 Washington DOR determination confirmed that professional implementation services and associated travel reimbursements are also subject to retail sales tax when provided exclusively in connection with a DAS, meaning the taxability of the core product extends to time-and-materials charges billed alongside it.
ESSB 5814 significantly expanded what qualifies as a DAS by repealing the exclusion for services involving primarily human effort. Before October 2025, a service that used software as a vehicle but was primarily delivered through human work could avoid DAS classification. That exclusion is gone. Any service that is at least in part transferred electronically using software applications now falls within the DAS definition, regardless of the human contribution. The DOR has provided interim guidance stating that pure professional services, such as legal, accounting, and engineering work, remain subject to service B&O tax rather than retailing B&O, but only where the service does not substantially involve automated delivery. Where automation is central to the product, such as an AI-powered legal research platform billed at a flat rate per response, the DOR has confirmed the service is taxable as a DAS.
Beyond expanding the DAS framework, ESSB 5814 added several discrete service categories to Washington's definition of a retail sale, effective October 1, 2025. Each carries its own sourcing rules and compliance considerations.
IT services became taxable as a catch-all category covering any service that supports or assists information technology infrastructure. This includes network assessments, planning, design, migration, network security, system upgrades, help desk services, onboarding and offboarding support, and software troubleshooting. IT services are sourced to where the services are received by the purchaser, meaning the customer's Washington address governs. Excluded from the IT services category are web hosting, domain registration, and payment processing, which are separately classified.
Custom software development and software maintenance contracts were explicitly added to the taxable base. Previously, custom software occupied an ambiguous position because it was not prewritten software and was not clearly a DAS. ESSB 5814 removed that ambiguity. Advertising services, defined broadly to include the creation, preparation, production, or dissemination of advertisements in digital or non-digital form, are now taxable. This covers graphic design, search engine marketing, and lead generation optimization. The only advertising categories excluded are newspaper, television, radio, and billboard advertising.
ESSB 5814 also extended retail sales tax to temporary staffing services and live presentations including webinars, seminars, and in-person training, categories that are relevant to SaaS companies that bill separately for customer onboarding sessions or training programs delivered outside the core subscription.
Existing contracts signed and executed before October 1, 2025, received a transitional grace period. Providers with pre-existing contracts who had not yet been paid could continue reporting under the prior B&O service classification through March 31, 2026. From April 1, 2026, all gross income received under those contracts must be reported under retailing B&O and subjected to retail sales tax.
One important condition applies: if an existing contract is altered after October 1, 2025, it immediately loses its transitional status and becomes fully subject to ESSB 5814 from that point forward. Alterations include changes to the parties, the underlying activities, rights and obligations, or the term and amount of the contract. Any amendment, even a minor one, ends the transition treatment.
The Washington DOR also launched a temporary ESSB 5814 Penalty Relief Program covering uncollected or unpaid retail sales and use taxes caused by the October 2025 changes. For providers who have not been fully compliant since the effective date, this program offers a path to correct historical gaps without full penalty exposure. Details are available through the Washington DOR.
The compliance burden in Washington is not just about collecting retail sales tax from customers. Digital service providers crossing the $100,000 economic nexus threshold, which is measured against total gross receipts including exempt and wholesale transactions in the current or prior calendar year, are simultaneously obligated to register for and remit Business and Occupation tax. B&O is a gross receipts tax assessed on the provider without deductions for costs or expenses.
ESSB 5814 also restructured B&O rates for service businesses. From October 1, 2025, service businesses are subject to progressive B&O rates based on affiliated group gross income: 1.5% for income below $1 million, 1.75 % for $1 million to $5 million, and 2.1% for income exceeding $5 million. An additional 0.5% surcharge applies to businesses with taxable income exceeding $250 million annually, effective January 1, 2026. Advanced computing businesses face a separate and substantially higher surcharge: effective January 1, 2026, the advanced computing business surcharge increased from 1.22% to 7.5%.
The practical consequence is that a digital service provider selling $500,000 into Washington owes both retail sales tax collected from customers at the applicable local combined rate and B&O tax on that same $500,000 of gross receipts at the applicable progressive rate, paid directly by the provider. Both obligations flow through the Washington DOR's My DOR portal, both require registration using the same Business License Application and Unified Business Identifier, and both are subject to Washington's late filing penalties, which begin at 9% and escalate to 29% by the end of the second month following the due date.
If you sell any form of digital service into Washington and have not reviewed your product catalog against ESSB 5814's October 2025 changes, the immediate priority is classification, not rate lookup. Rates in Washington are determined at the customer address level, and the DOR's Tax Rate Lookup tool provides the address-specific combined rate your billing system needs. But the rate is only relevant once you have confirmed which of your services are now taxable that were not before.
It is also worth noting that effective July 1, 2026, Washington introduced new exclusions and exemptions under ESSB 5814, including new exclusions for certain live presentations and a new sales and use tax exemption for purchases of qualifying retail services by schools and libraries. If any of those categories are relevant to your customer base, a review of the July 2026 changes is warranted alongside the October 2025 framework.
For providers with existing contracts executed before October 1, 2025, the April 1, 2026 deadline to begin collecting and remitting on those contracts under the new rules is either already passed or imminent. Providers who have not updated their billing for pre-existing contracts are now accruing unremitted tax liability on every Washington invoice issued under those arrangements. The DOR has noted it is involved in ongoing legal proceedings regarding ESSB 5814, and has acknowledged that courts will ultimately assess its constitutionality, but under Washington law, statutes are presumed constitutional and the DOR cannot refrain from enforcing them pending that outcome.
One forward-looking development is worth planning around now. In March 2026, Washington enacted additional legislation that partially rolls back ESSB 5814. Effective January 1, 2029, custom software, customization of prewritten software, and IT consulting, training, and support services will no longer be subject to retail sales tax, provided a court of final jurisdiction does not invalidate Washington's income tax before that date. That sunset provision does not reduce current obligations through 2028, but it is a relevant factor for companies making long-term decisions about contract structures, pricing, and system configurations tied to Washington compliance.
Washington's combination of broad DAS taxability, the expanded ESSB 5814 categories, progressive B&O rates, local destination-based sourcing, and aggressive audit enforcement makes it one of the highest-complexity digital tax environments in the country. The businesses managing it well are not the ones that know Washington's rules from memory. They are the ones that have built compliance infrastructure capable of applying those rules at the transaction level, automatically, every time.
Selling digital services into Washington? Your compliance clock is running. Between DAS taxability, ESSB 5814's expanded service categories, dual B&O and sales tax obligations, and local rates that swing up to 10.6% by address, Washington is one of the most complex digital tax environments in the country. CereTax handles Washington sales tax calculation at the transaction level, with real-time rate lookup, product classification logic, and the audit trail your team needs when the DOR comes calling.
👉🏻 Book a Strategy Call with CereTax to review your Washington digital services tax setup and identify potential exposure.
