Approve a pending fiscal period close (Step 2 of 2-person SoD)
Second step of the two-person SoD period close. The approver MUST
be a different principal than the user who called request-close;
the canonical handler enforces this via the api-key’s
created_by_user_id. Transitions the period from
close_requested to ready-to-close so the final close call can
post the locking JE. Requires the accounting:close_period scope.
Authorizations
API key issued per entity via Settings > Developers > API Keys.
Each key carries scopes (e.g. orders:read, products:write).
Bearer token format: Authorization: Bearer ark_live_ent_
Test keys use ark_test_ent_. Both are issued per entity
via Settings > Developers > API Keys.
Headers
Client-generated unique key for idempotent POST/PATCH/DELETE operations. Alias for the Idempotency parameter. Max 255 chars. On retry with the same key, the original response is returned without re-executing the operation. Keys expire after 24 hours.
255Path Parameters
Body
Optional approver note.
Response
Period close approved
An accounting period. Closed periods refuse new journal entry postings (Rule A3). Year-end closing entries that roll revenue and expense activity into retained earnings are posted via a separate explicit endpoint (POST /v1/accounting_periods/{id}/close-fiscal-year). The monthly-period close does NOT by itself post a retained-earnings rollover JE. Verified against live dev RDS accounting.accounting_periods.
Human-readable name (e.g. 'January 2025')
open, close_requested, closed NEW-GAP-REOPEN-PERIOD-ENTITY-ISOLATION-SOD-REASON-AUDIT (2026-05-15): operator-supplied justification from the most recent reopen. 10-500 chars when set. Cleared on next close.
User who most recently reopened this period.

