One bank credit appears to cover several payout references

Start with the posted credit and a candidate list

Choose the bank entry you cannot allocate and record its posted amount, currency, date and a masked reference. Keep the complete bank record in the authorized accounting system. Then list each candidate payout separately, using the provider's payout reference, amount, currency, current status and expected arrival date where one is shown.

Do not begin by adding store orders until their total resembles the credit. Stripe describes a payout as money sent from an available balance to the bank. That payout record is the relevant provider-side amount for this comparison; the gross customer payments behind it are another level of detail.

Record why each candidate was included and whether it has already been matched to another bank entry. A reference appearing in two proposed allocations is an unresolved duplicate. Keep the candidate list intact while you investigate instead of silently removing the rows that do not fit.

Use the report for the payout type it covers

For Stripe automatic payouts, the payout reconciliation report connects payouts with settlement batches and includes expected bank arrival dates. The report can include transactions from earlier periods. That means the date of a customer payment need not identify the bank entry receiving the later payout.

An expected arrival date is a provider expectation, while the posted date belongs to the bank record. Stripe says bank posting can take additional time. Compare the dates as separate fields; do not manufacture a fixed matching window and then treat every payout inside it as a component of the credit.

The automatic payout report is not a universal allocation report. Stripe says the business reconciles instant payouts because Stripe cannot identify their included transactions. Identify the actual payout type before deciding which evidence can explain it. Another provider needs its own payout and remittance records rather than Stripe's report definitions.

Read the status as well as the amount. Stripe's documented payout-failure path allows a payout first marked paid to become failed later. A historical paid label alone therefore cannot settle an unresolved bank match; use the current status and any relevant failure or return record.

Separate arithmetic agreement from reference agreement

First compare currencies. Amounts in different currencies cannot simply be added and matched to a credit in another currency. Where a conversion is involved, retain the provider and bank records that explain the actual conversion and credited amount. Do not infer an exchange rate just to close the difference.

Then sum the actual candidate payout amounts in the same currency and compare them with the posted bank amount. An exact total supports a possible grouping. It does not identify the grouping, because the amounts alone do not establish which references the bank entry represents. If the total differs, leave the remainder visible; do not assign it to a fee, conversion or adjustment without a corresponding record.

Finally, seek the remittance detail, bank reference mapping or written confirmation that connects the particular credit to the listed payout references. Neither Stripe's payout description nor its automatic payout report, by itself, establishes that your bank combines several payout records into one line. The many-to-one relationship must be supported by the actual records.

Confirm the allocation only to the extent that the reference evidence covers it. If evidence identifies some components but leaves others unmapped, keep the unresolved components and remainder separate. Do not mark all candidates reconciled because one reference is confirmed.

Turn the missing link into a precise inquiry

Your internal result should say whether the grouping is a candidate, a supported allocation or a partly explained credit. The next question follows from the missing field: request remittance detail for an unmapped credit, ask which bank reference corresponds to a named payout, or ask for the record explaining a specific difference. Include masked references and record locations in the worksheet, not complete bank details.

For a Prism processing consultation, describe the website, research-only products and the unresolved many-to-one matching question. Explain what the currency comparison, totals and reference evidence establish. Any requested reconciliation assistance needs a confirmed scope, responsibilities, fees and terms; the provider and bank retain their payout responsibilities.

The public contact form is for the question, not bank statements, customer records, passwords or card information. Follow-up is by email. Sending the request does not submit a processing application, purchase a service or guarantee recovery of an unmatched amount.

Bank-entry payout matching table

Complete one sheet for one posted credit. In the candidate rows, list each real payout separately within your notes, preserving its amount, currency and status. Mark the match confirmed only where actual remittance evidence connects the references; otherwise keep it candidate or partially explained.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.