If you sell across US states or into multiple countries, ERPNext's native tax handling runs out of road fast. Core ERPNext expects you to pre-build Sales Taxes and Charges Template records and Item Tax Template rows and attach them by hand or with static rules. That model cannot answer the real question at invoice time: given this exact ship-to address and this item's taxability, what is the correct combined state, county, city and special-district rate today? It has no concept of economic nexus thresholds, no exemption-certificate lifecycle, and no jurisdiction-level breakdown that a filing accountant or auditor will accept. Finance teams end up maintaining spreadsheets, over- or under-charging tax, and hand-assembling returns.

We build a proper Frappe app (its own module, installable via bench get-app / bench install-app) that connects ERPNext directly to Avalara AvaTax — or TaxJar, your choice — as the rating engine. The app hooks the tax lifecycle through hooks.py document events: on validate / before_save of Sales Invoice, Sales Order, Quotation and POS Invoice, a server-side call sends the ship-from and ship-to addresses, customer tax profile and per-line item tax codes to the provider, receives the calculated rates, and writes them back into the standard Sales Taxes and Charges child table plus a jurisdiction-level breakdown DocType so nothing about ERPNext's downstream accounting (GL entries, reports, e-invoicing) has to change. Committed documents call the provider's commit endpoint on on_submit and issue a void/refund on on_cancel, keeping ERPNext and the tax provider reconciled.

Around that core we add the DocTypes and controls a compliance team actually needs: an Address Tax Assignment / nexus registry that records where you are registered and monitors economic-nexus thresholds; an Exemption Certificate DocType linked to Customer, with validity dates, jurisdiction scope and attachment of the signed certificate, so exempt transactions are calculated correctly and evidenced; item taxability mapping (Avalara tax codes / TaxJar categories) at the Item and Item Group level; and a cached rate store plus a scheduler event (via scheduler_events) that periodically refreshes rates and re-checks nexus so a provider outage never blocks invoicing. Return-ready reports and a Query/Script Report roll transactions up by jurisdiction and period to match your Avalara Returns or filing workflow.

Access is governed with Frappe permissions and role profiles (for example a dedicated Tax Manager role for certificates and nexus, versus read-only visibility for sales users), and integration points are exposed as whitelisted methods over the Frappe REST API so an external site, POS or storefront can request a tax quote before an order exists. Provider credentials are stored in a Frappe Single/settings DocType (encrypted fields), and every provider call is logged for audit and troubleshooting. Client scripts surface the jurisdiction breakdown and any calculation warnings directly on the invoice form.

Because this is build-to-order, nothing ships until we agree scope on a short call. We confirm your provider (Avalara vs TaxJar), the transactions and countries in play, your nexus footprint and exemption rules, and your ERPNext version (we support v15 and v16). We then build against a staging copy of your site, run UAT with your real address and item data, and only cut over to production once you have signed off — with a rollback plan in hand. Typical delivery is one working week from confirmed scope, and you receive the full source and git repository so you are never locked in.