A PayPal report export leaves gaps: 31-day windows, a three-hour delay and a per-request record cap

What the report call allows

PayPal's Transaction Search API lists transactions for a date range with a maximum of 31 days; the end date is required. Executed transactions can take up to three hours to appear. A page holds 100 results by default and up to 500, and the call covers the previous three years. Each transaction has an event code, an amount and a fee amount. PayPal's reference page does not state a ceiling on how many records one request may cover. A third-party source, Airbyte's PayPal connector documentation, says PayPal caps a transaction search at 10,000 records, refuses a window that would exceed it with a RESULTSET_TOO_LARGE error (message "Result set size is greater than the maximum limit"), and that the connector copes by retrying the window as smaller date ranges. Treat the exact figure as third-party documented and confirm it for your own account. These limits are the reason a naive "export last month" request either fails or returns only part of what you expect.

Where gaps and double counting come from

A window that ends at "now" includes hours that have not appeared yet, so the next window starts after them and they are never read. According to that third-party documentation, a window with more records than the cap is refused with an error rather than returned in part, so the gap risk is a script that logs that error and moves on, or treats it as an empty result. Treat it as a signal to halve the window, never as no data. Reading only the first page returns 100 rows. Overlapping windows, chosen as a safety margin, duplicate rows unless the consumer deduplicates. Time zones turn a day boundary into two different sets of rows.

• Always read every page and compare the total of rows with any total the response reports.
• Do not treat a window ending inside the delay as final.
• Record the time zone used for each window.
• Never treat a too-large error as an empty result: shrink the window and read it again, and log that you did.

A window plan

Choose fixed, non-overlapping windows, comfortably inside 31 days and small enough that a busy window stays under the per-request cap (third-party documentation puts it at 10,000 records); if a request is refused as too large, halve that window and read it again. Lag the end of each window behind the present by more than the documented three hours, and re-read the most recent window on the next run to pick up late arrivals, deduplicating by transaction identifier and event code. Because PayPal can return two records that share a transaction identifier, include the event code and amount in the key. Finish every run with a count and a total per window and keep them.

A safe first investigation

Pick one busy day. Request it in a single call and again in smaller windows. Compare row counts and totals, and look for rows missing between the end of one window and the start of the next. Use invented or sandbox data when testing any export you will schedule.

• A count difference with equal totals is worth checking row by row.
• A difference at the end of a window may point at the delay.

What fits, what does not, and how it is accepted

Report windows matter in two paid jobs. In "Make PayPal refunds and fees appear in the ledger once each, linked to their sale" (from £445) the report is the replay source. In "Make a scheduled finance export to Google Sheets complete, current and honest on failure" (£245) the export is checked against a source total. Both prices are untested and confirmed after your enquiry, with payment after the agreed checks pass and you sign off.

Neither job decides which transactions belong in your accounts or alters PayPal data. This guide is written from vendor documentation read on 11 October 2026 and nothing was run against a live account. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.