Flux and Variance Analysis with Commentary

The control flow a finance team actually needs.

The ERP surface involved.

Automated flux report generation on close completion comparing actual vs. prior period, prior year, and budget; configurable materiality threshold (absolute and percentage) per account or account group; mandatory commentary flag for accounts exceeding threshold; rich-text commentary editor with character limit and structured driver tags (volume / price / timing / one-time / reclassification); workflow states: Pending Commentary → In Review → Approved; due-date enforcement with escalation; commentary stored per account per period with version history; commentary included in management pack export; API to pull flux data for downstream reporting tools.

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.

flux_analysis_item { id: string, entity_id: string, period: string, coa_account_id: string, actual_minor: int64, prior_period_minor: int64, budget_minor: int64, variance_minor: int64, variance_pct: decimal, currency_code: char(3), commentary_required: bool, status: enum, external_id: string };
flux_commentary { id: string, item_id: string, text: string, driver_tags: []string, version: int, approved_by: string, external_id: string };
(reference, product may differ).

POST /v1/flux-analyses { entity_id, period, materiality_minor, currency_code, external_id } -> 201 { id, items[] };
PUT /v1/flux-analyses/{id}/items/{item_id}/commentary { text, driver_tags } -> 200;
POST /v1/flux-analyses/{id}/approve -> 200 { status: APPROVED };
emits flux.commentary_approved event;
idempotent via external_id.

PENDING_COMMENTARY -> IN_REVIEW -> APPROVED;
guard: IN_REVIEW transition blocked if any flagged item has no commentary;
APPROVED locks commentary;
management pack export blocked until status is APPROVED.

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.

`flux_analysis_item` { id: string, entity_id: string, period: string, coa_account_id: string, actual_minor: int64, prior_period_minor: int64, budget_minor: int64, variance_minor: int64, variance_pct: decimal, currency_code: char(3), commentary_required: bool, status: enum, external_id: string }; `flux_commentary` { id: string, item_id: string, text: string, driver_tags: []string, version: int, approved_by: string, external_id: string }; (reference, product may differ).

`POST /v1/flux-analyses` { entity_id, period, materiality_minor, currency_code, external_id } -> 201 { id, items[] }; `PUT /v1/flux-analyses/{id}/items/{item_id}/commentary` { text, driver_tags } -> 200; `POST /v1/flux-analyses/{id}/approve` -> 200 { status: APPROVED }; emits `flux.commentary_approved` event; idempotent via `external_id`.

`PENDING_COMMENTARY -> IN_REVIEW -> APPROVED`; guard: IN_REVIEW transition blocked if any flagged item has no commentary; APPROVED locks commentary; management pack export blocked until status is APPROVED.