Declarative mappings from a source event to a journal entry shape. The Posting Rule Designer authors them; idempotent execution dedupes per source event.

Posting rules

A posting rule is a declarative mapping from a source event (an invoice created in CRM Sales, a sale rung up on POS, a payment recorded in the dealer payment ledger) to a journal entry shape. Rules are how other Yokes get their activity onto the books without anyone hand-typing journal entries.

The rule shape

Each rule names:

A source kind — which event the rule fires on.
A debit account code — which account gets debited.
A credit account code — which account gets credited.
An amount derivation — usually "the source event's amount field," sometimes a constant or a formula over source fields.

The platform stores rules per tenant. Two tenants can have different rules for the same source kind.

Sources

The set of source kinds available to your tenant is exposed at GET /gl/posting-rules/sources. The default shipped sources include invoice (CRM Sales, dealer line items) and expand as Yokes that emit posting sources are installed.

The default seeded rule

Install seeds one rule: invoice → AR / Revenue. Any Yoke that emits an invoice source posts a journal entry debiting AR and crediting Revenue automatically.

You can:

Edit the rule (change accounts, change amount derivation).
Disable the rule (it stops firing without being removed).
The default rule cannot be deleted entirely — disable instead. (This prevents an accidental "rule's gone, why isn't my CRM posting?" moment.)

Idempotency

When a source event re-fires (a webhook retry, an FSM event that fires twice, a replay during recovery), the same source event creates one posted entry, not two. The platform deduplicates by the source event's id within the tenant — a rule that fired against invoice id=42 will not fire against invoice id=42 a second time, ever.

The Posting Rule Designer

The Posting Rule Designer is the in-product UI for authoring rules. It sits in Settings → Yoke Ledger → Posting rules and follows the same Builder-surface pattern as the rest of the platform's authoring tools. See Workflows for the Builder pattern the Designer mirrors.

Designer features that customers see today:

Pick a source from the live /sources list.
Pick debit and credit accounts from your CoA.
Configure the amount derivation as a field from the source event, a constant, or a formula.
Save, preview against a recent source event, enable / disable.

What's not in posting rules today

Conditional rules — fire only when amount > X, only when a tag is set, only on weekdays.
Multi-leg rules — split the amount across more than two accounts.
Deferral schedules — recognize revenue over a period.
Rule simulation / dry-run — preview a month's worth of rule firings before enabling.