What an auditor checks in a sourcing review
The standard sourcing test runs the same way across CA CDTFA, NY DTF, and TX Comptroller audits.[1][2][3] The auditor selects a sample of transactions from the calculation log, identifies the ship-to address on each, resolves that address against the state's published rate tables for the transaction date, and recomputes the tax that should have been charged. If the rate the engine applied matches the rate the jurisdiction levies at the ship-to address on that date, the line passes. If it does not, the line becomes an exception, and the exception rate is extrapolated across the population to produce the assessment.
The mechanics are easier to describe than to defend. Each transaction carries a rate stack: a state rate, often a county rate, often a city rate, often one or more special-district rates (transit authority, business improvement district, transportation development district, mass transit district). The auditor recomputes every component. A transaction shipped to a Chicago address should carry the Illinois state rate plus Cook County plus the City of Chicago plus the Regional Transportation Authority plus any Special Service Area assessment in effect on the transaction date. A transaction shipped to a rural unincorporated address two miles outside the Chicago city boundary should carry the state, the county, and an RTA component but no city rate. The line items look identical on a Shopify Plus order export. The rate stacks are not.
At TaxCloud, the operator observation across the customer base is that sourcing errors are the quiet six-figure finding. A single misconfigured jurisdiction assignment applies the wrong rate to every order shipping to that area, and at high volume the auditor's extrapolation turns a configuration bug into a population-wide assessment. Brands rarely catch the error in advance because each individual transaction error is small, often a few dollars per order. The audit makes the cumulative version visible all at once when the auditor projects the error rate across the audit population.
The defensive posture is to recompute before the auditor does. Pull the calculation log for a sample of the audit period, run a parallel recomputation against current state DOR rate publications, and identify the gap before the IDR lands. Where the engine carries rooftop-level address resolution across all 13,000+ jurisdictions, the recomputation runs as a query rather than a reconstruction.
Destination versus origin sourcing: the split that catches multi-state brands
The origin-versus-destination distinction trips up brands operating across both. Most states are destination-sourced: the rate is determined by where the buyer receives the product, the ship-to address. In California, the destination-sourcing rule for the local (Bradley-Burns) portion of the tax is set out in Cal. Code Regs. tit. 18, §1802, which determines the place of sale based on which of the retailer's California locations participates in the sale, and treats out-of-state shipment as the default local-tax destination point when no in-state location participates.[4] Texas and Illinois source intrastate sales by origin, meaning the rate is determined by the seller's Texas or Illinois place of business when the order ships within the same state. A brand with a Texas warehouse applies a different rule to a Texas-to-Texas order than to a Texas-to-California order, and the audit checks that the engine got the distinction right.
The treatment splits as follows.
| State category | Sourcing rule | Statute / authority | What the engine must encode |
|---|---|---|---|
| Most states | Destination | SSUTA §310; Cal. Code Regs. tit. 18, §1802; state-specific equivalents | Resolve ship-to address; apply destination rate stack |
| Texas (in-state sellers) | Origin for intrastate; destination for interstate | 34 Tex. Admin. Code §3.334(b); Tex. Tax Code §321.203 [6] | Conditional per shipment leg: same-state apply origin; otherwise destination |
| Illinois (in-state sellers) | Origin for intrastate (Retailers' Occupation Tax); destination for interstate (Use Tax); destination-based sourcing extended to remote retailers and marketplace facilitators effective 2025 | Conditional per shipment leg and per seller type (in-state vs. remote) | |
| Missouri | Partial: destination for state-level sales tax; separate treatment for local components based on whether the sale is shipped from a Missouri seller location | Mo. Rev. Stat. §144.752 [9] | Encode the state-versus-local split per transaction |
For a $20M to $80M Shopify Plus brand with a Texas 3PL, the conditional looks straightforward and is wrong in roughly half of unaudited implementations. The order from a Texas warehouse to an Austin buyer carries the origin rate stack at the warehouse address: state plus the warehouse's county, city, and transit-authority components. The same warehouse shipping to a Phoenix buyer carries the Arizona destination rate. The engine must read both the origin location and the destination state, evaluate whether they are the same state, and select the rule before the rate-table lookup runs. A destination-only implementation produces a Texas state-only rate on the intrastate order, missing the local components that origin sourcing collects, which is the line the auditor finds first.
The audit failure mode at this scale is not a brand misreading the rule. It is a calculation engine encoding only one half of the conditional. Brands with a Texas 3PL added mid-year often discover at audit that the engine continued to destination-source intrastate Texas orders for months after the warehouse opened, because the origin location was not flagged in the engine's configuration when the 3PL came online. The exception rate on that population is uniform and projects cleanly across the period.
Illinois deserves a specific note. Illinois has been shifting its sourcing framework: the Leveling the Playing Field for Illinois Retail Act moved remote retailers and marketplace facilitators to destination-based sourcing, and more recent guidance (effective January 1, 2026) extends destination-based sourcing further within the Retailers' Occupation Tax framework, with a 15% penalty rate applied to sales the retailer cannot source to a specific location.[8] The origin rule for in-state retailers on genuinely intrastate sales still applies in the base case, but the exceptions have grown, and a calculation engine's Illinois configuration needs to be re-verified against current IDOR guidance rather than assumed stable from a prior audit cycle.
TaxCloud calculates across 13,000+ jurisdictions with rooftop-level sourcing through a single integration, applying each state's sourcing rule, destination by default and origin for Texas and Illinois intrastate sales where applicable, without requiring the brand to encode the conditional in its own integration layer.
The SSUTA §310 sourcing hierarchy and where state rules override
The Streamlined Sales and Use Tax Agreement establishes the default sourcing rule across the 23 full SST member states plus Tennessee as associate. SSUTA §310 sets a five-tier hierarchy that the calculation engine walks per transaction:
- Location where the buyer receives the product. For shipped orders, this is the ship-to address. The default rule for the vast majority of ecommerce transactions.
- Location indicated by the buyer's address in the seller's records. Used when the receipt location is not known, for example a downloaded digital good with no shipping leg.
- Location of the buyer's address obtained during the consummation of the sale. Used when the address in records is unavailable.
- Location from which the product was shipped or from which the digital good was first available for transmission. A fallback when none of the above can be determined.
- Location indicated by an address the seller has for the buyer. Final fallback.
For an ecommerce brand, the rule almost always lands at tier 1: the ship-to address. The hierarchy matters for downloadable products, services, subscription renewals with no fresh address capture, and edge cases where the receipt location is genuinely indeterminate, but the calculation engine still has to encode the full sequence and document why a non-tier-1 rule applied on any given transaction. An auditor reading the calculation log will notice if a transaction sourced under tier 3 or tier 4 cannot be explained.
State-specific rules override the SSUTA default for in-state sales in non-SST states. Texas (origin for intrastate, per 34 Tex. Admin. Code §3.334), Illinois (origin for the Retailers' Occupation Tax under 35 ILCS 120, per Publication 113, with the destination-based exceptions noted above), and Missouri (the partial split under Mo. Rev. Stat. §144.752) are the three to track at this scale. SSUTA also permits member states to elect "origin-based" sourcing for intrastate sales under §310.1, but no full member state currently applies that election broadly to remote sales.[5]
The engineering implication is that a clean SSUTA implementation is not sufficient. The engine must hold a state-by-state sourcing matrix that knows when the SSUTA hierarchy applies and when a state-specific override takes precedence. Encoding the hierarchy without the overrides produces destination-sourced rates on Texas-to-Texas and Illinois-to-Illinois orders, which is the failure mode the audit detects when the state's own DOR rate publication says otherwise.
For brands operating across the full 50-state footprint, the matrix is 23 SSUTA full-member states plus Tennessee as an associate participant, the non-SST destination states applying their own destination equivalents, three non-SST states with explicit overrides (Texas, Illinois, Missouri), and five states with no general sales tax. Holding that matrix in spreadsheets is where errors accumulate quietly until an audit projects them across the population.
Where calculation engines fail in sourcing reviews
The calculation engine is the audit's real target in a sourcing review. The auditor is not checking the brand's intent. The auditor is checking whether the rate the engine selected matches the rate the ship-to jurisdiction actually levies. Four engine failure modes recur across audits at the $20M to $80M band.
1. Misconfigured jurisdiction boundaries (the Chicago/Cook County rooftop problem). A ZIP code is not a tax jurisdiction. ZIP 60622 in Chicago covers addresses inside the City of Chicago and addresses in unincorporated Cook County that fall under the RTA but not the city. An engine that resolves to ZIP centroid rather than rooftop applies the same rate stack to both, which is wrong roughly six percent of the time in dense urban overlap zones according to DOR sample reviews. The fix is rooftop-level address resolution, not centroid-level. The Cook County, Denver, and Anchorage borough rate components are the canonical examples; the same problem exists in any market where city limits and ZIP boundaries diverge.
2. Stale rate tables. Local rates change quarterly in most states. An engine that updates its rate tables on a manual or monthly cadence will carry a stale rate for some portion of every quarter. The auditor pulls the state's rate publication for the transaction date and recomputes. A transaction processed on April 3 using the January rate table fails on a rate that changed April 1. At ten thousand orders per month on a stale table, the assessment compounds through the entire quarter before the fix lands.
3. Address-validation failures producing wrong-jurisdiction assignment. A buyer types "1234 Main St" without specifying Apt 4B in a building that straddles two cities. The engine validates the street segment to the wrong city, applies that city's rate, and ships the order. The exception surfaces months later when the auditor pulls the calculation log and notices the rate does not match the building's actual jurisdiction. Address validation against USPS Delivery Point Validation (DPV) and not just street-level standardization is the precondition for defensible sourcing.
4. Missing special-district overlays. A transit authority, business improvement district, transportation development district, or mass transit district overlays the state, county, and city rates with an additional rate component. Brands integrating with calculation APIs that return only state, county, and city components miss the overlay entirely, undercollecting on every transaction inside the district. The fix is engine-level coverage of every special-district rate component, refreshed on the publication cadence the state uses.
TaxCloud's reporting API exports the per-transaction jurisdiction assignment alongside the rate components applied, in the same field structure the auditor will recompute against. Each line carries the resolved jurisdiction code, the rate-table version applied at calculation time, the state, county, city, and special-district components, and the address-resolution method. The auditor reconciling against this output reads four hops per transaction: address, jurisdiction, rate-table version, rate components. Each hop is a separately verifiable record.
The calculation log as the audit's real target
In a sourcing review, the auditor's primary document request is the calculation log: the per-transaction record showing the jurisdiction assigned and the rate applied. It is the document that wins or loses the sourcing audit because it is the only record that ties the order to the rate decision the engine made at the moment of checkout.
The auditor's recomputation runs against three columns from the log: the ship-to address (or its normalized jurisdiction code), the rate applied, and the transaction date. The auditor pulls the state's rate publication for the date, resolves the address through the state's own address-to-rate tool where available (TX Comptroller offers one, IL DOR offers another, CA CDTFA's rate lookup map covers California), and compares.[11] A match closes the line. A mismatch flags it for analysis.
A defensible calculation log carries the following per-transaction fields at minimum:
- Transaction date and timestamp
- Ship-to address (street, city, state, ZIP+4 where available)
- Resolved jurisdiction code (state, county, city, special-district codes)
- Rate components (state rate, county rate, city rate, special-district rates)
- Total rate applied
- Tax computed
- Sourcing rule applied (destination, origin, or SSUTA tier number)
- Rate-table version in effect at calculation time
- Address-resolution method (rooftop, ZIP+4, centroid)
The rate-table version field is the one most engines omit and the one the auditor most often asks for in a sourcing review. State DOR rate tables change quarterly; the auditor needs to confirm that the rate applied on a March 28 transaction reflects the rate table in effect on March 28, not the version current when the report was generated. Without the version field, the brand cannot prove which rate publication the engine read against, and the auditor reads the gap into the worst-case interpretation.
For brands running the calculation through TaxCloud, the per-transaction jurisdiction-assignment log is exposed through the reporting API with the rate-table version and address-resolution method preserved per line, in the same format the auditor will recompute against.
What the production-ready operating model looks like
A brand at the $20M to $80M band running on Shopify or Shopify Plus across three or four channels has the volume to make sourcing errors compound and rarely has the in-house engineering bandwidth to monitor the engine's accuracy quarterly. Brands below the mid-market band rarely hit the volume where sourcing errors compound into a material assessment. Mid-market volume does. The operating model that holds at this scale carries three properties.
Sourcing decisions are encoded, not interpreted. The state-by-state sourcing matrix lives in the calculation engine's configuration, refreshed against state DOR publications on the state's cadence. The controller does not interpret 34 Tex. Admin. Code §3.334 monthly. The engine encodes it once and applies it per transaction.
The calculation log is exportable on demand. Whoever owns the audit response (the controller, the staff accountant, the platform engineer) can pull a dated calculation log for any state, any period, any sample size, in under an hour. The log carries the resolved jurisdiction, the rate components, the sourcing rule applied, and the rate-table version per line.
Quarterly recomputation is a standing process, not an audit-response scramble. A parallel recomputation against the current calculation log runs every quarter on a sample of high-volume jurisdictions. Variance above a defined threshold (0.1 percent is a defensible upper bound) triggers root-cause analysis before the next filing. The pre-audit posture is identical to the audit posture, which is what makes the audit close at the field-auditor level rather than escalate.
The reader here is past wondering whether sourcing matters. The brand has the warehouse footprint, the multi-channel volume, the calculation engine. The question is what the layer underneath looks like when the IDR lands and the auditor asks for the calculation log keyed to a sample of one thousand transactions across six states. TaxCloud is built for that calculation-and-evidence layer: 13,000+ jurisdictions with rooftop-level sourcing through one integration, the per-transaction jurisdiction-assignment log exposed through the reporting API in the field structure the auditor recomputes against, and consolidated SST filing across the 23 full member states plus Tennessee as associate with the calculation record keyed to each filed return.