Reconcile payout confirmations against expected obligations

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. When Contract Economics V1 rows exist for the run, expected obligations use net payable amounts rather than gross allocation totals.

• 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.
• 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 on a calculation run summarizes current payee controls and run-scoped net payable amounts that would affect payout exports from that run. It does not change calculation totals, execute payouts, or change imported reconciliation evidence.

• Included payees are clear for payout export based on current payee controls.
• Excluded payees are withheld from payout exports because they are on hold or below their minimum payout threshold.
• 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-Compatible Payables 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 expected net 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 expected net obligation.	Investigate the external payment amount and keep the variance explanation with the reconciliation evidence.
Underpaid	The grouped paid amount is lower than the expected net obligation.	Investigate whether another confirmation row is missing or the downstream payment was short.
Held	The payee is currently on payout hold according to payout ops controls.	Confirm whether external payment should have been skipped and preserve the hold reason.
Below threshold	The expected obligation is below the payee minimum payout threshold.	Confirm whether the amount should carry forward instead of being paid externally.

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.

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.

Related

Continue through the docs

Move from concepts to setup, then to statement output and audit review.

Quickstart: Generate the First Statement Review a run, generate statements, and export close-ready payout evidence. Statement and Export Field Reference A scannable reference for statement totals, payee fields, source evidence, and downstream export handoff. Troubleshooting Imports and Calculations Common symptoms, likely causes, and recovery steps for self-service payout workflows. All documentation

Feedback

Was this page helpful?

Send a note if a step is unclear, missing, or out of date.

Email Support