AI Browser Exports: Verify the Account and Rows

Verify the native report before downloading

A permitted browser can collect a report the supported connector does not expose. The first task is to prove the requested company, period and report definition. After changing a company selector, status filter or page, wait for both the header and final report rows to agree. A visible first page is not necessarily the full population.

Start listening for the application's download before clicking Export. Keep the resulting original file, filename, collection time, report title and selected filters. Avoid changing download settings while waiting. If an export is delivered by email, record that as pending until the actual attachment is retained. A timeout is an unresolved outcome, not permission to repeatedly click a write action.

For a workbook, inspect every required sheet and compare complete IDs, counts and control totals. For a paginated report, record the expected population and confirm every page is represented. Preserve a failed or partial file alongside the exception. Missing cost remains unknown, even when all visible rows link.

Preserve the filters on every page

After navigating from summary to attribution, products or cohorts, read that page's period and filters again. Retain the selected date range, timezone, comparison period, model, window and included population with the file. A previously selected global period is insufficient evidence that a newly opened view uses it. An old saved dashboard or an empty tile also needs investigation before concluding that a feature is unused or its data unavailable.

Triple Whale documents native Google Sheets reporting with report metadata and data tabs. Where authorized and available, evaluate that native route before building a browser collector. A visible Sheet link does not prove that the automation account has access. Preserve an untouched source copy; use a separate copy for transformations. Native collection, API access and browser fallback should all meet the same report-acceptance checks.

Rippling: collect the right population before totaling the grid

Our spend-review code recognizes a display shape with two USD-looking amounts as ambiguous. Resolve the exact amount against native transaction detail before summing it. A rounded grid amount and a precise detail amount are not interchangeable, even if every row has been collected. Likewise, retain original currency separately from the verified reporting-currency amount; do not invent a dollar amount for an unresolved foreign-currency row.

Date selection changes the question. A purchase-date-bounded grid can miss an earlier purchase finalized during the close period. If the question is finalized spend, establish the finalized-date population first rather than filtering purchases and assuming the two sets coincide. This is a timing/population issue, not a claim about the correct expense recognition date.

For a paginated grid, compare declared count, observed row count, native IDs and available row ordinals such as "3 of 25." A declared total supplied by the same capture is not independent proof. Require a populated company identity, not simply two empty identity fields that compare equal. Retain the unresolved differences. These controls inform our Rippling collection playbook; a successful extraction still needs a separate finance review.

Keep a collection receipt that another reviewer can reproduce

Record the actual browser build, automation package version, collection timestamp, selected account, report definition, filters, pagination and original-file hash. A version is a diagnostic aid: it helps distinguish a changed UI from a changed report population. It does not certify the report's numbers or prove that a later collection will work.

Prefer the native export when it provides stable identities and the required definition. Use a permitted browser for a missing native state or report; use an API for recurring eligible records. The acceptance question is the same in all three cases: does this retained source answer the specified financial question, with its limitations visible?

{
  "fictional": true,
  "unit": "USD cents",
  "id": "complete-export",
  "rawRows": 4,
  "distinctRows": 3,
  "coveragePct": 60,
  "missing": [
    "D",
    "E"
  ],
  "costMissing": [
    "B"
  ],
  "completeProfitCents": null,
  "limitation": "This is teaching arithmetic from supplied invented inputs, not source authenticity, financial assurance or authority to post."
}

Browser and API tradeoffs

A supported API is useful for recurring records and stable identifiers. A browser report can supply an exact native definition or UI-only state, but permissions, changed screens and delayed table rendering can make it unreliable. Record the actual browser and automation versions used for the collection. Use the bank-feed review for QBO candidate dates and existing postings; collecting a report does not authorize matching or adding transactions.

The Financial Systems Field Guide contains named-system collection questions, pitfalls and bounded read-only prompts.