Stop changed bank details from becoming a paid invoice mistake.
PayVerify is a callback evidence hub for invoice-heavy Australia/New Zealand SMBs: when a supplier email says “new bank account,” your team gets a forced verification trail before approving payment.
Landing-page validation only. No payment processing, bank credentials, or scam-prevention guarantee.
payverify case
Supplier bank change · hold payment
Payment fingerprint
Known supplier account differs from invoice PDF and email request
Trusted contact
Use vendor master phone number, not the number inside the email thread
Approval packet
Owner must sign off after callback note, timestamp, and callback result are stored
Decision trail
“Payment held until callback to known contact confirms whether bank-detail change is legitimate. Export includes approver, timestamp, evidence source, and final decision.”
Narrow customer
Australia/New Zealand SMB owners, finance leads, bookkeepers, and AP/admin operators who approve recurring supplier invoices without formal AP segregation.
Paid problem
A single redirected supplier payment can create direct loss, urgent bank recovery, supplier disputes, cyber-insurance headaches, and owner stress.
Landing test
Join to test whether a manual-first callback evidence packet beats spreadsheets, memory, generic training, and bank warnings before integrations exist.
Day-in-the-life pain
A familiar supplier thread says the account changed. Everyone is busy.
The invoice is due, the supplier relationship matters, and the email looks normal. The owner or admin knows they should verify the change, but the proof lives across a phone call, inbox note, spreadsheet row, bank warning, and memory. PayVerify makes verification the gate before approval.
Input
A supplier email, changed bank-detail notice, invoice PDF, trusted callback number, and the existing supplier-payment fingerprint. Redacted data is enough for validation.
Verification
PayVerify checks what changed, forces an out-of-band callback, records who verified it, timestamps approval, and keeps the old and proposed payment details separated.
Output
A pre-payment decision packet: safe to pay, blocked, or needs owner review — with an audit trail the bookkeeper, owner, or cyber-insurer can inspect later.
Why the workaround breaks
Training says “verify.” Operations needs a gate.
Manual callback policies are sensible, but they fail when the phone call is skipped, the trusted number is unclear, or the approval trail disappears after payment. The first product promise is narrow: make the verification path repeatable and reviewable.
Changed-detail intake
Capture the exact changed bank-detail request before it gets buried inside a trusted-looking email thread.
Trusted callback trail
Require a callback to a known-good contact source, then store who called, when, what was confirmed, and what evidence was used.
Supplier payment memory
Keep approved supplier-payment fingerprints so the next changed-detail request is compared against known history instead of staff memory.
Approval state
Give small teams a simple pending / verified / blocked board without replacing Xero, the bank, or the bookkeeper.
Concierge-first validation
Early users get a manual setup and one changed-detail simulation before any bank, email, or accounting integrations are promised.
Evidence, not proof
The signal is risk-backed, but willingness to pay still needs testing.
Public sources support the payment-redirection pain and current manual verification advice. They do not prove demand for software. This waitlist asks whether invoice-heavy ANZ SMBs will try a lightweight callback evidence hub before a scam happens.
Reddit-first scan · blocked
Direct Reddit and old.reddit searches for invoice/payment-detail complaints returned network-security blocks, so this page does not invent Reddit thread evidence.
GitHub public issue · changed invoice bank details
The public problem write-up describes the risky handoff: a familiar supplier email asks an owner or AP/admin worker to use new payment details before payment leaves the business.
GitHub validation plan · ANZ SMB pilot
A follow-on public experiment proposes testing a manual-first callback evidence hub with invoice-heavy Australia/New Zealand SMBs through bookkeeper and accounting-advisor referrals.
ACCC / Scamwatch signal
The public issue cites ACCC/Scamwatch and bank guidance that payment-redirection and fake-invoice scams can involve altered invoice payment details and require direct verification.
Objections
Not a bank. Not another awareness poster.
Why not just call the supplier?
That is the point. The pain is making the callback happen every time, documenting it, and preventing payment until the evidence exists.
Why not Eftsure, PayOK, GetVerified, or bank checks?
Those may be right for many firms. This test asks whether smaller invoice-heavy SMBs need a lighter callback evidence hub around those controls.
Why not a spreadsheet?
Spreadsheets track rows after humans remember to update them. PayVerify is designed as the pre-payment gate and retained evidence trail.
Is this financial advice or payment processing?
No. The validation offer does not move money, hold credentials, or guarantee scam prevention. It organizes verification work before payment.
Early waitlist
Run one changed-detail case through a manual packet.
Early users get a redaction checklist, a supplier-payment fingerprint template, one callback evidence packet, and a short review comparing it with their current spreadsheet/email/bank-check process.