Prove an accounting API export reached the last page

When a finance connector reports a successful download, ask what it completed. It may have received a valid response containing only the first page of records. The export needs a completion condition tied to the API's pagination rules, plus evidence that all accepted pages reached the destination. A request status, a green connection icon or a nonempty spreadsheet cannot establish that the entire accounting population was retrieved.

Stripe's v1 list documentation, for example, describes cursor-based pagination using object identifiers and a has_more response field. Its v2 APIs use a different interface. That is why the connector must follow the documented contract for the actual endpoint and version. Do not transfer pagination assumptions from one API family to another. The review procedure below applies to the completeness of the extraction, while the provider documentation supplies the technical meaning of its cursor and completion fields.

Record the source account, entity, endpoint, environment, date filters and requested status population before the export begins. Include the API version where it affects behavior. Fix those settings for the run. If a filter changes after an interruption, start a separately identified extraction instead of presenting the combined result as one continuous population. This is particularly important when one report includes paid invoices and another includes all invoices created during the same dates.

Distinguish creation time from update time. A transaction created last month may change today, and a created-date extract will not necessarily answer a question about current status changes. Confirm how the endpoint filters and orders records. Where the source can change during the scan, use a supported stable snapshot or another documented extraction approach. Reaching the final page proves that the chosen scan terminated; it does not by itself prove that the source remained unchanged throughout it.

For each page, record a run identifier, request cursor, returned count, first and last record identifiers, next cursor or completion indication, and the destination write result. Keep secrets and full personal records out of this operational log. A short, controlled page manifest gives the team enough evidence to investigate a gap without creating another unrestricted copy of the customer database. Retain the actual exported records in the approved storage location.

The safe checkpoint is the last page whose data has been durably accepted by the destination. If the connector stores the next cursor before it saves the current page, a crash can skip records when the job resumes. If it saves the page and crashes before updating the cursor, a retry may fetch the same page again. Design the destination write so that repeating a page does not create duplicate accounting effects, then advance the checkpoint after the write succeeds.

Use the source's stable record identifier to recognize a repeated record. A timestamp or row position is usually insufficient on its own because several records can share a timestamp and ordering can change. Keep the source account in the key when identifiers are scoped to an account. Separate staging the extracted data from posting entries to the ledger. The staging process can then be retried and checked without immediately repeating a customer charge or journal entry.

An illustrative run receives 250 records in pages of 100, 100 and 50. If the second page is fetched twice during recovery, there are 350 delivered rows but only 250 distinct source records. Reporting 350 as the extracted population would be wrong. Reporting 250 after merely dropping duplicate rows is also insufficient unless the records are the intended versions and the run reached a documented end. Keep page-delivery counts and unique-record counts as different measures.

Treat an empty page according to the endpoint's documentation. Some interfaces can return an empty intermediate result with a continuation token; others use an empty result to indicate completion. A connector should not invent a universal rule. Similarly, an unexpected missing cursor is not automatically the last page. Preserve the response shape, stop the affected run and raise a visible exception when the returned data violates the contract the connector expects.

Detect a cursor that fails to advance, a repeated page sequence and an unexplained change in account or environment. Those conditions can create a loop or mix records from different scopes. Use a maximum-run safeguard to stop an unhealthy job, but label that outcome incomplete. A technical timeout or page ceiling protects the service; it does not convert the partial extract into a complete financial dataset. The report should show that its required population remains unavailable.

Check child collections separately. An invoice-list endpoint may provide invoice objects without every line item or related payment detail. If the analysis needs those children, each relevant collection needs its own retrieval and completeness check. Count the expected parent-child relationships and preserve their identifiers. A completed parent scan can still leave a margin analysis incomplete because some invoice lines were never fetched.

At the end of the run, compare the staged population with a source report or other independent control that covers the same scope. Review record counts and relevant amount totals by currency and period. Explain differences caused by legitimate report definitions before treating them as extraction errors. Sample the beginning, the final boundary and any recovered pages. Those checks support the completion evidence but do not replace the actual pagination manifest.

Record the terminal condition, accepted record count, duplicate deliveries and unresolved exceptions alongside the resulting report. If a later repair changes the population, issue a new extract version and identify downstream reports that need refreshing. Test the connector's recovery behavior with an interrupted nonproduction run that fails between page retrieval and destination persistence. The expected outcome is a complete, traceable population with each intended record represented correctly after the restart.