Know what happens after revenue data is imported

Imported revenue rows are source evidence for payout calculations. Allocora helps map, review, and calculate from them; it does not execute payments after import.

Start Free Try Sample Data

Details

What to know

Import behavior

One stable CSV/XLS/XLSX source retains multiple non-overlapping statement batches and their immutable revenue evidence. Accepted historical rows are not updated in place.

Each batch records an inclusive statement period, SHA-256 file fingerprint, source snapshot, template and mapping version, status, and finalization evidence.
The same source can accept later non-overlapping periods; exact file replay and overlapping accepted periods are blocked.
Raw external IDs remain source evidence. Batch ID, source row number, and a versioned row fingerprint provide direct row provenance.
Repeated external IDs inside an otherwise valid file are retained and surfaced for review rather than silently skipped.
Unmapped product identifiers should be mapped before calculation runs are trusted.
Sample data is for learning the workflow and should stay separate from production close work.

Atomic failure and retry behavior

File parsing is all-or-nothing for financial writes. A parser or mapping persistence failure rolls back the batch rows and mappings before the failed status and audit evidence are finalized.

A failed batch rolls back its financial transaction but keeps the source reserved until terminal audit and finalization work completes; Retry then becomes available.
Retrying the stored failed artifact creates a new batch linked to the failed batch; successful redelivery of the same job does not create a second set of rows.
A completed batch remains retained and its exact file cannot be accepted again.
Only one pending, processing, or terminal-awaiting-finalization batch can reserve a source at a time; stale finalization recovery cannot reinsert financial rows.

Corrections and review

Corrections should be explainable as refunds, adjustments, or new source rows rather than hidden changes to final payout totals.

Review refund and adjustment signs before calculating.
Resolve readiness blockers before generating statements.
Use audit history and retained source context when a payee questions a total.

Reference Tables

Fields and checks

Import behavior checklist

Use this checklist before relying on imported rows in a calculation run.

Behavior	Expected result	User action
Statement period	Each retained batch covers one explicit, non-overlapping period.	Confirm the inclusive start and end dates before preview.
Exact file replay	The same SHA-256 file is rejected for the same source.	Open the existing batch or upload a genuinely different statement.
Repeated source IDs	Rows remain append-only and repeated IDs are surfaced for review.	Keep raw IDs unchanged and review duplicate warnings in Import Suspense.
Failed retry	No partial financial rows remain, and the new attempt links to the failed batch.	Re-preview the retained failed artifact, fix mapping or format issues, and confirm the retry.
Product mapping	Rows map to products or catalog items before rules can match.	Resolve unmapped identifiers before running calculations.
Refunds and adjustments	Negative or corrective rows affect the payout basis.	Review sign, type, date, and source context.
Sample data	Seeded rows help new users learn safely.	Reset or replace sample data before production close work.

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