Recover from common import and calculation blockers

Most payout calculation issues come from missing mappings, ambiguous rules, unexpected refund signs, unresolved exceptions, or API key handling errors.

Start Free Try Sample Data

Details

What to know

Recovery sequence

Start from the earliest source of truth and move forward through the workflow instead of fixing the final total first.

Check the imported revenue row.
Check Import Suspense for open blockers or warnings tied to the source and period.
Check product or payee mapping.
Check rule scope and effective dates.
Check calculation run exceptions.
Regenerate statements only after the run output is corrected.

Troubleshooting

If this does not work

Imported rows are visible but no allocations are produced.

Resolve product mappings and confirm at least one active rule matches the row scope and period.

Calculation readiness links to Import Suspense.

Open the linked queue, filter to open blockers, then resolve, exclude, or reprocess each issue before retrying readiness.

Allocora says this file was already accepted.

Open Import History and review the existing SHA-256 batch. Renaming or re-uploading identical bytes is still an exact replay; import the next genuinely distinct statement instead.

Allocora says the statement period overlaps.

Compare the inclusive start and end dates in Import History. Shared boundary dates count as overlap, so correct the dates or use the next distinct period.

An import says Finalizing after processing completed.

Keep the page open or return to Import History. Allocora is completing suspense and audit evidence and automatically retries stale finalization without importing the financial rows again.

A historical completed import has no statement period.

A manager must open Import History and classify that batch’s known inclusive period once before Allocora can safely admit another batch for the source.

A payee is missing from the statement list.

Confirm the payee exists, is referenced by an active rule, and has matching revenue rows in the calculation period.

The calculated total does not match a spreadsheet.

Compare source rows first, then refund signs, then rule scope, then effective dates. Avoid editing calculated output directly.

An API request returns unauthorized.

Verify the bearer token is present, current, server-side, and issued for the workspace automation that is making the request.

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