Recurring Periods
How recurring payment streams are proposed, posted, and protected from duplicates.
Recurring periods
A recurring payment stream repeats a fixed amount on a fixed cadence. O2A draws a sharp line between a recurring period that is merely due and one that has been made financially real: a due period is a proposal, and it only becomes fact when a Ledger Event is posted for it.
How It Works
A stream carries an amount and a period cadence — MONTH, QUARTER, SEMI_ANNUAL, or YEAR. When a period comes due it surfaces as a recurring period proposal, which is not yet a Ledger Event. Posting that period materializes exactly one Ledger Event for it, and duplicate protection keyed to the due period ensures the same period is never posted twice.
Statements
These statements fix the recurring-period contract:
- A recurring payment stream has an amount and a period.
- Recurring period values include MONTH, QUARTER, SEMI_ANNUAL, and YEAR.
- A recurring period proposal represents a due period before financial materialization.
- Recurring period posting creates one Ledger Event per due period.
- Recurring period posting uses duplicate protection for the due period.
Why It Matters
This separation keeps the source-truth rule intact for repeating payments. Future or matured-but-unposted periods stay proposals, so they never inflate a balance or P&L before money has actually moved. Per-period duplicate protection means re-running the stream cannot double-post the same period — financial history stays append-only and correct.