This is a close read on cash, not a formal accounting statement. It is the best view we have of money in and money out, and for most month-end checks it is all you need. But it is not double-entry books, so treat it as a strong estimate rather than a signed ledger.
The most common question we get is why this does not match the Revenue details export. It is not supposed to. The two reports answer different questions, and the first section explains how.
How to run it
Go to Payments, then Generate report, then Export client transactions. Set the execution-date filter to the period you want, and the report downloads.
Scope the execution-date filter deliberately. That date is what decides which transactions land in your period, so set it to the exact window you are reconciling -- a calendar month, a quarter, whatever you are checking against.
Cash vs revenue: the one thing to know first
You have two financial exports, and they are built to disagree.
The Client transactions export is a cash view. It counts money on the date it actually moves, whatever trip it was for. A deposit collected in March for an August trip is March money here.
The Revenue details export is a revenue view. It counts revenue on the date the trip runs, whether or not the money has arrived. That same August trip is August revenue there, no matter when it was paid.
So the same booking can land in different months on the two reports, and that is correct. Do not try to tie them to the penny -- a payment's date and its trip's date are rarely the same month. Use this export to understand what you collected. Use the Revenue details export to understand what you earned.
Row types and their signs
Every row is one movement of money. There are three kinds, and the sign tells you the direction.
Payment -- money in. Positive.
Refund -- money back out to the client. Negative.
Settlement -- a balancing adjustment, typically tax. Negative.
Because refunds and settlements are already negative, the amount columns are self-netting. When you sum a column, refunds and settlements subtract themselves automatically -- you do not need to back them out by hand. This matters for reconciliation: a column total is money in minus money back out, not gross collections.
Finding cash and offline payments
Cash and other offline payments appear in the Payment Type column as CUSTOM. The other values are CARD and ACH_DEBIT. These are stored in capitals, so filter for the exact word CUSTOM rather than a friendlier label.
To pull your offline payments:
Run the export with the Payment Type column included.
Open the file and filter or sort that column for CUSTOM.
Sum the amount column on what remains.
The filtering happens in your spreadsheet after the download, not in the export dialog.
In the app, the same information lives in the Payment column on Payments -> Client transactions, which spells out the method on each row -- Cash, Card ending in 4242, Bank account ending in 6789. You can read and sort that column, but the filters there do not include payment method, which is why the export is the better tool for a complete list.
Reconciliation: two things that change your total
If your hand-tally does not match the report, these are the two most common causes.
First, status. Every row carries a status -- Executed, Scheduled, Pending, or Executing. Executed means the money actually moved. Unless you filter to Executed, the export includes scheduled and pending rows for money that has not been collected yet, and your total will run high. If you want only real, completed money, filter to Executed.
Second, netting. As above, refunds and settlements are negative and already netted into any column sum. If you tallied only the positive payments and ignored the negatives, your number will be higher than the report's.
Between those two -- a wider status set, or the refund and settlement netting -- most discrepancies resolve. If yours does not, send it to us.
One difference worth knowing if you are comparing the screen against the file: the Payments tab filters on six statuses -- the four above plus Expected and Failed -- while the export carries only these four. A filtered on-screen list and a download will not always line up row for row.
Using it for monthly sales tax
If your jurisdiction collects sales tax on a cash basis -- tax owed when you actually collect the payment, not when the trip is booked -- this export is the right tool for your monthly filing. It is dated by when money moved and it carries the tax on each transaction, which is exactly what a cash-basis return asks for.
To pull a month's tax:
Set the execution-date filter to the filing month.
Filter to Executed, so you are only counting money that actually moved.
Sum the total tax column. Refunds are negative, so tax you refunded during the month nets out automatically -- which is what a cash-basis return wants.
If you need tax split by category (for example, state versus local), turn on the tax-category columns and sum those.
One caution. This fits a jurisdiction that assesses tax on collection. If yours assesses tax on the sale itself, whether or not it has been paid -- an accrual basis -- then the Revenue details export, dated by trip, is the closer match. Which basis applies to you is a question for your accountant, not something to infer from the report. We are showing you where the numbers live, not advising which return to file.
The columns
Columns are selectable, so your export may show a subset. Here is the full set, grouped by what they tell you.
Identity and client:
ID -- the transaction identifier.
Booking ID -- the booking this money was for.
Client ID, Client first name, Client last name, Client email -- who paid.
Classification:
Type -- PAYMENT, REFUND, or SETTLEMENT.
Status -- EXECUTED, SCHEDULED, PENDING, or EXECUTING. Executed is money that has actually moved.
Payment Type -- CARD, ACH_DEBIT, or CUSTOM. CUSTOM covers cash and other offline payments.
Payment Stage -- deposit, final payment, paid in full, and so on.
Amounts:
Amount -- what the client was charged, tax included.
Total tax -- tax within that amount.
Gross revenue -- amount minus tax. This is your pre-tax figure. Sum this column for period revenue.
Platform fees -- fees on the transaction.
Client fees paid -- the portion of fees passed to the client.
Net transfer amount -- amount minus fees. Closer to what lands in your account.
Timing:
Scheduled at -- when the transaction was scheduled.
Executed at -- when it actually moved. This is what the date filter uses.
Payout:
Booking total, Stripe payout ID, Payout arrival, Payout amount -- payout detail for money on its way to your account.
Trip detail:
Trip start date, Trip end date, Trip experiences, Trip experience types, Trip experience descriptions -- the trip the money was for.
The amount math
The report does the pre-tax math for you.
Amount = what the client was charged, tax included.
Gross revenue = amount minus tax. This is the pre-tax figure -- sum this column for the period.
Net transfer amount = amount minus fees. This is closer to what actually lands in your account.
Refunds and settlements are negative in every one of these columns, so when you sum a column the refunds subtract themselves. A column total is money in minus money back out.
A note on dates and time zones
The timing dates on this report -- when a transaction executed, when it was scheduled, when a payout should arrive -- and the execution-date filter itself all render in Mountain time. That is a system-wide default today, not a per-account setting. For an outfitter in the Mountain zone this is simply your local time.
This matters at month boundaries. A card charged at 8pm on the last day of the month, Mountain time, is correctly counted in that month here. (Underneath, the raw timestamp is stored in UTC, so a direct database or spreadsheet pull that skips this conversion can push a late-evening charge into the next day -- which is a common reason a raw query disagrees with this export by a transaction or two at the edges.)
If you operate outside the Mountain zone and a date ever looks off by a few hours at a boundary, that default is the reason. Tell us and we will sort it with you.
Common questions
Why does this not match the Revenue details export? Because this is cash and that is revenue. See the section above. Money is dated to when it moved; revenue is dated to the trip. Different questions, different months.
Why is my total higher than I expected? Most often, scheduled or pending rows are included. Filter to Executed to see only money that has actually moved.
Why is my total lower than I expected? Refunds and settlements are negative and already netted into the column sums. If you expected gross payments only, the netted refunds explain the gap.
How do I find just the cash payments? Filter the Payment Type column for CUSTOM in your spreadsheet after downloading. There is no payment-method filter in the Payments tab, though the Payment column there does show the method on each row.
Is the amount before or after tax? The amount column is tax-inclusive. The gross revenue column is the pre-tax figure (amount minus tax) -- sum that one for pre-tax revenue.
Is this my official revenue for the books? Treat it as a strong estimate of cash in and out, not a formal accounting statement. It is close, and it is the right tool for a month-end gut check, but it is not double-entry books.
If a number still does not look right after this, send us the report and the figure you expected, and we will trace it with you.