Annual Physical Inventory (Wall-to-Wall Count)

The control flow a finance team actually needs.

The ERP surface involved.

Inventory freeze flag blocks all in/out transactions during the window; freeze/unfreeze requires manager authorization; count sheets generated by location with item/expected-qty hidden for blind counting; support first count, second count, and recount tiers; variance report sortable by value and percentage; adjustment journal posts all variances in a single balanced batch; freeze period snapshot preserved read-only for audit access; duration limit: freeze window must not exceed 72 hours for business continuity; rollback plan if system goes down mid-count.

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.

physical_inventory_freeze { id: string, entity_id: string, warehouse_id: string, initiated_by: string, started_at: timestamp, lifted_at: timestamp, status: enum(ACTIVE,LIFTED) };
physical_count_sheet { id: string, freeze_id: string, location_id: string, item_id: string, first_count_qty: int, second_count_qty: int, final_qty: int, system_qty: int, variance_qty: int };
freeze_snapshot { freeze_id, item_id, location_id, system_qty, captured_at: timestamp, immutable: bool };
(reference, product may differ).

POST /v1/physical-inventory-freezes { warehouse_id, external_id } -> 201 { id, status: ACTIVE };
POST /v1/physical-inventory-freezes/{id}/submit-counts { counts:[{location_id, item_id, qty, count_tier}] } -> 200;
POST /v1/physical-inventory-freezes/{id}/post-adjustments -> 200 { gl_batch_journal_id };
POST /v1/physical-inventory-freezes/{id}/lift -> 200 { status: LIFTED };
emits inventory.freeze_lifted event.

ACTIVE -> ADJUSTMENTS_POSTED -> LIFTED;
guard: freeze duration must not exceed 72 h;
lift blocked until all variance sign-offs complete;
snapshot immutable after ADJUSTMENTS_POSTED.

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.

`physical_inventory_freeze` { id: string, entity_id: string, warehouse_id: string, initiated_by: string, started_at: timestamp, lifted_at: timestamp, status: enum(ACTIVE,LIFTED) }; `physical_count_sheet` { id: string, freeze_id: string, location_id: string, item_id: string, first_count_qty: int, second_count_qty: int, final_qty: int, system_qty: int, variance_qty: int }; `freeze_snapshot` { freeze_id, item_id, location_id, system_qty, captured_at: timestamp, immutable: bool }; (reference, product may differ).

`POST /v1/physical-inventory-freezes` { warehouse_id, external_id } -> 201 { id, status: ACTIVE }; `POST /v1/physical-inventory-freezes/{id}/submit-counts` { counts:[{location_id, item_id, qty, count_tier}] } -> 200; `POST /v1/physical-inventory-freezes/{id}/post-adjustments` -> 200 { gl_batch_journal_id }; `POST /v1/physical-inventory-freezes/{id}/lift` -> 200 { status: LIFTED }; emits `inventory.freeze_lifted` event.

`ACTIVE -> ADJUSTMENTS_POSTED -> LIFTED`; guard: freeze duration must not exceed 72 h; lift blocked until all variance sign-offs complete; snapshot immutable after ADJUSTMENTS_POSTED.