Add Receipt Collection to Your AI Workflow

The receipt-ingestion layer for an AI accounting workflow

You supply orchestration, business rules, review policy, and downstream systems. ExpenseBot supplies receipt intake, extraction, duplicate handling, expense records, exception states, and evidence in the customer’s own Google Sheet and Drive.

1. 1. Your workflow

   Receipt source

   An image or PDF arrives from the channel you already run: an inbox, a shared folder, a chat channel, a form, a client portal.

   ↓

2. 2. ExpenseBot

   ExpenseBot MCP

   Your agent submits the file once, or starts a bounded Gmail scan in the customer's connected account.

   ↓

3. 3. ExpenseBot

   Processing status and exceptions

   Extraction and duplicate checks run in the background. Your workflow polls for the authoritative outcome.

   ↓

4. 4. ExpenseBot

   Expense record and evidence

   An added receipt becomes a row in the customer's Google Sheet, with the source document kept in their Google Drive.

   ↓

5. 5. Your workflow

   Your agent or automation

   Your rules decide what happens next: review, notification, matching, coding, approval.

   ↓

6. 6. Your workflow

   Accounting or review destination

   The ledger or review queue your design names stays the source of truth.

Read as a sentence: a receipt source feeds the ExpenseBot MCP server, which returns a processing status and any exceptions, then an expense record with its evidence, which your agent or automation carries to the accounting or review destination you chose. ExpenseBot owns the three middle stages. It does not act inside the systems your agent connects to, so anything your agent does there runs on your agent’s own connections.

If you are still deciding what the whole pipeline should look like, AI accounting automation that starts with the receipt covers the end-to-end assembly. This page covers one decision: whether ExpenseBot can own the receipt leg of a system you are building.

Build the workflow, not the receipt plumbing

Receipt collection looks like one step on a whiteboard and turns into seven jobs in production. ExpenseBot already runs each of them, so your build starts at the point where the receipt is a record.

• File intake. Images and PDFs, including mixed batches, go through signed uploads. Your agent does not have to hold or host the files.
• Bounded Gmail scans. A recent-window scan covers roughly the last 60 days. Completed prior years are scanned one year at a time, after a preview and an explicit confirmation.
• Extraction. Vendor, amount, date, tax, and category are read from the document.
• Duplicate outcomes. A receipt ExpenseBot already holds comes back as a duplicate instead of a second row.
• Delayed processing. Extraction is asynchronous. A row usually appears within one to three minutes, and PDFs or large batches take longer.
• Held-for-review outcomes. A file with missing details or a possible duplicate is withheld and reported, not guessed at.
• Persistent evidence. The record lands in the customer’s Google Sheet and the source document in their Google Drive.

One point shapes everything downstream: submission is not extraction. submit_receipt starts the job and returns. get_last_receipt_result is the authoritative status tool, and it can stay pending. Design your workflow around that wait instead of assuming a result in the same call.

Exact MCP workflow contracts

These are the tools the receipt-collection job uses, with the state your workflow should expect from each. The connected tool list your client discovers is authoritative; this table is rendered from the same generated catalog.

The remote server publishes more tools than these, covering reports, income, mileage, and analytics. They are listed on the MCP page. A receipt-collection workflow rarely needs them, and requesting only the scopes this job uses keeps the connection narrow.

A reference receipt-collection workflow

Submit once, keep the submission ID, wait for the terminal verdict, then branch. Five steps cover the whole receipt leg.

1. Receive a receipt from a source your workflow already supports.
2. Submit the image or PDF once and persist the returned submission ID next to your own event ID.
3. Poll at the interval and within the time allowance the tool returned. For a small batch that is currently a check about every 20 seconds for up to five minutes, and longer for larger batches. Use the values in the response, not these.
4. Branch on the verdict. Not every terminal result is a success, and a batch needs its per-file outcomes read.
5. Pass the result and the evidence links to your review, notification, or accounting step.

on receipt_received(file, source_event_id):
    if store.has(source_event_id):        # already submitted, never resubmit
        submission_id = store.get(source_event_id)
    else:
        response      = call submit_receipt(file)
        submission_id = response.submissionId
        store.put(source_event_id, submission_id)

    repeat on the interval the response gave, within its time allowance:
        result = call get_last_receipt_result(submissionId = submission_id)
        if result.found: break

    if not result.found:
        notify "still processing, check again later"   # do not resubmit
        return

    switch result.verdict:
        added            -> hand record + evidence links to the next step
        duplicate        -> mark handled, reference the existing record
        skipped          -> report to a person
        held_for_review  -> relay the returned next step to the account owner
        errored          -> surface the error and stop
        mixed            -> handle each file from counts + per-file outcomes
        unknown, other   -> send to a person, do not resubmit

That is pseudocode for your orchestrator, not an ExpenseBot SDK. There is no webhook to subscribe to in this flow; the workflow learns the outcome by polling.

The verdict describes the whole submission. A one-receipt submission ends in one of the first five. A multi-file batch is not summarised reliably by a single word: a batch can report added while one of its files was skipped, so for batches read the counts and the per-file outcomes, which use added, duplicate, skipped, failed, and held_for_review. The rule behind every row: an unknown outcome stays unknown. A pending receipt is not a failed receipt, and submitting the same file again can create a duplicate expense.

Connect each customer’s account safely

Each customer signs in and authorises their own ExpenseBot account. A connection acts as that one account, so there is no shared credential that spans your client list.

• Remote agents add https://mcp.expensebot.ai/mcp. The server supports OAuth discovery, Dynamic Client Registration, and PKCE, so a client that supports them needs no hand-copied client ID or secret. The account owner completes sign-in and consent in the browser.
• Registration is not open to every callback. Automatic registration covers desktop clients that use a local loopback address and the connector platforms ExpenseBot has reviewed. A hosted agent outside that set uses a named, revocable token instead.
• Clients without remote OAuth MCP use the stdio package and token setup documented on the MCP page. Keep the token in the client’s secret store. A chat conversation is not a secret store, and neither is an email.
• Respect scopes and annotations. Access is granted per scope: reading expenses, writing expenses, Gmail scanning, reading reports, writing reports, and compliance. Request only what the job needs. Each tool is annotated as read-only or not, and your calling system should honour that when deciding what may run unattended.
• Verify read-only first. Before any write, ask for something harmless such as the top five expense categories this month and confirm the answer belongs to the right account.

Per-client instructions for ChatGPT, Claude, Gemini, remote agents, and desktop clients are in the connection chooser. The category background, including what a connector can and cannot see, is in what an MCP connector does.

Workflow recipes builders can adapt

The common receipt workflows are already written up as individual recipes, each one a verified workflow shape. Start from the closest one instead of designing from zero.

• Gmail attachment capture
• Drive folder capture
• Slack channel capture
• Success notification
• Action Needed routing
• Client and project expense entry
• Report handoff

The division of labour on this page is one a firm already runs. An accounting firm connected ExpenseBot over MCP to Viktor, the AI agent it was already using, with Zoho Books as its ledger. ExpenseBot captures the receipt and keeps the evidence, the firm’s agent applies the firm’s rules, and Zoho Books remains the accounting source of truth.

“The MCP connection itself is working well, and it gives us a practical way to combine ExpenseBot’s receipt capture with Viktor’s access to Zoho and our accounting rules.”John, an accounting firm using ExpenseBot with its own AI agent

What that shows is the connection and the split of responsibilities. It does not show ExpenseBot reconciling anyone’s books, and the firm’s full reconciliation routine still has to be validated on its own data. The setup and the review-first prompt are in using ExpenseBot with Viktor and Zoho Books.

MCP, native Zapier, or the ExpenseBot app?

Pick by how much the workflow has to decide for itself. Remote MCP is for an agent that chooses among tools, Zapier is for fixed mapped steps, and the app is for someone who wants the finished product.

ExpenseBot connects over remote MCP to custom agents, through a native app to Zapier, and through listed connectors to ChatGPT and Claude. For the Zapier decision specifically, including the current status of each Zapier route, see native Zapier app or Zapier MCP Client. The routes are separate connections and do not conflict, so a deterministic Zap and an agent can run against the same account.

Start with one test receipt

Prove the receipt leg on one account and one harmless file before you attach anything downstream.

1. Connect one test ExpenseBot account, not a client’s.
2. Let your client discover the tools and confirm the ones in the table above are present.
3. Submit one non-sensitive test receipt.
4. Persist the submission ID.
5. Wait for the authoritative result. Do not resubmit while it is pending.
6. Open the account’s Google Sheet and Drive and confirm the row and the receipt document are there.
7. Only then add the downstream actions.

No test account yet? Create one with a 60-day free trial, no credit card, then come back to the setup steps.