Loading
Because details get copied onto each payment run. A bank detail is updated in one place and not another, and the error surfaces when a supplier says they were never paid.
A vendor record holds who you buy from: payment terms, tax registration, bank details, contacts, and everything ever ordered, billed and paid.
There is one record, and payment runs read it rather than a copy. A change to bank details is held for a second approval, because that is the field fraud goes after.
A supplier emails new bank details. The change is flagged and held until confirmed on a known number, no payment run can use it in the meantime, and the old details stay in the history.
It will not verify that a vendor is who they say they are. It enforces the second pair of eyes; the check itself is a phone call somebody has to make.
Purchase orders, bills, debit notes and payments all reference it. Payables aging and the cash flow commitments group by it.
Yes — one organisation record with both roles, which is what allows contra settlement.
Yes, with who changed them, when, and who approved it.
Yes, which blocks new orders and payment runs while leaving history intact.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.