Struct Ledger 

pub struct Ledger {
    pub directives: Vec<Spanned<Directive>>,
    pub options: Options,
    pub plugins: Vec<Plugin>,
    pub source_map: SourceMap,
    pub errors: Vec<LedgerError>,
    pub display_context: DisplayContext,
}

A fully processed ledger.

This is the result of loading and processing a beancount file, equivalent to the tuple returned by Python’s loader.load_file().

Fields

directives: Vec<Spanned<Directive>>

Processed directives in source-faithful form: sorted by date, booked (cost specs resolved, interpolations applied), and plugin-rewritten. Pad directives remain as Pad; they are not pre-expanded into synthesized transactions.

Consumers split into two groups:

• Source-faithful consumers (stats, journal, formatter, LSP, BQL FROM #entries WHERE type = 'pad' audits, source-mapped diagnostics) iterate this field directly. Pads count as Pads.
• Balance-computing consumers (holdings, balances, balsheet, networth, income, FFI query.execute/batch, WASM expandPads/query) call Ledger::balance_view to get the directive stream MERGED with synthesized P-flag transactions for each pad-balance pair. This is the only way to get pad effects into per-account inventory math.

The two views are derived from the same source; there is no drift possible because Ledger::balance_view is a pure function of self.directives.

options: Options

Options parsed from the file.

plugins: Vec<Plugin>

Plugins declared in the file.

source_map: SourceMap

Source map for error reporting.

errors: Vec<LedgerError>

Errors encountered during processing.

display_context: DisplayContext

Display context for formatting numbers.

Implementations

impl Ledger

pub fn balance_view(&self) -> Vec<Directive>

Return the directive stream merged with synthesized pad-equivalent transactions, suitable for inventory / balance math.

For each Pad directive followed (in date order) by a Balance assertion on the same account, a Transaction with flag = 'P' is added to the view carrying the postings needed to make the balance match. A multi-currency pad produces one synth transaction per currency.

Original Pad directives are preserved in the view. Synth transactions are added alongside, not in place of. This matters for two reasons:

1. BQL queries against the #entries table (SELECT * FROM #entries WHERE type = 'pad') can still enumerate the pad directives the user authored. A REPLACE-style expansion would silently zero those out. (BQL’s default SELECT path operates on postings; pads have no postings, so a default SELECT never matches them regardless of this view shape.)
2. Multi-pad cases (issue #1300) produce exactly one synth per pad-balance pair: rustledger_booking::process_pads (which merge_with_padding delegates to) only retains the most recent same-account pad in its pending-pads map, so earlier same-account pads are silently shadowed and their source_account does NOT contribute to the synth. The validator emits E2003 for shadowed pads independently; this view reflects only the effective pad.

Inventory-walking consumers iterate Directive::Transaction and ignore Pad directives, so the preserved Pads are invisible to them.

When to use this vs. Ledger.directives: any consumer that maintains running per-account inventory state and asks “what is the balance” needs this view. Any consumer that asks “what did the user write” wants the raw directives field.

Performance

Each call clones every source directive once (O(n)). Inlines the merge logic from rustledger_booking::merge_with_padding so the already- owned booked vector can be moved into the merged output instead of cloned a second time. For short-lived CLI invocations the single clone is negligible. Long-lived processes (FFI servers, LSPs) that query the same ledger repeatedly should hoist the result above their loop. TODO(perf): memoize internally once a benchmark shows it matters.

Trait Implementations

impl Debug for Ledger

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.