Skip to content

Chart of Accounts — Proposed Guide

Planned API — Reference Only

Chart 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.

Illustrative query parameters
NameTypeDescription
subsidiary_idstringStable fictional subsidiary reference; not a secret and not evidence that a resource exists.
statusstringProposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success.

Static example requests

Proposed, non-executing request examples
# 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

200 (proposed example)Static response fixture

Fictional documentation data only. No request was sent, record created, review performed, payment initiated or provider connection activated.

JSON
{
  "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.

422 (illustrative; final error contracts are undecided)Proposed error fixture

Synthetic diagnostic example. Human-readable messages must not be used as stable programmatic contracts.

JSON
{
  "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

Illustrative field dictionary
NameTypeDescription
account_idstringStable fictional account reference; not a secret and not evidence that a resource exists.
account_codestringIllustrative account code value; interpret it only within the proposed topic-specific model described above.
namestringHuman-readable example label; stable relationships should use identifiers instead.
subsidiary_idstringStable fictional subsidiary reference; not a secret and not evidence that a resource exists.
statusstringProposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success.