Docs / Payout Confirmation Reconciliation

Reference

Reconcile payout confirmations against expected obligations

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.

Start Free Try Sample Data

Details

What to know

Where reconciliation fits

Reconciliation compares a locked Allocora calculation run with payout confirmation evidence from the system that actually paid sellers, affiliates, partners, or other payees. Expected obligations use included settled amounts from the same immutable settlement snapshot that produced the payment-ready files.

Run and review the calculation in Allocora first.
Execute payment movement in the external payout, bank, or accounting workflow.
Import the paid-out confirmation file back into the locked run.
Use the reconciliation page to compare expected obligations with confirmed paid rows.

Payment boundary

A payout confirmation import is evidence. It does not trigger payment movement, change the locked calculation output, or replace the downstream payout system.

Keep bank transfer, payout rail, tax, and KYC status in the system that owns those workflows.
Use Allocora to preserve calculated obligations, imported evidence, match decisions, and variance context.
Resolve mismatches before treating a payout period as fully reconciled.

Partial-payment match ledger

Payout Confirmation Reconciliation V2 separates imported confirmation rows from immutable match facts. A single expected obligation can be satisfied by multiple confirmation rows, and a single confirmation row can leave a residual amount that remains open for review.

Preview and stored rows include match status, match strategy, variance status, matched amount, residual amount, and match group key.
Many-to-one payment rows are grouped by matched payee, so expected totals are counted once while paid rows remain individually auditable.
Confirmed files are cumulative for the same locked settlement: a later batch starts from prior confirmed paid amounts and can close the remaining obligation without counting the expected amount twice.
The encrypted preview, confirmed batch, stored row, and immutable match fact bind to the exact settlement snapshot or settlement line used for the expected amount.
Stored confirmation batches create append-only reconciliation match facts; confirmed batch, row, and fact records are immutable.
Finance exports include expected amount, paid amount, matched amount, residual amount, match strategy, and variance status.

FX reporting context

Locked calculation runs store an FX reporting snapshot for display and close-package context. The current implementation records identity-rate context for same-currency reporting and preserves the boundary that calculations remain single-currency.

The snapshot captures source currency, organization calculation currency, reporting currency, rate, rate date, provider, and conversion lineage.
FX context is display-only and does not change calculation outputs, statement math, reconciliation math, or payout exports.
Mixed-currency calculations remain unsupported; split source data by organization currency before calculation.

Payout Ops Review

The Payout Ops Review block previews payee controls before lock. Locking freezes those decisions and run-scoped canonical obligations into the versioned settlement snapshot used by statements, payout exports, journals, close packages, and reconciliation. Later payee edits do not rewrite locked close evidence.

Included positive obligations are rounded once in aggregate at the currency exponent using half-up; residual minor units go to the largest fractional remainders, then immutable payee UUID ascending for ties.
Excluded positive obligations are withheld because they were on hold or below their minimum payout threshold at freeze, while their canonical liability remains visible in evidence.
Zero obligations are recorded but omitted from payment files; a negative obligation prevents the settlement snapshot from freezing.
Settlement rounding never carries into another period.
Statements, statement ZIPs, Payee Portal downloads, and public Evidence Center artifacts are usable only when their published batch binds to the locked run's latest settlement snapshot; re-locking withdraws older artifacts until the replacement batch is published.
Production settlement requires PostgreSQL so persisted financial decimals remain exact; unsupported database drivers fail before freeze or snapshot resolution.
Use the block before exporting payout files so downstream payment tools receive only eligible payees.
Built-in payment-ready export presets include Generic Payout CSV, PayPal MassPay CSV, Wise Batch CSV, Tipalti Payables Mapping CSV, and Generic AP / Bank Payment CSV.
Close Package V1 includes payment-ready preset files plus payee totals, import quality, reconciliation, statement, rule, and audit evidence for the locked run.

Reference Tables

Fields and checks

Payout confirmation file format

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

Reconciliation buckets

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 included settled obligation.	Review payment reference and evidence totals, then leave it as reconciled.
Partial	The matched confirmation evidence leaves a residual amount open or multiple confirmation rows satisfy one payable.	Review residual amount, match group, and external payment references before closing the variance.
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.
Overpaid	The grouped paid amount is higher than the included settled obligation, or money was reported against an excluded or zero settlement line.	Investigate the external payment amount and keep the variance explanation with the reconciliation evidence.
Underpaid	The grouped paid amount is lower than the included settled obligation.	Investigate whether another confirmation row is missing or the downstream payment was short.
Held	The frozen settlement line was excluded because the payee was on hold.	Confirm the external payment was skipped and preserve the frozen hold reason.
Below threshold	The frozen settlement line was excluded because its canonical obligation was below the payee minimum payout threshold.	Confirm the amount was withheld externally and preserve the frozen threshold evidence.

Examples

Payout confirmation CSV example

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 externally

Troubleshooting

If this does not work

A revenue summary export fails or produces unexpected matches.

Use a payout confirmation file instead. Revenue exports describe calculated or source revenue; reconciliation imports need paid amount plus a payee identifier.

All expected payees are missing and the uploaded rows are extra.

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.

The import area is unavailable for a run.

Confirm the calculation run is locked or in the required review state before importing payout confirmation evidence.

A stored payout-confirmation preview is rejected as stale.

The locked run no longer resolves to the same settlement snapshot. Re-preview the file so matching and expected amounts bind to the current immutable snapshot before confirming.

The preview cannot store the uploaded file.

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

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