On this page Jump to section
Question and scope
When a vendor record changes in QuickBooks Online, can the audit log export be used to reconstruct who made the change, when it happened, and what the record looked like before and after? The test compares audit log entries with the vendor record's current state and with any change request or approval record. It covers changes to name, address, email, phone, bank details, terms, and active status. The scope is one company file and a defined review window. The result shows whether the export is sufficient for a review, not whether the change itself was appropriate.
What the audit log can and cannot show
The audit log records events that QuickBooks Online chooses to retain, with a timestamp, user, and event description. It is not a full before-and-after snapshot of every field, so a reconstructed value may come from a combination of the log and other evidence. The log may show that a vendor was edited without showing the old bank account number in a readable form. A reviewer who treats the export as a complete history can overstate what it proves. The audit question is therefore about sufficiency, not just availability.
Audit log retention and export options can also differ by subscription and user role. The person who can view the log may not be the person who can export it, and the export may omit fields that are visible on screen. A bookkeeping VA should test the actual export in the file rather than assume the log matches the interface. The test documents the export format, the columns, and the date range that was available. Without that record, a later reviewer cannot tell whether a missing event was never logged or simply outside the export.
Population and unit
Start with a dated list of vendor record changes from the review window. Use the audit log to identify candidate events, then add changes found through vendor statements, payment requests, or owner messages. The unit is one vendor record change paired with one audit log entry or set of entries. A single change that produced several log rows is one observation with multiple evidence lines. Record the vendor reference, change type, date, actor, and source of the request. The population should include routine edits and changes that arrived through an integration.
Exclude vendor creations and deletions from the change population and record them separately, because they answer a different question. If a vendor was merged, treat the merge and the resulting record as one event only when the log links them. Freeze the list before reviewing the current vendor record, so the sample is not selected from changes that are easy to prove. Use internal vendor references in the working file to limit exposure of bank details. A frozen population keeps the review from becoming a search for the most convenient evidence.
Export method
Export the audit log for the full review window and for a short period before it, so the baseline state can be compared. Save the raw export without editing the columns, and keep a second copy for analysis. Record the export date, the user who exported it, and the filters that were applied. If the interface shows more detail than the export, capture the relevant screens as supporting evidence. The export should be a preserved artifact, not a spreadsheet that was cleaned before anyone reviewed it.
Open the export in a tool that preserves the original text and timestamps. Do not retype dates into a spreadsheet without recording the conversion, because a timezone shift can move an event to the wrong day. Keep the original file hash or a read-only copy so a later reviewer can confirm the evidence was not altered. Store the export with the vendor change list and the approval records in one folder. The folder structure is part of the evidence because it shows which records were reviewed together.
Matching and definitions
A matched entry means the audit log event can be tied to the vendor reference, the change type, and the date of the known change. A partial match means some of those elements agree but at least one is missing. An unmatched entry means the log shows an event that the change list does not explain. Record each category separately rather than forcing every event into a match. Report the reason for a partial match so the owner can decide whether the gap matters.
Capture the actor exactly as the log shows it, including service accounts or integrated apps. A change made by an app may appear under a generic user or integration name, which is different from a person making the change directly. Record the old value and new value only when the evidence supports them. If the log shows an edit but not the field, mark the value as unknown rather than reconstructing it from memory. The distinction between unknown and unchanged is central to an honest reconstruction.
Procedure
Work from the frozen change list and search the export for each vendor reference and date. Save the matching rows with their original row numbers so another reviewer can find them. Compare the event description with the change request and the approval record. If the log shows a different actor than the request, stop and investigate before concluding that the record is wrong. The first pass establishes what the log can support, not what the reviewer expected to find.
Run a reverse check by sampling audit log rows that mention vendor edits but are not on the change list. This catches changes that were never requested or recorded. For each reverse-check row, search the vendor file and the approval folder for an explanation. Record unmatched rows as exceptions with an owner and a follow-up date. The reverse check is what separates a reconstructed history from a list of known events. It is also the step most likely to reveal an integration that edits records outside the normal request path.
Worked example
Suppose a vendor's bank account changes on a Tuesday and the payment run is scheduled for Thursday. The change list names the bookkeeper as the requester and the owner as the approver. The audit log shows a vendor edit by the bookkeeper on Tuesday morning, but it does not show the old account number. The reviewer pairs the log with the vendor change form and the bank verification call record. That combination supports who and when, while the old value remains supported only by the change form.
A second vendor shows an audit log edit by an integration user on a date with no change request. The reviewer searches the integration's sync log and finds that the vendor address was updated from a connected system. That may be a legitimate automated change, but it still needs an owner who can confirm the source. The example shows why the audit log is a starting point for reconstruction, not a complete answer. A log that names an integration is useful only if someone can explain what the integration is allowed to change.
Evidence standard
Each observation needs the audit log row, the vendor change request, the approval, and the current vendor record. Keep the export and the change list together, with the date range and the user who exported them. Record the exact field values that can be supported and mark the rest as unknown. A reviewer should be able to follow the same path without asking the preparer what the log meant. The standard is repeatability, not the appearance of completeness.
Protect bank details and personal information in the working file. Use masked values for the last four digits and keep the full evidence in a restricted folder. Record who accessed the folder and when. An evidence standard that exposes sensitive data to the whole team creates a new risk while trying to control an old one. The review should leave the owner with a smaller exposure, not a second copy of every vendor's bank account.
Interpretation limits
A missing audit log entry does not prove that no change occurred. Retention, export filters, integration behavior, and role permissions can all hide an event from the reviewer. A log entry with the right actor does not prove the change was approved, because approval lives outside the log. A reconstructed value is only as strong as the document that supports it. These limits should appear in the review memo, not only in the reviewer's head.
The test also cannot establish intent. A vendor bank change may be legitimate, fraudulent, or simply a correction, and the audit log will look similar in each case. Pair the review with a call-back verification and a payment hold when bank details change. Report the limits so the owner does not treat the export as a fraud detection system. The log supports a conversation about control; it does not replace the control itself.
Review cadence
Run the audit log reconstruction after any vendor bank change, after a role change, and before a payment run that follows a holiday or staff absence. A monthly sample of ordinary vendor edits catches drift, while an event-driven review catches the changes that matter most. Keep the field definitions and the export method stable so results can be compared across periods. The cadence should reflect both the volume of vendor changes and the owner's tolerance for unresolved exceptions. A stable method is more useful than a perfect one that changes every month.
Close each review with a named owner, a specific repair, and a retest date. If the export format changes, record a new baseline and re-run the sample. Link the review to the vendor record access review and the month-end close checklist so the next reviewer inherits the context. A review that cannot show its own evidence trail has not reconstructed anything. The final memo should say what the log proved, what it did not prove, and who owns the remaining question.