Selecting Accounting

Select ACCOUNTING when every row in a business table should contribute exactly one debit or credit line to the profile’s accounting journal.

Typical source tables include invoice postings, bank movements, cash transactions, payroll entries, and other records where one row represents one accounting movement.

ACCOUNTING is not a visible value stored in a column of that name. It is a table-definition option that expands into a coordinated set of fields and attaches automatic posting behavior to the table.

What appears on the business table

Selecting ACCOUNTING creates these public fields:

Field	What the user supplies	Meaning
name	A short name, at most 10 characters	Groups source rows into one journal
account	A slash-delimited account such as 311/001	Account receiving the movement
tax_point_date	A date	Accounting date and foreign-currency conversion date
debit	A positive money value, or empty	Debit side of this row
credit	A positive money value, or empty	Credit side of this row

Exactly one of debit and credit must be supplied. Supplying both, supplying neither, or supplying a non-positive amount rejects the row.

The ACCOUNTING definition itself carries the currency and rounding used by both money fields. For example, choosing EUR means the generated debit and credit columns are both EUR money values.

The account field is virtual

The client reads and writes a path such as:

311/001

The physical business table stores an internal account_id that references the profile’s managed accounts table. Clients never submit account_id directly. On write, the server resolves the public path to an existing account with the same denomination currency; on read, it converts the ID back to the full path.

The account is required on inserts into an accounting-enabled table.

Reserved generated names

Because ACCOUNTING creates name, tax_point_date, debit, and credit, the table definition cannot separately declare columns with those names. The definition row itself must be named accounting, and a table can contain only one ACCOUNTING definition.

The generated accounting fields cannot be renamed. This keeps automatic posting behavior stable and recognizable across every accounting-enabled table.

What is provisioned for the profile

When the first table creates a profile, the server provisions the accounting foundation for that profile. This happens for every new profile, not only when its first business table selects ACCOUNTING.

Four managed profile tables make up the accounting bundle:

Managed table	Purpose
accounts	Account hierarchy and live projected balances
general_ledger	One row per named journal, including totals and close state
journal_lines	Debit and credit lines belonging to journals
custom_exchange_rates	Optional hand-entered rates maintained through ordinary table data

These are system definitions. Their structure belongs to the accounting backend, so general table-definition operations cannot modify or delete them.

Selecting ACCOUNTING on a business table does not create a separate ledger for that table. It registers the table as another source of lines for the profile’s shared general_ledger and journal_lines.

Accounting metadata outside the profile tables

Some accounting state is deliberately not presented as ordinary profile data. Shared control metadata records:

• which business tables have ACCOUNTING or ACCOUNTING_TRANSFER behavior;
• accounting periods and their predecessor chain;
• frozen book and denomination balance snapshots;
• profile approval;
• opening-balance account mappings;
• foreign-currency conversion evidence.

These records support consistency and auditability. Users work with them through accounting workflows, not by editing their underlying control tables.

From a row to a journal line

Suppose an invoice_posting table contains these rows:

name	account	tax point	debit	credit
INV-42	311	2026-08-09	120.00	—
INV-42	604	2026-08-09	—	100.00
INV-42	343	2026-08-09	—	20.00

Saving the first row creates an open journal named INV-42 if it does not already exist. Each row adds one line to that journal. Because all three rows share the same name and date, they build one balanced journal:

INV-42
├── debit  311    120.00
├── credit 604    100.00
└── credit 343     20.00

total debit  = 120.00
total credit = 120.00
balance      = credit - debit = 0.00

Rows with the same name must also have the same tax_point_date. A journal name is unique within the profile, and an existing closed journal cannot accept another source row.

Open journals may be incomplete

The first saved row can leave a journal unbalanced. This is intentional: related business rows may arrive separately. Balance becomes mandatory only when the journal is closed.

One transaction protects both records

The business row and its accounting effect are committed together.

• If the source row is invalid, no journal line is added.
• If posting fails, the source row is not committed.
• If posting succeeds, the journal totals and account projections are updated in the same operation.

This prevents a saved business record from existing without its required accounting effect.

Updating and deleting source rows

Updating an accounting-enabled row replaces its current accounting effect:

1. the previous source-linked journal line is soft-deleted;
2. the updated row is validated again;
3. a new line is posted with the row’s new revision;
4. affected journal totals and account balances are refreshed.

Deleting the business row soft-deletes its active journal line rather than erasing audit history.

Both actions fail if they would alter a closed journal or an accounting date protected by a closed period. The business-row change is rolled back with the failed accounting change.

Choosing Accounting versus a manual journal

Use an accounting-enabled business table when the journal line should be traceable to a domain record and should automatically follow that record’s insert, update, and deletion lifecycle.

Use a manual journal when the posting itself is the primary record and several lines should be created together without a separate business-table source.

Both paths use the same journals, accounts, totals, period rules, currency conversion, and close protection. Continue with Journals and accounts.

For the whole process in order, see the worked accounting lifecycle.

Continue through the accounting model

• Worked lifecycle follows one example from profile creation to approval.
• Journals and accounts explains posting, balances, account paths, currencies, and mutability.
• Periods and approval explains frozen snapshots and finality.
• Balance carry-forward explains mappings and validated transfer datasets.