When Integration Breaks Everything · October 09, 2026 · 4 min

ICMS, ST, and NF-e: Where Brazilian Tax Lives in B2B E-commerce

What the public documentation records about tax and what to ask the vendor about Brazil.

A man in a gray sweater reads a document while standing at a desk with a monitor, in an office with wide windows.

Whoever sells between companies in Brazil lives with ICMS (the state tax) by origin and destination state, tax substitution (ST), the taxpayer regime, and the electronic invoice (NF-e). When evaluating a B2B commerce platform, the practical question for the CFO and for the commerce director is where this calculation will live: in the platform, in the ERP, or in an external tax service.

On October 9, 2026, we opened the tax pages of the public documentation of SAP Commerce Cloud, Salesforce B2B Commerce, and Adobe Commerce. On those pages, the public documentation does not describe Brazilian tax localization: there is no mention of ICMS, of tax substitution, or of NF-e. This does not say what each product can do in a project. It says what is documented and, therefore, what needs to be asked.

What each vendor's documentation records about tax

The SAP Commerce Cloud documentation describes the Calculation SPI, which delegates the calculation of price and tax to external services, and records its scope:

limitation recorded in the vendor's documentation on June 23, 2026: the Calculation SPI, which delegates price and tax to external services, covers only the B2C cart without customization, and the B2B flow requires development ("This includes any scenarios outside the standard B2C cart and checkout flow unless additional custom implementation is provided.", https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/e1391e5265574bfbb56ca4c0573ba1dc/20c9ed7bbf6d427a9ab006602be3b637.html?locale=en-US&state=PRODUCTION&version=v2211).

Salesforce's documentation for B2B Commerce describes three paths for configuring the store's tax: the manual solution, the Salesforce tax solution with Stripe, or a custom extension. About the first, the text says that the manual solution suits a simple gross tax situation.

The Adobe Commerce tax documentation records a point about price precision:

limitation recorded in the vendor's documentation on October 8, 2026: prices loaded with more than two digits of precision are rounded to two ("Commerce automatically rounds all prices to two digits", https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/site-store/taxes/taxes).

In the same documentation, the tax guidelines by country cover the United States, Canada, and European countries.

How CWS Platform treats tax

On CWS Platform, tax per item comes from the customer's ERP tax API, before the order closes. The ERP remains the source of the tax calculation.

Three-step flow: the order goes through the price rule with the customer tax profile and queries the ERP tax API before closing.

What the platform does is use the tax profile in the price rule. A price rule can be eligible by ICMS taxpayer status, state registration, CNAE (the business activity code), NCM (the product tax code), and by the pair of origin state and destination state. Price tables, rules, and contracts are configured on the platform or received from the ERP, the CRM, or another system through an API, and in the seller's service the customer's same price rules apply.

question	what the public documentation records	CWS Platform
Where tax is calculated	At SAP, the Calculation SPI delegates the calculation to external services. At Salesforce, the manual solution, the solution with Stripe, or a custom extension.	Tax per item comes from the customer's ERP tax API.
What there is about Brazil	On the tax pages opened on October 9, 2026, the public documentation does not describe Brazilian tax localization.	Price rules eligible by ICMS taxpayer status, state registration, CNAE, NCM, and origin and destination state.
How B2B enters the calculation	At SAP, the Calculation SPI covers the B2C cart without customization, and the B2B flow requires development.	In the seller's service the customer's same price rules apply.

What to ask before signing

If the public documentation does not describe ICMS, tax substitution, and NF-e, the question to the vendor is direct: who calculates Brazilian tax in our project, with which integration, and who maintains that integration when the legislation changes?

Two-panel comparison: on the left, tax calculated in a new development; on the right, tax calculated in the system the tax team already audits.

Will your operation's tax live in a system that your tax team already audits, or in a new development?

When it makes sense to stay in the SAP, Salesforce, or Adobe ecosystem

Nothing above is, by itself, a reason to change platforms. There are scenarios in which staying in the ecosystem is the right decision.

A company already standardized on SAP. When the organization operates under global corporate guidelines and contracts already signed with the vendor, the edition connected to the back end synchronizes master data and invoices in a structured way, on the clean core strategy.

A commercial operation built on Salesforce. When pipeline, territories, and revenue splitting among teams already live in Sales Cloud, keeping commerce in the same ecosystem preserves that design.

A purchasing structure delegated to the customer, on Adobe. When the buyer company needs to manage its own divisions, users, and purchasing roles, the company accounts of Adobe Commerce resolve this natively.

Where to go from here

If your question is still which architecture fits your operation, and not which vendor to choose, the path is the seven questions that separate B2B commerce architectures.