RevOps HQ
← BACK TO CASE STUDIES
CASE STUDY8/19/2026

HubSpot–Avalara Integration Case Study: Tax Determination at Quote Time for a SaaS Firm

A software firm quoting tax-exclusive and discovering nexus exposure at invoice. Determination moved to quote time, exemption certificates read before the quote is issued, and the calculation left with the system that owns it.

CLIENT: Calderwood Analytics

Running B2B Software on HubSpot, or thinking about it?

Schedule a consultation

GET WEEKLY REVOPS INSIGHTS

No spam. Unsubscribe anytime.

Summary

Calderwood Analytics sells subscription analytics software into 31 US states, at an average contract value of $28,400. Quotes were issued tax-exclusive with a line reading "tax to be applied where applicable", and the applicable amount was determined by finance at invoice, ordinarily two to three weeks later.

The engagement moved determination to quote time by calling Avalara from HubSpot, read exemption certificates before a quote could be issued, and left every calculation with Avalara rather than reproducing any of it. Quotes requiring a post-acceptance tax correction fell from 23 percent to 2 percent, invoices held for exemption-certificate chasing fell from 14 percent to 1 percent, and the median close-to-invoice interval fell from 17 days to 4.

Background: A Number Decided After the Customer Agreed

The commercial problem was not tax. It was sequence. A customer agreed a figure, and a different figure arrived on the invoice, and the difference had to be explained by whoever was nearest.

Two conditions produced most of it. Economic nexus in a state the firm had recently crossed into changed what was taxable without anyone in sales knowing, and exempt customers who had not filed a current certificate were invoiced as taxable and then disputed it.

Soh and Sia (2004) found that a package embeds a model of how a generic business operates, and that adopting firms must decide deliberately where to change themselves and where to change the system. Calderwood had made no such decision about tax. Avalara held the determination logic and was consulted at invoicing, which put an authoritative answer three weeks downstream of the conversation that needed it.

The Audit

Three weeks against the CRM, the billing system and twelve months of invoice history.

Correction rate. 23 percent of accepted quotes required a tax correction before invoicing, and 6 percent produced a customer dispute.

Certificate coverage. 41 percent of customers claiming exemption had no current certificate on file. The claim lived in a HubSpot text property maintained by sellers.

Nexus drift. The firm had crossed an economic nexus threshold in two states during the period without any change in quoting behaviour, because nothing in the quoting path consulted a nexus position.

Cycle time. Median close-to-invoice was 17 days, of which a median 9 was tax and certificate resolution.

Determination Stays Where It Lives

The central decision was to reproduce nothing. Rates change, thresholds change, and product taxability rules change, and a second implementation of any of them inside HubSpot would likely drift from the first without announcing it. Wand and Wang (1996) treat an information system as a representation of the real world and define a data quality problem as a breakdown in the mapping between the two; two implementations of one rule are two representations of the same thing, and nothing keeps them agreeing except attention nobody has agreed to pay.

HubSpot therefore holds no rate, no threshold and no taxability rule. It holds a determination result and the identifier of the transaction that produced it, requested from Avalara at quote build and again at quote submission.

This is the module boundary Parnas (1972) demonstrated with two decompositions of the same program: one split by processing step, the other hiding each design decision behind an interface so a change touched one module rather than every module. Tax rules are exactly such a decision, and the interface is a request for an answer rather than for the inputs to compute one.

Entities on each side of the boundary, and the key joining each pairOn the left, HubSpot objects: company, contact, deal and line item. On the right, the finance system's customer, contact, invoice and invoice line. Each pair is joined by a named key — a stored external identifier for company to customer, email address for contact to contact, a purpose-built identifier for deal to invoice because no native key exists, and a mapping table for line items. Only the email address existed already; the other three keys had to be created. Company to customer and contact to contact are one to one; a deal may produce several invoices, and a line item several invoice lines.HUBSPOTSYSTEM OF FINANCIAL RECORDJOIN KEYCompanydomain · hs_object_idContactemail · hs_object_idDealamount · closedateLine itemproduct · quantityCustomerdisplay name · idContactemail · idInvoicetotal · due dateInvoice lineitem · quantityquickbooks_customer_id1 : 1email address1 : 1no native key — created1 : Nproduct mapping table1 : NOnly one of these four keys existed already. The three that had to be created are the three that break.
Entities on each side of the boundary and the keys joining them, with determination requested rather than replicated

The Build

Six weeks, four phases, using AvaTax for determination, Avalara CertCapture for exemption certificates, and a private HubSpot app for the calls.

Phase one, address validation. Ship-to and bill-to addresses were validated against Avalara before determination, because determination against an unvalidated address returns an answer with no standing. 12 percent of stored addresses failed validation and were corrected.

Phase two, product taxability. Every SKU was mapped to an Avalara tax code once, in review with the firm's accountant. The mapping is a property on the product record rather than logic in a workflow.

Phase three, determination at quote. A quote requests determination at build and at submission. A difference between the two is shown to the seller rather than resolved silently, which matters when a customer sits on a quote across a rate change.

Phase four, certificates. Exemption status is read from CertCapture, not from the seller-maintained text property. A claimed exemption with no current certificate blocks quote issue and creates a task to collect one.

Outcomes

Correction rate. 23 percent of accepted quotes before, 2 percent after. The residual is dominated by customers changing ship-to after acceptance.

Disputes. Customer tax disputes fell from 6 percent of invoices to 0.4 percent.

Certificate coverage. Customers claiming exemption with a current certificate rose from 59 percent to 98 percent, achieved by blocking issue rather than by chasing.

Close to invoice. Median 17 days before, 4 after.

Address quality. Validated ship-to addresses rose from 88 percent to 99.6 percent.

Finance time. Tax and certificate resolution fell by an estimated 31 hours a month, measured against the prior period's resolution log.

What Resisted

Multi-entity billing resisted. Calderwood invoices from two legal entities depending on contract, and the entity determines the nexus footprint that applies. The quote object carried no entity, and sellers had been choosing it at invoicing by convention.

The mechanism was to make the entity an explicit property on the quote with no default, so a quote cannot be built without one. Making it required rather than defaulted was deliberate: a default would have been correct most of the time, and the failures would have concentrated in exactly the cross-border cases the project existed to fix.

The second difficulty was that determination adds latency to quote build. Sellers noticed. Haug, Zachariassen, and van Liempd (2011) separate the operational cost of working around defective data from the cost of decisions taken on it, and the trade here was explicit: roughly 900 milliseconds at quote build against a median 9 days of downstream resolution. Stating it in those terms is what settled the objection.

Limits

This does not prove determination at quote time suits every seller. Calderwood sells into many states with genuine nexus complexity; a firm selling into one state with a stable product set would carry the same latency for almost no benefit.

The design also assumes Avalara is available at quote time. A determination failure blocks quote issue rather than falling back to an estimate, which is the correct behaviour for a tax figure and a poor one for a seller with a customer on the phone. No degraded mode was built, and that is a real limitation rather than an oversight.

Figures are from the client's invoice history and HubSpot reporting. Nothing here is a controlled comparison, and the period included a pricing change that may have affected dispute rates independently.

Conclusion

The integration is a sequencing decision rather than a technical one. The tax figure existed all along and was simply produced too late to be useful, and moving it earlier required deciding that HubSpot would never compute it.

The general form is that a system which owns a calculation should be asked for the answer rather than for the inputs. Copying the inputs creates a second implementation, and a second implementation is a disagreement waiting for a rate change.

References

Haug, Anders, Frederik Zachariassen, and Dennis van Liempd. 2011. "The Costs of Poor Data Quality." Journal of Industrial Engineering and Management 4 (2): 168–193. https://doi.org/10.3926/jiem.2011.v4n2.p168-193

Parnas, David L. 1972. "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM 15 (12): 1053–1058. https://doi.org/10.1145/361598.361623

Pipino, Leo L., Yang W. Lee, and Richard Y. Wang. 2002. "Data Quality Assessment." Communications of the ACM 45 (4): 211–218. https://doi.org/10.1145/505248.506010

Soh, Christina, and Siew Kien Sia. 2004. "An Institutional Perspective on Sources of ERP Package–Organisation Misalignments." Journal of Strategic Information Systems 13 (4): 375–397. https://doi.org/10.1016/j.jsis.2004.11.001

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479

Conflict of Interest

RevOps HQ is a HubSpot Solutions Partner and was engaged and paid by the client described.

Acknowledgments

Prepared by RevOps HQ.

Schedule a consultation

Thirty minutes, no deck. We look at your portal and tell you what this would involve for a b2b software business — including whether it is worth doing yet.

HubSpot services

Onboarding, implementation, integration, migration, administration and training, each scoped and priced before the work begins

WEEKLY PROGRAM

RevOps Office Hours

A recurring weekly RevOps operating program. Live support plus hands-on HubSpot implementation work.

$1,500/mo
Monthly Operating Program
  • 1 live Office Hours session per week
  • 4 hours of hands-on implementation work per month
  • Hours allocated against priorities agreed at the start of each period
  • Recurring monthly cadence