QuickBooks Online Advanced Workflows: Automation for Finance Teams

The short answer: QuickBooks Online Advanced workflows live inside QuickBooks and watch QuickBooks records. Zapier and Make sit outside QuickBooks and connect it to other systems. Pick the one that matches where the work actually lives.

The long answer requires a bit more nuance because the question really has two parts — what each tool can do, and where the tradeoffs sit. Let’s walk through both.

What QBO Advanced workflows can do. They watch a fixed list of QBO events: invoice created, bill created, payment received, deposit made, journal entry posted, and a handful of others. When one of those events happens and the conditions you set match, the workflow fires an action — an email, an internal notification, a status change, an approval request. The engine runs inside Intuit’s own infrastructure, so it is fast (typically 30 to 90 seconds from trigger to action), reliable, and not subject to external rate limits. It does not cost extra on top of your Advanced subscription. And critically, every action shows up in the QBO audit log with the workflow name attached, which is useful for compliance and tracing.

What QBO Advanced workflows cannot do. They cannot trigger on events outside QBO. If a deal closes in HubSpot, QBO does not know. They cannot write data anywhere except inside QBO — you cannot, for example, have a QBO workflow create a row in a Google Sheet or post to a Slack channel directly. They handle AND conditions but not OR conditions. They cannot do multi-step branching logic. They cannot transform data — what comes in is what goes out. They cannot loop. They cannot call external APIs.

What Zapier and Make do. They are general-purpose automation platforms. Zapier connects roughly 7,000 apps. Make connects somewhere similar. Both let you build multi-step workflows that span apps — trigger in HubSpot, look up data in QBO, post to Slack, create a row in Notion, all in one workflow. Both handle conditional logic, branching, data change, error handling, and retries. Both have visual builders that are accessible to non-developers. Both are paid by usage — Zapier charges per task (each step in a multi-step workflow is one task), Make charges per operation (similar but with more generous limits per dollar).

Where Zapier and Make are weaker. Speed: 1 to 5 minutes is normal versus 30 to 90 seconds for native workflows. Cost: at scale, task-based pricing adds up fast. Reliability: any time you connect two systems, you have a new failure mode — auth tokens expire, APIs change, rate limits trip. Audit trail: a Zapier-driven action shows up in the QBO audit log as the Zapier service account, not as the originating user, which is a compliance problem for some audit frameworks. Vendor risk: you have added a third party to your data path who can see customer names, dollar amounts, and email content. For most clients that risk is acceptable. For some (healthcare, defense, legal) it is not.

How to choose. The decision tree we use with clients is simple. First question: does the trigger or the action involve a system other than QBO? If no, use native QBO workflows. They are faster, free, and audit-clean. If yes, you need Zapier or Make. Second question: does the workflow need OR logic, branching, or data change? If yes, Zapier or Make. If no, native QBO workflows can probably do it. Third question: do you have audit or compliance requirements that demand all actions show in the QBO audit log with the originating user? If yes, lean toward native workflows even if it means accepting some manual steps.

A concrete example that comes up monthly. A client wants Slack notifications when a customer pays an invoice. QBO workflows cannot post to Slack, so this requires Zapier or Make. We typically set it up as a two-step Zap: trigger on Payment Received in QBO, send a Slack message to a #finance channel. Total cost: about $20 a month at the volume our typical client sees, and the alert hits Slack in 2 to 3 minutes after the payment posts. Could you do this with a QBO workflow? No — native workflows only send to email or to QBO users, not to Slack.

A counter-example. A client wants to flag every bill above $5,000 for CFO sign-off. This is a pure QBO-to-QBO routing task. Use the native workflow. It will fire in under a minute, it does not cost anything extra, and the audit log will show the CFO as the approver, which is what auditors want to see. Building this in Zapier would be slower, more expensive, and harder to defend.

The hidden third option. If you find yourself needing more than three or four cross-system automations, neither Zapier nor Make is the right long-term answer — you have outgrown both. At that point, the answer is either a dedicated middleware layer (Workato, Tray.io) or a custom integration built against the QBO API. We see this transition happen at clients with $20M+ in revenue and finance teams of three or more. Below that, Zapier or Make is fine.

One last thing worth saying about cost. Native QBO workflows are included in Advanced. Advanced costs roughly $200 per month at list price. Zapier’s mid-tier Professional plan is $73 per month for 2,000 tasks. Make’s Pro plan is $19 per month for 10,000 operations. For a typical small finance team doing 5 to 10 cross-system automations, Make is usually the cheaper option. For a team where the automations are critical to month-end and need to be bulletproof, Zapier’s reliability is worth the extra cost. We tend to recommend Make for cost-sensitive clients and Zapier for clients where downtime is genuinely expensive.

If you want help building this out, that is part of what we do as a client accounting services engagement. We will look at your current process, map the trigger and action points, and recommend the right tool for each one. Sometimes the answer is native workflows. Sometimes it is Make or Zapier. Sometimes it is none of the above — the right answer is to stop trying to automate something that should still go through a person.

Start with five. The same five we set up for every QBO Advanced client. They cover most of the recurring follow-up work that drains a finance team’s week, and they are all simple enough to build in under 20 minutes each.

1. Overdue-invoice reminders at 7 and 30 days past due, for invoices above $250. This is the workflow that pays for itself in the first month. The trigger is invoice overdue. The conditions are days past due greater than 7 (or 30 for the second tier) and amount greater than $250. The action is a polite email reminder at 7 days and a firmer one at 30. Why $250? Because below that threshold, the reminder email costs you customer goodwill more than it actually collects — people who owe you $80 are usually not the ones the email will move. We’ve seen DSO drop by 4 to 9 days when this single workflow goes live across a client’s customer base. The CFO usually notices the cash-flow improvement before the AR clerk notices they got a chunk of their week back.

2. Bill approval routing above a dollar threshold. Trigger on bill created. Condition: amount greater than $1,500 or whatever your sign-off threshold is. Action: notify the approver in QBO and mark the bill as pending approval. Picking the right threshold matters. Set it too low and the approver gets notification fatigue and starts rubber-stamping — which means the control exists only on paper. Set it too high and big-ticket bills slip through. For most clients with $1M to $10M in annual spend, we start at $1,500 and adjust. For clients with much higher transaction volume, we sometimes go to $5,000. The trick is making the volume of approvals match the time the approver actually has.

3. Customer statements on the first of every month. Trigger: first of the month. Condition: customer has open balance greater than zero. Action: send a statement email with the open invoices listed. This is a simple workflow that replaces a 90-minute recurring task. Most AR teams send monthly statements manually, one customer at a time, on the first business day of the month. Automating it eliminates that block of time and ensures it happens even when the AR person is on vacation. The one watch-out: statement emails feel formal, so customize the template to match your brand voice. The default QBO statement email reads like a collections agency letter.

4. Internal alert on large bank deposits. Trigger on deposit created. Condition: amount greater than $10,000. Action: notify the controller and CFO. This is a cheap, easy fraud and error control. If a $42,000 deposit shows up that nobody at the company recognizes, you want the controller to see it the same day, not at month-end when it gets reconciled. The $10,000 threshold is meaningful for two reasons. First, it lines up with the IRS Form 8300 reporting threshold for cash transactions, so anything above it should be on your radar anyway. Second, it is high enough that you are not getting alerts on routine customer payments but low enough to catch errors before they compound.

5. Journal-entry approval for entries above $500 not created by the controller. Trigger on journal entry created. Conditions: amount greater than $500 AND not created by the controller. Action: notify the controller for review. JEs are where bookkeeping mistakes hide. They are also where some flavors of fraud live — a careless or dishonest bookkeeper can do a lot of damage with a quick journal entry. A required second-look on entries above a meaningful amount catches both. We exclude the controller’s own entries because otherwise you get a loop where the controller is reviewing their own JEs, which is not a control. If the controller is the only senior accountant, route to the CFO or external CPA instead.

What we deliberately don’t automate first. A lot of clients ask about automating vendor payments — trigger on bill approved, action: pay the bill. We push back on this. Workflows are for routing and approving, not for moving money. Anything that initiates a cash movement should go through a person, even if that person is just clicking a confirm button. The reason is simple: when a payment goes out wrong, you want a human to be responsible, not a rule.

What to add once the first five are live. Once the foundational five are working, the next wave of workflows is usually client-specific. Common ones we build in the second wave: automatic class assignment based on customer (useful for clients with departmental tracking), expense receipt reminders to sales reps who haven’t uploaded receipts within 5 days of expense creation, sales-tax-rate alerts when a customer in a new state generates an invoice (to flag potential nexus issues), and project-budget alerts when actual costs hit 80% of the approved budget. None of these are universal — they depend on the client’s business model.

What we never automate. Customer credits, refunds, write-offs, and anything that touches the equity section. These should always go through a person with a real review. The same is true for any workflow that would auto-close a transaction or auto-mark something as paid without a real confirmation. The five workflows above all stop short of changing financial reality — they route and remind, but the person still has to act.

The order of operations matters. Build them one at a time. Test each one for a week before turning on the next. The temptation is to build all five in one afternoon and turn them all on at once, but that is how you get into a situation where customers are getting emails you didn’t intend, approvers are getting flooded, and you can’t tell which workflow is misfiring. We build one a week for the first month with every new Advanced client. By week four, the foundational set is live and the team has had time to notice and adjust to each one.

If you are not on Advanced yet and you are evaluating the upgrade, these five workflows are the strongest argument for it. The Plus tier has a stripped-down version with only invoice reminders. Advanced opens up the full engine. For most clients, the time savings from the five workflows above pay for the Advanced upgrade in the first month. For details on the Advanced tier and what else it unlocks, see our main QuickBooks Online Advanced guide.

Every workflow-driven action shows up in the QuickBooks audit log just like a manual action. The workflow name appears as the user who took the action, the timestamp is when the workflow fired, and the affected record is logged. That gives you a basic paper trail. Whether that paper trail is enough for your compliance situation is a different question, and the answer is almost always: it is a starting point, not a finish line.

What the QBO audit log captures for workflow actions. The trigger event, the workflow that fired, the time it fired, the record affected, the action taken (email sent, status changed, approval requested), and the result (success or failure). You can filter the audit log view by workflow name to see every action a specific workflow has taken. You can also drill into individual records to see whether a workflow touched them. The data is reasonably complete for tracing what happened on a given day.

What the audit log does not capture. The content of emails sent by workflows. The reasoning a human applied when they accepted or rejected an approval. The user-agent or IP address for workflow-driven actions (because they did not come from a user session). Changes to the workflow itself — if someone edits a workflow’s condition from “greater than $1,500”. To “greater than $5,000,”. That change is logged elsewhere and is easy to miss.

The retention question. The in-product audit log view scrolls back about two years for most subscriptions. Older entries are not deleted from Intuit’s records as far as we can tell, but they are not visible through the standard interface. If you need older audit entries, you have to request them from Intuit support, and the process is slow. For compliance, you should not depend on the in-product view. Export the log monthly and store it in a retention system that meets your industry’s requirements.

SOX and similar regulated audits. If you are a subsidiary of a public company, or otherwise subject to SOX 404 controls, the QBO audit log is not enough on its own. SOX requires evidence that controls operated effectively over a period, which means you need archived logs, documented control descriptions, evidence that workflows have not been altered without proper change management, and segregation of duties around who can edit workflows. The QBO audit log gives you one piece of that puzzle. The rest you build around it.

SOC 2. Same general answer. SOC 2’s Common Criteria around change management (CC8.1) and logging (CC7.2) ask for evidence that changes to the system are reviewed and that logs are protected from tampering. QBO’s audit log meets the second requirement by design — you cannot edit audit log entries. It does not meet the first by itself, because the workflows themselves can be edited by anyone with admin access, and the edit log for the workflows is not as clean as it could be. We typically pair QBO with a separate change-control system for clients pursuing SOC 2.

IRS recordkeeping. The IRS recordkeeping requirements at irs.gov/businesses/small-businesses-self-employed/recordkeeping set a baseline for what you need to retain — receipts, invoices, bank statements, payroll records, and so on. The audit log itself is not on the IRS list because they generally do not ask for process controls. But if you are ever in an audit dispute about a specific transaction — say, defending the classification of a meal under IRS Publication 463 — the audit log can be useful supporting evidence about who approved the expense and when.

Payroll tax penalties under IRC §6656. One area where workflow logs occasionally matter: failure-to-deposit penalty cases. Under IRC §6656, the IRS imposes penalties for late payroll tax deposits, with the rate increasing from 2% to 15% depending on how late the deposit is. If you are appealing one of these penalties for reasonable cause, evidence that you had a workflow set up to alert the controller about payroll-related deadlines — and that the workflow fired but the responsible person was out sick or had a family emergency — can support a reasonable-cause abatement. We have used this exact argument successfully twice in the last three years.

Segregation of duties as a workflow control. Workflows can be part of a segregation-of-duties control if you set them up right. A workflow that routes bill approvals from the AP clerk to a different approving user, where both users have unique logins and the AP clerk cannot edit the workflow, satisfies a basic SoD control. The IRS and SOC 2 all care about SoD in different ways, but the principle is the same: the person initiating a transaction should not be the same person approving it. A workflow that enforces that routing is useful evidence in any of those frameworks. The control breaks if (a) the same person has the credentials for both users, (b) the AP clerk can edit the workflow, or (c) the approver is a generic shared account that multiple people use.

What we actually recommend for clients with real audit exposure. First, export the audit log monthly. We have a Make scenario that does this automatically and drops the CSV into a folder structured by year and month. Second, document each workflow in a separate change log — what it does, when it was created, who has edit rights, and a history of changes. Third, do a quarterly access review — pull the QBO user list, confirm everyone with admin access still needs it, confirm no one has both AP-clerk and approver roles. Fourth, for any workflow that is part of a control, lock the workflow with a documented review and approval before any change is made.

The honest tradeoff with audit-ready workflows. Building this discipline around your QBO workflows takes time. For a small finance team, the question is whether the compliance benefit justifies the operational cost. If you are SOX-exposed, regulated, or pursuing a SOC 2 audit, yes. If you are a small business with no audit pressure, probably not. Most of our clients fall in the second category, and we tell them not to over-engineer the controls. A clean audit log and a quarterly access review is enough for most situations. The full SOX-ready treatment is overkill until you actually need it.

One last point about workflows and tax audit defense. If you are ever in an IRS field audit and the agent asks how you approved a particular expense, “the workflow approved it”. Is not a sufficient answer. The fact that a workflow routed the approval and a person clicked Approve does not, by itself, substantiate the business purpose of the expense. You still need the receipt, the business purpose, and (for meals) the attendee list. The workflow speeds up the approval. It does not replace the substantiation requirements that Publication 463 spells out. This is something we cover with new clients during the bookkeeping kickoff so the expectations are clear from day one.

Not really. And being honest about the limits is more useful than telling you what you want to hear.

QBO Advanced workflows are built for one trigger, one or two conditions, and a single action path. The engine does not handle OR conditions inside a single workflow, it does not branch based on outcome, and it does not handle escalation logic like “if approver A doesn’t respond within 48 hours, route to approver B.” If your approval chain has multiple decision points, dollar tiers, department routing, fallback paths, or anything resembling a state machine, the native engine will fall short.

What you can do with chained workflows. You can fake some multi-step behavior by chaining workflows together. Workflow 1 triggers on bill created, routes to the manager. When the manager approves, that approval changes the bill status, which is the trigger for Workflow 2. Workflow 2 sees the status change, checks whether the amount is above the next tier, and routes to the controller. With three or four chained workflows, you can build something that looks like a tiered approval chain.

Why the chained-workflow approach breaks down. Each chained workflow is independent. There is no central view that shows “here is the full approval path for this bill, with each step’s status.” If a bill gets stuck because the second-level approver missed the notification, you have to dig through individual workflow histories to figure out where it stopped. Reporting on approval cycle times across the full chain is essentially impossible. And the moment you need to change the chain — say, adding a new tier — you have to edit every workflow in the chain by hand. This is brittle.

What real approval chains need. A real AP approval system has: tiered routing based on dollar amount, department, or vendor category. Fallback approvers with escalation rules. A single dashboard showing the status of every in-flight approval. The ability to add comments or attachments at each step. Clean reporting on cycle times and bottlenecks. And audit trails that show the full path. QBO Advanced workflows give you maybe two of those six features.

When to graduate to a dedicated AP tool. If any of these describe your situation, the QBO workflow engine is not going to be enough. You process more than 100 bills a month. You have more than three approval tiers. You have department-specific approvers. You have vendors that require special handling (1099 contractors, related-party transactions, government grants). You need to pay bills via ACH or check from the same tool that approves them. You need vendor portal access where vendors submit their own invoices. You need real spend analytics.

The tools that actually do this well. The four we recommend most often, in rough order of complexity. Bill.com is the most popular AP tool that integrates with QBO. It handles tiered approvals, payment runs, and 1099 tracking. Pricing starts around $45 per user per month. Good for small to mid-sized businesses. Ramp is newer, faster-growing, and includes corporate cards plus AP. It is free for the AP product if you use their cards. The approval engine is solid but less customizable than Bill. Airbase is more sophisticated, handles complex multi-entity approval chains, and is priced for larger finance teams — expect $4,000 to $8,000 a year minimum. Tipalti is the heavyweight, used by companies with global vendor bases, complex tax-withholding requirements, and high transaction volume. Pricing usually starts in the five figures annually.

How to decide between AP tools and QBO workflows. Count your monthly bills. If you process under 25 bills a month with one approval tier, native QBO workflows are fine. If you process 25 to 100 bills a month with two approval tiers, native workflows can still work but you will feel the friction. Above 100 bills a month or three tiers, get a dedicated tool. The math is simple: if a bookkeeper spends two hours a week chasing approvals manually, that is $3,000 to $5,000 a year in time. Most AP tools cost less than that and pay back in saved time alone, before you count the cleaner audit trail and the faster cycle times.

The hybrid approach we use most often. For clients in the 25-to-100-bills-per-month range, we frequently set up a hybrid. Use Bill or Ramp for the bill approval and payment workflow. Sync approved bills back to QBO for the books. Use QBO native workflows for the things QBO does well: customer reminders, statement automation, internal alerts on deposits and journal entries. That gives you the right tool for each job without overengineering. The integration between Bill and QBO is mature; Ramp’s QBO integration is good and improving fast.

One specific multi-tier setup we see succeed in native QBO. A two-tier approval chain with a single dollar threshold works fine. Bills under $5,000 get approved by the department manager. Bills $5,000 and above get approved by the CFO. Two workflows, one trigger each, clean and easy to maintain. The moment you try to add a third tier or a department dimension, you are off the happy path.

Where this fits in your overall finance stack. Approval workflows are one piece of a larger system. The full stack includes the GL (QBO), the AP tool (Bill, Ramp, etc.), the expense management tool (often the same as AP these days), the bank, the payroll system, and a reporting layer on top. Workflows live in two places: inside QBO for QBO-native automations, and inside the AP tool for AP automations. Trying to do everything inside QBO workflows is a sign that your finance stack has not matured to match your transaction volume. For more on building a complete finance stack around QBO, see our main QuickBooks Online Advanced guide and the expense claims walkthrough.

If you are not sure where you fall on this spectrum, send us your monthly bill count, your current approval tiers, and the tools you are already using. We can usually tell you in 20 minutes whether native workflows are enough or whether you should be looking at a dedicated AP tool. That conversation is part of how we scope a client accounting services engagement.

When a workflow stops firing, the cause is almost always one of four things. Check them in order. You’ll fix 90% of cases without ever opening a support ticket.

1. Is the workflow actually enabled? Sounds obvious. Is the first thing people miss. Open Manage Workflows and confirm the toggle is on. We have seen clients spend two hours debugging a workflow that someone accidentally disabled during a different change. Also check whether anyone with admin access edited the workflow recently — a single condition change can stop a workflow from matching the records you expect.

2. Does the test record actually meet every condition? This is where most real failures live. Workflows use strict AND logic. If the workflow is set to fire on “invoice overdue greater than 7 days AND amount greater than $250”. And your test invoice is 6 days overdue, the workflow will not fire. Date conditions are the most common trip-up. QBO uses calendar days, not business days. The “overdue”. Count starts from the due date, not the invoice date. And the engine evaluates conditions at the time of the trigger event, not the time you are looking at the record — so an invoice that was overdue when the workflow checked but is now paid still got skipped.

The fix for condition mismatches: use the workflow history view. Manage Workflows shows a history of every time a workflow ran, including the records that matched and the records that almost matched but didn’t. If you don’t see your test record in either list, the trigger event you expected never actually happened. If you see it in the “almost matched”. List, the condition tells you what didn’t line up.

3. Does the recipient still have a valid email and active user status? A common failure on internal-notification workflows: the workflow was set up to notify a user who has since been deactivated or removed from QBO. The workflow fires, but the notification has nowhere to go. The audit log will show the workflow fired successfully, but the user never gets pinged. Fix: open the workflow, confirm the recipient is still an active QBO user, and update if needed.

For customer-facing workflows, the parallel failure is that the customer’s email on the QBO customer record is wrong, blank, or going to a spam folder on the customer’s end. The workflow sends the email. The email never arrives at the customer’s inbox. You see no obvious failure indicator. Fix: every quarter, audit the email field on your customer records. We have a saved report that flags customers with missing or obviously malformed emails. Send that report to the AR clerk for cleanup.

4. Is something on the receiving side blocking the email? Workflow emails come from a QuickBooks-branded address by default. Some corporate email systems flag these as suspicious. The email gets quarantined, delivered to a junk folder, or silently dropped. Symptoms: the workflow history shows successful sends, but customers swear they never got the email. Fix: ask one or two customers to whitelist the sending domain, or change the workflow’s reply-to address to one on your own domain so the email looks more legitimate. For high-volume reminders, consider whether your AR communication should go through a real email tool (HubSpot, Mailchimp, Postmark) instead of QBO’s built-in sender.

Other less common causes worth knowing about.

Workflow conflicts. If you have two workflows with overlapping triggers and conditions, the order they fire in is not always predictable. Symptoms: one workflow seems to “steal”. The trigger from another. Fix: review your full workflow list and look for conflicts. Tighten conditions so only one workflow can match any given event.

Time zone confusion. Workflows that trigger on a date or time use the company’s home time zone, not the user’s. If your company is set to Eastern Time but you are in California, a workflow that fires at “the start of the month”. Will fire at 9 PM Pacific on the last day of the previous month, which can be confusing. Fix: check the company time zone in Account and Settings before debugging time-based triggers.

Disabled triggers due to QBO updates. Twice in the last three years, Intuit pushed a backend update that broke a specific workflow trigger. Both times, the fix required toggling the workflow off and back on. There is no warning when this happens. If a workflow that used to work suddenly stops, toggle it off, save, toggle on, save again. Sometimes that’s all it takes.

Permissions on the recipient. A workflow that routes a bill for approval can fail silently if the recipient does not have the right permissions to view bills. You set up the routing, the workflow fires, but the recipient cannot actually see the bill they are supposed to approve. Symptoms: the recipient gets the notification but the link goes to an error page. Fix: confirm the recipient’s role includes bill review permissions. This is more of an issue with custom roles — we cover custom roles in our custom roles guide.

The systematic debugging approach we use. When a client says “my workflow isn’t working,”. We run through this checklist in order. (1) Is it enabled? (2) Did the trigger event actually happen? Check the audit log for the record. (3) Did the conditions match? Check workflow history. (4) Did the action complete? Check workflow history for the success/fail flag. (5) Did the recipient actually get the notification or email? Ask them or check the email. The answer is almost always between steps 3 and 5. Step 1 catches the embarrassing cases. Steps 2 through 5 catch everything else.

What to do when you have ruled out all of the above. If the workflow is enabled, the trigger fired, the conditions matched in history, the action completed in history, and the recipient confirms they got the notification, then the workflow is working. The problem is probably your expectation. Look at the workflow’s definition again with fresh eyes. We’ve had clients insist a workflow was broken when in fact it was firing exactly as configured — the configuration just did not match what they thought they had set up.

When to open a support ticket with Intuit. Almost never. Intuit support is not deeply versed in workflow internals and the standard response is “try toggling it off and on.” If you have genuinely ruled out the four common causes above and the workflow history confirms the workflow is not firing on a record that meets the conditions, escalate to Intuit’s accountant-tier support or work through your QBO partner. As a CAS firm, we have direct access to escalation paths that regular subscribers don’t.

Prevent the problem before it happens. The best debugging is the kind you don’t have to do. Two habits cut workflow problems by a lot. First, name your workflows clearly — “AR Reminder 7-day above $250”. Is much easier to debug than “Workflow 4.” Second, document each workflow in a shared place (a Notion page, a Google Doc, anywhere) with its trigger, conditions and the business reason. When you come back to debug it three months later, the documentation is what tells you whether the current behavior matches what you intended.