Finance Lease Recognition under ASC 842 / IFRS 16

The control flow a finance team actually needs.

The ERP surface involved.

NPV calculation uses effective interest method with IBR or implicit rate; payment schedule supports variable payments (CPI-indexed) with remeasurement triggers; system maintains full amortization table with opening balance, interest accrual, payment, and closing balance per period; separate GL accounts for ROU asset, accumulated amortization, lease liability current, and lease liability non-current; dual-standard support (ASC 842 and IFRS 16 in parallel books); commencement journal and each period's entries are atomic ACID transactions; disclosure report auto-generated for financial statement footnotes.

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.

leases { id: string, external_id: string, entity_id: string, lease_type: enum(FINANCE,OPERATING), standard: enum(ASC_842,IFRS_16), commencement_date: date, end_date: date, ibr: decimal, rou_asset_minor: int64, lease_liability_minor: int64, currency_code: char(3), status: enum(ACTIVE,MODIFIED,TERMINATED) };
lease_amortization_schedule { id: string, lease_id: string, period_date: date, opening_liability_minor: int64, interest_accrual_minor: int64, payment_minor: int64, principal_reduction_minor: int64, closing_liability_minor: int64 };
(reference, product may differ).

POST /v1/leases { entity_id, lease_type, standard, commencement_date, end_date, ibr, payment_schedule: [{date, amount_minor, currency_code}], residual_value_guarantee_minor, external_id } -> 201 { id, rou_asset_minor, lease_liability_minor, currency_code, amortization_schedule_id };
GET /v1/leases/{id}/amortization-schedule;
GET /v1/leases/{id}/disclosure-report;
emits lease.recognized event;
idempotent via external_id.

DRAFT -> ACTIVE;
ACTIVE -> MODIFIED (remeasurement);
ACTIVE -> TERMINATED;
terminal TERMINATED;
guard: ACTIVE requires commencement_date, ibr, at least one payment schedule entry, and lease_type classification.

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.

`leases` { id: string, external_id: string, entity_id: string, lease_type: enum(FINANCE,OPERATING), standard: enum(ASC_842,IFRS_16), commencement_date: date, end_date: date, ibr: decimal, rou_asset_minor: int64, lease_liability_minor: int64, currency_code: char(3), status: enum(ACTIVE,MODIFIED,TERMINATED) }; `lease_amortization_schedule` { id: string, lease_id: string, period_date: date, opening_liability_minor: int64, interest_accrual_minor: int64, payment_minor: int64, principal_reduction_minor: int64, closing_liability_minor: int64 }; (reference, product may differ).

`POST /v1/leases` { entity_id, lease_type, standard, commencement_date, end_date, ibr, payment_schedule: [{date, amount_minor, currency_code}], residual_value_guarantee_minor, external_id } -> 201 { id, rou_asset_minor, lease_liability_minor, currency_code, amortization_schedule_id }; `GET /v1/leases/{id}/amortization-schedule`; `GET /v1/leases/{id}/disclosure-report`; emits `lease.recognized` event; idempotent via `external_id`.

`DRAFT -> ACTIVE`; `ACTIVE -> MODIFIED` (remeasurement); `ACTIVE -> TERMINATED`; terminal `TERMINATED`; guard: ACTIVE requires commencement_date, ibr, at least one payment schedule entry, and lease_type classification.