Two read-only routes: the New Expense trigger reacts to activity, and the Find Expense search answers a question about existing records.
Find Expense
Filter on any combination of Merchant, Search Text, Category, Group
or Tag, Start Date, and End Date. Dates are YYYY-MM-DD and the range
is inclusive. Search Text covers supported expense fields including merchant,
category, and structured Notes.
The search returns up to 20 matches, each with the expense ID, date, merchant, amount and currency, the original amount and currency where the charge was in another currency, category, group, Notes, and a review link.
That 20-result cap matters for design: Find Expense is for answering "does this exist" and "what matched", not for pulling a month of data. Use a report for that.
New Expense trigger
Fires when a recent expense appears, returning the same shape. It is a polling trigger — the right tool for reacting to activity, the wrong tool for exporting a large historical ledger.
Approval patterns worth building
- Threshold alert — New Expense → Filter on amount above your limit → notify the approver with the review link.
- Client check — New Expense → Filter on the client group → post to that client's channel.
- Reconciliation lookup — an inbound invoice or statement line triggers Find Expense on merchant and date range; a Path handles "found" and "not found" differently.
What approval means here
These steps read. They do not mark anything approved, and ExpenseBot does not run unattended approval. A Zap can route an expense to a human and give them the review link; the decision stays with the person. A Zap that completes does not prove anything downstream reconciled.