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 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.

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