How to restore a deleted invoice in QuickBooks Online

REAL SANDBOX TEST · OCTOBER 4, 2026

Watch a deleted invoice return to QuickBooks

We backed up invoice 1167 for $125, deleted it in QuickBooks Online, reviewed Akika’s one-step restore plan, and verified the recovered invoice and customer balance.

2-minute annotated walkthrough with on-screen captions and soft instrumental background music; no narration. Edited from real screen captures, with waiting times shortened. Recorded in a QuickBooks sandbox using Akika’s development environment; its interface and branding may differ from the current product. The video length is not a restore-time promise.

Read the video transcript

1. Start with a known invoice. Invoice 1167 belongs to Akika Demo Customer. It totals $125, is dated October 4, 2026, and is due November 3.
2. Confirm a completed backup. The invoice exists in a saved backup before deletion. Connecting a backup app after deletion cannot recreate missing history.
3. Delete the test invoice. We delete the disposable sandbox invoice in QuickBooks. No invoice is sent to a customer.
4. Confirm the deletion. After another backup, Akika shows the invoice as Deleted while retaining its earlier version.
5. Select the earlier version. We check the saved customer, invoice number, dates and $125 total, then choose Restore Version.
6. Read the proposed change. The preview contains one step: create invoice 1167 for Akika Demo Customer.
7. Check prerequisites and approve. This sandbox has open books, no bank rules and no matched bank transactions for this invoice. The invoice is unpaid, with no tax or attachments.
8. Read the restore report. Akika reports Done for the single planned action.
9. Verify in QuickBooks. The restored invoice has its original number, customer, invoice date, due date and $125 balance.
10. Check the details and balance. Its Services line, description, quantity of one and $125 amount match. The customer’s transaction list shows exactly one invoice and a $125 open balance.

This test covers one unpaid invoice. It does not demonstrate recovery of linked payments, tax, attachments, or an entire company. Review backup coverage for your own case.

How to recover a deleted invoice in QuickBooks Online

Start by checking what recovery history you already have. A backup must contain the invoice from before it was deleted. Connecting a backup app today cannot create a snapshot of yesterday's missing record.

The right approach depends on your QuickBooks plan and available history. QuickBooks Online Advanced and Intuit Enterprise Suite have their own backup and restore feature, with documented coverage limits. If you use Akika, check the saved records in your connected company. If neither has a suitable backup, the audit log can help you recreate a saved transaction manually.

If you have an Akika backup from before the deletion

1. Confirm the company and the time. Find the backup from before the invoice was deleted. Match the customer, invoice number, date, and amount to the record you need.
2. Compare the saved record with the current company. Check whether an invoice has already been recreated. Review the customer, items, tax settings, and linked payments so you do not introduce a duplicate or lose a relationship.
3. Review the proposed restore. Select the supported record and inspect the recovery plan. Current permissions, closed books, linked records, and QuickBooks API restrictions can affect which changes are possible.
4. Approve the plan and inspect the result. Review any failed or skipped steps before retrying. Confirm the invoice in QuickBooks, check its payment links and the customer's balance, and keep the restore report.

If you do not have a suitable backup

Intuit's audit-log instructions explain how to locate a deleted, previously saved transaction and re-enter its details. Open Settings → Audit log, filter by the relevant user, date, and event, find the deletion, and view its history. Use the available information to recreate the transaction with its original date, then check its accounting and payment relationships.

The audit log is a source of transaction details, not an Akika backup. If the history is incomplete or the affected records are complex, review the recovery with the person responsible for your books before writing changes.

Before an import, app sync, or cleanup

1. Confirm a completed backup exists and includes the records you may need to recover. Take an on-demand snapshot before starting a substantial change.
2. Record the starting balances and keep the source file or list of affected records.
3. For a spreadsheet, review the import plan and resolve validation findings before approving it. An import's undo has its own eligibility checks; it is not an unconditional rollback.
4. For a move to a different company, use Company Copy and review its destination checks and reconciliation results.
5. After the change, compare the results and balances with what you expected.

Explore Akika's QuickBooks Online Backup & Restore for supported records and recovery limits, or see the subscription and trial details.

Why recovery needs more than a saved file

Most people do not start thinking about QuickBooks Online backup when everything is calm. They start thinking about it after a bad import, a sync job gone sideways, a deleted invoice, or a well-meaning cleanup that touched more records than anyone expected.

That moment exposes a quiet truth: taking a copy of accounting data is not the product. Recovery is the product.

A backup system that can only say "here is yesterday's file" still leaves the accountant with the hardest work: figuring out what changed, which records are safe to put back, which relationships have to be rebuilt first, and how to avoid making the ledger worse while trying to fix it.

A useful QuickBooks Online backup is not a static export. It is a versioned, explainable recovery system for a live accounting graph.

The dangerous word is "backup"

"Backup" sounds simple because files trained us to think that way. Copy the spreadsheet. Copy the folder. Copy the database. If something breaks, put the old copy back.

QuickBooks Online is not a folder. It is a hosted accounting system with records, references, permissions, API limits, concurrency controls, attachments, deleted states, and business rules. An invoice points at a customer, line items, tax codes, terms, classes, departments, payments, and sometimes attachments. A restore that ignores those dependencies is not a restore. It is a second incident.

That is why the interesting engineering problem is not "can we fetch data?" It is "can we turn a point-in-time view of the company into a safe recovery plan?"

QuickBooks gives you signals, not a time machine

QuickBooks Online has useful native tools and developer surfaces, but each one solves a different part of the problem.

Audit log

The audit log is valuable for investigation. It can help answer who changed something and when. Intuit documents how to use it to find deleted transaction details and re-enter them manually. Recovery from an existing backup, including QuickBooks Online Advanced's backup feature, is a separate workflow with its own coverage and prerequisites.

Webhooks

Webhooks are a strong change signal. Intuit documents them as event-triggered callbacks that notify an app when data changes in connected QuickBooks Online companies. They are great for knowing that something happened. They are not, by themselves, proof that you have a restorable historical copy of every affected record.

Change Data Capture

Change Data Capture is useful for reconciliation because it returns changed entities for a look-back window. Intuit documents two constraints that matter for backup design: CDC tracks changes within the last 30 days, and responses can handle a maximum of 1,000 objects. That makes CDC a good ingredient for staying current, not a substitute for independent point-in-time snapshots.

The pattern is clear: QuickBooks tells you a lot about change, but a durable backup product has to preserve its own history.

A real snapshot is a graph, not a row dump

For QuickBooks Online backup, the basic unit is not "an invoice JSON blob." The basic unit is a versioned accounting graph.

A good snapshot preserves enough context to answer recovery questions later:

• What existed at the time? The record payload, stable identifiers, timestamps, and active/deleted state.
• What did it depend on? Customers, vendors, items, accounts, classes, departments, tax codes, terms, and parent-child references.
• What changed since then? The difference between the selected snapshot and the current company state.
• What can be written back? QuickBooks permissions, API support, current record state, and conflicts all matter.
• What should a human approve? Financial recovery should be reviewable before anything touches the live company.

This is where exports fall short. A CSV export can be useful for audit support or manual review, but it usually strips away relationships, API write constraints, and the order of operations needed for a clean restore.

Restore planning is dependency management

Imagine an invoice was deleted. Recreating that invoice may require the customer, item records, tax settings, payment terms, and classes to exist first. If any of those changed after the snapshot, the restore system has to make a decision: use the current object, recreate the missing object, skip the restore, or ask for review.

Now scale that from one invoice to a damaged import batch. You need a plan, not a button.

The restore plan should be explicit about:

• Scope: exactly which records are being recovered and why.
• Order: dependencies before dependents, so transactions are not recreated against missing references.
• Conflicts: records that exist today but differ from the selected snapshot.
• Idempotency: retries should not duplicate transactions because a previous attempt partially succeeded.
• Auditability: who approved the restore, what was written, what failed, and what was skipped.

This is also why "restore everything" is often the wrong first answer. If the blast radius is a deleted bill, the safest recovery is usually granular. If the blast radius is a broad integration mistake, point-in-time recovery may be appropriate, but only after previewing the difference.

What Akika Labs optimizes for

Akika Labs is built around the recovery side of the problem: encrypted point-in-time QuickBooks Online backups, change review, granular restore, and clear restore status for QuickBooks Online companies.

The product uses official QuickBooks Online APIs, stores snapshots independently, and treats restore as a reviewed workflow instead of a blind overwrite. That matters because accounting data is operational data. The goal is not to make a dramatic rollback. The goal is to put the books back into a trustworthy state with the least unnecessary movement.

In practice, that means three design choices:

• Prefer precision over drama. Recover a single record when one record is the problem.
• Show the difference before the write. A human should understand the impact before restore begins.
• Keep evidence. Backup and restore history should help with audits, client questions, and post-incident review.

Questions to ask before you need a restore

If you are evaluating any QuickBooks Online backup approach, ask these questions before you need the answer:

• Can I restore one invoice, bill, customer, vendor, or journal entry without rolling back the whole company?
• Can I preview what changed between two points in time?
• Does the system store independent historical snapshots, or does it only react to recent change events?
• How does it handle deleted records, attachments, references, and conflicts?
• Can I export data for audit review even if I do not restore it?
• Is restore activity logged clearly enough for a client, accountant, or auditor to understand?
• What happens if a restore partially fails because QuickBooks rejects one write?

The best time to answer those questions is before the import, before the app sync, before the cleanup, and definitely before the Friday afternoon panic.

Sources and further reading

• Intuit: use the audit log to re-enter deleted transactions in QuickBooks Online
• Intuit Developer: QuickBooks Online webhooks
• Intuit Developer: Change Data Capture operation