Include only documented completed amounts that meet the provider's requested period and scope. Do not total every attempted amount or treat a pending payment, required customer action or uncaptured authorization as a completed payment. Preserve the original export and place excluded or unresolved records in a separate reconciliation. If the request also asks for attempts, declines, refunds or disputes, supply those categories distinctly rather than deleting them from the history.
For: A research-only business preparing requested processing history from an export containing completed payments and unsuccessful or unfinished attempts.
Read the provider's request for the account, legal entity, period, currency and measure it wants. Completed processing volume, attempt counts and net receipts answer different questions. If the request leaves its measure unclear, label your working total explicitly and obtain clarification before presenting it as the requested figure.
Keep the downloaded export unchanged. In a working copy, preserve each row's payment reference, exact status, amount and timestamp, along with the field names. Identify whether a row represents a payment, an attempt or a later event. A row count is not a count of completed payments until that distinction is established.
Group records by their genuine provider references, not by equal amounts or similar customer details. Where several rows document the same payment, retain their relationship but count the completed amount only once. Where the relationship is missing, leave it unresolved rather than guessing which row is a duplicate.
Use the payment state to interpret the amount
For Stripe, the PaymentIntent status is more specific than the Dashboard's summary label. Stripe documents succeeded as a completed payment flow. processing is still pending for asynchronous methods, and requires_action means an additional step is needed. Neither pending processing nor required action establishes a completed amount merely because an amount field is populated.
requires_capture needs particular care: Stripe maps it to uncaptured or partial capture. Do not count the full intended amount as completed volume. Inspect the actual capture record. If the provider's requested measure includes a documented partial capture, use only that captured amount and identify the remaining authorization separately. Without the capture evidence, the amount remains unresolved for this calculation.
Stripe also distinguishes issuer declines, blocked payments and invalid API calls. A blocked payment does not obtain issuer authorization, and invalid calls typically do not appear as payments in the Dashboard. Therefore an integration log and a payment export may cover different sets of attempts. Do not treat an error-log amount as a sale, or claim an export measures every failed attempt when its coverage does not establish that.
Preserve the reporting period and later adjustments
Record which event date places a completed amount in the requested period and which time zone the report uses. A payment's creation time and the time it completed need not answer the same reporting question. Use the requested basis consistently; do not move a still-pending attempt into completed history simply because it started inside the period.
A current status is evidence of what the record says when retrieved. If the provider wants the state at an earlier cutoff, locate the relevant dated record instead of assuming today's status was already true then. Keep amounts in their recorded currency and resolve any requested conversion basis separately.
Stripe notes that later refunds and disputes are on the Charge, even when the PaymentIntent still says succeeded. A succeeded-only filter therefore cannot, by itself, produce a refund-adjusted or dispute-adjusted total. Retain those events where the request requires them, and state whether the submitted total is before or after the requested adjustments. Do not silently remove a successful payment to conceal a later refund or dispute.
Make the filtered result explainable
The working reconciliation should separate included completed amounts, excluded attempts and unresolved rows, with a reason and a source reference for each. Keep failures available if the provider asks for the full history. Excluding an unsuccessful attempt from a completed-volume sum does not authorize omitting it from a request that expressly includes unsuccessful activity.
An unexplained difference between this calculation and the requested statement remains a difference to investigate. It is not a balancing entry to invent. The usable result is a traceable total with its exact scope and disclosed gaps, not a larger-looking figure assembled from every amount column.
For a Prism processing consultation, describe the provider's history request and the distinction your export does not make clearly. Use the processing service page to scope help organizing that question. Scope, responsibilities, fees and terms are agreed before work; a prepared reconciliation does not establish underwriting approval. Keep the export and customer-level records out of the public consultation form.
Attempt-to-completed-volume filter
Apply these fields to each genuine payment group in a working copy of the export. Keep the original intact. Use included, excluded or unresolved with a reason; sum only documented amounts meeting the requested definition. Preserve excluded rows for any broader history request and keep the detailed register inside your authorized records system.
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.
Attempt-to-completed-volume filter. The last column is for temporary notes.
Filter field
Record to inspect
Inclusion rule
Your finding
Requested scope
Record to inspectThe provider's written measure, account, entity, currency and period.
Inclusion ruleA completed-volume subset does not replace a request for full activity.
Payment reference
Record to inspectThe provider payment reference and any attempt or event references belonging to it.
Inclusion ruleRetain the relationship and avoid counting several representations of the same completed amount.
Actual payment status
Record to inspectThe specific provider field, such as Stripe PaymentIntent status, plus the observation date.
Inclusion ruleSeparate completed flows from processing, required action, failure and unresolved states.
Captured amount record
Record to inspectThe actual capture evidence, currency and amount; investigate requires_capture rather than assuming the full amount was captured.
Inclusion ruleInclude only supported completed amounts under the requested measure; leave missing capture evidence unresolved.
Reporting period
Record to inspectThe event timestamp and time zone relevant to the provider's requested date basis.
Inclusion ruleA current status does not prove the state at a historical cutoff.
Refunds and disputes
Record to inspectCharge-level adjustment records where the request includes them.
Inclusion ruleA succeeded PaymentIntent does not establish the absence of later adjustments.
Reason for inclusion
Record to inspectThe classification, supporting reference and any unresolved mismatch with the requested statement.
Inclusion ruleRecord included, excluded or unresolved; do not fill gaps with invented amounts.
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.
Limits
This is an evidence-reconciliation worksheet, not a universal provider reporting formula, accounting opinion or eligibility determination.
The stated status meanings apply to Stripe. Other providers' exports require their own field definitions.
Keep customer records, card data, full account details and original financial exports out of the public inquiry.
Payment status updates — checked 2026-09-21. Stripe distinguishes succeeded, processing, requires_capture and requires_action. Dashboard labels summarize the payment; later refunds and disputes are recorded on the Charge. These meanings do not define a prospective provider's requested volume formula.
Stripe declines — checked 2026-09-21. Failures include issuer declines, blocked payments and invalid API calls. Blocks do not obtain issuer authorization, and invalid API calls typically do not appear as payments in the Dashboard.
Discuss my processing options
Want to talk through your own processing situation?