QuickBooks Audit Log

What the log actually captures

The common assumption is that the audit log is a transaction report. It is wider than that. Alongside transactions it captures list changes and settings changes, so an edited customer, a renamed account or a switched preference all leave an entry, and so does a user signing in.

There is one documented gap in that coverage worth knowing before you rely on it for access questions. Sign-outs are only recorded when the user selects Sign out. Closing the browser or letting the session time out leaves no entry, so the log shows a sign-in with no matching sign-out and nothing is wrong.

The filter panel narrows by User, Date and Events, and results come back 150 records at a time. On a file where a sync writes daily, that limit is the practical constraint: filter to the account and the days you care about before you start reading, because the unfiltered view of a synced file is mostly the sync.

The audit log and the audit history are different objects

The audit log is file-wide. You open it from Settings, then Audit log, and you use it to find out that something changed at all.

The audit history belongs to a single transaction. Open the transaction, select More actions, then Audit history. Intuit describes it as a record of who made the changes, when the changes were made, and what the changes are. Show all expands the view, and Compare puts versions side by side so you can see which field moved.

The division of labour is worth internalising, because using the wrong one wastes an afternoon. If you know which record is wrong, go straight to its audit history and compare versions. If you only know that a total is wrong, start in the log, filter to the account and the period, and find the record first.

Access differs too. The log requires admin access. The audit history requires full access rights. A bookkeeper with limited access can be looking at the same file and see neither.

Why a synced file shows changes nobody remembers making

This is the part that matters most in a file fed by Stripe, and it surprises people every time.

QuickBooks creates a set of profiles that stand in for actions no human performed, and one of them covers connected apps. Intuit is explicit: "You connect a third-party app to QuickBooks. When the third-party app sends data to QuickBooks, or when it makes a change to your existing data, this appears as a System Administration event."

So in a file where Stripe activity arrives through an integration, the sync is not a named user in the log. Its records are System Administration entries. That is not a defect and it is not something to fix, but it changes how you read the log: the useful question is rarely who wrote this record, it is whether this record was written by the sync or touched by a person afterwards.

Three other profiles do similar work. Online Banking Administration covers automatic changes related to connected bank accounts. Support Representative covers changes made by a QuickBooks Online support consultant. Import Administration covers automatic changes from a QuickBooks Desktop conversion.

Read in that light, the log becomes a separation tool. Sync-written records carry a system profile. Anything else on the same record is a person, and a person editing a synced record is the single most common cause of a file that stops agreeing with Stripe.

What the audit log will not do for you

The log is a record, not an undo button, and the distinction has teeth when a transaction has been deleted.

Intuit is direct about the outcome: "Once a transaction is deleted in QuickBooks Online, it can’t be restored." What the log preserves is the detail, so you can find the deleted transaction and re-enter it manually. That is re-entry, not recovery: a new record, with a new identity, that merely resembles the one that is gone.

There is a second limit stated just as plainly. "Audit log only works for transactions that were saved. There is no available report for deleted transactions." A transaction that was never saved leaves nothing behind.

This is the whole reason experienced bookkeepers void rather than delete. A voided transaction stays in the file, numbered and searchable, with its amount zeroed. A deleted one leaves the file entirely and survives only as a description in a log, which is a much weaker thing to hand an auditor.

Using it on a reconciliation that broke

The audit log has one job it does better than any other tool in QuickBooks, and Intuit builds it into the official procedure.

When a previously reconciled account reports that its beginning balance has changed, the documented causes are all edits to history: a reconciled transaction that was edited, deleted, voided, moved or unreconciled, a categorized bank feed transaction sent back to pending, or an incorrect opening balance from when the account was created.

The instruction for finding which one applies is specific. Go to Settings, then Audit log, filter to the account and the period since your last completed reconciliation, and review the log for deleted or voided transactions.

On a Stripe-fed file that procedure gets sharper, because of the profile split above. The holding account is the account every synced record passes through, so it is the account most likely to have been edited after the fact. Filter its audit log to the period, and the entries divide cleanly into what the sync wrote and what somebody changed. The second list is almost always short, and the answer is almost always in it.