Reference
Use payout confirmation reconciliation after a calculation run is locked and the external payout rail, bank process, or accounting workflow has produced evidence of what was actually paid.
Details
Reconciliation compares a locked Allocora calculation run with payout confirmation evidence from the system that actually paid sellers, affiliates, partners, or other payees.
A payout confirmation import is evidence. It does not trigger payment movement, change the locked calculation output, or replace the downstream payout system.
The Payout Ops Review block on a calculation run summarizes current payee controls that would affect payout exports from that run. It does not change calculation totals, statement totals, or imported reconciliation evidence.
Reference Tables
Upload paid-out confirmations, not revenue exports. Each row should identify a payee and the amount that was actually paid.
| Column | Required | Purpose |
|---|---|---|
| payee_id | One identifier required | Matches the row to the Allocora payee reference when your payout file carries the payee ID. |
| One identifier required | Matches the row to the payee email when that is the stable downstream identifier. | |
| configured crosswalk field | One identifier required when configured | Matches using a workspace-specific payee metadata crosswalk. |
| amount | Yes | Actual paid amount to compare against the expected calculation-run obligation. |
| currency | Optional | Currency code for review context and mixed-currency checks. |
| paid_at | Optional | Date the downstream payout was completed or recorded. |
| payment_reference | Optional | Bank, payout rail, or accounting reference for later audit review. |
| note | Optional | Operator note explaining external payment context. |
Use these buckets to decide what needs review after the confirmation file is previewed or stored.
| Bucket | What it means | Typical next action |
|---|---|---|
| Matched | The imported confirmation row matched a payee in the run and the paid amount equals the expected obligation. | Review payment reference and evidence totals, then leave it as reconciled. |
| Missing | The run expected an obligation for a payee, but no imported confirmation row matched it. | Check whether the payout was skipped, paid under another identifier, or missing from the confirmation file. |
| Extra | The imported confirmation row does not cleanly belong to the run because the payee identifier is unmatched, ambiguous, or invalid. | Fix the identifier, remove the row from the confirmation file, or add the needed payee crosswalk before importing again. |
| Underpaid or overpaid variance | The row matched a payee, but the actual paid amount is lower or higher than expected. | Investigate the external payment amount and keep the variance explanation with the reconciliation evidence. |
Examples
This example confirms two sellers by email. Use payee_id instead when your payout export carries Allocora payee references.
CSV
email,amount,currency,payment_reference,paid_at,note
[email protected],120.750,USD,payout-alpha-001,2026-06-03,Paid externally
[email protected],120.750,USD,payout-beta-001,2026-06-03,Paid externallyTroubleshooting
Use a payout confirmation file instead. Revenue exports describe calculated or source revenue; reconciliation imports need paid amount plus a payee identifier.
The identifiers in the file probably do not match payee_id, email, or a configured crosswalk. Export or copy the downstream payee identifiers used by the locked run and preview again.
Confirm the calculation run is locked or in the required review state before importing payout confirmation evidence.
Retry with a readable CSV or spreadsheet. If the same file still fails, ask the workspace administrator to check artifact storage for payout evidence.
Feedback
Send a note if a step is unclear, missing, or out of date.
Start free, use sample data, then replace examples with your own revenue rows when the workflow is clear.