Zapier and Make differ less in what they can do than in how they ask you to think. Zapier's newer model puts an AI step in the middle of a Zap that can call a remote MCP server and work out the calls itself. Make's model is explicit modules wired into a scenario, where every operation is named and its inputs are visible before it runs. For expense capture — where the steps are genuinely fixed — the explicit model is easier to reason about; for expenses embedded in a larger agentic workflow, the AI step saves wiring. We built the same ExpenseBot integration for both, so this is a builder's comparison rather than a feature table.
Most Zapier-versus-Make articles are written by people who have used one of them. This one is written after building the same integration twice — an expense-capture and bookkeeping integration for ExpenseBot, shipped as a native app on each platform, with the same set of workflows as the target on both sides.
That turns out to be a useful vantage point, because the differences that matter to someone building on these platforms are not the ones that show up in a pricing comparison. Task counts and operation limits are real, and every other article covers them. What follows is the part that is harder to find: what changes about the work when you move the same automation from one to the other.
What We Actually Built
The same job on both platforms: let an automation move receipts and expense data in and out of ExpenseBot, without either platform having to understand bookkeeping.
On Make, that shape is a set of named modules — upload a receipt through the signed receipt pipeline and retrieve its exact processing result, search expenses with structured constraints, create a cash expense, add mileage, add income, start a Gmail receipt scan and check its status, create an expense report, plus a guarded API call for advanced scenarios that is restricted to ExpenseBot's own endpoints. Category and group dropdowns are populated live from the connected account, so a scenario builder picks from real values instead of typing strings that may not match.
On Zapier, there are two routes rather than one. The MCP Client lets an AI step inside a Zap talk to a remote MCP server you add once and reuse — that path is in beta and works today. The native app adds structured triggers, searches and actions covering the same ground as the Make modules: receipt upload and result polling, reviewed expense creation, mileage and income with retry-safe source event IDs, Gmail scan runs and monitoring, expense search, and report generation.
Both were tested against live accounts before submission. The detail worth stating plainly, because it is the one people ask about: replaying the same expense action creates exactly one spreadsheet row, not two. Retry safety is not a configuration option you remember to enable.
The Real Difference: AI Step vs Explicit Module
This is the fork in the road, and almost everything else follows from it.
Make asks you to name every operation. A scenario is a chain of modules, each one a specific call with specific inputs, and you can see the whole path before you run it. When something breaks, you know which module broke, and the bundle that went into it is right there. The cost is that you have to know the shape of the workflow in advance and wire every branch, including the ones that only fire when something goes wrong.
Zapier's AI step asks you to name the outcome. The MCP Client model means an agent step can see a tool list and decide which calls to make. You are not wiring a branch for every case, because the agent handles variation that you would otherwise have to anticipate. The cost is the mirror image of Make's: the exact call sequence is decided at run time, so reasoning about what will happen is harder than reading what did.
| Zapier (AI-step model) | Make (module model) | |
|---|---|---|
| You specify | The outcome you want | Each operation, in order |
| Call sequence decided | At run time, by the agent | At build time, by you |
| Handles unanticipated variation | Yes — that is the point | Only if you wired that branch |
| Easy to predict before running | Less so | Yes — the path is visible |
| Debugging a failure | Read the agent's trace | Read the failing module's bundle |
Neither column is the winner. They are two answers to "who decides the steps", and the right answer depends on whether the steps are actually fixed.
How Each One Holds Your Credentials
A difference that looks like plumbing and is really about who can revoke what.
The Zapier path uses OAuth. You add ExpenseBot's MCP server URL, Zapier opens ExpenseBot's sign-in and consent screen in the browser, and the connection completes through OAuth discovery with Dynamic Client Registration and PKCE — there is no client ID or client secret to copy by hand, and no long-lived string sitting in a field somewhere.
The Make path uses a revocable ExpenseBot AI Assistant Token, stored in Make's credential vault and sanitized out of Make's logs. It is a named credential you issue and can destroy independently, without touching any other connection.
Practically: OAuth is less to handle and ties the connection to a browser consent you can withdraw from ExpenseBot's side. A named token is more explicit about scope — one credential, one purpose, revoked on its own. Both end at the same place, which is that you can cut access without waiting for anyone.
The Same Recipe, Built Twice
The clearest way to see the difference is one workflow expressed on both platforms. Take the most common one: a receipt arrives as a Gmail attachment and should end up as an expense.
On Make, the scenario is five modules in a row: watch Gmail → Upload Receipt → Delay → Get Receipt Processing Result → router. The result is a terminal state — added, duplicate, skipped, errored or unknown — and the router sends each one somewhere. You can look at that scenario six months later and know exactly what it does.
On Zapier's MCP Client, the same job is a trigger and an AI step told to upload the attachment and report the outcome. Shorter to build. The trade is that "report the outcome" is a sentence, and a router branch is a fact.
The delay-then-poll shape is worth understanding on either platform, because it is the part people get wrong. Uploading and reading the result are separate steps by design: the upload returns immediately so your scenario is not blocked while extraction runs, and the result step tells you what happened to that specific file. Ask too early and you get no answer; skip the result step entirely and you have built an automation that cannot tell success from failure.
We wrote the whole set up as individual recipes, platform-agnostic, so you can build them on either side: Gmail attachment capture, Drive folder capture, Slack channel capture, success notification, Action Needed routing, client and project expense entry, and report handoff.
ExpenseBot supplies structured expense data and Gmail receipt capture — extraction, duplicate detection, review, and the spreadsheet record. The automation platform handles external triggers, routing, reminders, and notifications. Whichever you pick, it orchestrates ExpenseBot rather than duplicating its accounting rules, and your accounting platform remains the final books.
Where Each One Wins
Having built both, the split is fairly clean, and it is not about capability.
Reach for Make when the workflow is deterministic plumbing. Receipt capture is the canonical example: the steps do not vary, the failure modes are known, and the value is in handling every one of them explicitly. A finance team that wants to point at a diagram and say "this is what happens to a receipt" is better served by a scenario than by an agent. The live dropdowns matter more than they sound like they should — the difference between choosing an existing client group and typing one is the difference between a clean report and a duplicate bucket that splits your totals.
Reach for Zapier when expenses are one part of something larger and more conversational. If a Zap is already doing several things and the expense step is a small piece of a workflow whose shape varies by request, an AI step that can call the tools it needs is less work than wiring each combination. This is also the route that exists today, in beta, without waiting for a listing.
The pragmatic answer for a lot of teams is that this is not a permanent choice. The recipes above describe workflow shapes, not platform features, and moving one from a scenario to a Zap is an afternoon rather than a migration.
What Neither One Will Do
Both integrations inherit the same boundary, and it is worth saying plainly because it is the thing most likely to surprise someone designing an automation.
- Changes preview and ask. ExpenseBot shows the records a change would affect and asks for explicit confirmation before saving. Do not design a Zap or a scenario that assumes unattended, unconfirmed writes to your books — the approval step is the product's contract, not a setting to turn off.
- Gmail scanning is separately authorized and user-triggered. A scenario can start a scan and poll it until it reports a terminal status. It is not a background watcher, and it is not the same thing as your automation platform's own Gmail trigger reading attachments.
- Neither platform becomes your books. Your expense records live in a Google Sheet in your own Drive, and your accounting platform remains the accounting source of truth. The automation moves things between them.
- Revocation is one step on both. Disconnect in Zapier and withdraw the authorization from ExpenseBot's side; or revoke the AI Assistant Token that Make holds.
Where Things Actually Stand
Being precise about this, because "integration available" covers three different states:
- Zapier MCP Client — beta, usable today. Add
https://mcp.expensebot.ai/mcpas a custom MCP connection and authenticate in the browser. It is Zapier's beta surface, so treat it as one: verify a read-only request before building anything on top of it. Setup: connect ExpenseBot to Zapier's MCP Client. - Native Zapier app — submitted, under review. Built and tested, not publicly listed. You cannot install it from a directory search yet.
- Native Make app — submitted, in review. Same position. In the meantime, ExpenseBot's MCP connection works from any MCP-compatible assistant or agent, and early access to the Make app is available by emailing support@expensebot.ai. Details: does ExpenseBot work with Make.com?
We would rather say this than imply either app is a click away. When a listing goes public, this section gets updated with the link.
If you want to connect ExpenseBot to an assistant directly rather than through an automation platform, that is a different route — see managing expenses in ChatGPT or Claude and the MCP connector explainer for what a connector is and how the connection kinds differ.