Skip to main content

Jurisdictions

The Jurisdictions tab is where the merchant records the jurisdictions they are active in or still monitoring.

This tab is not about rate math by itself. It is about the merchant’s tax footprint and readiness.

It does not register the business with a tax authority. It records the merchant's own operational status inside eshopOS.

What a Registration Means​

A registration records that a jurisdiction matters to the merchant operationally.

That can mean two different things:

  • the merchant is active and collects there
  • the merchant is monitoring and not yet collecting

This distinction matters because the engine should not treat every known jurisdiction as automatically live for collection.

Why This Tab Exists​

Without registrations, a merchant can create rules in isolation but still lack a clear operational map of where they actually intend to collect.

The registration layer solves that by letting the merchant say:

  • where they are live
  • where they are still tracking thresholds
  • where they are inactive

Core Fields​

Country Code​

The country code identifies the main jurisdiction.

Region Code​

The region code is optional and is used when a country-level entry is not precise enough.

Status​

Status should be used intentionally:

  • active means the jurisdiction is live for collection
  • monitoring means the jurisdiction matters, but collection is not yet fully active
  • inactive means the record is retained but not operationally active

Registration Number​

This field stores the merchant’s own internal or official reference for that jurisdiction when available.

Filing Frequency​

This field is operational metadata that helps the merchant understand the cadence associated with the jurisdiction.

Threshold Amount and Currency​

These fields record the threshold context used for planning and monitoring.

Collect Tax​

This switch determines whether the jurisdiction should actually collect tax, rather than simply remain visible for monitoring.

What Merchants Should Actually Fill​

Not every merchant should create many registrations. The correct question is:

In which jurisdictions do we actively care enough to track status and collection?

For many merchants, the list is short. A short accurate list is better than a long speculative list.

  1. add the primary live jurisdiction first
  2. add secondary jurisdictions only when they matter operationally
  3. keep uncertain jurisdictions in monitoring instead of guessing
  4. enable collection only when the merchant is ready for that jurisdiction

Example Operational Patterns​

One-country merchant​

A one-country merchant may have a single active registration and nothing else. That is a clean, valid setup.

Expanding merchant​

An expanding merchant may keep one jurisdiction active and two others in monitoring while preparing the supporting rules.

Region-sensitive merchant​

A region-sensitive merchant may use country plus region entries when state or province logic matters.

Common Mistakes​

Creating registrations “just in case”​

This makes the system look more complete than it really is. A registration should reflect real operational intent, not theoretical expansion plans.

Marking a jurisdiction active before rules and testing exist​

This creates a false sense of readiness. A jurisdiction should not be treated as ready merely because it appears in the table.

Confusing registration with filing automation​

The registration entry documents scope and collection intent. It does not by itself file taxes or prove compliance.

Best Practice​

Use registrations as the authoritative list of tax-relevant jurisdictions for the store. Keep the list intentional, reviewed, and aligned with actual business operations.

Next Reading​