AI Agents for QuickBooks: Reconcile Payments Across Systems

What AI agents can do with QuickBooks (and where they stop)

AI agents can read QuickBooks Online data, match it against payment evidence from other systems, flag anomalies, and prepare close work. They should not decide accounting treatment on their own. The reliable pattern is deterministic code for exact matches and recordkeeping, with the agent's judgment reserved for ambiguous cases a person then approves.

Intuit already ships AI inside QuickBooks, covering areas such as accounting, payments, and customer work. Its overview of Intuit AI in QuickBooks Online notes that availability depends on product and plan, so check what your account has. Those features work inside the books. The harder job for a finance operations lead is the work that spans systems: a Stripe payout, an invoice in QuickBooks, an email from a customer, and a reviewer in Slack.

That cross-system work is where Major fits. Major is the enterprise platform where agents build the software they run on. The agent works out the matching logic once, builds a reconciliation app with its own database and logs, and from then on runs that app instead of reasoning through every payment again. The model handles judgment calls. The app handles everything repeatable, and it remembers.

Here is how the options compare:

• QuickBooks native AI: in-product bookkeeping assistance, reviewed by the user inside QuickBooks.
• Major: an agent-built app that spans QuickBooks, Stripe, and Slack, with durable state, scoped credentials, and audit.
• Manual process: fully human-controlled, but the same matching gets repeated by hand every cycle.

Major does not replace native QuickBooks functionality. It coordinates around it.

Where a QuickBooks agent helps finance operations

Three patterns are worth building, each naming the connectors it needs.

Payment Match and Exception Agent (QuickBooks + Stripe + Slack). Stripe payments are compared with open QuickBooks invoices. Exact matches are recorded. Partial, duplicate, and unmatched payments go to a Slack review channel.

Invoice Evidence Follow-Up (QuickBooks + Gmail + Slack). When an invoice has no matching payment, the agent searches the finance inbox for remittance notes, drafts a reply for a person to send, and posts the case to Slack. The agent reads email and writes a draft. A reviewer decides what goes out.

Close-Prep Aging Digest (QuickBooks + Google Sheets + Slack). A scheduled run pulls open invoices, writes an aging snapshot to a sheet, and posts a short Slack digest of the accounts that need a human before close. Same query each time, so it belongs in code.

Each pattern carries one risk. Matching on amount alone breaks when two customers owe the same figure. Evidence has to include customer and reference, not just the total.

What the QuickBooks API makes possible

QuickBooks Online uses OAuth 2.0, and every call is scoped to one company (a realm). Through it you can read and write accounting entities such as invoices, payments, customers, and bills. The Intuit authentication docs cover scopes, and you should read them before you pick credentials.

Keep these cautions in front of you:

• The query language has no joins, no OR, and no GROUP BY. Anything that needs those happens in your own code.
• Only filterable properties can appear in a WHERE clause, and filterability varies by entity. See the data queries reference.
• Updates require the current SyncToken. Fetch the record immediately before you write.
• Confirm rate limits and endpoint details in Intuit's current documentation. They change.

The API moves data. It does not make accounting decisions, so those rules live in your app and your review policy.

How to build a QuickBooks payment-reconciliation agent on Major

This is an implementation pattern, not accounting advice or a promise of error-free books. Currency support, write permissions, and plan limits vary by account.

1. Connect three systems. QuickBooks, Stripe, and Slack, each with its own scoped credential. Start the QuickBooks and Stripe connections read-only where possible. Major's credential proxy applies the scope at the point where the agent acts.
2. Build the state in an app. The reconciliation app holds payments, invoice_matches, review_queue, and audit_events tables, plus an exception-review view for finance reviewers. A match record carries payment_id, invoice_id, match_status, evidence, reviewer, and decision_at. State persists outside the model's context window.
3. Run the exact match in code. A scheduled daily workflow pulls eligible Stripe payments and open QuickBooks invoices, then compares amount, currency, customer or reference, and your timing tolerance. Processing is idempotent, so a rerun never double-records a payment.
4. Let the agent judge exceptions only. For ambiguous, partial, or duplicate candidates, the agent reads the evidence and drafts a plain explanation for the reviewer. It cannot silently pick an accounting treatment.
5. Gate writes. Reviewers sign in under role-based access. A finance role approves any write, the app retrieves the current SyncToken, and the action is logged.
6. Audit everything. Input references, model judgment, approval, and resulting action all land in audit_events.

You can start building this free on Major. For the controls behind steps 1 and 5, see how to put control where agents act.

Start with a review queue, then expand safely

Do not start with auto-posting. Automating every match is the wrong first move for reconciliation, because one bad write in the books is expensive to unwind.

Here is the worked example end to end. The Payment Match and Exception Agent wakes on its daily schedule. A Stripe payment of a given amount arrives with a customer reference. The app finds one open QuickBooks invoice with the same amount, currency, and reference inside the timing tolerance. It stores the evidence and marks the row matched. No model call happens.

A second payment arrives for less than the invoice total. Two invoices from the same customer are open. The app marks it ambiguous, queues it, and the agent drafts a note: the payment may be a partial against either invoice, with the evidence for each. A message lands in the Slack review channel. A finance reviewer picks the invoice, the app fetches the current SyncToken, applies the approved write, and logs who decided and when.

The rollout order matters:

• Run in read-only shadow mode and compare the app's matches with what finance does by hand.
• Review the stored evidence with finance until the exact-match rules hold up.
• Enable narrowly scoped writes only after you have written an approval policy and tested it.
• Watch the exception queue. A growing queue means your rules need tightening.

This is why the pattern gets steadier with use. The agent reasons about the matching once, the app runs it every day, and the model's share of the work shrinks to the exceptions. Major agents reason once and run forever, though the model still handles the judgment calls. For more on the finance side, see auditable close workflows, finance agent use cases, and governed workflow automation.

Start building on Major

Build a QuickBooks reconciliation app that matches payment evidence across Stripe and QuickBooks, keeps an auditable review queue, and routes uncertain cases to Slack.

• Start building free
• Book a demo

Related articles

• How to Build a Claude Agent: Tools, State, and Workflows
• Major x Snitchfeed: Official API and MCP Connectors for Social Listeni
• Anthropic vs OpenAI: An API Comparison for Builders