Nacha Phase 2 Audit Trail: What Your Bookkeeper Needs to Keep
Most discussion of Nacha Phase 2 stops at the rule and the workflow: have a risk-based process, verify vendor bank changes out-of-band, do not trust the channel that asked. That is the front half of the job. The back half is the part that gets skipped, and it is the part someone will eventually ask you to produce. When a payment goes wrong, or a renewal questionnaire lands, or an auditor samples your controls, nobody wants to hear that you "always call to check." They want the record. This post is about that record: what a defensible one contains, why the usual stand-ins do not qualify, how long to keep it, and what the people who ask for it are actually looking for. It is informational, not legal, accounting, insurance, or Nacha advice.
A control without a record is a habit
Nacha's 2024 Risk Management rules require covered parties to "establish and implement risk-based processes and procedures reasonably intended to identify ACH entries initiated due to fraud." The word "implement" is doing quiet work there. A process you run but cannot evidence is, from the outside, indistinguishable from no process at all. If you cannot show that the control operated on a specific change, for a specific vendor, on a specific date, then for review purposes it did not.
This matters more under Phase 2 than it did before. Phase 2, effective Monday, June 22, 2026 (June 19 is the Juneteenth federal holiday, so the next banking day applies), removes the 6-million-entry volume threshold that scoped Phase 1 to larger originators. After that date, all non-consumer Originators, Third-Party Service Providers, and Third-Party Senders must have risk-based fraud-monitoring processes, regardless of size. The framing worth keeping in mind: June 22 is the date the obligation turns on for everyone and stays on, not a deadline that expires. See Nacha: Fraud Monitoring Phase 2 and Phase 1.
The reason the highest-risk moment is the vendor bank-change request is the same reason it always was. The FBI's IC3 2024 Internet Crime Report put reported business email compromise losses at $2.77 billion across 21,442 complaints, roughly $129,000 per reported incident. When one of those incidents touches your firm, the first question is not whether you had a policy. It is whether you can show what you did on the change that went bad.
What a defensible record actually contains
A defensible record is not a longer note. It is a set of discrete facts, captured at the time they happened, in a form that resists later editing. Six elements make up the core. If any one is missing, the record gets weaker in a predictable way.
1. The vendor, identified unambiguously. Not "the supplier" or a first name, but the specific vendor as it exists in your books, ideally tied to the QuickBooks Online vendor ID. If you carry two vendors with similar names, the record has to say which one.
2. The change itself. What was requested, in concrete terms: the new account's last four digits, the new routing number's institution, and what it replaced. You do not store full account numbers in your own evidence file. The point is to fix what was being asked, so that later you can show the verified detail matched what was actually paid.
3. The channels, both of them. The channel the request arrived on (the email thread, the phone call, the portal message) and the separate channel used to verify it. The whole logic of the control is that these two differ. A record that names only one channel cannot demonstrate that the verification was out-of-band, which is the property that makes it a control at all.
4. Timestamps for each step. When the request was logged, when verification was sent, when the confirmation came back. Sequence is evidence. A confirmation timestamped before the request, or a release timestamped before the confirmation, tells a reviewer the process did not actually run in order. Real timestamps protect you precisely because they can also expose a broken process, which is why a reviewer trusts them.
5. The attestation. The actual confirmation from the previously verified contact, in their words where possible: who confirmed, that they confirmed the change is real, and that the details match. "Confirmed" as a checkbox is thinner than "Maria in AR confirmed the new account ending 4417 on a recorded call." The attestation is the human core of the record; everything else is metadata around it.
6. A tamper-evident seal. A cryptographic hash (SHA-256) computed over the record at the moment it is finalized. This is the element that separates a structured record from a defensible one. A hash lets you demonstrate, later, that the record you are producing is byte-for-byte the record that existed at the time, not something edited after the fact. Without it, every other field is only as trustworthy as "we promise we did not change it."
Put together, these six answer the one question a reviewer is really asking: can you show what you checked, when, through which independent channel, and that the record has not been altered since?
Why a memo field or a screenshot is not enough
This is where most firms are today, and it is worth being precise about why the common stand-ins fall short. They are not worthless. They are just not what gets asked for.
The QBO memo field is a live, editable field. A line like "called vendor 6/12, OK to pay" sits in a record that anyone with access can overwrite, with no preserved history of who wrote it or when. It captures that a note exists now. It does not establish when the note was written, whether it was edited, or who entered it. It is mutable by design, which is the opposite of what evidence needs to be. It also collapses the whole event into one free-text string, so the discrete fields a reviewer wants, the two channels, the sequence of timestamps, the specific account detail, are not separately recorded and cannot be reliably reconstructed.
A screenshot of the confirmation email is self-referential. If the verification you are evidencing was an email confirmation, a screenshot of that email proves only that the email exists. It does not show that the address belonged to the previously verified contact rather than the channel that requested the change, and an image file carries no integrity guarantee. Screenshots are trivially editable and routinely are, even innocently, cropped, annotated, re-saved. An image is an illustration, not a record.
A folder of PDFs and emails is better, but it is not a control trail. Many careful bookkeepers keep exactly this. The gap is that nothing binds the pieces together, fixes when each was created, or proves the set is complete and unaltered. You have the raw materials of evidence without the structure that makes them defensible as a unit.
The test is the same one a reviewer applies. If a payment to a vendor were disputed eighteen months from now, could you produce a single record of exactly what you checked, when, through which independent channel, and demonstrate it has not been quietly edited since? A memo field and a screenshot do not pass that test. A structured, timestamped, hashed record does.
How long to keep it, and why
There is no single Nacha-published "keep vendor-verification evidence for X years" number for an SMB originator, so retention is a judgment call you set deliberately rather than a figure you copy from the rulebook. A few reference points shape a reasonable default.
ACH origination records and authorizations live on a multi-year horizon in the Nacha framework generally; two years is a common floor people anchor to for ACH-related records. Fraud and the disputes that follow it surface late, often a year or more after the payment, when an account is reconciled or a supplier finally chases a missing receipt. Cyber-insurance claims and the questions that come with them can run well past the policy year in which the loss occurred. And your own professional standards as a bookkeeper or CPA may already set a longer baseline for client records.
The practical synthesis most firms land on is to retain vendor bank-change verification evidence for the longer of your existing client-records retention policy or a multi-year minimum, and to align it with your cyber-insurance carrier's stated requirement. Many firms standardize on a horizon in the range of three to seven years for records of this kind, which comfortably covers the window in which a disputed payment or an insurance question is likely to arise. The reasoning is straightforward: the evidence is cheap to keep and expensive to lack, and the moment you need it is precisely the moment you cannot create it after the fact. Confirm the specific number against your own retention policy, your carrier's questionnaire, and your CPA. Treat what follows as a default to refine, not a rule to adopt.
Two retention details people miss. First, the record has to remain readable and verifiable for the whole retention period, which means the integrity seal and the underlying file both have to survive, not just one of them. Second, retention has to outlast the staff who created the record. A control documented only in one bookkeeper's inbox is a control that leaves when they do.
What an auditor, insurer, or bank actually asks for
The audience for this evidence is narrower and more specific than "compliance" in the abstract. Three parties tend to ask, and they ask for different things.
An auditor or examiner samples. They will not review every change. They pull a handful of vendor bank changes from the period and ask you to walk each one: show me the request, show me how you verified it, show me when, show me that it was a different channel than the one that asked. What sinks firms here is not the absence of any process but inconsistency, the control that ran on the big payments and got skipped on the routine ones. A uniform, per-change record is what survives sampling.
A cyber-insurance carrier asks on the questionnaire and again at claim time. Renewal questionnaires increasingly include a line about vendor / payment-change verification: do you confirm banking-detail changes through an independent channel, and can you evidence it. Answering yes is one thing. At claim time, if a BEC loss occurs, the carrier may ask you to demonstrate that the control you attested to was actually operating on the relevant transaction. A retained, per-change record is the difference between an answered questionnaire and a substantiated claim. Check your own carrier's wording, because it varies, and the exact phrasing tells you what they expect you to keep.
A bank or ODFI asks as part of its own Nacha obligations. Your originating bank is itself a covered party under these rules, and it may ask its originating customers to describe and, on request, evidence their fraud controls. Being able to hand over a clean account of how vendor bank changes are verified is a smoother conversation than improvising one.
Across all three, the shape of the request is the same: not "do you have a policy," but "show me this specific change." Evidence that is organized per change, captured at the time, and tamper-evident is what answers that cleanly.
Where BankChangeGuard fits
BankChangeGuard is one SMB-priced way to produce exactly this record as a routine byproduct of running the control, rather than as a separate documentation chore that quietly lapses. It connects to QuickBooks Online with read-only access on the vendor and bill scopes. It does not touch bank credentials, does not originate ACH, and does not move money.
When a vendor claims new bank details, your bookkeeper logs the request against the synced QBO vendor and records the new account's last four. BankChangeGuard emails a one-time code to the previously verified contact, the person on file before the change was requested, not the channel that asked. When they enter the code, the confirmation is captured. You then export a structured audit record as a PDF: the vendor, the change, both channels, the step-by-step timestamps, the attestation text, and a SHA-256 hash of the record so later alteration is detectable. That is the six-element record above, generated once and retained, in a form built to be handed to an auditor, an insurer, or your bank.
To be precise about scope: the email callback is a workflow control, not independent verification that the new account belongs to the vendor, so for high-value or suspicious changes you should still add a phone call to a number you already had on file and require dual approval before release. BankChangeGuard supports your Nacha Phase 2 fraud-monitoring obligations by giving you a documented, retainable control record. It does not make you "Nacha-compliant," Nacha does not certify tools, and it does not replace your bank's own Nacha obligations. The decision to release, hold, or escalate, and the ACH origination itself, stay with you and your bank. Pricing is $99 per month, flat: one seat, one QBO company.
If you want to see the artifact first, look at a sample audit PDF and the compliance page, which states exactly what the record does and does not claim.
FAQ
What is the minimum a vendor-verification record should contain? The vendor (tied to its QBO ID), the specific change (new account last four), both channels (the one that requested and the independent one that verified), timestamps for each step, the attestation from the previously verified contact, and a tamper-evident hash of the record. Miss any one and the record gets weaker in a predictable way; the hash and the second channel are the two that most often distinguish a defensible record from a note.
Is a note in the QuickBooks Online memo field enough? No. The memo field is a live, editable free-text field with no preserved history of who wrote it or when, and it collapses the event into one string rather than discrete, dated facts. It is better than nothing and not what an auditor, insurer, or bank asks for. A structured, timestamped, tamper-evident record is.
How long should we keep vendor bank-change evidence? There is no single Nacha figure for SMB originators, so set this deliberately. A common default is the longer of your existing client-records retention policy or a multi-year minimum, often landing in the three-to-seven-year range, aligned to your cyber-insurance carrier's stated requirement. Confirm the exact number with your CPA and your carrier; the evidence is cheap to keep and impossible to recreate after the fact.
Does keeping this record make us "Nacha-compliant"? No. Nacha is technology-neutral and does not certify tools, and no record or software confers compliance on its own. The record helps you evidence that a risk-based control operated. Compliance remains a property of your overall process and the judgment of your bank and CPA.
This article is informational and does not constitute legal, accounting, insurance, or Nacha compliance advice. Confirm current requirements against the Nacha rulebook and consult your bank, CPA, and counsel for your specific situation.