Statutory tax & localisation
Govern a site-bound legal/jurisdiction profile containing registration, fiscal/localisation, effective tax-rule and statutory document-series policy through immutable versions and independent approval.
Screen orientation
Tax Accountants author and submit with finance_localisation:write; different Finance Controllers decide or retire with finance_localisation:approve. Project/Contract, Accountable Executive, Compliance and Auditor readers receive finance_localisation:read. Tenant, assigned site and classification clearance always apply.
The register shows the active definition and full retained version history. Create or replacement panels group legal identity, localisation, tax rules, series constraints and controlled evidence; lifecycle controls act only on the current immutable version.
Field reference
The entries below describe the current screen controls and read-only values. They do not relax server-side validation, site scope, classification handling or required independence in a governed decision.
| Field or value | Control | Required or shown when | How to use or read it | Result |
|---|---|---|---|---|
| Legal entity code / Country / Jurisdiction / Site | Text, country code and select | Required; the tuple must be unique. | Use the accountable legal entity, ISO country code, jurisdiction code and an assigned site. For India GST, use the exact two-digit state/UT code that prefixes the GSTIN. | Creates the stable profile identity and site/classification scope, not a ledger company or transaction. |
| Registration type / number / authority / regime | Text | Required. | Enter only verified legal-registration data and cite the governing authority/regime. India GSTIN formatting and state-prefix agreement fail closed. | Becomes immutable version evidence and is never used to file automatically. |
| Base currency / Locale / Timezone | Text | Required; ISO currency, BCP 47 locale and IANA timezone formats. | Set company-approved operating defaults. The India form starts with INR and en-IN as editable defaults; statutory-date handling requires Asia/Kolkata, while the base/functional currency remains company supplied. | Defines future consumer context without fetching exchange rates or rewriting historical records. |
| Fiscal start / Tax point / Price inclusion | Number and selects | Required. | Record the exact fiscal boundary and whether future pricing is tax-inclusive. Tax point is policy metadata, not a transaction date decision. | Freezes fiscal/localisation policy inside the checksum. |
| Rounding level / Rule / Decimal places | Selects and number | Required. | Choose line/document/component level, half-up/half-even/up/down and the permitted precision from approved policy. | Describes calculation policy only; no amount is calculated here. |
| Place of supply required / Reverse charge enabled | Checkboxes | Required explicit policy choices. | Enable only when future consumers must capture or support these facts. The flags never determine them for a transaction. | Records required downstream controls without creating a tax decision. |
| Tax rule and components | Repeatable form | At least one rule; code unique within the version. | Enter category, direction, supply/collection type, total percentage, dates, authority and named components. Components must equal the total; exempt/zero/out-of-scope totals must be zero. | Creates effective immutable rule configuration, not a tax line or posting. |
| Document series | Repeatable form | At least one type/series pair; unique within the version. | Describe prefix, separator, minimum digits, start, reset, maximum length and authority. India GST statutory series use financial-year reset and fit 16 characters. | Creates a numbering constraint only; no number or document is allocated. |
| Effective from / to | Dates | Required start; optional end. Rule dates must remain inside this period. | Approval activates immediately, so the profile period must include today. Future scheduling is not part of this release. | Controls active-version eligibility without a background scheduler. |
| CLEAN evidence version IDs | Controlled document identifiers | Required for definition, submission and decision actions. | Choose exact same-site evidence within the profile classification. Do not paste filenames or uncontrolled web content as a substitute. | Links immutable evidence snapshots to the exact version and action. |
Actions and effects
When to use: After all validation and evidence requirements pass.
What it does: Creates a new immutable DRAFT and SHA-256 checksum; a replacement never edits prior history.
When to use: Only by its Tax Accountant author while DRAFT.
What it does: Moves the exact checksum to PENDING_APPROVAL and retains submission evidence.
When to use: Only by a different named Finance Controller while pending.
What it does: Approves and immediately activates an effective-current version, or rejects it while retaining history. It performs no tax or accounting transaction.
When to use: Only by an independent Finance Controller with controlled evidence.
What it does: Removes the active definition while retaining the profile/version register; it does not reverse any transaction because none is created here.
Lists and states
- Profile register: legal/jurisdiction/site identity, classification, status and active/current version distinguish usable configuration from draft or retired history.
- Version history: checksum, effectivity, actor names, rule/series counts and decision evidence show exactly what was submitted and approved.
Authority boundary
This screen is configuration authority only. It does not calculate tax, decide transaction facts, allocate statutory numbers, issue invoices/notes, create journals/returns/filings/payments, fetch exchange rates, value inventory or modify Programme, Supply, receipt, stock, ledger or custody truth.