Two historical reports disagree at the month boundary

Define the requested month before choosing its total

A month label is not a complete reporting definition. Copy the provider’s requested dates, account, legal entity and type of history. Then identify whether it wants payment activity, balance activity, fees or bank receipts. Those records can concern the same business while measuring different events. Do not assume that the file with the word monthly in its title answers the request.

Keep the original file names, export times, filters and report descriptions with the records. Where the request leaves a timezone or date basis unstated, write that uncertainty beside the report you can supply. You can prepare a clearly labeled comparison while awaiting clarification; you cannot call an inferred basis the provider’s requirement.

Separate a clock conversion from a different financial event

For each timestamp, read the zone or offset from the report definition or export settings. Do not infer it from the merchant’s address, the browser clock or a date that happens to resemble local time. If a record provides no timezone, mark it unresolved before converting it. Preserve the original timestamp alongside any normalized value and use the offset applicable to that date, including any daylight-saving change.

Converting a clock preserves the underlying instant. Choosing a different event date changes what the period measures. Stripe’s Fees report documents incurred-at and balance-transaction date bases; a fee’s incurred date and its balance effect answer different reporting questions. Changing the display timezone cannot make those two events the same event.

Stripe also distinguishes when funds become available from the payout schedule that sends funds, with bank posting potentially later. A bank-receipt month is therefore not a substitute for the requested payment-history month. Use the event named by the request, and retain other dates as reconciliation evidence rather than blending them into one total.

Make the start and end rules explicit

Record the start boundary, end boundary and the report’s inclusion rule. A date picker showing the last day of the month may cover that full day, while a timestamp filter ending at the start of that day would cover a different period. Read the tool’s actual definition. Do not add or subtract a day solely to force agreement.

For a separate comparison calculation, you can express a calendar month as starting at its first midnight, included, and ending at the following month’s first midnight, excluded, in the agreed timezone. That is a transparent comparison convention, not a claim about the default behavior of either reporting tool. Translate each tool’s documented settings to that interval and record how you did it.

Trace real rows around the boundaries by their existing references. Identify which rows are included in one report but excluded from the other, and whether the difference follows from timezone, date basis or filtering. Do not move a transaction between original files or overwrite its recorded date. If a report supplies only totals, state that a row-level boundary explanation remains unverified.

Explain the remaining difference without manufacturing agreement

Compare totals only after matching the account scope, currency, event basis and time interval. Maintain a separate adjustment schedule that ties each explained difference to genuine rows. Do not combine currencies as though they were one amount, count two exports of the same activity twice, or insert an unexplained balancing figure.

Even matching dates may leave different coverage. Stripe’s Fees report covers most balance-paid fees and excludes specified categories such as Terminal devices, Capital, Atlas and fees invoiced after use. Data can take up to 96 hours after affecting the balance to appear. Stripe also notes that revenue-share treatment can differ in a balance comparison. These are checks to apply when those reports are involved, not a diagnosis of every month-end discrepancy.

The application packet should identify the original reports, their definitions, the basis selected for the requested total, the evidenced adjustments and any unexplained remainder. If both reports are internally consistent but measure different events, label both rather than declaring one wrong. If aligned definitions still leave a difference, ask the report owner about the specific unmatched rows.

A Prism processing consultation can discuss how to organize this history and the provider question it needs to answer. Describe the report names and unresolved period definition; keep statements, account details and customer rows out of the public form. Scope, responsibilities, fees and terms are confirmed before work. The provider decides whether the evidence satisfies its request.

History period alignment table

Use paired entries for the two actual reports. Preserve originals and put any normalized calculation in a separate file. Work down the table before comparing totals; an unknown timezone or event basis prevents a definitive boundary explanation. Record file locations and definitions, not customer rows or full account numbers.

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.