Can software decide economic nexus for your clients, and where does it have to stop?

No. Software can count revenue and transactions by state, compare them to a threshold table, and tell you when a client is approaching a line. It cannot decide whether a receipt is sourced to that state, whether the product is taxable there, or whether to register. Those are judgment calls, and registration is close to irreversible.

What economic nexus is, after Wayfair

Before 2018 a state could not make a seller with no physical presence collect its sales tax. In South Dakota v. Wayfair, Inc., 138 S. Ct. 2080 (2018) the Supreme Court concluded that the physical presence rule of Quill was "unsound and incorrect", and held that Quill Corp. v. North Dakota and National Bellas Hess, Inc. v. Department of Revenue of Ill. "should be, and now are, overruled". The law in front of the Court, the opinion records, "applies only to sellers that deliver more than $100,000 of goods or services into South Dakota or engage in 200 or more separate transactions for the delivery of goods and services into the State on an annual basis". States then wrote their own versions of that test. The versions differ in the number, in what gets counted, and in the period you count over.

Thresholds are not one number, and they move

New York requires registration when the cumulative total of gross receipts from sales of tangible personal property delivered into the state exceeded $500,000 and the seller made more than 100 sales delivered in the state, measured over "the immediately preceding four sales tax quarters". The state says plainly that "Both of these conditions must be met during the lookback period" (NY Department of Taxation and Finance). California uses one test, whether "total combined sales of tangible personal property for delivery in California by the retailer and all persons related to the retailer exceed $500,000" in the preceding or current calendar year, and it has no transaction count at all (CDTFA).

And the numbers move. South Dakota, the state that won Wayfair, dropped its own transaction count: "Effective July 1, 2023, the remote seller registration criteria no longer includes the 200 or more transactions threshold" (South Dakota DOR). Any list of fifty thresholds is a dated document, including the one inside your software.

What an agent genuinely does well here

Monitoring. Pull the client's sales by ship to state, roll them forward on each state's own measuring period, compare each state to its stored threshold, and raise an alert at some margin below the line rather than after it. Count what the state counts, which is not always taxable sales. New York defines gross receipts for this purpose as "the amount received for all sales of tangible personal property delivered into New York, whether taxable or exempt, without any deductions for expenses", and sales made through a marketplace are included in the calculation. Do it monthly, and keep the arithmetic in a record someone can reopen a year later. This is boring, high volume, date sensitive counting, the work software does better than people.

Where it stops, first: is this receipt sourced to that state

A ship to address is a proxy for the legal question, not an answer to it. Drop shipments, services performed outside the customer's state, digital goods, resale sales, and a bill to address that differs from the delivery address all break the proxy. California layers district tax on top, so even an in state sale raises a second question, which district rate applies. Put receipts the agent cannot classify into an exceptions queue with a human name against it. An agent that guesses silently produces a threshold number that looks precise and is not.

Where it stops, second: is the product taxable there

Taxability is state by state and category by category, and it does not track the threshold test. Because New York counts exempt sales toward gross receipts, a client can cross a registration threshold on a stream of sales that generates almost no tax. An agent can hold a taxability matrix and apply it consistently, but somebody in your firm owns each cell, and filling one in is giving tax advice. Decide who signs it before you deploy.

Where it stops, third: marketplace facilitator treatment

This is where naive automation fails most often. New York makes the marketplace provider responsible for collecting tax on the sales it facilitates, while the seller still has to "report its sales of tangible personal property facilitated by a marketplace provider on its periodic sales tax returns as nontaxable sales". The seller's relief from liability is conditional, and one of the conditions is holding a properly completed Form ST-150, the certificate of collection, from the provider (NY marketplace guidance). So facilitated sales can push a client over a registration line and produce no tax to remit. An agent that nets marketplace sales out of the count will miss the registration. One that ignores the provider's duty will over collect. Neither error shows up in a dashboard.

Registration is close to a one way door

The alert is not the decision. Registering creates a filing obligation that continues whether or not there is tax to pay. New York tells registered vendors that "Even if your business did not make any taxable sales or purchases during the reporting period, you must file your sales and use tax return by the due date" (NY filing requirements). Registering also fixes a date, which interacts with how you handle prior periods, and that is a planning conversation, not a toggle. The calendar differs by state too. Texas measures its $500,000 safe harbor over the preceding twelve calendar months and starts the collection duty no later than the first day of the fourth month after the month the safe harbor is exceeded. Keep that decision in a partner's hands and log who made it.

The threshold table is the product, and it needs change management

Everything above depends on one maintained artifact: a dated table of each state's current threshold, measuring period, and whether a count applies. It decays. The FTC Safeguards Rule asks for this discipline in 16 CFR 314.4(c)(7), "Adopt procedures for change management", and 314.4(g) requires you to evaluate and adjust the program in light of "any material changes to your operations or business arrangements". Version the table, date every row, link it to the state's own page, and show that date inside the alert. If a state's current threshold cannot be verified, the correct cell contents are "unverified", not last year's number.

Your client's data is leaving the building

If the agent calls an outside model or a third party tax data service, that vendor is a service provider under 16 CFR 314.2, "any person or entity that receives, maintains, processes, or otherwise is permitted access to customer information through its provision of services directly to a financial institution that is subject to this part." That pulls in 314.4(c)(3), "Protect by encryption all customer information held or transmitted by you both in transit over external networks and at rest", with "effective alternative compensating controls reviewed and approved by your Qualified Individual" where encryption is infeasible. Smaller firms get real relief: 314.6 provides that "Section 314.4(b)(1), (d)(2), (h), and (i) do not apply to financial institutions that maintain customer information concerning fewer than five thousand consumers", which removes the written risk assessment, the testing and penetration testing cadence, the written incident response plan and the annual report to the governing body. It does not remove encryption, multi factor authentication, service provider oversight, or the 314.4(j) duty to notify the FTC within 30 days of discovering an event involving at least 500 consumers.

On 7216, consent is available

If the sales data reached you in connection with preparing a client's return, it is tax return information, and making it known to an outside tool is a disclosure. That is not a prohibition. 26 CFR 301.7216-3 sets a consent condition rather than a ban: a preparer "may not disclose or use a taxpayer's tax return information prior to obtaining a written consent from the taxpayer". The order matters, because the consent has to be in place before the data moves. One subsection deserves separate attention if any part of the chain sits abroad. 301.7216-3(b)(4)(ii) permits a US preparer to obtain consent to disclose a taxpayer's SSN to a tax return preparer located outside the United States "only if" that disclosure uses "an adequate data protection safeguard as defined by the Secretary in guidance published in the Internal Revenue Bulletin". Whether a particular AI vendor is a tax return preparer for that purpose is a question for counsel rather than a settled point. Ask where processing happens before you draft the form, not after.

What you type into a public AI platform is not privileged

Firms that work with counsel on a disputed assessment should know about one recent ruling. In United States v. Heppner, No. 25 Cr. 503 (JSR) (S.D.N.Y. Feb. 17, 2026), Judge Rakoff wrote that the ruling "appears to answer a question of first impression nationwide" on whether a user's exchanges with a publicly available AI platform are protected by attorney-client privilege or the work product doctrine, and that "For the reasons that follow, the answer is no." A footnote goes further: "even if certain information that Heppner input into Claude was privileged, he waived the privilege by sharing that information with Claude and Anthropic, just as if he had shared it with any other third party."

Treat that as a rule about your existing files, not only about new text. But do not treat it as settled. The court's own footnote records that it is "unaware of, and the parties have not identified, any case to date that has presented this issue." One district court memorandum binds no other court, no appellate court has spoken, and nobody can tell you how this comes out in your circuit. We have gone through the reasoning, and the opening the court left, in more detail here.

Your WISP probably does not mention any of this

Many firms built their written information security plan from IRS Publication 5708, which says of itself that it is "not intended to replace your own research, to create reliance or serve as a substitute for developing your own plan based upon the specific needs and requirements of your business or firm." That sample document, 29 pages at revision 8-2024, contains zero occurrences of "artificial intelligence" and no standalone "AI". If you adopted it close to verbatim, your plan does not describe the disclosure you are about to start making, which is also a material change to your business arrangements under 314.4(g). Update the plan the week you deploy the agent, not after the first review.

What this means for your firm

Scope the first build as a monitor and nothing more: it counts, it cites the state page behind each threshold, and it routes what it cannot classify to a named reviewer. Keep sourcing, taxability, marketplace treatment and the registration decision with people, and write down who owns each one before the first alert fires. Then fix the paperwork that automation touches, the 7216 consents and the WISP, because those are the two items that turn a sensible tool into an exposure.

Gaper builds and deploys custom production AI agents in your own cloud, and your firm owns the code, the threshold table and the data. We work on exactly this kind of narrow, auditable monitoring problem rather than selling a tax product. For a scoping conversation or for general enquiries, use the contact form on gaper.io.

Book a free AI assessment

Thirty minutes, no commitment. We map one workflow, make the build or buy call, and scope the smallest thing worth shipping.