For years, the standard advice for any software product entering the US market was simple: plug in TaxJar or Avalara and move on. Both are excellent products. Both solve a real problem. And both add a line item to your customer’s bill that can run anywhere from $1,500 to tens of thousands of dollars per year depending on transaction volume.
Monesize Core takes a different position. US sales tax calculation is not a feature that should live outside your financial operations platform. It should be built directly into the transaction lifecycle, the same way invoicing, payments, and accounting are. This article explains how the Monesize Core US Sales Tax Module works, what it covers, what it intentionally does not cover, and why we built it this way.
When a business uses an external tax provider like TaxJar or Avalara, a few things happen that are worth understanding.
First, every invoice or sale triggers an outbound API call to a third-party service. That call costs money, adds latency, and introduces a dependency. If the provider has an outage or you exceed your plan’s transaction limit, your billing workflow is affected.
Second, you are now maintaining an integration. Authentication keys, webhooks, version updates, rate limit monitoring. Someone on your team owns that.
Third, and most importantly for mid-market businesses, you are paying a recurring subscription for a capability that sits adjacent to your core financial system rather than inside it. You cannot see the tax calculation logic in your own platform. You cannot audit it without logging into another dashboard. Your finance team is context-switching between tools.
For US-based businesses with 50 to 500 employees, multiple locations, and a mix of B2B and B2C transactions, this fragmentation has real operational cost. Monesize Core eliminates it.
The Monesize Core US Sales Tax Module is a fully proprietary, self-contained tax engine. It ships as part of the core platform. There is no third-party API call on any transaction. No external subscription. No integration to maintain.
When a business creates an invoice or records a sale, the engine runs automatically in the background and does the following:
It checks whether the US tax module is enabled for that deployment. If it is not, nothing happens. The module is completely invisible. Non-US deployments are never touched by any of this code.
It resolves the customer’s US state from the buyer’s address on the transaction.
It checks whether the seller has nexus in that state. Nexus is the legal concept that determines whether a business is obligated to collect sales tax in a given state. The admin configures nexus states directly from the organization settings dashboard. If the seller does not have nexus in the customer’s state, no tax is applied.
It checks whether the customer is tax-exempt. Businesses, nonprofits, and government entities frequently provide exemption certificates. In Monesize Core, individual customers can be marked as tax-exempt with an exemption reason attached to their profile. If a customer is exempt, the engine returns zero and records the reason.
It checks whether the product category is exempt in that state. SaaS, for example, is not taxable in roughly half of US states. Food and prescription medication carry different treatment. The admin defines product categories and configures exemptions per state per category. If a category is exempt in the customer’s state, no tax is applied.
It looks up the state base rate from the rate table and computes the tax amount.
It stores the result directly on the transaction as a snapshot: the state code, the rate that was applied, the tax amount in minor currency units, and the reason the engine produced that result.
All of this happens before the invoice or sale is confirmed. The person creating the transaction sees a live tax preview showing the state, rate, amount, and reason before they click create. They are never surprised by the number on the final document.
The engine works through a sequential set of checks. Each check can terminate the calculation with a zero result and a clear reason code. Only if all checks pass does the engine compute and apply tax.
The reason codes matter. They appear in the tax preview panel and are stored on the transaction. When a finance team member pulls a transaction six months later and asks why a sale shows zero tax, the answer is already there. It might say “No nexus,” meaning the seller was not registered in that state at the time. Or “Customer exempt,” meaning the customer had a certificate on file. Or “Category exempt,” meaning SaaS was not taxable in that state. This creates a clean, auditable trail without anyone needing to reconstruct the logic after the fact.
The module gives administrators direct control over four things.
State rates. All 50 US states and the District of Columbia are seeded into the platform with current base rates from the Tax Foundation’s 2026 published data. Administrators can update any rate, toggle a state active or inactive, set an effective date, and add notes directly from the rates dashboard. The platform does not require anyone to wait for a software update when a state legislature changes a rate.
Product category exemptions. Categories are free-form and admin-defined. A deployment serving a software company might define “SaaS” and configure it as exempt in the 18 or so states that do not tax remotely accessed software. A deployment serving a retailer might define “Clothing” and configure reduced rates for states like New York that exempt clothing under a certain price threshold. Each category can be set as fully exempt or assigned a reduced rate for a given state.
Nexus states. The organization settings page includes a 50-state checkbox grid. Administrators select the states where the business has sales tax nexus. The engine only calculates tax in states that appear on this list. When the business expands into a new state and crosses the economic nexus threshold, the admin adds the state. No code change required.
Customer tax exemptions. Individual customer profiles can carry a tax-exempt flag and an exemption reason field. This is where reseller certificate numbers, nonprofit status, or government entity classifications are recorded. The engine reads this flag at calculation time.
One of the things we cared about when designing this module was that the person creating a transaction should never be making a financial commitment without seeing what the tax outcome will be.
On both the invoice creation form and the direct sale form, there is a US Sales Tax Preview panel. As soon as the user selects a buyer state and enters line items, the panel updates in real time. It shows the state name, the rate being applied, the computed tax amount in the transaction currency, and the reason the engine produced that result.
If the buyer is in a no-nexus state, the panel says so. If the customer is exempt, it says so. If the category is exempt, it says so. The user can see exactly why the tax is what it is before they confirm anything.
This is not just a convenience feature. It is how you prevent disputes. When a customer calls and asks why their invoice shows sales tax, the answer is already documented in the transaction record. When an auditor asks how tax was computed on a specific invoice, every field they need is on the invoice itself.
Calculating tax is one side of the obligation. Knowing how much you owe to each state at the end of the month or quarter is the other.
The module tracks every taxed transaction by state. The liability report aggregates this data for any date range you specify. It shows, per state, the total taxable sales amount, the total tax collected, and the transaction count. There is a grand totals row at the bottom. The report is exportable and every export is logged in the activity audit.
This is the filing summary your finance team uses when preparing and submitting state returns. The actual submission to state tax authorities is done manually by the finance team using this exported report, which is standard practice for mid-market businesses that do not yet have the volume to justify automated electronic filing.
We believe in being explicit about scope boundaries. The following are known, intentional limitations of the current version, not bugs or oversights.
State-level rates only. The module applies the base state rate. County, city, and special district surcharges are not included. For the B2B-focused mid-market customer, state-level rates cover the majority of tax liability. Many states have no local surcharges at all. For states where local rates are significant, B2B transactions frequently involve exempt buyers or high enough invoice values that the relationship allows for correction. A future version may add ZIP-code-level rate tables.
No automated filing. The module produces filing summary reports. It does not submit returns directly to state tax authorities. Automated electronic filing to state portals requires state-by-state API integrations and is planned as a future capability.
No economic nexus threshold tracking. The engine collects tax in states the admin has explicitly added to the nexus list. It does not automatically determine when the business crosses a threshold and should begin collecting. The admin is responsible for monitoring this and updating the nexus list accordingly. The economic nexus threshold established by the South Dakota v. Wayfair ruling is generally $100,000 in sales or 200 transactions in a calendar year per state, though individual state thresholds vary.
No marketplace facilitator rules. If a business operates as a marketplace facilitator, those obligations are outside the scope of this module.
Category-based taxability, not SKU-level. Tax exemptions are configured per product category per state, not per individual item or SKU. This is the right level of granularity for most mid-market B2B businesses.
The US Tax Module is one module in a platform that already handles invoicing, sales, purchases, expenses, payroll, accounting, inventory, counterparty management, UK VAT and HMRC MTD filing, multi-currency transactions, and more.
The module is fully integrated into the transaction lifecycle. Tax amounts flow through to the invoice totals, which flow through to the accounting journal entries, which flow through to the balance sheet and income statement. Everything is connected. There is no separate tax dashboard to reconcile against your books at month end.
The module is also fully conditional. A UK deployment never sees the US tax engine. There is no US Tax entry in the navigation, no tax preview on forms, no tax fields on customers. The module is invisible unless it is explicitly enabled. A business that starts in the UK and expands to the US does not need a different product. They enable the module in organization settings and configure it.
The Monesize Core US Tax Module is designed for US-based mid-market businesses with 50 to 500 employees, operating across multiple locations or selling into multiple states, primarily in B2B or mixed B2B and B2C markets, selling physical goods and/or services.
It is particularly well suited for businesses that are frustrated by paying a separate TaxJar or Avalara subscription on top of their financial operations platform. Businesses that want their finance team working in one tool. Businesses that want a clean audit trail without patching together logs from multiple systems. And businesses that want a platform that grows with them as they expand into new states, without requiring new integrations each time.
At current TaxJar pricing, a business processing 2,000 or more transactions per month pays over $1,500 per year for tax calculation alone. Avalara pricing for multi-state coverage starts higher. These costs are entirely separate from whatever the business pays for its core financial operations software.
Monesize Core includes US sales tax calculation in the platform. There is no additional line item for tax calculation. When a business adds a new nexus state, they check a box. When a rate changes, they update a number. When a new product category needs to be configured, they add a row. All of this happens in the same dashboard where they manage their invoicing, expenses, payroll, and accounting.
One platform. One subscription. Tax included.
The US Tax Module ships as part of Monesize Core and is enabled per deployment. To get started, a general administrator enables the module in Organization Settings under Tax and Financial, enters the company’s Employer Identification Number, and selects the nexus states. The platform is pre-loaded with all 51 state and district base rates. From that point, every invoice and sale automatically triggers the tax engine.
For businesses migrating from an existing TaxJar or Avalara setup, the transition is straightforward. The rate and nexus configuration mirrors what you already have in your current provider. Category exemptions map directly to the product tax code classifications you are already using. And because everything is stored locally, you are not dependent on any external service being available when you need to process a transaction.