Territory and Quota Management

The control flow a finance team actually needs.

The ERP surface involved.

Territory definition by ≥3 dimensions (geo, industry, named account); automated lead/account routing on record creation and ownership change; quota entry in currency at account-executive and team-level; prorated quota recalculation on mid-year territory change; attainment = bookings ÷ quota displayed as percentage with trend; quota import via CSV; territory overlap conflict detection; historical quota vs attainment retained when territory is reassigned; manager rollup of team quota and attainment

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Audit evidence is a chain, not a folder.

territory { id: string (terr_*), external_id: string, name: string, rules: array[{ dimension: enum(GEO, INDUSTRY, NAMED_ACCOUNT), values: array }], status: enum(ACTIVE, ARCHIVED) };
quota { id: string (quota_*), external_id: string, territory_id: string, rep_id: string, period: string, quota_amount_minor: int64, currency_code: char(3), prorated: bool };
linked to account, opportunity;
(reference, product may differ).

POST /v1/territories { external_id, name, rules } -> 201 { id, status };
POST /v1/quotas { external_id, territory_id, rep_id, period, quota_amount_minor, currency_code } -> 201 { id };
GET /v1/territories/{id}/attainment?period= -> 200 { attainment_pct, bookings_minor, quota_minor, currency_code };
POST /v1/territories/import (CSV) -> 202;
emits territory.assigned, quota.prorated events;
idempotent via external_id.

Territory: DRAFT -> ACTIVE -> ARCHIVED;
quota: ACTIVE -> PRORATED | COMPLETED;
guard: ARCHIVED territory reassigns accounts before deactivation;
PRORATED quota created automatically on mid-year rep transfer;
attainment computed live from closed-won opportunities.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`territory` { id: string (terr_*), external_id: string, name: string, rules: array[{ dimension: enum(GEO, INDUSTRY, NAMED_ACCOUNT), values: array }], status: enum(ACTIVE, ARCHIVED) }; `quota` { id: string (quota_*), external_id: string, territory_id: string, rep_id: string, period: string, quota_amount_minor: int64, currency_code: char(3), prorated: bool }; linked to `account`, `opportunity`; (reference, product may differ).

`POST /v1/territories` { external_id, name, rules } -> 201 { id, status }; `POST /v1/quotas` { external_id, territory_id, rep_id, period, quota_amount_minor, currency_code } -> 201 { id }; `GET /v1/territories/{id}/attainment?period=` -> 200 { attainment_pct, bookings_minor, quota_minor, currency_code }; `POST /v1/territories/import` (CSV) -> 202; emits `territory.assigned`, `quota.prorated` events; idempotent via `external_id`.

Territory: `DRAFT -> ACTIVE -> ARCHIVED`; quota: `ACTIVE -> PRORATED | COMPLETED`; guard: ARCHIVED territory reassigns accounts before deactivation; PRORATED quota created automatically on mid-year rep transfer; attainment computed live from closed-won opportunities.