Allocora
Docs / Quickstart: Configure a Payout Rule

Quickstart

Configure payout logic as versioned rules

Rules tell Allocora how to allocate source revenue to payees. They should be explicit, versioned, and reviewed before a close period is finalized.

Start Free Try Sample Data

Before You Begin

  • Create or select the payee that should receive the allocation.
  • Map the products or source identifiers the rule should evaluate.
  • Know the rate, split, tier, floor, cap, or effective dates from the payout policy.
  • For tiers, confirm whether attainment resets per record, per calculation run, quarter, or year; whether higher rates apply only to current revenue or reprice the whole window; and what happens exactly at a threshold.

Expected Result

A versioned rule that explains who receives an allocation, which rows qualify, and which rate or split applies.

Steps

Follow this path

Each step keeps source revenue, rules, calculation output, and statement evidence in a reviewable sequence.

  1. 01

    Choose the payee or payee group that should receive the allocation.

  2. 02

    Select the product, source, metadata, or period scope for the rule.

  3. 03

    Enter the percentage, tier, split, floor, cap, or other supported payout logic. For grouped tiers, select the attainment window and application method.

  4. 04

    Set effective dates so prior periods keep their original logic.

  5. 05

    For a grouped rule, simulate the saved policy in Account > Rule Simulation > Attainment scenario before running a real calculation; otherwise use the standard transaction simulation.

Details

What to know

Rule design principles

A payout rule should explain who gets paid, what rows qualify, which period it applies to, and how much is allocated.

  • Prefer narrow scopes over broad catch-all rules.
  • Use effective dates when terms change.
  • Use priority intentionally when more than one rule could match.
  • Run simulation before changing active payout logic.

Avoiding rule ambiguity

Ambiguous rules make payout reviews slower. Keep rule names and scopes specific enough for finance and operations teams to understand later.

  • Name rules after the contract or payout policy they represent.
  • Include product or source context when it matters.
  • Review conflicts before creating a calculation run.

How tier attainment is configured

Each revenue record with marginal bands remains the default. When the contract uses grouped attainment, a saved rule can group all matching records for the same payee and tier program within a calculation run, quarter, or year.

  • You choose the business terms; Allocora creates the stable tier-program identity behind the rule and preserves it across compatible updates.
  • At the boundary means the higher tier starts when attainment equals the threshold. Above the boundary means the higher tier starts only after attainment is greater than the threshold.
  • Quarter/year policies require a cycle start month, IANA timezone, and refund treatment because monthly runs carry attainment inside that window.
  • The available reverse-original refund option proportionally reverses the locked original commission without reducing attainment.

Current grouped-tier safety limits

Stateful monthly runs become a chain of locked attainment evidence, so Allocora prevents operations that would make that chain ambiguous.

  • A quarter/year run cannot cross its attainment-window boundary, and later runs must be chronological and contiguous.
  • Start a new quarter/year program at its configured boundary. A mid-window first run is blocked unless carry-in was administratively provisioned with nonnegative eligible revenue, prior gross commission, a source note, approver, approval timestamp, and an as-of date immediately before the first calculation period. The account UI does not create this evidence.
  • Approved or used carry-in fields are immutable. Allocora stores a canonical carry-in hash on every downstream snapshot and displays it in locked evidence.
  • Locking makes the provisional attainment result effective. A locked run with effective tier state cannot be unlocked or executed again.
  • While a quarterly or yearly program has an open effective attainment window, the allocated stateful tier cannot be removed or deactivated. Finish the window or use the controlled reconciliation workflow first.
  • An adjustment or replacement is allowed only at the latest effective point; later dependent runs must be reconciled in chronological order.
  • Restate original attainment window is available for quarter/year policies. An authorized user selects the linked refund on the affected locked run, records a reason, and reviews and locks every delta-only replacement run in chronological order.

Reference Tables

Fields and checks

Tier policy choices

Choose the row that matches the written commission agreement. These options are additive; the legacy per-record behavior remains the default.

Attainment window Available method What the current run pays
Each revenue record Marginal Each record is calculated independently through the tier bands.
Calculation run Marginal The change in cumulative marginal entitlement across all matching records in the run.
Calculation run Current-period attained rate All eligible revenue in this run at the rate selected by the run total.
Quarter or year Marginal The change in cumulative marginal entitlement from locked opening attainment to closing attainment.
Quarter or year Current-period attained rate Only this run revenue at the rate selected by closing quarter/year attainment; prior runs are not repriced.
Quarter or year Retroactive true-up Full-window entitlement at the closing rate minus gross commission already recognized in locked prior runs.

Quarterly tiers with monthly calculation runs

Example tiers: USD 0-10,000 at 5%, above USD 10,000 at 10%, and above USD 50,000 at 30%. The boundary setting is Above the boundary, so exactly USD 10,000 remains at 5%. Each monthly total can contain many revenue records.

Run Opening + current = closing Current-period rate result Retroactive true-up result
January 0 + 5,000 = USD 5,000 USD 250 at 5% USD 250
February 5,000 + 5,000 = USD 10,000 USD 250 at 5% USD 250
March 10,000 + 7,000 = USD 17,000 USD 700 at 10% USD 1,200 = 1,700 full-quarter entitlement - 500 prior gross
Quarter total USD 17,000 USD 1,200; earlier months were not repriced USD 1,700; March includes a USD 500 catch-up

Production-service simulation inputs

For the March retroactive result, open Account > Rule Simulation > Attainment scenario and select the saved grouped rule.

Input Value Expected result
Opening attainment 10000 Closing attainment becomes USD 17,000.
Current revenue amounts 2000, 2000, 3000 Current eligible revenue is USD 7,000 across three records.
Prior effective gross commission 500 Gross due now is USD 1,200: USD 700 base plus USD 500 retroactive adjustment.

Feedback

Was this page helpful?

Send a note if a step is unclear, missing, or out of date.

Email Support

Apply this in a workspace

Start free, use sample data, then replace examples with your own revenue rows when the workflow is clear.

Start Free Browse Docs