Skip to main content

Operating Model

Advanced tax should be run like an operational system, not a one-time configuration exercise.

This page explains how teams should actually manage it over time.

Ownership​

One team or person should own tax behavior inside the platform. That owner does not need to work alone, but someone should clearly own:

  • engine state
  • jurisdiction list
  • rule quality
  • product classification
  • simulator signoff before rollout

Without ownership, advanced tax drifts into a collection of saved fields no one fully understands.

Suggested Workflow​

1. Define Scope​

Decide which jurisdictions matter now.

Do not build a giant theoretical scope. Build the scope the business actually needs.

2. Configure the Engine​

Set the baseline engine behavior before writing specific rules.

3. Record Jurisdictions​

Document where the business is active and where it is only monitoring.

4. Build the Minimum Rulebook​

Add only the rules necessary to support the current business model.

5. Map Products​

Classify the products that matter for live tax behavior.

6. Simulate Real Scenarios​

Run representative checkout cases and review warnings, matched jurisdictions, and tax totals.

7. Enable Live Checkout​

Only after the simulator results align with expected outcomes.

Ongoing Maintenance​

Advanced tax needs regular review whenever:

  • the store enters a new jurisdiction
  • tax treatment changes for shipping
  • products are added that need different classification
  • the pricing model changes from inclusive to exclusive or vice versa

Change Management​

Every change to advanced tax should answer three questions:

  1. what business behavior are we changing?
  2. which jurisdiction or product does it affect?
  3. which simulator scenarios did we run afterward?

If those answers do not exist, the change is not well controlled.

Rollout Strategy​

The safest rollout strategy is staged:

  1. prepare the engine
  2. keep checkout disabled for advanced mode
  3. populate registrations and rules
  4. classify products
  5. run simulator scenarios
  6. enable advanced collection

This is why the engine has a live enable switch instead of assuming every saved rule should immediately affect customers.

  • keep rule names readable
  • keep registrations intentional
  • document why a non-obvious rule exists
  • rerun the simulator after each material change
  • remove stale rules instead of letting the rulebook bloat indefinitely

What Success Looks Like​

A well-operated advanced tax setup has these traits:

  • the engine state is understood
  • active jurisdictions are explicit
  • rules are minimal and readable
  • products are classified intentionally
  • simulated outcomes are reviewed before go-live

That is the standard teams should aim for.