QuickBooks Online Advanced Backup and Restore: Recovering from Mistakes

The short version: QuickBooks Online Advanced keeps backups for as long as your Advanced subscription is active, but the controls Intuit gives you to manage that retention are limited. The interface shows you the recent restore points clearly. Older daily backups are still on Intuit’s servers, but accessing them is not a self-service operation. And there is no paid tier or setting that lets you extend retention beyond what Intuit chooses to keep.

What the interface shows. When you open Settings, then Back up company, then the Restore tab, you’ll see a list of restore points. For most accounts that list shows roughly the last 90 days of daily backups, with the timestamp of each one. You can pick any point in that list and run a restore against it. That is the working window for self-service restores.

What lives behind the interface. Intuit keeps older daily backups on its own infrastructure for as long as you remain an active Advanced subscriber. The older backups are not visible in the standard Restore screen, but Intuit support can pull them on request. We have walked clients through this process twice. Both times required filing a support ticket, getting escalated to the QBO accountant-tier support, providing the company ID and the desired restore date, and waiting between two and five business days for the older backup to be made available in the Restore list. It works, but it is not fast and not guaranteed for points older than six months.

What happens if you cancel Advanced or downgrade. The moment you downgrade to Plus, the backup feature stops creating new restore points. Existing backups stay viewable for a grace period (we have seen 30 days quoted, but Intuit has changed this without notice) and then they disappear. If you cancel QBO entirely, backups go with the account. This is one of the strongest arguments for running independent backups outside Intuit’s ecosystem, especially in months where you are evaluating a switch off QBO.

Why there is no “extend retention” button. Intuit treats backups as a service feature, not a configurable retention policy. The product team has been asked about extended retention many times in their user feedback forums and the response has been consistent: not on the roadmap. The practical reasons are storage cost and audit complexity, but the result for users is that you have to plan retention yourself if you need more than 90 days of accessible restore points.

What we do for clients who need longer retention. We layer three things on top of Intuit’s native backup. First, a monthly Local Backup to Google Drive or Dropbox. Local Backup exports the file as a structured set of CSVs, journal entries, and supporting files. It is not directly restorable through the QBO interface (Intuit has been explicit about this in their documentation), but it is a complete enough export that we can reconstruct the books if Intuit’s native backup is unavailable. Second, a quarterly export of the full general ledger, trial balance, and supporting reports to PDF, saved in the client’s Dropbox under a year/quarter folder structure. Third, for clients above five million in revenue or with audit exposure, a paid third-party tool like Rewind or Backup for QuickBooks. These services run their own daily backups, keep their own retention windows (often two to seven years configurable), and support record-level restore that Intuit’s native engine does not.

The cost of layered backup. The monthly Local Backup is free except for the Google Drive or Dropbox storage. Quarterly PDF exports cost about 30 minutes of bookkeeper time per quarter. A third-party tool runs roughly $40 to $300 a month depending on file size and feature tier. For most mid-sized clients we recommend the first two as a baseline and add the third only when there is a real reason. Pure cost-versus-benefit: if your books would take more than three days of bookkeeper time to reconstruct from external records, a paid third-party backup pays for itself in the first incident.

Common misconceptions about retention. The first is that Local Backup is a substitute for Intuit’s native backup. It is not. Local Backup is an export, not a restorable backup. You can use it to rebuild the file by hand, but you cannot click Restore and have Intuit pull the data back in. The second misconception is that the audit log is a backup. The audit log shows what changed, but it does not let you roll back to a prior state. The third is that Intuit will keep your data forever after cancellation. They will not. Treat cancellation as a deadline to get your data out.

The right retention plan for most businesses. Native daily backup with the 90-day visible window is enough for routine recovery. Add a monthly Local Backup for archival. Add a quarterly full export for the kind of long-term records the IRS expects you to keep under Publication 583. That’s three habits, none of them complicated, and together they cover the realistic recovery scenarios.

One last point worth knowing. The retention question often comes up after a specific scare. A bookkeeper deletes something they shouldn’t have. A client looks at a transaction from six months ago and wants to see what it looked like before an edit. A new CFO walks in and asks for proof of the books at year-end. The honest answer is that QBO’s native backup gives you good coverage for the recent past and partial coverage for the older past. If you have material audit exposure or you need to reconstruct historical states reliably, the native tool is a starting point, not a finish line. Build the layered system. Test the restores. Document the dates. Your future self will thank you when the inevitable mistake happens.

If you want help designing a retention plan that matches your specific exposure, that’s part of how we scope a bookkeeping or client accounting services engagement. We’ll look at your transaction volume, audit risk, and how often the books are touched, and recommend a layered backup setup that fits the budget. For more on what Advanced unlocks beyond backup, see our main QuickBooks Online Advanced guide and the reclassify transactions walkthrough for the kind of cleanup work that should always be backed before it starts.

No, and this is the single biggest limitation of QBO’s native restore. The engine restores the entire company file to a prior state. There is no native option to roll back one transaction, one account, one customer, or one date range while leaving everything else alone. That all-or-nothing constraint shapes how you should think about restore.

Why Intuit built it this way. The technical reason is that QBO’s underlying database has thousands of interlinked records, and a clean restore at the company-file level can preserve referential integrity. A partial restore would have to figure out, for example, whether to bring back an invoice but leave the customer that was created after the backup, or what to do when a deleted bill references a vendor that was also edited later. Solving that cleanly is genuinely hard, so Intuit chose to ship the simple version: roll the whole file back, or don’t.

The sandbox workaround. Even though you cannot natively restore a single transaction, you can fake it with a sandbox. The process: spin up a test company in QBO (most accountant subscriptions include test company access), restore the backup into the test company, find the records you need, export them as CSV or recreate them in the live file by hand, then discard the sandbox. This is the technique we use any time a client needs to recover something specific without wrecking everything that happened after the backup point. It works for invoices, bills, journal entries, customer records, and most other named-record types.

When the sandbox workaround works well. If you need to recover one or two specific records that were deleted or edited, and the original records can be re-entered into the live file without changing the surrounding records, the sandbox approach is fast and clean. We did this last quarter for a client whose bookkeeper deleted 12 invoices from a prior month. Restored to sandbox, exported the 12 invoices to CSV, re-imported them into the live file with the same numbering, done in about two hours. The live file was never offline.

When the sandbox workaround does not work well. If the records you need to recover have lots of downstream effects that have already happened (payments applied, reports filed, returns submitted), re-entering them by hand is complicated and risky. Each re-entered record might trigger reconciliation breaks, customer balance mismatches, or sales-tax recalculations. For these cases, you have to choose between a full restore (with all the rollback that implies) and accepting the partial loss.

Third-party tools that do support partial restore. If partial restore is a recurring need, the workaround is to pay for a third-party backup service that supports record-level rollback. Rewind is the most common one we set up for clients. Rewind backs up every change in real time and lets you restore individual transactions, customers, vendors, or accounts without touching anything else. The pricing runs from about $40 a month for small files to several hundred for large ones, and the implementation is straightforward. Backup for QuickBooks is a similar product with overlapping features. For clients who have had a serious restore incident or have high transaction volume, paying for record-level restore capability is usually worth it. We have a client who processes about 4,000 invoices a month and saves 3 to 5 hours a week just on selective restores when individual invoices get corrupted in their bank feed match process.

What you can do without paying for a third-party tool. Even without record-level backup, you can build habits that reduce the need for partial restore. First, name your transactions clearly so you can find and undo them by hand if needed. Second, use journal entries with descriptive memos for any non-routine change so you can reverse them cleanly. Third, batch your risky changes (chart cleanup, bulk reclassification, vendor merges) into focused windows where you take a manual backup beforehand and where everyone knows a rollback might be needed. Fourth, train your bookkeepers to use the “void” function rather than the “delete” function when undoing a transaction. A voided transaction is recoverable from the record itself. A deleted transaction often is not, short of restore.

The accounting-software philosophy question. The all-or-nothing restore has a side effect worth thinking about. It pushes responsibility upstream, toward not making the mistake in the first place. Because restore is expensive (everything after the backup point gets rolled back), bookkeepers think twice before bulk deletes. That’s actually a feature. The accounting profession has historically built controls around prevention rather than correction, and QBO’s restore design reflects that. It is not a sin to take a manual backup before any risky change. It is the right habit. Treat restore as the absolute last resort, not as a casual undo button.

One workaround we have used that is worth mentioning. If the only thing you need to recover is the historical state of a single report (say, what the P&L looked like on a specific date last quarter), and you have a saved PDF of that report from the time, you may not need a restore at all. Just compare the current numbers to the saved PDF, identify the differences, and decide whether to make corrective journal entries or leave it. We have used this approach when an audit committee asked for a snapshot of the books at a specific date and the live file had been touched since.

The IRS angle. Partial restore is also relevant when you are correcting books that have already been used for tax returns. If you discover that one transaction was wrong on a return you already filed, you should not just delete and re-enter it in the books. You should make a corrective journal entry (so the audit trail shows what changed and why) and, if the change is material, amend the return. IRS Publication 583 requires you to keep records that support your filed returns, and a partial restore that overwrites those records without documentation could create an audit problem.

What we recommend for most clients. Use the native all-or-nothing restore for emergencies, not for regular maintenance. For routine corrections, void instead of delete, use journal entries with clear memos, and document the change. For recurring needs around partial recovery, pay for Rewind. For audit-exposed periods, take a manual backup before any change and save a PDF of the affected reports for comparison. None of this is exotic. It is just the discipline that separates clean books from books that auditors find unsettling.

For more on this kind of bookkeeping discipline, see our QuickBooks Online bookkeeping guide. For the broader Advanced toolset, the main pillar page covers what each Advanced feature changes and how the pieces fit together.

Restore rolls back the entire company file in QBO to the moment of the backup. Anything that posted between the backup point and the restore disappears. That sounds simple. In practice, it creates a chain of side effects across bank feeds, payroll, sales-tax calculations, and any integration touching the file. Knowing what comes back and what does not is the difference between a clean recovery and a new mess.

What the restore actually does. The native Restore action overwrites every transaction, list, and setting in the live file with the values from the backup. Customers added since the backup are gone. Vendor edits made since are reverted. Invoices, bills, payments, journal entries, deposits, expenses, and transfers all return to their state at the backup point. Custom field values revert. User access changes revert. Even the chart of accounts reverts to the prior structure, which is one of the more painful side effects when someone has been doing chart cleanup.

Bank feeds after restore. Bank feeds are where the most confusion lives. The connection to your bank stays alive through restore. The transactions that have already been downloaded into the bank-feed queue are the question. QBO’s behavior here has changed over time, but the current behavior we see is: pre-backup transactions return to the matched state they were in at the backup point, and post-backup transactions need to be re-pulled. The bank feed will re-fetch transactions for the period after the restore date, but you will need to re-match them against the restored ledger entries. Anything that was cleared after the backup point now shows as un-cleared in QBO, even though it cleared in real life. You have to walk through the re-match process for every transaction posted in the gap window.

How long the bank-feed re-match takes. For a client with low bank-feed volume (maybe 30 to 50 transactions a week), re-matching after a one-week gap is a 30 to 60 minute task for one bookkeeper. For a higher-volume client (200 to 500 transactions a week), the same one-week gap can take 4 to 8 hours of cleanup. That is one reason the timing of restore matters: do it during a quiet period (Sunday evening, end of month before close kicks off, holiday) so the cleanup happens before the next wave of transactions hits.

Payroll. Payroll is the highest-stakes part of a restore. The payroll module in QBO is logically separate from the rest of the company file but its journal entries and tax liabilities live in the GL. When you restore, the GL entries from any post-backup payroll runs get rolled back, but the actual money has already moved. Direct deposits to employees, tax deposits to the IRS, and state filings are all real-world actions that the restore cannot reverse. So you have a books-versus-reality mismatch: the GL shows no payroll for the post-backup period, but the IRS has received the deposits and the employees have been paid.

What to do about that payroll mismatch. The fix is to re-enter the payroll runs that happened in the gap window, but you have to do it carefully so you don’t create duplicate tax liabilities. Generally, the cleanest approach is to re-run the payroll inside QBO with the same paycheck dates and amounts as the real runs, which posts the journal entries back into the GL. The system will see the existing tax deposits and not duplicate them, but you must verify this in the payroll center before assuming. We’ve seen one case where a poorly handled post-restore payroll re-entry created a duplicate IRS Form 941 obligation that took two months to unwind. Verify before you let payroll auto-pay.

Integrations and connected apps. Any third-party app connected to QBO (Bill, Ramp, Salesforce, Shopify, Square, Stripe, an inventory tool, a CRM) keeps its own data and its own state. Restore inside QBO does not roll back those external systems. So a customer that was added in QBO via a Salesforce sync after the backup point gets deleted from QBO during the restore, but the Salesforce record still exists. The next sync will re-create the customer in QBO. Sometimes that’s what you want. Often it creates duplicates or refights the change you were trying to undo. Before any restore, list every connected app, decide whether to disconnect it during the restore, and plan the re-sync carefully.

Sales tax. The Sales Tax Center recalculates liabilities based on the transactions in the file. Post-restore, your sales tax liability for the gap period will revert to the pre-backup state, which may be zero or some lower number than what you actually owe. Importantly, any sales tax payments you have made will also revert, so you may show as owing money you have already paid. This is a numbers-only problem (the real payment was made), but it can confuse a bookkeeper for hours. Compare your post-restore sales tax liabilities to your bank records and adjust by journal entry if needed.

Reconciliations. Bank and credit card reconciliations completed after the backup point are reverted. You’ll need to re-reconcile the post-backup periods. This is usually a couple of hours per account per month, but it depends on volume. If you did a major year-end reconciliation cleanup after the backup point, restore will undo all of that work. Take a manual backup before reconciliations specifically because you do not want to redo the entire process if something goes sideways.

Open invoices, open bills, and customer balances. Customers whose balances changed in the gap window (because of new invoices, payments, or credits) will revert to their backup-point balances. Customers will not, of course, revert their actual payments. You have to look at every customer with activity in the gap window, compare the QBO balance to the real-world balance, and make journal entries or re-enter transactions as needed. For a client with 200 active customers and a one-week gap, this is a half-day of work. For 1,000 customers and a month-long gap, this is a week.

Why restores happen during off-hours. The cumulative weight of all these side effects is the reason we run restores in the evening or on a weekend. The bookkeeping team needs uninterrupted time to walk through the post-restore cleanup before regular transactions resume. Running a restore during business hours, with bank feeds still pulling and customers still paying, creates a moving target where you can never catch the file up.

Our restore checklist. Before any restore: list all connected apps and decide which to disconnect; export a current copy of all key reports (P&L, balance sheet, AR aging, AP aging, sales tax liability) to PDF for comparison; communicate the restore window to all users so nobody is in the file; take a fresh manual backup so you can undo the restore if needed. After: re-pull and re-match bank feeds; re-enter or verify payroll for the gap window; review and adjust sales tax; re-reconcile post-backup periods; review customer and vendor balances against external records; reconnect apps and verify the first sync; document the entire process in a memo for the client’s records.

If that sounds like a lot, it is. A restore is a controlled event, not a casual click. For clients who run restores more than once a year, we usually recommend investing in better preventive controls instead of better restore habits. The reclassify transactions guide and payroll guide both cover the changes that most often lead to restore situations. The bookkeeping service page describes how we build the prevention layer that makes restores unnecessary in normal months.

The short answer: the IRS does not specifically audit your QBO restore history. They audit your books. But a restore can create audit problems indirectly when it changes numbers that were already on a filed return or a payroll deposit, and the documentation around a restore matters more than most bookkeepers realize. Let’s walk through where the real risk lives.

What the IRS actually looks at. In a typical income tax audit, the IRS examines specific line items on the return and asks for supporting records. They want to see receipts, invoices, contracts, bank statements, and the books that produced the numbers on the return. They generally do not ask about your bookkeeping software’s restore log. They will, however, notice if the books you provide do not match the return you filed, and they will notice if the books show evidence of post-filing changes that affect the numbers under audit.

The scenario where restore creates audit exposure. Imagine you filed your 2024 income tax return in April 2025. In July 2025, your bookkeeper restores the company file to a point in March 2025, which rolls back several months of transactions that were on the filed return. Now the books no longer match the return. If you are audited for 2024, the IRS will look at the books, see numbers that don’t match the return, and ask why. If you cannot produce a clean explanation (with the prior-state evidence to back it up), the audit gets harder. The agent may suspect manipulation. The penalties can escalate from a simple accuracy adjustment to a fraud adjustment, which is dramatically more expensive.

What documentation protects you. The IRS does not require you to keep restore logs specifically, but it does require you to keep records that substantiate your filed returns. IRS Publication 583 lays out the basic recordkeeping rules: keep records for at least three years (and longer for situations like worthless securities or substantial omissions of income), keep enough detail to support the numbers on your return, and keep the supporting documents for transactions like receipts and invoices. The natural protection against a restore-related audit problem is a “books at the time of filing” snapshot. Before you file any return, export the relevant financial reports to PDF (general ledger, trial balance, P&L, balance sheet for the period covered by the return) and save them in a permanent archive. If a restore later changes the books, the PDFs prove what the numbers were when the return was filed.

Payroll tax has its own risk profile. Payroll tax restores are more dangerous than income tax restores because the IRS receives a deposit and a quarterly filing in roughly real time. If you restore a period after a payroll tax deposit has been made and a Form 941 has been filed, the books will show no record of that deposit or filing. The IRS still has the deposit. You may end up with a tax-deposit history at the IRS that does not match the payroll register in your books. Reconciling that is annoying. If the restored books show a smaller liability than what was actually deposited, you might unknowingly underpay the next deposit while assuming you overpaid the previous one. That triggers IRC Section 6656 failure-to-deposit penalties, which start at 2% and climb to 15% depending on how late the eventual catch-up payment is.

The “audit suspicion” angle. Restores by themselves are not suspicious to the IRS. Most field auditors don’t even know what a QBO restore is. But auditors do look for signs that the books were edited after the fact in ways that affect what’s being audited. If your audit log shows large reversals of journal entries right after the audit notice was received, the agent will ask about it. The same is true if the audit log shows a restore action right after the agent’s records request was sent. The cure: never restore an audit-exposed period without clear documentation of why, when, and what the prior state was. Print the audit-log entries. Save the prior reports. Make a memo. The IRS will not punish you for fixing genuine bookkeeping errors. They will punish you for the appearance of evidence tampering.

What about prior periods that have already been on returns? The general principle: if you restore a period that was already on a filed return, treat it as a potential amendment situation. Look at what the restore changed. If the changes are immaterial (rounding, recategorization that doesn’t change taxable income), document them and move on. If the changes are material (a transaction was missing or duplicated, a credit was wrong, a 1099 vendor was misclassified), you may need to amend the return. The Form 1040-X process for individuals and the equivalent business amendment forms exist for exactly this kind of correction.

The state-tax dimension. States vary on how aggressive they are about post-filing changes. New York, where many of our clients operate, has aggressive state-tax audits and will follow up on inconsistencies between books and returns. California, Texas, Florida, and other large states have their own audit teams with their own approaches. State sales-tax audits in particular tend to be granular and will compare the books to the filed sales-tax returns transaction by transaction. A restore that changes sales-tax-relevant data after a return was filed can trigger a state notice quickly.

The “good faith” defense. The IRS recognizes that books get edited and corrected as a normal part of running a business. The principle they apply is good faith: did you make the changes for legitimate bookkeeping reasons, with appropriate documentation, in a way that maintained the integrity of the underlying records? If yes, restores and corrections are part of normal business and not problematic. If no, you have an issue. The documentation habit is what proves good faith. A memo dated the day of the restore that explains why the restore was needed, what the prior state was, and what the restore changed is far stronger evidence than trying to reconstruct the reasoning two years later under audit pressure.

Our restore documentation template. Every restore we run for a client produces a memo with: the date and time of the restore, the user who initiated it, the backup point being restored to, the reason for the restore, a list of the records that were affected, the export of the post-restore P&L and balance sheet, and a comparison to the pre-restore versions. This memo gets saved in the client’s compliance folder along with a copy of the relevant audit-log entries. If the IRS ever asks, the memo answers the question. The exercise of writing the memo also forces the bookkeeper to think through whether the restore is really the right call, which has prevented at least three restores over the years that would have created more problems than they solved.

One specific audit story. A client we took over from a previous CPA had a six-month-old restore in their QBO history that had rolled back about $180,000 of prior-period transactions. There was no documentation. When the client was selected for a routine IRS audit, the agent noticed the books for the audit year did not match the filed return. We spent about 40 hours reconstructing what the restore had done, building the supporting documentation after the fact, and amending the return. The penalty exposure was significant. If the prior CPA had spent 30 minutes writing a memo at the time of the restore, the audit would have been a quarter of the size. That experience is why we now treat restore documentation as non-negotiable.

What to do if you have an undocumented restore in your history. Don’t panic, but don’t ignore it. Pull the audit-log entries around the restore date. Identify what changed by comparing reports from before and after if you have any saved copies. Write the memo now, even retroactively, explaining what you can reconstruct about the reasoning. Save everything in your compliance folder. If the restore changed numbers on a filed return and the changes are material, talk to your tax preparer about whether an amendment is appropriate. This is exactly the kind of cleanup we handle as part of a bookkeeping or client accounting services engagement when a new client comes to us with a messy file history.

For more on the recordkeeping standards the IRS expects, see the IRS recordkeeping page and Publication 583. For the broader picture of how Advanced features change your audit exposure, our main Advanced guide and the reclassify transactions walkthrough cover the most common change types that create audit risk.

For most businesses above one or two million in revenue, yes. The native Intuit backup is good for what it is, but it has structural limitations that make external backup a smart layer on top. The honest tradeoff is some money and a bit of operational effort in exchange for real protection against the failure modes Intuit’s tool cannot cover.

What Intuit’s native backup does well. Daily automated backups with no manual setup required after the initial toggle. Self-service restore through a clean UI for points in the last 90 days. Backups that maintain referential integrity across the entire data model. Audit-logged restore actions. No additional cost beyond the Advanced subscription. For routine recovery from bookkeeper mistakes, it covers the case well.

What Intuit’s native backup does not cover. Five specific failure modes are worth thinking about. First, account suspension. If your Intuit account is suspended for a billing dispute or any other administrative reason, you may lose access to your file and the backups simultaneously. We have seen this happen twice in our practice when a client’s credit card on file expired and the recovery process took longer than expected. Second, account compromise. If a bad actor gets into your QBO admin account, they can delete users, delete backups, and damage the file in ways that the native backup cannot undo because the bad actor has the same admin rights as you. Third, data corruption on Intuit’s side. Rare, but it happens. If the underlying database for your company file gets corrupted, Intuit’s own backups may also be affected. Fourth, voluntary departure. If you decide to leave QBO entirely, native backups go with the account. Once you cancel, you have a grace period to export and then the data is gone. Fifth, partial recovery. As covered elsewhere in this guide, native restore is all or nothing. There is no way to restore one transaction without rolling back everything.

The three layers of external backup we use. Layer one is the in-product Local Backup linked to Google Drive or Dropbox. This is free except for the cloud storage. Set it up once, run it monthly. The output is a structured export of your file (CSVs, journal entries, supporting files). It is not directly restorable through QBO’s interface (Intuit has been clear about this constraint), but it is complete enough to reconstruct the books manually if needed. Layer two is a quarterly export of key reports to PDF. P&L, balance sheet, general ledger, trial balance, AR aging, AP aging, sales tax liability summary, and any reports the client needs for compliance. Save in a folder structure by year and quarter. Cost: about 30 minutes of bookkeeper time per quarter. Layer three, for high-value or audit-exposed clients, is a paid third-party tool like Rewind or Backup for QuickBooks. These run their own daily backups, hold their own copies independent of Intuit, and offer record-level restore that native QBO does not.

The cost of layered backup. Layer one: free (plus storage). Layer two: about 2 hours of bookkeeper time per year. Layer three: $40 to $500 per month depending on file size and feature tier. For most mid-sized clients, layers one and two are the baseline and we add layer three only when the client’s audit exposure or transaction volume justifies it. The pure cost-versus-benefit math: if your books would take more than 3 days of bookkeeper time to reconstruct from external records in a worst-case scenario, layer three pays for itself in the first incident. For a high-volume CAS client we estimated reconstruction would take about 8 weeks, which made the $250/month tool an easy yes.

What we configure in Rewind specifically. Daily backups (the default). Retention set to 365 days (configurable up to seven years in their tool). Notifications to the controller’s email on every successful backup. Slack notification on any failed backup. Test restore monthly to a sandbox to verify the backups actually work. The monthly test is the single most important habit. We have caught two cases in three years where backups appeared to be running but were not actually capturing recent changes. Without the test restore we would not have known until we needed them.

The “are external backups safe” question. Reasonable to ask. Any third-party tool that backs up QBO has read access to your full financial data, which is a meaningful trust decision. We only recommend tools that hold SOC 2 Type II attestation, that publish their data-handling practices clearly, and that have a track record of incident response. Rewind, Backup for QuickBooks, and a couple of other major players all meet that bar. We do not recommend new or obscure tools because the trust calculus is too steep.

What about Local Backup specifically. Intuit’s Local Backup feature deserves a closer look because it is sometimes oversold and sometimes underused. Oversold: people assume Local Backup means they can restore through the QBO UI if Intuit’s online backups are unavailable. They cannot. Intuit has been explicit that Local Backup data cannot be restored through the in-product Restore tool. Underused: people skip Local Backup entirely because of the above limitation, missing the value of a structured export that you control. The right way to think about Local Backup is as an export-for-archival, not a backup-for-restore. Run it monthly, save the files, and treat them as your independent record of the books at a point in time. If Intuit ever becomes unavailable, you’ll need to rebuild the file from this export, which is a project, but you have the data. Without Local Backup, you don’t.

What we tell clients who push back on the cost of layered backup. Bookkeeping is one of those functions where the cost of failure is dramatically higher than the cost of prevention. A bookkeeper losing two weeks reconstructing a file because the native backup was unavailable costs more than a year of third-party backup. A failed audit because the books no longer match the filed return costs more than a decade of layered backup. The discipline pays for itself in the first incident, and you usually do not get to choose when the incident happens.

What we tell clients who are skeptical of Intuit. If you trust Intuit enough to run your bookkeeping on QBO, you can trust them enough to provide the primary backup. But the trust is not infinite. Treat Intuit as one vendor in your finance stack. Like any single-vendor dependency, the right hedge is to keep an independent copy that does not depend on that vendor’s good behavior. The same logic applies to your bank, your payroll provider, and your tax software. Single-vendor finance stacks are convenient. They are also exactly where the worst incidents happen.

When external backups are overkill. Very small businesses, with under maybe $500K in annual revenue, low transaction volume, and no audit exposure, are usually fine with just the native backup plus occasional manual exports. The cost-versus-benefit of layered backup at that size does not justify the operational effort. Once you cross into the territory of payroll, real AR aging, multi-state sales tax, or any kind of investor reporting, the calculus shifts. The threshold is fuzzy but you’ll feel it when you cross it: when a one-day file loss would seriously disrupt your operations, layered backup is no longer optional.

The bottom line. Run Intuit’s native backup automatically. Add Local Backup to cloud storage monthly. Export key reports to PDF quarterly. For mid-sized and larger clients, add a paid third-party tool with record-level restore. Test the restore process monthly to a sandbox. Document each restore you actually run. None of this is complicated. All of it is the difference between a clean recovery and a multi-week disaster. For help setting up the right backup layers for your specific situation, that’s part of our bookkeeping and client accounting services engagements. For the broader Advanced toolset and how backup fits with the other features, see our main QuickBooks Online Advanced guide, the workflows guide, and the payroll guide.