Prop Firm Payout Reconciliation: An Operator Checklist
Prop firm payout reconciliation links each trader reward request to its approval, payment instruction and supported outcome evidence. Match stable references, amounts and currencies across the CRM, payment provider and relevant financial records. Keep missing or conflicting results in an owned exception queue instead of marking a request paid because it was approved or an API call succeeded.
This checklist is a proposed operating procedure for teams designing that workflow. Adapt it to your programme terms, payment channel, provider contract and finance process. It describes requirements to agree and test; it does not claim that a particular PropFirmsTech deployment or payment provider includes every step.
Separate trader rewards from merchant settlement
The word “payout” can refer to different movements. A trader reward is a payment obligation arising under your programme terms. A processor payout may instead move your business’s available processing balance into its own bank account. A trading-account balance adjustment is another record again.
Keep separate ledgers or clearly identified transaction types for:
- The trader’s reward request and the firm’s eligibility/approval decision.
- Instructions and results from the service used to send that reward.
- Challenge-purchase receipts, refunds, disputes and processor fees.
- Transfers of merchant processing balances into the firm’s bank account.
For example, Stripe’s payout reconciliation report matches merchant bank payouts to their underlying settlement batches. It is not, by itself, a register of a prop firm’s trader rewards. Stripe also documents different reporting treatment for automatic, manual and instant payouts. Confirm which report covers the movement you are investigating.
A linked purchase can provide context for a reward review, but do not net a purchase, refund and reward together without an explicit authorised accounting treatment.
Establish the reward reconciliation record
Give every request a stable internal reference. Keep its original approval and subsequent payment attempts linked to that reference. A retried delivery of one instruction and a newly authorised payment attempt must remain distinguishable.
Use this field checklist as a starting point. Keep sensitive destination details in the appropriate protected system; a shared reconciliation sheet should use masked references and access appropriate to its purpose.
| Record group | Fields to retain or reference | Check |
|---|---|---|
| Identity and eligibility | Request ID, internal trader/account IDs, programme version, review period and decision reference | The request belongs to the intended trader and account |
| Approval | Approved amount/currency, decision time, authorised actor and any adjustment reason | The execution instruction matches the accepted decision |
| Destination | Provider, environment, provider account and masked beneficiary/destination reference | Test/live and destination details cannot be confused |
| Execution | Internal operation ID, provider object/reference, attempt ID, request time and idempotency reference where supported | One approved obligation is not unintentionally instructed twice |
| Provider result | Current provider state, source record, event ID, observation time and failure/return reference | A notification can be traced to the operation it describes |
| Money movement | Amount/currency sent, fees, conversion details and relevant bank/recipient evidence | Gross, net, fees and exchange differences are explained |
| Resolution | Exception type, owner, next action, review date and correction authorisation | Every unmatched item remains visible until accepted resolution |
Keep values with their currencies and documented units. Do not assume every API amount is expressed to two decimal places. Store the provider’s original reference and agreed conversion method so a later reviewer can reproduce the comparison.
Map states to evidence before automating them
Use internal states that your team can explain. Map them to each provider’s actual states and events; the names below are examples for a runbook, not a universal API specification.
| Internal state | Evidence required | What remains unresolved |
|---|---|---|
| Submitted for review | Valid request linked to an account and programme | Eligibility and approval |
| Approved | Recorded decision by the permitted actor, amount and destination checks | Payment instruction and outcome |
| Instruction accepted | Provider reference linked to the approved operation | Provider completion, rejection or unknown outcome |
| Provider reports completed | Current provider record and the meaning of its completion status | Any further receipt/settlement evidence required for that channel |
| Reconciled | Required records match and exceptions are accepted under the agreed close procedure | Later returns, disputes or corrections still need handling |
| Failed, returned or outcome unknown | Provider failure/return evidence, or a documented missing result | Investigation and an authorised correction or new attempt |
Preserve the raw provider state beside your internal interpretation. Stripe’s Payout object illustrates useful distinct fields such as a payout identifier, balance-transaction reference, destination, arrival date, status and failure details. These describe that product’s object; they do not establish the states or permissions of a different reward provider.
Define exactly what staff may tell a trader at each stage. “Approved,” “sent to the provider” and “provider reports completed” communicate different evidence. Record recipient receipt separately when it is required and available. An estimated arrival date, successful webhook response or internal green badge does not independently prove receipt in the recipient’s account.
Run the reconciliation in a repeatable sequence
Choose a frequency based on your operation and provider reporting availability. Record the comparison time, timezone and export/report scope so another reviewer can reproduce it. Recent unresolved items must carry forward into the next run.
- Capture the source set. Collect approved requests, open/unknown attempts, recent provider results and relevant financial records for the agreed period. Include earlier unresolved requests and later updates to earlier operations.
- Check completeness. Confirm pagination, export filters, environment, provider account and currency coverage. Record any unavailable source or reporting delay before drawing conclusions.
- Match stable references first. Join the internal request and execution operation to the provider reference. Use amounts and timestamps as supporting checks; similar amounts alone do not establish a match.
- Compare decision and execution. Verify the approved amount, currency and destination against the instruction. Explain partial payments, rejected attempts and any authorised adjustments individually.
- Compare the financial result. Match the required provider/bank evidence, fees and conversion records. Keep fees paid by the firm separate from deductions authorised against a trader reward.
- Investigate exceptions. Assign an owner, evidence, next action and review date. Resolve unknown outcomes before deciding whether another instruction is appropriate.
- Review and close. Have the designated reviewer accept the matches and documented exceptions. Retain the source references and corrections under the firm’s existing records policy; do not overwrite the original evidence.
Reconcile totals within each currency as well as individual records. Where an approved gross reward permits deductions, explain the relationship between the gross amount, authorised deductions and recipient amount. Where the firm pays a fee separately, show it as a separate cost. Keep source and destination currencies distinct for conversions; adding them together produces a misleading total.
Treat retries as a controlled recovery action
Event delivery can fail even when the underlying payment succeeds. Stripe’s webhook guidance documents duplicate events and delivery without a guaranteed order. For providers with comparable behaviour, the integration needs a recorded processing result and a way to retrieve current state. Verify the exact contract for each provider.
If a request times out, look up the original operation through supported tools before creating another payment instruction. Where supported, agree how an idempotency reference ties retries to the same business operation. Stripe’s idempotency documentation describes provider-specific rules, including parameter checks and key retention; do not assume another provider follows them.
Keep event-delivery identity separate from the reward/payment identity. Two event IDs can concern the same underlying operation. A repeated notification should not cause another transfer, and an earlier notification should not silently replace a later accepted state. The API integration checklist covers these acceptance cases in more detail.
Give exceptions a specific next action
| Exception | First investigation | Control before correction |
|---|---|---|
| Approved request has no execution reference | Check whether it was queued, rejected locally or never submitted | Confirm no provider operation exists before authorising submission |
| Timeout or provider outcome unknown | Retrieve the original operation and check reporting availability | Hold duplicate execution until the outcome is established |
| Provider result has no internal request | Check environment, account scope, missing joins and manual provider actions | Identify its origin and authorisation before attaching or adjusting it |
| Amount, currency or destination differs | Compare the approval, actual instruction, fees and conversion evidence | Require a recorded decision for any correction; retain both values |
| Completed operation later fails or returns | Link the provider’s updated result and any returned funds | Reopen the reconciliation and approve any replacement attempt separately |
| Multiple execution references exist | Check retries, partials, batch membership and independently created attempts | Establish the actual movement before cancelling or instructing anything else |
Set escalation thresholds and approval roles for your team. A second reviewer for execution changes can be a useful control; define it as part of your process rather than assuming a provider enforces it. Use supported reversal/correction procedures, and keep an audit trail linking the correction to the original request.
Test the runbook before using it for live rewards
Use the provider’s sandbox or another explicitly approved test method. Demonstrate a normal result, duplicate event, out-of-order event, timeout after provider acceptance, rejected instruction, later return and missing report. Confirm that each case produces the intended record and exception, without a duplicate execution.
Check that support staff can explain the state using the same evidence finance sees. Agree who may change a destination, approve a reward, execute an instruction and accept a reconciliation exception in the CRM workflow. Restrict each action to its intended role.
Reviewing your payment handover? Bring one mapped test request, your state definitions and an exception example to a PropFirmsTech demo. Use the payment integration overview to identify the provider questions, then confirm the supported scope and approvals for your own implementation. Technical integration does not establish provider eligibility, settlement timing or guaranteed payment availability.
