Skip to content

Last reviewed: 2026-08-13 Accepted decisions: - ../decisions/accepted/0020-initial-release-scope-and-financial-workflow-taxonomy.md - ../decisions/accepted/0024-operational-summary-workflow-boundaries-and-purchasing-facts.md - ../decisions/accepted/0026-initial-release-single-currency-boundary.md - ../decisions/accepted/0029-cross-workflow-accounting-event-identity.md - ../decisions/accepted/0034-sales-tax-accounting-and-remittance-boundary.md

Banking and Finance Summary Fact Contract

Purpose and ownership

This contract defines the provider-agnostic Banking and Finance Summary boundary used to validate, explain, prepare, reconcile, and later persist accepted cash, bank, credit-card, clearing, statement-match, and closing-balance results.

The operational finance system owns bank-feed rows, payment instruments, deposit composition, card transaction detail, reconciliation execution, statement files, and operational matching. BooksPlus owns accepted accounting event identity, workflow review, account-role templates, relationship and allocation validation, period control, posting, audit, and reconciliation to posted ledger balances.

BooksPlus does not create a bank, cash, or credit-card subledger. Detailed statement and reconciliation rows remain in versioned operational manifests referenced by Source Documents.

Canonical objects

  • BankingAndFinanceFact
  • FinanceSettlementAllocation
  • FinanceDirectComponent
  • FinancePreparedReconciliation
  • FinanceStatementMatchResult
  • FinanceAccountReconciliationResult
  • FinanceAccountReconciliationLine
  • FinanceSalesTaxRemittanceMatchResult

Fact types and source-event stages

Fact type Source-event stage Posting meaning
finance_receipt_clearing_settlement receipt_clearing_settled Move a later bank or cash deposit from receipts-for-deposit clearing to the reviewed destination account.
finance_disbursement_clearing_settlement disbursement_clearing_settled Move a later bank settlement from payment-disbursements clearing to the reviewed bank account.
finance_direct_receipt_summary direct_receipt_settled Recognize one Finance-owned receipt already settled to bank or cash without inventing a Sales clearing stage.
finance_direct_disbursement_summary direct_disbursement_settled Recognize one Finance-owned ordinary operating disbursement already settled to bank or cash without inventing a Purchasing event.
finance_credit_card_charge_summary credit_card_charge_accepted Recognize one Finance-owned ordinary operating or finance-charge component against a reviewed credit-card liability.
finance_credit_card_payment_summary credit_card_payment_settled Settle a reviewed credit-card liability from a reviewed bank account.
finance_account_transfer_summary account_transfer_settled Move value once between two distinct reviewed bank or cash accounts for one direct transfer event.
finance_charge_summary finance_charge_assessed Recognize an explicit bank or card fee or interest charge against its reviewed settlement account.
finance_interest_income_summary interest_income_received Recognize explicit interest income received directly into a reviewed bank account.
finance_statement_match_result statement_match_completed Preserve a non-posting statement match to an event already posted directly to bank.
finance_account_reconciliation_result account_reconciliation_completed Preserve a non-posting period reconciliation from reviewed source closing balance to posted ledger balance.

Every type is owned by banking_and_finance_summary. Provider journals, account numbers, bank-feed descriptions, invoice text, counterparty names, equal amounts, or a bank-statement row cannot select the workflow, fact type, stage, component, account, template, or relationship.

The ordinary Finance workflow accepts only original facts and results. Corrections and reversals remain held for the Corrections workflow.

Common identity and provenance

Every fact or reconciliation result requires:

  • stable record id and company id;
  • source system and source-system instance when applicable;
  • source object type, external object id, and external event or version id;
  • idempotency key and normalized meaning hash;
  • explicit fact type, source-event stage, owning workflow, and change type;
  • source-world activity date or inclusive date range;
  • target FinancialPeriod and posting date for a posting fact;
  • company currency and preserved source-currency evidence;
  • active same-company primary Source Document;
  • supporting Source Documents and stable evidence references;
  • import-run and source-group provenance for file or machine intake;
  • source completion time and BooksPlus acceptance time; and
  • posting-template and mapping versions when a posting template applies.

Exact source identity or idempotency replay requires exact normalized meaning. Changed reuse conflicts and cannot silently replace accepted meaning. A different original for an already accepted source event remains held.

Import and preparation boundary

File or machine preparation accepts an AccountingImportIdentifiedCandidate only when:

  • candidate company and source system equal the fact and request context;
  • verified currency is present and equals the company currency;
  • the explicit route is banking_and_finance_summary;
  • identity outcome is ready_for_workflow;
  • change type is original with no related-original identity;
  • import-run, source-group, source object, external object, external event, idempotency, and normalized-meaning identity are complete;
  • candidate posting date equals the fact posting date when the fact posts;
  • candidate source reference identifies the active primary Source Document; and
  • fact type and source-event stage are an accepted pair.

Strict route isolation applies. Sales and Receivables, Purchasing and Payables, Inventory, Opening Balance, Correction/Reversal, Unclassified, missing, or ambiguous routes cannot prepare through Banking and Finance.

Import-run and source-event provenance remains visible. Provider journal, description, account, bank, card, invoice, counterparty, or reference text cannot establish the Finance route or accounting meaning.

Settlement accounts and components

Reviewed settlement account selections use immutable BooksPlus account ids:

  • bank accounts require bank.operating;
  • cash accounts require cash.on_hand;
  • credit-card accounts require liability.credit_card;
  • receipt-clearing accounts require clearing.receipts_for_deposit; and
  • disbursement-clearing accounts require clearing.payment_disbursements.

FinanceDirectComponent contains:

  • stable component reference unique within the fact;
  • explicit disposition;
  • positive amount and company currency;
  • resolved immutable destination account id;
  • active Source Document and reviewed classification evidence; and
  • relationship or allocation references when another accepted event supplies required meaning.

Allowed direct component dispositions are:

  • trade_receivable_settlement;
  • customer_deposit;
  • unapplied_customer_cash;
  • operating_expense;
  • finance_charge; and
  • interest_income.

Direct Finance facts do not accept inventory acquisition, prepaid expense, capital project, fixed asset, sales tax, use tax, payroll, loan, equity, dividend, owner draw, refund, chargeback, or foreign-exchange components. Those cases remain held until their owning truth accepts them.

Posting templates

Fact type or disposition Debit Credit
receipt-clearing settlement selected bank.operating or cash.on_hand selected clearing.receipts_for_deposit
disbursement-clearing settlement selected clearing.payment_disbursements selected bank.operating
direct receipt applied to receivable selected bank.operating or cash.on_hand receivable.trade
direct receipt classified as customer deposit selected bank.operating or cash.on_hand liability.customer_deposits
direct receipt classified as unapplied cash selected bank.operating or cash.on_hand liability.unapplied_customer_cash
direct operating disbursement reviewed expense.operating component selected bank.operating or cash.on_hand
ordinary credit-card charge reviewed expense.operating component selected liability.credit_card
credit-card finance charge reviewed expense.finance_charges selected liability.credit_card
credit-card payment selected liability.credit_card selected bank.operating
direct account transfer destination bank.operating or cash.on_hand distinct source bank.operating or cash.on_hand
bank finance charge reviewed expense.finance_charges selected bank.operating
interest income received selected bank.operating revenue.interest

Posting amounts are positive. Direction comes from the fact type and explicit component disposition. A transfer source and destination must be distinct immutable accounts. One direct transfer creates one balanced entry; BooksPlus does not synthesize withdrawal and deposit events in addition to it.

Externally accounted lines are reconciliation evidence. They never replace these templates or bypass central Accounting.

Clearing allocations and relationships

FinanceSettlementAllocation contains:

  • stable allocation id;
  • accepted prior Sales receipt or Purchasing payment event;
  • stable prior component or payment-allocation reference when applicable;
  • allocated company-currency amount;
  • clearing account id;
  • clears relationship id and version; and
  • active evidence references.

For receipt clearing:

  • the Finance settlement is the source and each prior accepted Sales receipt, customer-deposit, or unapplied-receipt event is a target of clears;
  • every target must have posted to the selected clearing.receipts_for_deposit account;
  • allocations sum exactly to the Finance settlement and cannot overlap the posted open clearing amount; and
  • one settlement may clear several prior receipts and one prior receipt may be cleared by several settlements.

For disbursement clearing:

  • the Finance settlement is the source and each prior accepted Purchasing vendor-payment or direct-purchase event is a target of clears;
  • every target must have posted to the selected clearing.payment_disbursements account;
  • allocations sum exactly to the Finance settlement and cannot overlap the posted open clearing amount; and
  • one settlement may clear several prior payments and one prior payment may be cleared by several settlements.

The prior event must be accepted and posted before a dependent clearing settlement becomes ready. A ready_to_post Finance batch reserves its allocations against the posted open clearing balance. Posting revalidates and consumes that balance atomically. Staged, held, and abandoned batches do not reserve it.

For a direct receipt applied to trade receivables, applies_to points from the Finance receipt to each accepted posted Sales invoice event. Workflow-owned allocations sum exactly to the receivable-settlement component and cannot exceed the posted open receivable amount. Customer-deposit and unapplied-cash classifications do not invent an invoice relationship.

A relationship preserves evidence and ordering but never authorizes posting, changes event ownership, or creates another posting result.

Direct-settlement isolation

  • A Sales-source receipt that posted to receipts-for-deposit clearing is not a Finance direct receipt.
  • A Purchasing-source vendor payment that posted directly to bank remains Purchasing-owned and is not a Finance direct disbursement.
  • A Purchasing-source vendor payment that posted to disbursement clearing is not reposted by Finance; only its later bank settlement is Finance-owned.
  • A one-stage Finance-owned receipt or disbursement does not gain a synthetic Sales or Purchasing clearing stage.
  • A vendor invoice, customer invoice, or counterparty reference on a Finance event is evidence or allocation context and cannot recreate that invoice.
  • A Finance direct disbursement cannot settle trade payables. Vendor-payment issuance remains Purchasing-owned.
  • A one-stage Finance-owned card charge may recognize only accepted ordinary operating or finance-charge components. A separately supplied Purchasing acquisition remains Purchasing-owned and cannot be reposted as a card charge.

Statement-match result

FinanceStatementMatchResult contains:

  • stable result and source identity;
  • statement account, statement-line, statement, and match-run identities;
  • statement date and amount in company currency;
  • accepted same-company event already posted directly to the same bank account;
  • statement_matches relationship id, version, and evidence;
  • match status and reviewed attribution; and
  • exact amount and account reconciliation.

The only accepted durable match status in the initial release is matched. Missing, ambiguous, mismatched, or unreconciled proposals return visible held issues and are not persisted as completed match results.

statement_matches points from the later Finance result to the already posted direct-bank event. It is support-only and non-posting. It does not create a Summary posting preview, change event ownership, reserve or consume a clearing balance, or create another journal entry.

Missing, ambiguous, mismatched, cross-company, wrong-account, wrong-currency, or unreconciled matches remain visible. A discrepancy, fee, interest item, or exchange difference is not forced into a statement match.

Sales-tax remittance statement match

The Sales Tax Accounting and Remittance Contract adds one bounded Finance- owned non-posting result for a seller-owned remittance already posted directly to bank or cash. FinanceSalesTaxRemittanceMatchResult links the statement identity and evidence directly to the exact SalesTaxRemittance and posted journal entry. It requires the same company, bank account, currency, and amount and persists only matched.

This result does not turn the tax remittance into a Finance direct disbursement, create an accepted accounting event, consume a clearing balance, or create another posting. Missing or discrepant results remain visible and cannot be forced through an ordinary Finance component or statement match.

Account-reconciliation result

FinanceAccountReconciliationResult covers one company, one reviewed bank, cash, credit-card, receipt-clearing, or disbursement-clearing account, and one FinancialPeriod. It contains:

  • inclusive source business-date range, source time zone, half-open cutoff instants, and reconciliation run identity and version;
  • company accounting time-zone identity and a cutoff matching the same FinancialPeriod under the Business Time Contract;
  • source opening balance in debit-positive sign convention;
  • source-period debit and credit activity;
  • source closing balance;
  • FinanceAccountReconciliationLine children for outstanding or timing items;
  • signed debit-positive adjustment total;
  • adjusted source closing balance;
  • posted ledger opening, period debit, period credit, and closing balances for the same immutable account and cutoff;
  • exact source-to-ledger differences;
  • manifest identity, version, SHA-256 digest, row count, and active Source Document evidence; and
  • reviewer identity, review time, status, and exception count.

Required equations:

source opening debit-positive balance
+ source-period debits
- source-period credits
= source closing debit-positive balance

source closing debit-positive balance
+ signed reconciliation-line adjustments
= adjusted source closing debit-positive balance

posted ledger opening debit-positive balance
+ posted ledger period debits
- posted ledger period credits
= posted ledger closing debit-positive balance

adjusted source closing debit-positive balance
- posted ledger closing debit-positive balance
= source-to-ledger difference = 0

Each reconciliation line has stable identity, explicit type, signed debit-positive amount, source or accepted-event reference when applicable, and active evidence. Operational bank-feed and statement rows remain in the manifest, not a BooksPlus subledger.

Initial reconciliation-line types are:

  • outstanding_item; and
  • timing_item.

The type explains why the line exists. It does not infer debit or credit direction. The explicit signed debit-positive amount alone controls the reconciliation equation.

The only accepted durable account-reconciliation status in the initial release is reconciled. Incomplete, exception-bearing, or nonzero-difference proposals return visible held issues and are not persisted as completed reconciliation results.

A completed reconciled result is non-posting. An unexplained difference, missing statement, incomplete manifest, duplicate coverage, unresolved line, or nonzero exception count remains visible and does not create a balancing, clearing, suspense, fee, interest, or discrepancy entry.

Exact preparation reconciliation

Every posting fact preserves:

  • normalized external-line debit and credit totals;
  • identified-candidate debit and credit totals;
  • candidate-to-line debit and credit differences;
  • reviewed operational control debit and credit totals;
  • workflow component or allocation totals;
  • prepared-preview debit and credit totals;
  • candidate-to-prepared differences;
  • operational-control-to-prepared differences;
  • company currency; and
  • evidence, relationship, allocation, and account-role readiness.

All applicable differences must be exactly zero at Money precision before a preview is ready. Every component or allocation appears once in its applicable control total. Rounding, residual, suspense, or discrepancy treatment cannot be inferred from a provider line.

Source evidence

  • Every fact and result references one active same-company primary Source Document.
  • Statement, balance, allocation, account, match, manifest, control-total, and reconciliation evidence remains linked through active Source Documents or stable references owned by those documents.
  • Superseded evidence cannot support new routine preparation.
  • Sensitive credentials, full account credentials, payment instruments, and raw protected banking data are not stored in ordinary facts, logs, audit events, or support output.

Held behavior

Preparation returns visible blocking issues and no posting preview for:

  • missing, ambiguous, inactive, superseded, or cross-company Source Documents;
  • missing or mismatched company, source system, source identity, route, original change type, fact type, stage, posting date, FinancialPeriod, currency, source reference, or provenance;
  • missing, ambiguous, inactive, retired, non-posting, or wrong-company account role targets;
  • an unsupported or provider-inferred component, settlement mode, account, relationship, or template;
  • missing, unresolved, invalid, cross-company, wrong-direction, wrong-account, overlapping, over-applied, or unreconciled allocations or relationships;
  • an unposted prior event required by a clearing or receivable allocation;
  • equal source and destination accounts for a transfer;
  • duplicate direct and clearing treatment for one source settlement;
  • a Finance event that would repeat a Sales, Purchasing, Inventory, or prior Finance posting;
  • an unexplained source-to-ledger, statement-match, candidate, preview, operational-control, or closing-balance difference;
  • unsupported inventory, prepayment, capital, fixed-asset, tax, payroll, loan, equity, dividend, owner, refund, chargeback, cash-over/short, suspense, exchange-difference, or foreign-currency treatment; and
  • correction, reversal, late, backdated, or changed finalized-period meaning not accepted by the Corrections workflow.

Held evidence never creates a ready reservation, journal entry, posting result, or ledger effect.

Implementation boundaries

Initial implementation slices may separately own:

  • starter-chart and account-role readiness;
  • receipt/disbursement clearing and direct bank/cash preparation;
  • card, transfer, finance-charge, and interest preparation;
  • statement-match and account-reconciliation results;
  • Summary review and posting orchestration; and
  • persistence, replay recovery, reservations, and company backup.

Provider adapters, UI, corrections, reversals, foreign currency, cash over/short, loans, equity activity, payroll, tax-remittance accounting, capital and fixed assets, check printing, payment execution, bank-feed operation, automatic matching, and reconciliation execution remain outside this contract's ordinary Finance implementation boundary. The bounded non-posting sales-tax remittance match is governed by the Sales Tax Accounting and Remittance Contract and must not expand ordinary Finance templates.

  • account-role.contract.md
  • accounting-import-candidate.contract.md
  • financial-period.contract.md
  • business-time.contract.md
  • money.contract.md
  • purchasing-and-payables-summary-fact.contract.md
  • source-document.contract.md
  • summary-accounting-batch.contract.md
  • sales-tax-accounting-and-remittance.contract.md
  • ../accounting/posting-and-reversal.md
  • ../accounting/summary-accounting.md