Entries

Entries represent the individual accounting effects associated with an Infrarails transaction.

Each entry connects a transaction to an account and records the debit or credit effect of that financial operation.

Together, entries provide the underlying accounting representation of financial movements.

Understanding entries

A transaction describes the financial operation.

An entry describes how that operation affects a specific account.

For example:

Transaction: Transfer €100.00
             |
             +-- Debit Entry
             |     Account A
             |     €100.00
             |
             +-- Credit Entry
                   Account B
                   €100.00

Both entries belong to the same transaction.

Double-entry accounting

Infrarails uses double-entry accounting principles.

For a balanced financial movement, the total debit amount equals the total credit amount within the applicable accounting context.

The fundamental relationship is:

Total Debits = Total Credits

For example:

Total debits: €250.00

Total credits: €250.00

The transaction is balanced.

Entry properties

Entries are associated with the transaction and account they affect.

Common entry concepts include:

Exact field names and additional attributes depend on the public API schema.

Multiple-entry transactions

A transfer can contain more than two entries.

For example, a transaction could distribute €100.00 from one account to two destination accounts:

The total debit and credit amounts remain equal.

This structure supports accounting workflows involving multiple affected accounts.

Issuance and retirement entries

Infrarails supports ISSUE and RETIRE transaction types.

For these operations, the core processor accepts one submitted entry and normalizes the operation into two accounting entries.

The normalized entry structure maintains consistency with the accounting model.

Applications should use the supported transaction operations rather than attempting to reproduce internal normalization logic independently.

Entry amounts

Monetary amounts use integer minor units.

For an EUR account with currency exponent 2:

Applications must respect the currency exponent when interpreting entry amounts.

Entries and account history

Entries provide the relationship between transactions and individual accounts.

This allows applications to construct account activity histories and support financial reporting.

An account history can include:

• Transaction date.
• Transaction identifier.
• Entry direction.
• Amount.
• Transaction status.
• Reference information.

Where available, statement APIs may provide additional contextual information, including transaction details and running balances.

Entries and transaction finalization

Entries are associated with their parent transaction.

Applications should not assume that the presence of an entry automatically means its financial effect has been finalized.

The transaction's status and the ledger's posting rules determine how its accounting effects should be interpreted.

Best practices

• Treat entries as accounting records associated with transactions.
• Validate transaction balancing requirements.
• Use integer minor units for financial amounts.
• Respect account currencies and currency exponents.
• Do not create direct balance adjustments outside supported ledger operations.
• Preserve transaction and entry identifiers for auditability.
• Use transaction status when interpreting account activity.

Next steps

Continue with Transaction Lifecycle to understand how transactions progress from creation to finalization.