Avalara AvaTax 3.5.0 is installed on the dev environment and switched off, which is its shipped default. Turning it on gives us correct tax with no development work. Every part of AvaTax a customer can see is written for Magento's old checkout, and we run Hyvä Checkout — so none of it loads. Making all of it work is 18 to 30 developer days, and two things block anyone starting.
Nothing in the first cell has executed. AvaTax needs an account and a licence key we don't hold, so "works" below means theme-independent by mechanism, read out of the module's own wiring — not observed running. That is the single biggest unknown in the estimate.
This is the majority of the product and roughly 91,000 of its lines. None of it cares which theme the storefront uses, because none of it renders anything a customer sees.
| Capability | Why the theme can't affect it |
|---|---|
| Tax calculation on carts and orders | Total collectors in etc/sales.xml — live REST v2 rates, including retail delivery fees |
| Filing data returned to Avalara | Invoices and credit memos post through the queue, on by default |
| Orders blocked when AvaTax is unreachable | PreventOrderPlaceObserver — stops orders booked at the wrong tax |
| Product and customer tax codes | Admin attributes |
| Admin screens, diagnostics, logging, cron | Hyvä replaces the storefront theme only; the admin is untouched |
AvaTax ships 29 JavaScript files and 16 templates for the storefront, every one written against Magento's Knockout checkout. We replaced that checkout with Hyvä Checkout, so they never load. There is no shortcut on the shelf: Hyvä has carried a public request for AvaTax since December 2023 with nothing published, and Avalara archived its public source repository in February 2026.
| Feature | Days | Risk | What we lose by skipping it |
|---|---|---|---|
| Address validation during checkout | 5–8 | High | Customers can enter bad addresses, which is also the main cause of wrong tax |
| Exemption certificates in the customer account | 5–8 | High | Wholesale customers can't upload their own; staff key them into Avalara by hand |
| Address validation in the account address book | 2–3 | Low | Saved addresses go unchecked until checkout |
| AvaTax tax lines in cart and checkout totals | 1–2 | Low | Totals still show tax, without AvaTax's labels and breakdown |
| Electronic invoicing documents for customers | 2–3 | Low | Only matters if we adopt e-invoicing, which is off today |
| Testing across all five storefronts | 2–4 | Low | Not optional if any of the above ships |
| Multi-address checkout validation | 0 | Dropped | Hyvä has no multi-address checkout, so there is nothing to port it into |
| Option | Cost | What it buys |
|---|---|---|
| Calculation only | 2–4 days | Correct tax and automatic filing data. Tidy the totals display, leave validation off. No customer-facing change. |
| Calculation and address validation
recommended
|
8–14 days | The above, plus customers get corrected addresses at checkout. Most of the tax-accuracy benefit sits here. |
| Everything | 18–30 days | Adds self-service exemption certificates, the one item that saves staff time on wholesale accounts. |
I'd take the middle option. Certificates are the joint most expensive item and the only one whose work a person in the office can absorb instead, so they're worth deferring until someone counts how many certificates we actually process in a month.
Found while testing this, unrelated to AvaTax, and it hits every developer. No cart means no way to test tax at all. Our sanitiser writes a plaintext placeholder into an encrypted payment field, and decrypting it produces bytes that break the page. Tracked as issue 378. Dev owns it; it is a small fix.
Nothing above can be confirmed without live API calls, including the claim that calculation works out of the box. Business owns this one, and it is the largest source of error in the day ranges.
Avalara ships this extension through the Adobe Marketplace only and archived its public repository in February 2026. Anything we build for the storefront is a private layer on code we can't watch change in advance, so each AvaTax upgrade needs a test pass rather than a version bump. That argues for building less of it, which is the other reason I lean to the middle option.