Research · Published:
Vendor bank-change timing inside a payment proposal
Research on preserving which bank instruction, verification event, and payment-proposal version existed at each decision cutoff.
Methodology
A bank-detail change received near a payment cutoff creates two linked questions: whether the new instruction was validly verified and which instruction a particular payment proposal actually used. This study focuses on chronology because a current vendor-master screen cannot prove what was selected when the proposal was created, reviewed, approved, exported, or released. The research output is a reconstruction of change request, independent verification, master-data versions, proposal versions, exclusions, and downstream events. It does not validate ownership of an account, decide that a callback was sufficient, edit supplier banking, select the old or new instruction, waive a hold, approve an exception, create a payment file, or release funds. The distinction matters for outsourced AP support: staff can make the evidence chain visible, but convenience and deadline pressure must not convert a preparation role into vendor-master or treasury authority.
Evidence and scope
The source population begins with every vendor-bank change whose request, effective date, approval, or system update overlaps a declared payment-preparation window. It also includes every proposal line for those suppliers, whether paid, excluded, held, rejected, or rolled forward. The register records entity, supplier identifier, change case, request channel, received time, requested values represented only by controlled references, verification method and independently sourced contact, verifier, approver, master-data version, effective time, proposal identifier and version, invoice keys, amount and currency, selected payment-method token, holds, export time, file identifier, bank response, and final disposition. Sensitive bank values never enter an ordinary audit sheet. Masked fingerprints or secure system references are enough to test version relationships. Shared suppliers across entities remain separate because one entity's verified instruction may not govern another entity or payment method.
Key Stats
Request provenance is evaluated before timing. The FBI's current business-email-compromise guidance warns that messages may appear to come from known sources and advises verifying changes in account number or payment procedures through independently obtained contact information. That is risk guidance, not proof that any request is fraudulent or a complete private-company procedure. The preparer records observable features: sender, channel, attachments, urgency, differences from approved records, and the source of the verification contact. It does not use the phone number supplied in the same change message as independent evidence unless company policy explicitly defines and controls that path. A supplier confirmation establishes what the contacted person said; authorized company owners still decide whether the verification and documentation meet policy and whether the master may change.
Research-to-practice
The central timeline separates requested effective date, verification time, approval time, system-entry time, master effective time, proposal creation, proposal refresh, approval, export, transmission, acceptance, rejection, cancellation, and settlement evidence. These events may occur in different systems and timezones. A proposal created before a bank change can refresh afterward. A master update approved before cutoff can fail to reach the payment engine. A rejected file may be regenerated after the instruction changes. The packet preserves every version and the rule or system behavior used to select details. It never assumes that the latest screen retroactively governed an earlier export. Where a platform does not retain versions, the research records the evidence gap and available compensating sources instead of manufacturing certainty from a screenshot taken after the event.
Implementation
Proposal-line reconstruction uses stable identifiers and protected account fingerprints. For each version, the reviewer can see the supplier record, payment method, masked destination token, invoice population, hold state, and actor or process that refreshed it. A difference matrix identifies lines added, removed, altered, or unchanged. The packet distinguishes a master-data change from a proposal override and an override from a bank-file transformation. If an authorized employee decides to retain an old instruction for a specific payment, that disposition and its authority are linked; the support analyst does not implement or infer it. If a bank rejection triggers resubmission, the rejected file, response code, correction decision, and new file remain chained. Reusing a proposal number does not permit the previous version to disappear.
Key Takeaways
Challenge cases include a verified change approved after proposal creation; a request for one entity mistakenly visible to another; a supplier with separate domestic and foreign-currency accounts; a change entered in the master but not synchronized; an urgent invoice paired with a bank request; a file rejected and rebuilt after the change; a callback made to a number from the request; and a proposal refreshed without a clear audit event. Two reviewers reconstruct which bank-detail token each proposal stage used and identify unresolved verification or authority questions. The method passes when the same chronology and gaps emerge. It fails when current master data is treated as historical evidence, when masked values cannot be related safely across sources, when an unsuccessful file is discarded, or when deadline language is accepted as permission to bypass a required hold.
Findings
Access and separation are critical. AP support may index requests, gather approved verification records, compare masked tokens, preserve proposal histories, maintain holds already authorized by policy, and route precise exceptions. It may not amend vendor banking, obtain verification through an unapproved channel, approve the change, remove a security hold, override proposal details, create or modify bank files, approve payments, or release funds. Vendor management, finance, treasury, security, and payment approvers retain their assigned decisions. NIST least privilege and audit controls support restricting privileged functions and retaining who did what, when, where, and with what result. GAO's Green Book supports separation of duties, quality information, and documented control activity. The exact workflow remains the company's responsibility.
Findings
Useful measures include in-scope changes, independently sourced verification records, approval states, master versions retained, affected proposals, pre-change and post-change proposal lines, synchronization gaps, holds, overrides, rejected files, owner dispositions, and second-review reproducibility. A fast update is not inherently a good result, and a held payment is not inherently a failure. Reports should never expose bank data or rank staff by how quickly they clear security exceptions. Limitations include system histories that overwrite values, external bank processing outside the company's visibility, supplier organizational changes, shared-service configurations, and inaccessible verification recordings. This research cannot determine legal account ownership, prove or disprove fraud, define bank liability, or authorize payment. Its supported conclusion is that the risk becomes governable when every requested and approved change, effective-time decision, proposal version, masked destination, hold, export, and final owner action can be reconstructed without relying on the latest screen or oral memory.
Findings
The handoff to the authorized payment owner should show one compact lineage for each affected line: verified supplier identity reference, approved master version, proposal version, masked destination token, security holds, invoice population, and latest bank response. It explicitly says whether the proposed destination changed after an earlier approval and whether the workflow requires renewed review. The owner records the chosen action and reason; the support role only preserves it. After transmission, settlement or rejection evidence is appended without treating bank acceptance as proof that the supplier ultimately received or allocated funds. If the supplier later disputes receipt, the same lineage supports investigation while keeping the original verification and release decisions intact. This end-to-end record is more useful than a screenshot of a successful status because it exposes every controlled transition. A separate exception note records any unavailable system event, the compensating evidence used, and the person accountable for resolving the gap. Reviewers can then distinguish confirmed chronology from an inference instead of allowing a plausible narrative to harden into fact.
Preserve bank-detail chronology without changing or releasing funds
Support can assemble proposal versions, change records, and verification evidence. Authorized company owners control vendor-master changes, exceptions, payment approval, file creation, and release.
Review payment run preparationSources
These primary sources support the control principles and evidence boundaries in this report.
FAQs
Are the planning numbers benchmarks?
No. They describe a testable workflow shape and are not promises, market averages, or production targets.
What should an outsourced AP assistant own?
Repeatable preparation, documentation, status tracking, and follow-up within least-privilege access. Named finance owners retain approval and payment decisions.
When should an item be escalated?
When evidence is missing, a request changes payment details, a duplicate or fraud signal appears, or the item falls outside the written rule.