Allocora
Docs / Quickstart: Generate the First Statement

Quickstart

Generate a statement from reviewed calculation output

Statements should come after a reviewed calculation run. They turn calculation output into payee-facing evidence without changing money movement.

Start Free Try Sample Data

Before You Begin

  • Complete or open a calculation run for the close period.
  • Resolve unmapped products, unmatched rules, and unexplained exceptions.
  • Confirm the output is ready for payee or finance review.

Expected Result

A statement generated from reviewed calculation output, plus settlement-snapshot-bound Close Package V1 or payment-ready export evidence for downstream accounting or payout workflows.

Steps

Follow this path

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

  1. 01

    Open a completed calculation run.

  2. 02

    Review totals, exceptions, payee allocations, and unmapped rows.

  3. 03

    Lock the run once the output is final enough for statements and payment-ready exports. Locking freezes the versioned settlement snapshot used by every downstream amount.

  4. 04

    Choose Generate Statements and confirm generation for the full run. Eligible payees use their enabled summary and product statement settings.

  5. 05

    Download the completed statement ZIP; the run page confirms the request before the browser receives the attachment.

  6. 06

    Export Close Package V1 ZIPs or payment-ready payout CSV presets for downstream review.

Details

What to know

Statement readiness checklist

Do not generate payee-facing statements until source rows, product mappings, and rule output have been reviewed.

  • The calculation run completed without unresolved blockers.
  • The close period and source selection are correct.
  • Payee totals match the expected review view.
  • Adjustments and refunds have understandable context.

Replacing published statements

On the same locked run and settlement snapshot, the previous publication remains current until every replacement PDF and the complete ZIP pass verification. A failed attempt leaves that publication current.

  • Choose Regenerate all statements and review the confirmation. Previous versions remain in workspace history, and the Payee Portal changes only after successful publication. No emails or share links are sent automatically.
  • Download current ZIP remains available while regeneration is submitting or processing and after a failed attempt. Repeating the same submission does not start another generation; a separate attempt must wait until the active one finishes.
  • The statement selection is captured when generation starts; a queue retry uses that same selection.
  • If regeneration would omit an already published summary or product statement, restore the corresponding payee statement settings and start a new attempt.
  • A run with no eligible statements does not publish a ZIP.
  • Generation does not automatically email statements or create share links.
  • The run page shows the latest generation attempt separately from the published ZIP, so a pending or failed attempt does not hide the available download.
  • If published files or publication records are missing or inconsistent, generation is blocked with a reconciliation message. Review and reconcile the existing publication before trying again; a rejected request creates no new generation attempt.
  • New share links and emails use the current published statement. Previously issued links keep their original PDF while its verified files remain available; you can revoke those links at any time.

Review statement history

Open a payee in your workspace and go to Statements. Choose Current for the available published statements, Historical for earlier published versions, or All to include records that need investigation.

  • Historical includes retained statements replaced for the same run or published before the run was unlocked and locked again. Review these versions as past evidence.
  • Owner, Admin, and Finance users can download an available historical PDF. Allocora returns the saved file and records who requested it, when, and which statement version.
  • All also shows unavailable records, including unsuccessful generations and statements whose files cannot be verified. These records cannot be downloaded or newly shared.
  • Regeneration retains prior statement files and delivery evidence. There is no statement cleanup action, and previously deleted files cannot be restored from this history.
  • New share links and emails remain limited to Current statements. Workspace history does not add earlier statement versions to the Payee Portal; its Archived tabs continue to cover earlier calculation runs replaced by adjustment runs.

Keep selected Payee Portal access

Selected statements and their current replacements gives the payee access to the current published version of each statement you selected.

  • A successful replacement for the same workspace, payee, calculation run, statement type, scope, and product updates the visible PDF. It does not grant access to another statement or calculation run.
  • The selection is saved when you create the invitation, so replacing a statement before the invitation is accepted keeps that choice.
  • A failed generation leaves the previous verified publication current. If no verified current version is available, the portal shows no statement for that selection.
  • Changing permissions or the access expiration keeps your selected statements. You can explicitly remove a selection or revoke access from Payee Portal Access.
  • Previously issued share and Evidence Center links still open their original PDF, subject to expiry, revocation, and file availability.

What a statement represents

A statement explains calculated obligations. It is not proof that money has already moved unless your downstream payment workflow adds that status.

  • Use statements for payee transparency.
  • Use Close Package V1 for finance review, payout rail handoff, and close evidence.
  • Review the three-decimal canonical obligation beside the currency-minor-unit settled payout, rounding delta, settlement status, and exclusion reason.
  • Use audit history when a payee questions a calculated amount.

How grouped tier adjustments reach statements

For a retroactive grouped tier, Allocora keeps revenue-linked allocation lines and the payee-level catch-up or true-down as separate evidence. The canonical gross ledger combines them exactly once before contract economics and statement totals are calculated.

  • The current-period base remains tied to the revenue rows that produced it.
  • A non-zero retroactive tier adjustment appears as its own calculation component with snapshot evidence.
  • Gross allocated includes both sources exactly once; reserve, recoupment, clawback, hold, and minimum-threshold logic then determines net payable.
  • If gross for a payee is negative, Allocora records the unpaid amount as refund/clawback carry with zero net payable. Later positive gross consumes that carry first, and a zero-activity run preserves the balance as explicit evidence.
  • Configured opening, advance, expense, and clawback balances initialize the first authoritative payee/currency period. Later periods start from the prior canonical locked component closings, even when the payee profile has a newer version.
  • Each component exposes start, applied, and end values. Total Closing Balance covers the recoupment and refund components. Threshold and reserve balances appear separately as Opening, Held, Released, and Closing.
  • Statements, exports, reconciliation, and evidence bundles use the same canonical gross-ledger projection and immutable settlement snapshot. Gross-accrual journals use the gross projection directly; payable-ready journals separate current payable and retained closing balances, debit transferred opening balances at their frozen source accounts, and add a rounding-adjustment expense leg when required. Replacement and adjustment run lineages use Adjustment Delta exports and are blocked from journal CSV until delta-aware journal entries are supported.

Retained royalties across periods

Amounts below the minimum payout threshold accumulate across locked periods for the same payee and currency. With a threshold of USD 50, a first period of USD 30 is retained; USD 25 in the next period creates one payable amount of USD 55.

  • Review threshold and reserve Opening, Held, Released, and Closing separately. Held is new retention in this period; a transfer does not add revenue or royalty expense.
  • For a final threshold payout, an Owner or Admin selects the active payee under Final payout below threshold, enters a reason, and reviews the calculation before locking. The stored minimum threshold remains unchanged.
  • A period without new revenue can carry an available retained balance or prepare its final threshold payout through the ordinary calculation review. It uses the normal calculation-run allowance.
  • Reserve percent applies only to new eligible royalties. Existing reserve balances remain retained when that percent changes.
  • A payee on hold can have a locked financial calculation, while preparation of a payment file remains subject to the hold.
  • A locked period that already recorded retained royalties cannot be replaced or adjusted. Keep that run as the financial record and continue with the next period.
  • A run calculated before retained royalties were enabled shows a review blocker. Recalculate it before locking.

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