Processor Payout Exception Report

What does Processor Payout Exception Report do?

Turn exported processor transactions, declared payout batches and explicitly linked bank credits into a traceable exception report. Run it at each payout review or period close to check signed gross/fee/net arithmetic, itemized payout totals and the bank allocations you supply. It works through the Apify API or Console with CSV or normalized JSON. It does not connect to a processor or bank, guess matches, move money or produce accounting journals.

The useful boundary is a handoff across existing exports and spreadsheets. Stripe already provides automatic-payout reconciliation reports, and connected accounting tools may already meet your needs. This report is for reviewing exported evidence without adding account credentials. Mathematical agreement here means agreement of your supplied records, not proof that an export is authentic or that a bank received funds.

How to create a payout exception report

1. Export minimized transaction itemization, declared payout batches and bank credits. Use account aliases rather than bank account numbers or personal information.
2. Give every row an exact processor, account, uppercase currency and literal ID. Specify the currency's minor-unit scale, for example {"USD":2,"JPY":0}. Keep all amounts as major-unit decimal strings and preserve refund/adjustment signs.
3. Provide each input table as {"rows":[...]} for JSON or {"csv":"header\ndata","mapping":{...},"defaults":{...}} for CSV. The input tab contains a synthetic multi-processor CSV example. Reuse saved mappings in an Apify Task for subsequent periods.
4. Declare transaction coverage by payout expected-arrival dates and bank coverage by posting dates. Mark a scope complete only when its relevant exported records are included. Set a fixed asOf UTC timestamp and your calendar-day arrival-review threshold.
5. Supply depositLinks using exact payout/deposit IDs and the same context. Download the full JSON, all-evidence CSV, review-queue CSV or standalone HTML and review unresolved rows.

An unrelated credit with an equal amount or nearby date remains unlinked. The Actor never matches it automatically. When one deposit covers multiple payouts, each link must specify a signed allocation, and all allocations must conserve the complete deposit amount. An invalid split quarantines every link to that deposit.

Input and CSV mapping

Total JSON input is limited to 2 MB and 10,000 combined table rows; split larger periods or accounts into separate runs. IDs remain strings, including leading zeros, and are case sensitive. Dates use YYYY-MM-DD; asOf uses YYYY-MM-DDTHH:mm:ss.sssZ. Amounts permit a minus sign, at most 18 integral digits and no more fractional digits than your declared scale, which must be 0–4. Exponents, separators, numeric JSON amounts and ambiguous date formats are rejected.

Table	Required normalized fields	Optional fields
transactions	processor, account, currency, id, category, gross, fee, net	payoutId, date
payouts	processor, account, currency, id, amount, status, expectedArrivalDate	mode: automatic, manual or instant
deposits	processor, account, currency, id, amount, postingDate	reference
depositLinks	processor, account, currency, payoutId, depositId	allocation

Payout status is paid, pending, failed or canceled. CSV column names default to normalized field names. A mapping goes from normalized field to exact CSV column: {"id":"balance_transaction_id","payoutId":"automatic_payout_id","category":"reporting_category"}. Defaults supply fields absent from the CSV, for example {"processor":"stripe","account":"merchant-alias","currency":"USD"}. A field cannot have both a mapping and a default. CSV supports UTF-8 BOMs, quotes, quoted commas/newlines and explicit comma, semicolon or tab delimiters. Empty optional cells are omitted. Duplicate, blank or padded headers and irregular rows are rejected. Extra CSV columns are ignored; remove unrelated personal columns before uploading. Unknown normalized JSON fields are rejected.

Stripe itemization recipe

Export the itemized payout reconciliation report, including balance_transaction_id, automatic_payout_id, reporting_category, gross, fee, net and currency. Map the first three fields as above; map the monetary fields directly and provide processor/account defaults. Set transactionCoverage to the expected-arrival range used for the report, not the original charge creation range. Supply a separate payout table with exact payout IDs, signed amount, explicit status and expected-arrival date. This recipe is a mapping guide, not an authenticated integration or complete fee/accounting analysis. Preserve signed amounts exactly; no currency conversion or automatic sign inversion occurs. Manual/instant activity without explicit payout IDs stays unresolved.

Shopify export recipe

Shopify's documented payout CSV includes amounts, fees, net, type and payout timing/status information, but does not establish a stable payout ID or currency for this join. Supply your explicit processor/account/currency context and a stable caller-owned transaction ID. Map gross to Amount, fee to Fee, net to Net and category to Type when those are your actual headers. For a file you have independently assigned to one exact payout, supply a payoutId default. For mixed payouts, add an explicit payout-ID column before uploading. Do not use payout date as an authenticated payout identity. Without an explicit ID, records remain unassigned. A payout-table status must be normalized to the supported values; the Actor does not reinterpret provider status names or localized decimal/date formats.

Output and interpreting uncertainty

One dataset item contains the complete summary, declared scope and flat rows. The Console has overview and evidence views. You can download the dataset in formats such as JSON, CSV or Excel; the separately prepared KVS exports contain the complete nested report or flat evidence.

Evidence field	Meaning
kind, processor, account, currency, relevant IDs	Scoped transaction, payout, deposit or link identity
status, transactionStatus, bankStatus	Agreement, review, unknown, pending/failed or bank not checked
expected, observed, residual	Exact decimal arithmetic; residual is observed minus expected
transactionGross, transactionFee, transactionNet	Eligible signed itemization totals on payout rows
linkedAmount, bankResidual	Usable explicit allocation total and linked-minus-payout residual
issues, sourceRefs	Reason codes with severity and source table/row pointers

Identical repeated IDs are counted once and flagged as duplicate exports. Conflicting IDs are quarantined, with all source rows retained. A malformed gross-minus-fee calculation is excluded from payout sums and makes that payout itemization unknown. Complete supplied itemization with a differing total produces a variance; incomplete coverage cannot produce a clean agreement. Manual/instant payout itemization remains unknown when unassigned activity exists in the same context.

Omitting deposits means bank not_checked; {"rows":[]} is an explicitly empty bank export. Pending/failed payouts are distinct from absent bank evidence. A paid payout beyond your caller-defined delay without an explicit link yields a review item only when complete bank coverage includes expected arrival through asOf. This is not a missing-money conclusion. Delay uses UTC calendar days, excludes the exact threshold day and applies no weekend/holiday calendar. Future and out-of-window evidence remain unresolved. The coverage declaration cannot be independently verified by this Actor.

Full JSON must be below 8 MB and every generated export below 9 MB. High-conflict input can expand beyond these limits and be rejected before a report event. CSV formulas are neutralized with an apostrophe, including negative-looking amount cells; use the JSON for machine arithmetic. HTML escapes content and uses no external scripts or resources. Download the HTML attachment and open it locally.

Price and repeated use

The launch price is $0.50 per completed report, with platform usage included and no separate startup or dataset-item fee. A separate new run is billable again, even for the same input. Same-run resurrection checks input fingerprint and complete saved-report integrity, restores convenience exports and retains one dataset item and one report charge. If delivery is interrupted before the event charge, some uncharged convenience files can remain; recovery verifies or regenerates the report. Deleting or modifying a charged dataset blocks recovery. Billing and dataset writes are separate operations; ambiguous persisted states fail closed.

Schedule an Apify Task or call the API for each new exported period. Saved mappings reduce repeated setup, but you must still supply authorized current evidence and honest coverage. Check the Store pricing tab for the active price before running.

Data handling, limits and support

This is a cloud report, so uploaded data and exports are stored in your Apify run's storage under the platform's retention and sharing settings. Use authorized minimized records and pseudonymous account keys, remove names, emails, bank/card numbers and unrelated columns, and review your own access/retention settings. The Actor does not log customer rows. It makes no external data/model requests and needs no processor/bank token.

It provides operational arithmetic evidence, not financial/tax advice, a fraud allegation, fee-policy assessment, source authentication, FX conversion, a clearing-account balance, a GL journal or payment execution. Native processor reports and existing accounting tools remain appropriate when they already cover your workflow. Use the Issues tab to report a reproducible mapping or calculation problem with synthetic minimized data; the API tab provides integration examples.