Capital Allocations
An accounting allocation assigns the period's recognized results to recipients. The run must explain the source P&L pool, each recipient line must explain its assigned share, and capital movements must record the delivered effect. Those movements join contributions, distributions and other history to form investor capital, which can then be compared with the GL.
Open Accounting → Accounting Review & Close → Capital Allocations to review that chain. Check account coverage as well as amounts: a subscription with no capital account can disappear from a balance bridge even while its operational funding exists.
Match the scope
Choose Entity and Accounting Period. This tab reviews the entity without the detailed app's Share Class or Allocation Run selectors. Most tables initially hide Ready rows; Roll-Forward remains a balance bridge.
Subscription Coverage is expanded for fictional core subscription #1. It is Blocked because it has zero capital accounts. The operational subscription exists, but its accounting coverage is incomplete.
Follow one allocation from source to recipient
First establish the Posted earnings pool and the applicable allocation basis. The selected run distributes that pool; summing its signed recipient components tests the total distributed. Recipient controls then compare each assigned result with its capital effect. Finally, the roll-forward and GL comparisons place those effects in cumulative investor history. Each stage can fail independently, so total run agreement cannot establish correct delivery to every investor.
Suppose a period's Posted class P&L totals USD300 and the approved basis for one run allocates 60% and 40% to two recipients. The run would contain USD180 and USD120 of allocated results. Allocation Tie-Out asks whether the run totals USD300; Allocation Recipients asks what each line delivered to its intended account; Txn Posting and the capital ledger provide further evidence about the resulting movements and their sources. Run-total agreement alone cannot establish that either recipient received the correct accounting effect.
This is a hypothetical relationship between the controls, not an allocation policy or a run produced in the sandbox. In the core native example, Subscription #1 has no capital account and no accounting allocation run exists. Start with that missing coverage when investigating the absent investor history, then inspect the independently produced run and movements through the authorized accounting process.
Work through the chain
Use each control to answer its own question: total allocation, recipient delivery, movement lineage, balance history, account coverage, class aggregation and GL agreement. When two results differ, match the actual populations before choosing a correction. A latest exact-period run and a list containing multiple subperiod versions do not measure the same calculation.
- Allocation Tie-Out: compare the selected-period run's source pool with its allocation outputs.
- Allocation Recipients: inspect recipient lines, expected versus actual capital effects and account delivery.
- Txn Posting: investigate existing capital transactions and the specific missing allocation-derived components this control can detect. It is not a universal inventory of all unrecorded investor activity.
- Roll-Forward: explain opening balance plus signed period movements to closing balance. Do not add the opening balance or other sections again.
- Subscription Coverage: identify eligible subscriptions missing the required capital-account relationship.
- Class Roll-Up: inspect class-level account coverage and aggregate balances.
- Equity Tie-Out: compare the capital ledger with the configured Posted equity and cumulative earnings bridge.
- Capital Close Readiness: review Capital-stage generic blockers, including unfinalized runs or missing capital effects.
These tables do not share one identical population. Run tie-out uses the exact selected start/end window and its latest run selection. Recipient roll-up can include contained subperiods and multiple versions. Generic readiness selects nonvoided allocation runs whose as-of date equals period end. Coverage and class roll-up also use different subscription populations.
Some detailed controls suppress records with unresolved ignored-exception comments independently of the visible table filter. Inspect review notes and approved exception rationale when reconciling populations.
If one section looks clean and another does not, compare scope, dates, version, lifecycle and recipient/account identities before assuming a contradiction. Use Fees & Capital Allocations for the detailed filters and explanations.
Resolve the responsible cause
Follow the record into Accounting Operations for capital accounts, transactions and journals, or into the supported allocation workflow for the run and recipient output. Participation schemes in the Allocations app define economic ownership; they are distinct from these accounting allocation runs.
Correct the independently wrong source, relationship or accounting output. Confirm persisted results after any authorized execution and refresh the affected controls. Do not finalize a run by editing a status field, create a second recipient movement to force a total, or change a participation percentage merely to clear an accounting difference.
A 100% total checks the arithmetic. Also confirm the approved allocation policy, the intended recipients and the capital movements recorded for them. A zero GL/capital difference can also conceal missing records on both sides.
The Core Entity 1 example has an active subscription without a capital account and no allocation runs. It illustrates incomplete coverage; it is not an example of completed allocation or verified capital NAV.
Revisit Gross NAV and affected reports after correcting capital or allocation economics.