Skip to main content
POST
Reopen a closed accounting period

Authorizations

Authorization
string
header
required

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.

Path Parameters

id
string<uuid>
required

Body

application/json
reason
string
required

Operator-supplied justification (SOX-grade audit trail; required). 10-500 chars.

Required string length: 10 - 500
Example:

"Q1 inventory recon required reposting of adjusting JE for COGS reclass."

acknowledge_old_period
boolean
default:false

Required true when the period ended more than 180 days ago. Defaults false.

sod_override_authorized_by
string<uuid>

The user id of the person who AUTHORIZED an override of guard 5 (Segregation of Duties). Supply it when the caller is the same human who requested or approved the original close and no second party is available. The ACTING user is unchanged and every audit row still names the human who performed the reopen; this field names who authorized it. Validated FAIL-CLOSED against a live ACTIVE membership on THIS entity carrying accounting.close_period, so a viewer cannot authorize and a member of another entity cannot (Layer 1); anything unresolvable is a refusal, never a silent downgrade to "no override". The authorizer MAY be the acting user, which is deliberate: a single-owner entity has no second party to offer, and a guard that can only be satisfied by naming someone who authorized nothing would force a false audit row. Every use writes a PERIOD_REOPEN_SOD_OVERRIDDEN activity row beside the ordinary PERIOD_REOPENED one and stamps the override into the persisted reopen_reason. Omit it and the 403 sod_self_reopen_forbidden envelope is byte-identical to the one shipped before this field existed, so no existing caller changes.

Response

Period reopened

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.

id
string<uuid>
read-only
entity_id
string<uuid>
read-only
period_name
string

Human-readable name (e.g. 'January 2025')

start_date
string<date>
end_date
string<date>
status
enum<string>
read-only
Available options:
open,
close_requested,
closed
closed_by
string<uuid> | null
read-only
closed_at
string<date-time> | null
read-only
close_requested_by
string<uuid> | null
read-only
close_requested_at
string<date-time> | null
read-only
close_approved_by
string<uuid> | null
read-only
close_approved_at
string<date-time> | null
read-only
reopen_reason
string | null
read-only

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.

reopened_by
string<uuid> | null
read-only

User who most recently reopened this period.

reopened_at
string<date-time> | null
read-only
created_at
string<date-time>
read-only