Portfolio Accounting System

The instrument master is the foundation. It defines identifiers, asset class, currency, settlement convention, price factor, coupon schedule, maturity, corporate action terms, token precision, issuer, and other reference data. A wrong instrument record can create errors across settlement, valuation, accruals, tax, reconciliation, and reporting. The portfolio accounting system should not treat reference data as passive lookup data. It is part of the accounting control environment.

The transaction ledger records portfolio events. Trades, transfers, subscriptions, redemptions, cash movements, income events, fees, expenses, corporate actions, financing charges, and adjustments enter as source events. Each event should retain provenance: source system, timestamp, raw record, normalized fields, account mapping, instrument mapping, and approval status.

The position engine and cash ledger convert events into state. The position engine calculates holdings by instrument, account, portfolio, lot, and settlement status. The cash ledger tracks settled cash, unsettled cash, receivables, payables, fees, income, currency balances, and funding movements. The system must preserve the difference between expected activity and confirmed accounting state because operations, portfolio management, accounting, and reporting teams rely on different views.

Accrual, valuation, and tax-lot logic make the system more than a transaction store. A fixed-income portfolio requires coupon schedules, accrued interest, amortization, accretion, maturity, and call features. A multi-currency portfolio requires FX rates, local and base currency views, value dates, and revaluation logic. A taxable portfolio requires lot selection, cost basis, wash or adjustment handling where applicable, and realized gain or loss treatment.

The reconciliation layer controls whether the calculated record is trusted. Position reconciliation, cash reconciliation, transaction reconciliation, corporate action checks, price checks, FX checks, and close controls determine whether the system can publish accounting and reporting outputs. The evidence layer records the outcome: matched records, classified breaks, unresolved exceptions, adjustments, approvals, run logs, and close status.

Source ingestion brings in raw events from systems that were built for different purposes. An OMS may send executed trades and allocations. A broker may send confirmations and fees. A custodian may send settled positions and cash. A bank may send payment activity. A pricing source may send marks and FX rates. A corporate action feed may send event terms and election deadlines. A blockchain indexer or custody ledger may send token movement and finality evidence. The accounting system should retain both the raw source and the normalized record.

Normalization turns those sources into a common model. The system maps identifiers, accounts, legal entities, portfolio hierarchies, currencies, time zones, market calendars, sign conventions, settlement dates, and event types. This layer prevents phantom breaks caused by different systems describing the same event in incompatible ways.

State engines then calculate portfolio records. The transaction ledger stores event history. The position engine calculates holdings and lot-level state. The cash ledger calculates settled and unsettled balances, receivables, payables, and currency exposure. The accrual engine calculates income and expense recognition. The valuation layer applies prices and FX. The tax-lot layer preserves cost basis and realized gain or loss logic.

Reconciliation checks the system's internal state against external evidence. A position should agree to custodian, prime broker, administrator, CSD, or on-chain records when timing differences are accounted for. Cash should agree to bank, custodian, settlement, and payment records. Trades should agree to execution, allocation, confirmation, and settlement records. Corporate actions should agree to event terms and entitlement calculations. Breaks should be classified by cause and routed to an owner.

Approval and close controls define when records can be used. Some differences are expected timing differences. Some are material breaks. Some require adjustment. Some require escalation. The system should capture who reviewed the exception, what evidence was used, what adjustment was made, and whether the portfolio was closed with unresolved items.

Outputs should be views of controlled state. The same underlying records can support an IBOR view for expected portfolio state, an ABOR view for confirmed accounting state, a PBOR view for performance reporting, a subledger output for accounting integration, and management or client reports. The system should make the basis of each view clear.

Digital assets and tokenized securities add new architecture requirements. The system must store wallet or custody records, token identifiers, chain identifiers, transaction hashes, finality state, token decimal precision, settlement asset movement, and on-chain evidence. Those fields should join the same accounting architecture rather than sit in a separate ledger that accounting teams have to reconcile manually.