# Domain Model

EntryTarget's domain is built around four core entities that work together to implement double-entry bookkeeping.

## Entity Relationships

```
Transaction (logical group)
    |
    |-- Journal Entry 1 (debit Account A, credit Account B)
    |       |-- Ledger line (debit on Account A)
    |       |-- Ledger line (credit on Account B)
    |
    |-- Journal Entry 2 (debit Account C, credit Account D)
    |       |-- Ledger line (debit on Account C)
    |       |-- Ledger line (credit on Account D)
    |
    ...
```

## Core Entities

### Account

A financial account that holds a balance in a specific asset (currency). Each account has a category, an asset, a balance, and a version that increments on every balance change.

See [Accounts](/docs/concepts/accounts.md) for details.

### Journal Entry

A single debit-credit pair. Moves a specific amount from one account (debit) to another (credit). Belongs to a transaction and carries a sequence number.

See [Transactions & Journal Entries](/docs/concepts/transactions-and-journal-entries.md) for details.

### Transaction

A logical group of journal entries executed atomically. Identified by a `transaction_id` (UUID v7). A transaction can contain multiple journal entries, potentially in different currencies.

There is no `transaction` table — the transaction ID lives in the `journal` table. You query a transaction's journal entries via `GET /transaction/:id`.

See [Transactions & Journal Entries](/docs/concepts/transactions-and-journal-entries.md) for details.

### Ledger

The account statement — every debit and credit line for an account, ordered by `account_version`. The ledger is the complete, ordered history of all movements on an account.

See [Ledger](/docs/concepts/ledger.md) for details.

### Ledger Archive

Compressed historical ledger records. Each archive record holds up to 1,000 ledger lines in a structured array. Used to reduce the size of the live ledger table while preserving full history.

See [Ledger Archive](/docs/concepts/ledger-archive.md) for details.

## Identifiers

All entity IDs are **UUID v7** — sequential by timestamp. This provides:

* **Globally unique** identifiers with no coordination
* **Chronological ordering** — IDs sort naturally by creation time
* **Index efficiency** — B-tree indexes grow in order with minimal fragmentation

## Timestamps

All timestamps are generated by the database (not the application) at the moment of the transaction commit, with millisecond precision. This ensures:

* No clock skew between application and database
* All records in the same batch share the exact same timestamp
* Consistent ordering regardless of application server

{% hint style="info" %}
POST endpoints do not return `created_at` in the response. Use the corresponding GET endpoint to retrieve timestamps.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://entrytarget.gitbook.io/docs/concepts/domain-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.