Software collection playbook

Ramp: prove complete expense collection

Complete expense rows versus visible virtualized cells.

By Sam Yang · Updated 2026-10-07

Have you collected card transactions and reimbursements as different populations?

Choose the Ramp card-transaction or reimbursement source before totaling expenses. A file covering all available history is not automatically a selected-month export, and the two reports need separate coverage checks.

Evidence basis: Saved native Transactions and Reimbursements export observations. The observed row-count check proves collection coverage, not financial reconciliation; current filters and report access need verification.

Verify supported API objects and complete record scope. Use native exports where an essential financial field cannot be retrieved through authorized API access.

The question concerns card transactions for one accounting month

The saved native export covered the rendered transaction history; it did not establish an export date filter. Retain the original and verify the actual date field before deriving the selected period.

Employee reimbursements are part of the expense review

Collect the separate reimbursement population and its native status and payment evidence. Do not assume the card transaction file includes it or that a reimbursement record proves bank settlement.

Use supported API or native report access for the required scope. A permitted browser session can collect a specific gap. Neither route proves reconciliation or complete costs.

Put the evidence to work

The expense grid exported successfully. Do we now have every expense that belongs in the close?

First define the population and period. A viewport can omit later rows, a default API population can omit a requested state, and a changing transaction can appear in different versions. Prove the selected coverage, then review accounting dates and booked identities separately. A completed collection does not prove a completed close.

Prove a transaction collection is complete for its defined scope

Choose the company/entity, currency, date field, period and transaction states needed for the question. A spend review and a review of declined attempts have different populations.
Use an adequate permitted API or verified native export when available. Retain IDs, the selected filters and actual received files; do not substitute the visible viewport for the requested population.
For API collection, follow documented pagination and retain returned IDs. For rendered collection, retain each observed page/range and horizontal fields for the same rows.
Compare collected IDs and counts with the source control for the same population. Detect repeats and missing ranges; keep repeated versions rather than silently selecting one.
Record completion only for the verified scope, with exceptions and collection time. Separately inspect any fields that the chosen source cannot supply.

Bring to the review: A population receipt with scope, unique IDs, received files, observed counts/ranges and change exceptions.

Then decide: Recollect only an affected interval or record when coverage or versions disagree. Do not call an unqualified native CSV or a screenshot a complete transaction source.

Bridge selected Ramp activity to booked accounting

Retain the transaction ID, source state, transaction date, accounting date and currency where supplied by the qualified source.
Keep card purchases, reimbursements and bill-payment populations distinct. A common spend-management interface does not make them one ledger source.
Collect the corresponding accounting destination and booked entry evidence. An accounting connection or sync-ready state does not establish that the exact entry posted.
For a transaction spanning periods, explain which date drives the selected accounting review. Keep the source view and book view as separate populations.
Return missing booked identities, date differences, incomplete source coverage and version changes as separate exceptions.

Bring to the review: A source-to-book exception report with transaction identity and the evidence supporting each claimed link.

Then decide: The reviewer resolves timing and classification, and verifies posted results through the accounting workflow. Download completion is a collection state, not proof of reconciliation.

Which collection route answers this question?

Choose the route for the missing evidence and the access available in your account. The comparison below distinguishes documented coverage from coverage that still needs checking.

Supported transaction API

What it supplies: Ramp documents a transaction-list route with filtering/ordering; its default population excludes declined transactions when state is not specified. Authorization scopes and required population must be checked.
What still needs proof: The default result is not every conceivable spend-management record. Exact state filters, fields and permitted account scope require current validation.

Choose it when: Prefer supported reads when they cover the required identities, dates and states; add an explicit state population when the question includes declined attempts.

Verified native file

What it supplies: An available native file can preserve report-specific columns and selected filters. Retain original bytes and compare the file's population with the source control.
What still needs proof: The saved rendered collection did not qualify native CSV coverage. This guide does not convert that observation into a universal Ramp export limitation.

Choose it when: Use the file after its actual scope, rows and required fields are demonstrated.

Permitted rendered browser collection

What it supplies: Saved evidence establishes collection across multiple rendered ranges with retained custody, separate from native CSV.
What still needs proof: Visible cells are not the whole grid; scrolling and repeated reads do not create a transactional snapshot. Current fields and page limits may differ.

Choose it when: Use it for a specific missing authorized source population or detail, retaining stable IDs and change exceptions.

Reproduce the diagnostic

A complete-looking capture with one changed record

All records and amounts below are fictional teaching inputs. This example demonstrates the calculation, not a customer outcome or a reproduced software defect.

Earlier capture totals 120 + 80 + 50 = 250 across three rows. Later capture totals 120 + 80 + 60 = 260 across three rows. Counts agree, but T-03 changed by 10. Adding both reads would incorrectly report 510.

What the CSV columns mean

All rows and identifiers are fictional teaching data in USD, not a Ramp export or customer result.
capture identifies an illustrative earlier or later read. amount is a positive spend amount; compare versions by transaction_id instead of adding captures together.
The supplied capture sets describe the same three selected transactions. The example does not establish why T-03 changed or which accounting period it belongs in.

Earlier capture total: 250 USD; One observed version of the three-record population.
Later capture total: 260 USD; A later version, pending authoritative review.
Version total difference: 10 USD; T-03 changed; equal counts did not establish a frozen snapshot.
Incorrect combined-read total: 510 USD; A demonstrably wrong way to count this supplied population.

Inspect capture-versions.csv

capture,transaction_id,amount
earlier,T-01,120
earlier,T-02,80
earlier,T-03,50
later,T-01,120
later,T-02,80
later,T-03,60

Download this CSV

Next decision: Inspect T-03's authoritative current state and preserve the version exception. Use one qualified population for a subsequent review, not the sum of repeated reads.

Expected results and calculation checks Download the reproduction code

Run the example locally

Save the CSV files, expected-results.json and reproduce.mjs in one folder. With Node.js installed, run the command below. It calculates the checks from the CSV bytes and rejects a changed input or expected result.

node reproduce.mjs expected-results.json

No software login, customer records or API key is required.

When the result does not make sense

The file opens and its first rows look right, but the total is low.

Check: Compare the selected population, date field and transaction state with the requested question. Inspect page/range coverage and source counts.

Resolve the question: Collect the missing qualified population and label the previous result partial; do not fill an absent interval with zero.

The same transaction ID appears with two different amounts.

Check: Check collection timestamps and source versions. This may be a changed record rather than two separate spend events.

Resolve the question: Retain both versions as a conflict and obtain the current authoritative record. Do not sum them or silently choose the larger amount.

The accounting connection is healthy but a transaction is not in the ledger.

Check: Inspect the specific transaction's source state and destination record, then compare date/entity scope. Connection health is not an entry read-back.

Resolve the question: Return the missing or pending identity for review. Keep collection, sync eligibility and confirmed posting as separate states.

Where automation earns its place

Good work for automation

ID-based collection receipts, missing-range checks, field completeness and version comparisons make repeated collection more useful than screenshot totals. Supported API reads are usually the simpler route when their scope is adequate.

Keep a person on these decisions

A reviewer decides which date, entity and expense type belongs in the close and resolves changed records with original support. Neither an AI browser nor an accounting connection chooses the correct treatment from a plausible total.

References behind these workflows

Product documentation supports the specific scope stated beside each source. Level's diagnostic methods and fictional calculations remain distinct from vendor capabilities.

Ramp transaction API reference
Transaction list schema and documented default exclusion of declined transactions; not proof of complete close coverage. Reviewed 2026-10-07.
Ramp authorization scopes
Read versus write scopes and accounting metadata access, with actual grants to verify. Reviewed 2026-10-07.

Explore the financial diagnostic examples

Collect and verify the population

Native Transactions CSV: The saved route used Export (CSV) and compared retained rows with the rendered transaction count. Preserve the complete native file and inspect its actual history.
Native Reimbursements CSV: Keep its count, identities and status population separate from card transactions; row-count equality establishes coverage only.
Requested-period and ledger handoff: Derive the requested dates from the retained native fields, then review accounting destination and payment evidence separately. A successful export is not a reconciled expense total.

Use a verified native export or collect the complete authorized grid by stable record ID. Retain all requested date ranges and actual received files. Detect missing IDs, repeats and changes during collection.

Evidence acceptance checklist

Define the transaction or expense population and date range.
Retain stable record IDs beyond the visible viewport.
Detect repeated, missing or changed records across collection pages.

Fictional collection example

A fictional expense grid shows the first page successfully, while later pages contain additional transactions. Return the requested population and observed coverage separately. Re-reading a changing grid can also return a different record version; collect the change as an exception rather than assuming a frozen snapshot.

Invented teaching scenario, not a customer result or a reproduced vendor defect.

Capture the setup with the evidence

Company, legal entity or account, report name, period, basis, currency and timezone.
Selected filters, status, page count, original record identifiers and control totals.
Collection time, source route and authorized role. Record browser and automation versions when using a browser.
Original files and exceptions. Keep credentials, customer identifiers and financial artifacts private.

A browser version helps reproduce an interface issue. It does not validate the financial conclusion.

Pitfalls and stop conditions

The visible viewport is not the whole population. Repeated reads do not guarantee a transactional snapshot. A successful download does not establish accounting reconciliation.

How a plausible answer can go wrong

A full-history transaction file compared directly with a monthly ledger produces a population mismatch. Collecting that file alone can also leave reimbursement costs unreviewed, even when every card row was retained.

Stop if account identity, permission, cutoff or population is uncertain. Return the missing evidence for review. Do not fill the gap with an invented record, a balancing entry or an assumed zero.

Read-only AI collection prompt

Replace the bracketed scope before use. This prompt collects evidence; it does not permit edits, approvals or accounting execution. Requesting an emailed report is a separate account action and requires explicit authorization.

Collect read-only evidence for Ramp to answer [financial question]. Confirm [company], [account/entity], [period], [basis], [currency] and [allowed reports]. Use a verified native export or collect the complete authorized grid by stable record ID. Retain all requested date ranges and actual received files. Detect missing IDs, repeats and changes during collection. Retain original files, complete record IDs, counts, filters, collection timestamp and exceptions. The visible viewport is not the whole population. Repeated reads do not guarantee a transactional snapshot. A successful download does not establish accounting reconciliation. Stop if the source or scope is uncertain. Do not post, match, reconnect, delete or change settings. Return the evidence for financial review; do not claim the books are correct. Do not approve, submit payroll, pay, transfer, refund, send messages, invite users or accept terms. Stop at any login, MFA or credential prompt and hand back to the account owner. Store files only in [approved private location]. Do not paste customer artifacts into public tools. Use only preauthorized collection actions. Request an emailed report only when its delivery is explicitly authorized; otherwise ask the account owner to supply the file.

Next decision

What does the evidence support?

Can another reviewer reproduce the selected-period card and reimbursement populations separately from their original files? Use that handoff to investigate ledger and payment differences, with unresolved identities or dates explicit.

Compare the same population, identities and cutoff. Keep unsupported costs or settlements visible before using the result for pricing, cash or close.

Open the financial acceptance guide →

Sources and scope

Base product-reference scopes were reviewed 2026-10-06. No end-to-end dated native UI walkthrough is published for this software. Individual source rechecks are dated with their citations. Operator decision guidance was reviewed 2026-10-07. The references below support their stated product scope, not every observed interface detail. It is not a vendor capability certification, a measured customer result or an independently reconciled account. Verify current features and entitlement in the account you use.

Ramp read and write permission scopes
Read and write scopes, not UI snapshot guarantees.

Content revision history