Skip to main content

Products & Simulator

This section combines two operational jobs:

  • product tax classification
  • checkout tax validation

They belong together because a rulebook is only as good as the way real products are mapped into it.

Product Mapping​

Product mapping tells the engine which tax code and tax behavior each product should use.

That matters because the engine does not read business intent from a product name. It needs explicit classification.

What the Merchant Should Fill​

For each important product, the merchant should decide:

  • what tax code best fits the item
  • whether the item is taxable, reduced, or exempt

This does not need to happen for every product on day one if the merchant is only piloting advanced tax. But the products that affect live checkout should be mapped before activation.

Simulator​

The simulator lets the merchant generate a backend tax quote without placing a real order.

That is operationally valuable because it allows the team to test:

  • destination changes
  • shipping changes
  • discount changes
  • product mix changes

before live customers are affected.

Why the Simulator Matters​

Advanced tax should not be rolled out purely by inspection of saved fields. The right question is:

When a real basket hits checkout, does the backend return the outcome we intended?

The simulator is how teams answer that question safely.

At minimum, merchants should test:

  1. one standard product in the home country
  2. one standard product in a secondary jurisdiction
  3. one product plus shipping
  4. one discounted basket
  5. one reduced or exempt product if that behavior exists

How to Read the Result​

A good simulation result answers all of these clearly:

  • which jurisdiction was matched
  • whether tax is being collected
  • what the final tax amount is
  • how the line items were interpreted
  • whether any warnings were returned

Warnings are especially important because they often indicate incomplete setup rather than a pure calculation failure.

Common Mistakes​

Treating the simulator as optional​

If advanced tax is live but the merchant never simulated representative baskets, the team is effectively testing on customers.

Mapping only a few products and assuming the rest are fine​

Unmapped products may still fall back to defaults. That may be acceptable temporarily, but it should be an intentional decision.

Ignoring warning messages​

Warnings are part of the decision surface. They usually indicate scope gaps, missing rules, or fallback behavior.

Best Practice​

Run the simulator every time the team changes:

  • engine settings
  • registrations
  • rules
  • product tax mappings
  • shipping assumptions

That discipline turns advanced tax from a configuration screen into a controlled operational workflow.

Next Reading​