The Architecture Canontruth · evidence · projection
Pattern

Effective-Dated Financial Rules

pattern-effective-dated-financial-rules · canon/patterns/effective-dated-financial-rules/unit.md

Effective-Dated Financial Rules

Financial policy changes over time, but historical settlements must never be recalculated because today's fee schedule changed. Store fee rules as effective-dated records; each transaction references the rule in force when it occurred. Truth is preserved across time — history stays reconstructible and correct.

Problem

Financial policy changes over time. Historical settlements, fees, commissions, taxes, discounts, and revenue shares must not be recalculated because today's rule changed. If the current rule is the only rule, history becomes unstable.

Context

Use this pattern when money, eligibility, pricing, commissions, royalties, fees, or settlements are calculated under policies that change by date, market, product, contract, or participant class.

Forces

  • Business rules need to change without corrupting historical results.
  • Auditors and operators need to reconstruct why a transaction settled the way it did.
  • Teams are tempted to keep only the latest policy because it is simpler.
  • Backfills, disputes, refunds, and reports need the rule that applied at the time.
  • Documentation of policy changes must match executable system behavior.

Solution

Store financial policies as effective-dated records. Each transaction references the rule version in force when the transaction was created or settled. Never infer historical rule choice from today's configuration. Treat the rule version as part of the transaction's truth.

Consequences

History remains reconstructible. Policy changes become explicit. Settlements can be audited without guessing which code or configuration was live at the time. Documentation and executable rules stay connected because the rule record becomes part of the evidence.

Failure Modes

  • Historical transactions recalculate from the latest rule.
  • Reports join to current policy instead of the transaction's rule version.
  • A policy migration overwrites the old rule record.
  • Refunds or disputes use today's policy instead of the original one.
  • Policy changes are described in docs but not represented as versioned system state.

Proof Points

commerce need historical rule identity so financial truth survives policy evolution.

  • Ampriot — reservations, settlements, fees, and simulated

Full source pattern: 07-versioned-financial-rules.md.

Incoming References

Case Study 1