A statement can match an approved USD15.00 commission and still have no evidence that it was paid. If a portal shows both facts as a green “paid” badge, a partner gets an answer the records cannot support.
Start by following one line from the proposed statement to its source commission and payment reference. Then keep the lines you cannot explain in view. This exercise gives you a fictional statement, its receipt journal and a completed and blank worksheet to try before building a reporting view in Overskill.
Use this optional Part 2 workflow example when a partner needs a clearer explanation of a statement. It gives you a reporting requirement to carry into your app brief, not a new way to send payments.
If you only need the affiliate program for an app sold through Overskill Payments, start with the existing affiliate help. It describes the built-in program and places commission records and payouts with Whop. A separate portal should explain source evidence; it should not become a competing payment ledger.
Freeze the statement you are trying to explain
Download the proposed statement, Download the fictional receipt journal and Download the statement review worksheet. These are original teaching files, not a provider export or customer payment history. No transaction, refund or collection takes place.
The selected statement belongs to partner P-A, in USD, with an inclusive cutoff of November 15, 2026 at 15:00 UTC. The fixture uses integer minor units: 1500 is USD15.00. Its separate EUR row uses the same two-digit scale, but it cannot join the USD total. A real source needs its own documented currency and precision rules.
An event must have occurred and arrived by the cutoff to inform this snapshot. Payment M112 occurred at 14:59 but arrived at 15:01. It cannot justify “paid” on a statement frozen at 15:00. Preserve the later receipt for a later review; do not rewrite what was known earlier.
This is a traceability exercise for the supplied lines. Even a clean result would not prove that an upstream export included every earning or payment.
Follow the amount, then the payment evidence
The worksheet keeps the proposed amount beside its source value. That makes a difference visible without silently correcting either file.
Scroll horizontally to compare all columns.
| Proposed line | Evidence in the fixture | Explanation the reader can support |
|---|---|---|
| S01: USD15.00 approved | C101 is approved for 1500; no payment reference | Approved/unsettled in this snapshot; no linked settlement evidence |
| S03: USD16.00 approved | C103 is approved for 1500 | Hold the USD1.00 difference; retain both values |
| S04: USD22.00 paid | M104 is processing at cutoff | Hold the paid claim; processing is not settled |
| S05: USD30.00 paid | M105 is settled for 3000; later A105 is an unresolved -500 adjustment | Retain the historical payment and show the adjustment separately |
| S07: USD9.00 paid | C107 exists, but M107 is absent | Hold; missing payment evidence is unknown, not zero |
In this invented contract, settlement evidence must match the commission, partner, currency and full amount. A payment status alone is insufficient. A reference belonging to another partner or commission cannot support the line, even if its amount looks right. Partial or grouped payments need an explicit allocation policy; this exercise does not guess one.
The fixture's settled label is a declared evidence threshold, not proof that a real recipient received money in a bank account. These labels are not Whop API statuses.
Keep repeats, conflicts and adjustments distinct
R16 and R17 carry the same source event for M106. They are two arrivals of one piece of evidence, so USD12.00 enters the settled section once. Count by the source and event identifier together, rather than counting receipt rows.
E-C108 is different: the same event identifier appears with amounts 700 and 900. Neither wins. Hold that commission rather than selecting the larger value or whichever receipt arrived later. For unconflicted records, the exercise uses the greatest eligible source revision, not arrival order. M104's later settled revision occurs after the cutoff and therefore does not replace its processing status here.
Adjustment A105 is USD-5.00 against C105 after M105's USD30.00 historical settlement evidence. Keep the adjustment linked and unresolved. Subtracting it from historical settled amounts would not create evidence of a new payment, and the worksheet does not authorize a clawback.
The completed worksheet explains all 12 proposed lines. Two belong outside the selected partner/currency. The remaining 10 produce these separate sections:
- Pending: one line, USD8.00.
- Approved/unsettled: one line, USD15.00.
- Evidenced settled: two lines, USD42.00.
- Hold: six lines, with no reconciled subtotal.
- Separate unresolved adjustment: A105, USD-5.00.
The whole statement remains unresolved. USD42.00 minus USD5.00 is arithmetic, but it is not a newly evidenced USD37.00 payment. Adding pending, approved and settled amounts together would likewise produce a number without a useful payment meaning.
Decide whether a separate explanation view helps
If the provider's existing statement already answers these questions, keep it. A new portal is useful only if it helps the authorized reader trace the line and understand what still needs review.
Ledgerline's current template page describes partner statements and is a candidate for the presentation. Inspect the current preview and starting options there; this exercise has not tested its data persistence, source synchronization, cross-partner privacy or actual settlement. A payout control in a demo is not evidence of money moving. Leave payment-changing controls out of a read-only adaptation.
For permissions, a partner should see only their own authorized statement. Operator-only raw receipts, internal notes and source connection settings stay private. Test two partners across detail, list, search and export using the private-record access guide. A filter that looks right on one screen does not establish that boundary.
Turn the evidence rules into your app brief
Open the partner-statement app brief when the separate view has a clear job. Edit its fields to name the operator and partner, the statement records, and the outcome: explain each line from source evidence without changing payment records. Keep Use this guide’s access rules selected so partner-only statement access and operator-only source records remain in the prompt. Retain explicit unknowns, duplicate/conflict handling, a frozen cutoff and adjustments shown separately from historical payments.
Read the generated prompt before selecting Start build, the primary action. Copy brief is useful while comparing approaches. The link imports no worksheet or CSV; supply the fictional examples separately only where supported, and do not put private partner information in the initial brief. Usual account access and credit requirements apply when building.
The first acceptance check is small: a second partner cannot read P-A's statement, a missing reference stays unresolved, and replaying M106 does not add another payment. Finish the source mapping and privacy tests before using real records. The reporting view should make uncertainty understandable, not make it disappear.