Sales tax and VAT software for Salesforce

Only with an outside engine. Salesforce states that if your use case requires tax calculation on the quote, your org must integrate with a third-party tax engine or a custom configuration, and that only AvaTax is available pre-packaged for CPQ. Everything else is a custom integration. Salesforce also treats the result as provisional: quote and order tax are estimates, and Billing performs the final calculation on the invoice. Its own guidance is to calculate quote tax on quotes with subtotals of $1 million or greater, given how much a large tax figure moves the total. Commenda calculates from the ship-to address and the product tax code, so the same number holds from quote to invoice.

For simple, static rates, and Salesforce says so in those words. It recommends the standard engine for simple and static tax calculations such as VAT, strongly recommends it only for simple taxation use cases, and does not support customizations made to its behaviour. Three constraints matter in practice. Salesforce does not provide tax rate data, so you enter and update every rate yourself. It requires a tax rate record for every jurisdiction or address you tax in. And in a multicurrency org it ignores the rate's currency, so a 10% GBP tax rate applies 10% to a USD invoice line too. Commenda maintains the rates instead, across all 50 states and 70+ countries.

No, and it does not present that as its job. Salesforce Billing calculates tax on order products and invoice lines. On its own engine, Salesforce documents reporting as a separate process you handle, and notes that third-party integrations are often where reporting services come from. Remittance is the tax engine's, not Salesforce's: Salesforce states that most tax services use the posted invoice data to remit directly to a governing authority or to drive remittance through reporting, and that external engines ignore unposted transactions. Commenda files across all 50 states on each state's required frequency, files EU VAT with OSS and GST across APAC and Canada, tracks remittance per jurisdiction, and files amendments where a period needs correcting.

Check the legal entity first. Salesforce applies a tax treatment to an order product only when both records have matching legal entities, and states that if they do not match, or if one of the legal entities is null, it does not calculate tax for that order product. A tax treatment and its tax rate must also share a tax code. There is a second trap: an invoice line inherits its parent order product's legal entity and tax at creation, and Salesforce documents that later changes to the order product do not carry over. So a correction made after the fact can look applied and still bill the old figure.

No. Nexus is not a concept Salesforce Billing models. A tax rate is a record you create for a jurisdiction, and tax gets calculated where you created one. Nothing measures whether you should have registered somewhere you have not. Commenda measures your revenue against economic and physical thresholds in all 50 states, every EU member state, and 70+ countries, and notifies you at 80% of a registration threshold rather than after you cross it. Registering everywhere at once is not the answer either, because a registration starts a filing obligation whether or not you owe tax. We run the exposure analysis first and sequence registrations by liability size.

In a meaningful minority of states, yes. Some states include exempt sales when working out whether you have crossed the economic nexus threshold, so you can owe a registration obligation in a state where the underlying sale is not taxable. SaaS taxability itself varies state by state, and within a state by delivery model and customer type. New York is the classic example of a state treating B2B SaaS as tangible personal property. Each SKU is mapped to a product tax code that resolves to the right treatment per state, so a product taxable in one state and exempt in another is handled without you maintaining a 50-state matrix.

Yes, quite a lot. Salesforce documents them as two separate tax processes. CPQ calculates tax on the quote object and can only use an external engine, with AvaTax as the one pre-packaged option. Billing calculates on the order and invoice objects and can use its own internal engine. Tax rules and tax treatments, which is how Billing varies treatment by legal entity, are not part of CPQ at all. The internal engine also caps at 1,000 quote lines per API call. Commenda sits outside both, so the calculation, the exposure history, and the returns do not depend on which of the two you licence.

No engineering work on your side either way. Commenda supports 100+ integrations, with native connectors across accounting, billing, and commerce systems, a REST API for teams that want to call tax directly, and a mapped monthly CSV where no native connector exists. Where a native path is not already in place for your setup, we confirm the supported route rather than assume it works out of the box, and we scope which of your Salesforce records should feed tax before anything is switched on. The API covers calculation by product, tax code, and address, nexus determination, and exemption lookup, and it can be white-labelled so your customer never sees Commenda.