Chart of Accounts — Proposed Guide
Planned API — Reference OnlyChart of Accounts: A proposed account directory would expose authorized account references used in expense coding. Account codes may repeat across…
Overview
A proposed account directory would expose authorized account references used in expense coding. Account codes may repeat across subsidiaries and should not be treated as globally unique ids.
Key concepts
Store account id, code, name and active state. Preserve provider and entity context in mappings.
Implementation considerations
Closed or inactive accounts should not receive new postings. Do not infer tax treatment or ledger type from a display name alone.
Proposed API behavior
GET /v1/accounting/accounts is an illustrative design for this topic. Path and field names may change before implementation. Access would require an authorized organization context and operation-specific permission; no public API or authorization grant is available here.
| Name | Type | Description |
|---|---|---|
| subsidiary_id | string | Stable fictional subsidiary reference; not a secret and not evidence that a resource exists. |
| status | string | Proposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success. |
Static example requests
# Proposed request text only; this reserved host is not a live API.
curl -X GET 'https://api.remizen.example/v1/accounting/accounts?subsidiary_id=sub_example_123&status=draft' \
-H 'Authorization: Bearer YOUR_API_KEY'Fictional response example
Fictional documentation data only. No request was sent, record created, review performed, payment initiated or provider connection activated.
{
"data": [
{
"account_id": "acct_example_123",
"account_code": "account code example",
"name": "Example business unit",
"id": "accounting_example_123",
"organization_id": "org_example_123"
}
],
"pagination": {
"has_more": false,
"next_cursor": null
},
"meta": {
"request_id": "req_example_123",
"reference_only": true
}
}Illustrative error case
Review this failure case in context: Closed or inactive accounts should not receive new postings. Do not infer tax treatment or ledger type from a display name alone.
Synthetic diagnostic example. Human-readable messages must not be used as stable programmatic contracts.
{
"error": {
"code": "validation_error",
"message": "The proposed chart of accounts operation requires review of its input or authorization.",
"request_id": "req_example_123"
}
}Proposed data types
| Name | Type | Description |
|---|---|---|
| account_id | string | Stable fictional account reference; not a secret and not evidence that a resource exists. |
| account_code | string | Illustrative account code value; interpret it only within the proposed topic-specific model described above. |
| name | string | Human-readable example label; stable relationships should use identifiers instead. |
| subsidiary_id | string | Stable fictional subsidiary reference; not a secret and not evidence that a resource exists. |
| status | string | Proposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success. |