What Is a Sales Tax Integration?
TL;DR
A sales tax integration connects your accounting or ERP system to a service that calculates the correct sales tax on each transaction, and often files returns with each jurisdiction too. Buyers routinely treat calculation and filing as one product, but vendors frequently sell them separately.
A sales tax integration links your financial system to a tax engine that determines the right tax and, in many cases, submits the returns.
Calculation figures out the correct rate at the transaction level, while filing and remittance prepares and pays actual returns to each jurisdiction. These are two distinct jobs.
Calculation happens either in real time on individual transactions or in batches after the fact, and modern integrations calculate in real time.
A tax engine connects to your system in one of three ways: a certified app, a vendor-configured bundle, or direct API calls.
What a sales tax integration is
A sales tax integration connects your accounting or ERP system to a service that determines the correct sales tax and, in many setups, files and pays the returns. The service reads your transaction data, applies the right rate based on where the sale happens and what you sold, and returns the tax owed. Some products stop there. Others carry the numbers through to actual returns filed with each state.
The confusion starts because calculation and filing are two separate jobs that vendors sell separately. Calculation determines the right tax at the moment of sale. Filing and remittance means preparing returns and paying each jurisdiction what you owe. Plenty of buyers assume one product covers both, then discover they still need a filing vendor. The rest of this article works from that split, so start there.
Calculation vs. filing: two different jobs, sometimes two different vendors
Calculation and filing are separate jobs, and buyers routinely treat them as one product when vendors often sell them apart. Calculation determines the correct tax on a specific transaction. It reads the customer's address, the product being sold, and any exemption certificate, then returns a rate or dollar amount for that sale. Filing and remittance is the later work of preparing returns for each jurisdiction, submitting them on the right schedule, and paying what the business owes. A vendor can be excellent at one and not touch the other.
Three patterns show up in the market. Some vendors handle calculation only and leave filing to you or another provider. Stripe Tax is a fair example of the calculation-only pattern. It computes tax at checkout and hands you the numbers, and you own the returns from there. Some vendors do both, but as disconnected steps, sometimes routed through a different team or an outside partner. That handoff is where things get missed, because the group filing your returns works from data it did not calculate and may not fully understand.
The third pattern keeps calculation and filing under one team working from the same transaction data. Taxwire is an example of that unified approach, with transaction-level calculation and filing handled in-house off the same underlying records. When one team owns both, a discrepancy in a return traces directly back to the transactions that produced it, and no data crosses a boundary where context gets lost.
Before you sign with any vendor, ask two questions. Is filing included, or am I buying calculation only? And if filing is included, does the same team handle both jobs, or is there a handoff to a separate group or partner? The answers tell you where responsibility sits when a return is wrong.
Real-time vs. batch calculation
Real-time calculation happens at or immediately after the moment of sale, on the specific transaction, and it is what you should expect from a modern integration. When an order posts, the tax engine reads that transaction's details and returns the correct amount right then. You know the tax was applied correctly before the record moves anywhere else. Batch calculation works differently. It processes transactions in bulk after the fact, often overnight, which creates a lag between the sale and the moment you know the right tax was charged.
Batch tends to show up in older or legacy setups where the accounting system was never built to call a tax engine per transaction. The risk is the gap. If a batch run at 2 a.m. flags a jurisdiction error, the sale already closed hours earlier at the wrong rate, and you are correcting after the customer has been invoiced. Real-time calculation closes that gap by resolving tax while the transaction is still in your hands.
One nuance keeps "real-time" from meaning the same thing everywhere. Some systems calculate the moment a record is saved and show the result immediately. Others calculate on save but only display the amount after you refresh the record. Both are real-time in the category sense, because the calculation runs against the individual transaction rather than a nightly batch, but the timing you see on screen depends on the vendor and the underlying tax engine. Ask a vendor when the number appears, not just whether it is real-time.
The three ways a tax engine connects to your system
A tax engine reaches your accounting or ERP system through one of three methods: a certified or native app, an account customization or bundle install, or a direct API or middleware call. None of the three is better on its own. The right fit depends on which ERP you run, which vendor you pick, and how much configuration help your setup needs before it works.
Certified or native app
A certified app is one the vendor has built and submitted to a specific ERP's app marketplace, where the platform reviews it against its own standards before listing it. That review is what "certified" means. The platform has confirmed the connector installs cleanly and behaves the way its marketplace expects. Because the platform has already vetted it, a certified app is usually self-service. You find it in the marketplace, install it into your instance, and configure it through the platform's normal setup flow without waiting on the vendor's engineers.
The convenience comes with a real constraint. Certification ties the app to a fixed set of behaviors the platform has approved, so a certified connector often supports only certain tax engines or a narrower band of use cases. If your business needs a calculation path the certified app wasn't built to handle, the app can't stretch to cover it, because changing it would break the certification. For a standard setup on a mainstream ERP, that tradeoff rarely bites. For anything unusual, the boundaries of what a certified app allows can become the thing you run into first.
Account customization or bundle install
An account customization, sometimes called a bundle install, puts the vendor's own code and scripts directly into your ERP instance rather than routing through a marketplace listing. The vendor's engineers usually configure it themselves, so this path is rarely self-service. Someone on the vendor's side sets up the scripts, maps them to your fields, and confirms the calculations run correctly inside your specific account.
Taxwire connects to NetSuite this way. A named Taxwire engineer configures the bundle inside your instance rather than handing you a marketplace app to install on your own. The upside of that hands-on approach is reach. Because the code lives in your instance and isn't bound by a marketplace's certification rules, a bundle install can support tax engines and use cases a certified app cannot. If your setup needs a calculation path or a configuration the certified connector doesn't offer, the account-customization route can accommodate it.
The cost is that you depend on the vendor's team to build and maintain it. You don't click install and go. You work with an engineer who sets it up and stays involved when your requirements change. For businesses whose needs sit outside what a packaged app covers, that trade is often worth making.
API or middleware
An API or middleware connection calls the tax engine directly instead of relying on a packaged connector at all. Your system sends each transaction's details to the engine, the engine returns the correct tax, and your software records the result. There's no marketplace app and no bundle sitting inside an ERP. The connection is code you or your developers write against the vendor's API, or a middleware layer that sits between your systems and passes the data through.
This is the flexible option, and it's flexible because you build it. Nothing about the API assumes a particular ERP or billing structure, so it fits situations the other two methods can't reach. If you run custom billing software, or an in-house platform, or any setup where no off-the-shelf connector exists, the API is often the only path that works.
The people who need it are usually the ones without a standard system to plug into. A company on a mainstream ERP will typically reach for a certified app or a bundle first, because those handle the integration work for them. A company that built its own billing stack has no such shortcut, so it calls the tax engine directly and takes on the development and maintenance that come with it. The flexibility is real, and so is the engineering effort required to use it.
What actually determines the tax owed
Three inputs decide the tax a business owes on any given sale, and each one is hard enough on its own to make manual calculation impractical at scale. A tax engine has to resolve all three for every transaction before it can produce a rate or an amount.
Nexus determines where a business is obligated to collect tax at all. A company creates nexus in a state through physical presence like an office or warehouse, or through economic activity once its sales into that state cross a threshold. You only calculate and remit tax where you have nexus, so getting this wrong means either collecting where you shouldn't or missing an obligation entirely.
Jurisdiction determination pinpoints which rates apply to a specific sale, and it usually starts from an address. A single delivery address can sit inside overlapping state, county, city, and special-district taxes that stack into one combined rate. Modern engines resolve this down to rooftop-level geolocation rather than relying on the ZIP code, because two addresses in the same ZIP can fall into different local jurisdictions with different rates.
Product taxability decides whether a given item is taxable and at what rate once the jurisdiction is known. The same product can be fully taxable in one state and exempt in another. Groceries, clothing, and digital goods are common examples where states disagree, and some states apply a reduced rate rather than a full exemption. An engine has to map each product to a taxability category and then apply that category's treatment in each jurisdiction where the sale lands.
Stack those three together across thousands of transactions and dozens of jurisdictions, and the reason businesses connect an engine instead of maintaining rate tables by hand becomes clear.
Pricing models you'll encounter
Vendors price sales tax integrations in three main ways, and knowing which model you're looking at makes comparison easier. Flat pricing charges a set fee per period, often tiered by transaction volume. Per-transaction pricing charges for each calculation or return, so your bill tracks activity directly. Percentage-of-revenue pricing ties the fee to how much you sell, which can climb fast as revenue grows even when your transaction count stays flat.
Each model favors a different kind of buyer, so match it to how your volume and revenue actually move. Taxwire uses flat, tiered-by-transaction-volume pricing, and its cost moves with the number of transactions rather than your revenue. When you compare vendors, confirm which of the three you're being quoted, since a percentage-of-revenue quote and a flat quote can look similar at low volume and diverge sharply later.
FAQ
Do I need a separate filing vendor? Not necessarily, but you have to ask, because calculation and filing are sold separately more often than buyers expect. Some vendors calculate the right tax and stop there, leaving you to file and remit through another provider or your own team. Others handle both, so confirm whether filing is included and whether the same team runs calculation and filing off the same transaction data or hands the work off between groups.
What's the difference between real-time and batch calculation? Real-time calculation determines the tax on a specific transaction at or immediately after the moment of sale, so you know the correct amount was applied right away. Batch calculation processes transactions in bulk after the fact, often overnight, which creates a lag between the sale and confirmation that the tax was right. Real-time is the expectation from a modern integration, though exact timing varies. Some engines calculate the moment a record is saved, and others calculate on save but only show the result after a refresh.
How do I know which connection type my ERP supports? Start by checking your ERP's app marketplace for a certified or native connector, since that path is usually self-service and the simplest to install. If none exists or your setup needs an engine or use case a certified app can't cover, ask the vendor about a bundle or account customization installed directly into your instance and configured by their team. For custom billing software or systems with no packaged connector, you'll likely call the tax engine through an API or middleware. The vendor's implementation team can tell you which methods fit your ERP and how much configuration each one takes. For NetSuite specifically, see the NetSuite-specific guide.