Account Reconciliation Workflow and Sign-Off

The control flow a finance team actually needs.

The ERP surface involved.

Reconciliation templates assignable to GL accounts with configurable source (sub-ledger pull, manual import, balance feed); auto-population of GL balance from live trial balance; variance calculation as GL balance minus expected balance with drill-through to JEs; configurable materiality tolerance per account; structured reconciling-item register with aging; workflow states: Draft → Submitted → Approved / Returned; due-date tracking per reconciliation per period; reconciliation status roll-up on close dashboard; prior-period comparatives displayed; PDF export of completed reconciliation with approver signature metadata.

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.

account_reconciliation { id: string, entity_id: string, period: string, coa_account_id: string, gl_balance_minor: int64, expected_balance_minor: int64, variance_minor: int64, currency_code: char(3), status: enum, approved_by: string, approved_at: timestamp, external_id: string };
reconciling_item { id: string, recon_id: string, description: string, amount_minor: int64, currency_code: char(3), external_id: string };
(reference, product may differ).

POST /v1/account-reconciliations { entity_id, period, coa_account_id, external_id } -> 201 { id, gl_balance_minor, currency_code };
POST /v1/account-reconciliations/{id}/submit -> 200 { status: SUBMITTED };
POST /v1/account-reconciliations/{id}/approve -> 200 { status: APPROVED };
emits reconciliation.approved event;
idempotent via external_id.

DRAFT -> SUBMITTED -> APPROVED;
alternate path SUBMITTED -> RETURNED -> DRAFT;
terminal APPROVED (locked);
guard: submit blocked if variance_minor > materiality_tolerance_minor;
approve requires Reviewer role.

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.

`account_reconciliation` { id: string, entity_id: string, period: string, coa_account_id: string, gl_balance_minor: int64, expected_balance_minor: int64, variance_minor: int64, currency_code: char(3), status: enum, approved_by: string, approved_at: timestamp, external_id: string }; `reconciling_item` { id: string, recon_id: string, description: string, amount_minor: int64, currency_code: char(3), external_id: string }; (reference, product may differ).

`POST /v1/account-reconciliations` { entity_id, period, coa_account_id, external_id } -> 201 { id, gl_balance_minor, currency_code }; `POST /v1/account-reconciliations/{id}/submit` -> 200 { status: SUBMITTED }; `POST /v1/account-reconciliations/{id}/approve` -> 200 { status: APPROVED }; emits `reconciliation.approved` event; idempotent via `external_id`.

`DRAFT -> SUBMITTED -> APPROVED`; alternate path `SUBMITTED -> RETURNED -> DRAFT`; terminal `APPROVED` (locked); guard: submit blocked if variance_minor > materiality_tolerance_minor; approve requires Reviewer role.