Software and accounting guide

Ramp: cards, expenses, bill payments and accounting

Ramp is a business spending platform with corporate cards, expense management and accounts payable tools for reviewing and paying supplier bills.

By Sam Yang · Updated 2026-10-09

How Ramp supports the workflow

Who this guide is for: Owners, office managers and finance teams who need to follow employee spending and supplier payments into the books.

Everyday uses

Review card spending and the receipts attached to it.
Manage employee expenses and reimbursements.
Review supplier bills, approval steps and payment records in the enabled tools.

How it connects to accounting: Card purchases, employee reimbursements and supplier bill payments need separate accounting checks. Keep each source record’s ID and dates, then confirm the corresponding entry in the books. A ready-to-sync status does not prove that the entry posted.

How to connect it and get the records you need

A built-in connection transfers the records its vendor supports. An API lets software read or exchange specific records directly. Browser automation may use the screens and reports your role can access when a direct connection leaves a gap. Its coverage and reliability need checking for the specific workflow. Start with the options available in your account, then check what actually reaches your books.

Supported API

Use documented transaction reads with the required permissions and status filters, and collect every page of results. If the review includes declined attempts, set the appropriate state filter rather than relying on the default results.

Native files

Use an available export after confirming which spending records, dates and fields it includes. Compare its count with the same source view.

Browser assistance

Use the interface for a missing receipt, accounting detail or other exception. A few visible rows are not the full spending record.

Start here: Decide whether you are reviewing a card purchase, reimbursement or bill payment before choosing the export and accounting destination.

Integration options and their limits

An API gives software direct access to supported records. Native reports are the files and reports available inside the product. Browser automation collects through the screens you can access. Choose the route that supplies the missing records, then check that it covers the accounts and dates you need. Reports may contain filters or omit rows. Browser work depends on permitted account access and can fail when screens change. Check record IDs, counts and dates whichever route you use.

Supported transaction API

What it supplies: Ramp documents a transaction-list API with filters and ordering. Its default results exclude declined transactions when no state filter is specified. Check the granted permissions and the records your review needs.
What to check first: The default results do not include every type of spending record. Check the current status filters, fields and accounts you are allowed to read.

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

Verified product export

What it supplies: The dated saved route used Export (CSV) for Transactions and separately for Reimbursements. It retained the downloaded files and checked their row counts against the corresponding on-screen counts. The transaction file covered the available history shown by that report.
What to check first: That collection did not establish an export date filter or prove accounting reconciliation. Check the current file’s dates, statuses and fields before selecting one month. The Transactions file does not establish Reimbursements coverage.

Choose it when: Use the product CSV when its rows and fields answer the question. Keep each original file, then select the requested period using the date fields you have checked.

Authorized browser collection

What it supplies: The saved collector also supports collecting rows shown in the browser when a product CSV is unavailable. It keeps the row ranges and source files. Label this as browser collection rather than a product export.
What to check first: Visible cells are not the whole grid. Records can change during scrolling and repeated reads, so confirm IDs, page coverage and changes between reads. The fallback does not establish that every Ramp account needs browser collection.

Choose it when: Use it for specific missing records or details you are allowed to collect. Keep transaction IDs and flag records that changed during collection.

What to automate and what an accountant should review

Good work for automation

Automation is useful for keeping transaction IDs, finding missing page ranges, checking required fields and comparing changed records. These checks tell you more than a screenshot total. A supported API is usually the simpler route when it supplies the records needed.

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.

Lessons from accounting and operations

Known problems and what to check

Have you collected card transactions and reimbursements as different sets of records?

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: The observed row-count comparison checks the number of rows. It does not by itself confirm the right IDs, dates, statuses, later changes or agreement with the books. Current filters and report access need verification.

Check whether the supported API provides the transaction types, dates and fields needed. Use a product export when an essential financial field is unavailable through the authorized API.

The question concerns card transactions for one accounting month

The saved product 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 records and their status and payment evidence from Ramp. Do not assume the card transaction file includes it or that a reimbursement record proves bank settlement.

Start with an API, connection or built-in report that your account offers and you have confirmed. An authorized browser session may collect records those routes leave out; test its coverage for the workflow. Still check the totals against the books and confirm that all relevant costs are included.

Pitfalls and when to pause

A few visible rows are not the complete collection. Records can change between reads, so repeated collection does not guarantee a frozen copy. A completed download does not establish that expenses agree with the books.

How a plausible answer can go wrong

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

Pause if you cannot confirm the account, permission, reporting dates or completeness of the records. Return the missing evidence for review. Do not fill the gap with an invented record, a balancing entry or an assumed zero.

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 records, date field and transaction statuses with the question being reviewed. Check page and row-range coverage against the source counts.

Resolve the question: Collect the missing verified set of records 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: Keep both versions as a difference to resolve and obtain the current original record. Do not add them together or silently choose the larger amount.

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

Check: Inspect the transaction’s Ramp status and corresponding accounting record, then compare the company and dates. A healthy connection does not replace reopening the actual accounting entry.

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

Collect the records and check nothing is missing

Native Transactions CSV: The saved method used Export (CSV) and compared the downloaded rows with the on-screen transaction count. Keep the complete original file and check the dates it contains.
Native Reimbursements CSV: Keep reimbursement IDs, counts and statuses separate from card transactions. Matching row counts show only that the number of rows agrees; verify the retained IDs and statuses separately. Counts do not prove payment or correct entries in the books.
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 product 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.

Checks before using the records

Define the transaction or expense set of records 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, cash or accrual accounting basis, currency and timezone.
Selected filters, status, page count, original record identifiers, record counts and totals used to check completeness.
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.

Practical workflows

Practical checks you can follow

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

First decide which records and period you need. The visible grid can omit later rows, an API’s default results can omit a status you need, and a transaction can change between reads. Check that the collected records cover the question. Then compare accounting dates and the entries in the books. Downloading the records does not complete the close.

Check that the collection includes every transaction needed for the review

Choose the company, currency, date field, period and transaction statuses needed for the question. Reviewing purchases and reviewing declined attempts require different records.
Use a supported, authorized API or verified product export when it supplies the needed records. Keep record IDs, selected filters and the files actually received. Do not treat the few rows visible on screen as the complete collection.
For an API, follow its documented next-page instructions and keep the returned IDs. For a browser collection, keep each page or row range and any columns reached by scrolling sideways for those same rows.
Compare collected IDs and counts with the source count for the same records and filters. Find repeated IDs and missing pages or date ranges. Keep both versions of a changed record rather than silently choosing one.
Mark collection complete only for the records and dates you have checked. Keep unresolved items and the collection time, and separately identify any fields the chosen method does not supply.

Bring to the review: A collection checklist with the selected records, unique IDs, received files, row counts and ranges, plus any changes found between reads.

Then decide: Collect only the affected dates or records again when counts or versions disagree. A CSV whose contents have not been checked, or a screenshot, does not establish a complete transaction collection.

Compare selected Ramp activity with the entries in the books

Keep the transaction ID, status, transaction date, accounting date and currency wherever the checked source provides them.
Keep card purchases, employee reimbursements and supplier bill payments separate. Their presence in one spending platform does not make them the same type of accounting entry.
Collect the corresponding record in the accounting system and its posted entry. An accounting connection or a ready-to-sync status does not establish that this entry posted.
For a transaction spanning periods, explain which date drives the selected accounting review. Keep the source view and book view as separate sets of records.
List missing accounting entry IDs, date differences, missing source records and changed transaction versions separately.

Bring to the review: A list of differences between Ramp and the books, with each transaction ID and the records supporting its proposed accounting 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.

Worked example

A complete-looking capture with one changed record

All records and amounts below are fictional teaching inputs. CSV files are spreadsheet-compatible text files. 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.

AI prompt for collecting records without changing them

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 can you decide from these records?

Can another reviewer recreate the card and reimbursement lists for the selected period from their separate original files? Use those lists to investigate differences in the books and payment records, and clearly identify any uncertain IDs or dates.

Compare the same records, accounts and reporting dates. List costs or payments you cannot yet verify before using the result for pricing, cash planning or month-end review.

Read the next finance check →

References behind these workflows

Each product reference supports only the features and limits described beside that source. Level's checks and fictional calculations are separate from what the vendor documents.

Read the product and workflow references with their scopes and review dates Explore the financial diagnostic examples

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-09. 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 what your plan includes in the account you use.

Ramp read and write permission scopes
Product reference: Read and write scopes, not UI snapshot guarantees.
Product reference: Read versus write scopes and accounting metadata access, with actual grants to verify. Reviewed 2026-10-07.
Workflow reference: Read versus write scopes and accounting metadata access, with actual grants to verify. Reviewed 2026-10-07.
Ramp product and platform features
Product reference: Corporate cards, expense management and accounts payable product families; no entitlement or automatic reconciliation guarantee. Reviewed 2026-10-08.
Ramp transaction API reference
Product reference: Transaction list schema and documented default exclusion of declined transactions; not proof of complete close coverage. Reviewed 2026-10-07.
Workflow reference: Transaction list schema and documented default exclusion of declined transactions; not proof of complete close coverage. Reviewed 2026-10-07.

Content revision history