On this page Jump to section
Published November 2, 2026
Question and scope
Receipt collection depends on a small piece of contact information that is easy to change and easy to forget. A vendor updates its billing contact, the team edits the vendor record in QuickBooks Online, and the next receipt request goes to an address that no longer reaches the person handling invoices. The request may look sent in the team's records while nothing is actually moving.
This note asks a practical question: after a vendor contact change, do open and future receipt requests still reach a contact who can respond? The scope is the request path, not the accounting treatment of the underlying transaction. The test does not measure whether every vendor responds promptly; it measures whether the request still has a valid destination and an owner.
Population and unit
Begin with a dated list of vendor contact changes for the review period. Capture the vendor, the field that changed, the old value, the new value, the date of the change, and the person who made it. If the system does not retain the old value, note that limitation rather than reconstructing it from memory.
Then identify every open receipt request linked to those vendors at the time of the change. An open request is one that has not reached a final state such as evidence attached, accepted exception, or carried forward with an owner. Use the same status definitions the receipt queue already uses.
The unit of analysis is one request, not one vendor. A vendor with four open requests has four separate paths that may fail in different ways. Counting only vendors can hide a case where one request was updated and three were missed.
Defining a surviving request
A request survives a contact change when three conditions hold. First, the request has a destination that is still valid for the vendor. Second, the destination is recorded in the approved system rather than in a personal address book. Third, the request has a named owner who will notice if no response arrives.
A request fails the test when the destination is known to be stale, when the request points to a generic inbox that nobody monitors, or when the owner has left the workflow without a handoff. A request is unverified when the team cannot confirm whether the destination works. Report unverified separately; do not count it as a success or a failure without evidence.
The distinction matters because a contact change can look harmless in the vendor record while breaking the request trail. The new contact may be correct for billing but not for document requests, or the new address may be a distribution list that silently drops external senders.
Measurement design
A practical design combines a record review with a small delivery check. The record review confirms that every open request has a recorded destination and an owner. The delivery check confirms that at least one request per changed vendor reached a monitored destination, using a reply, a delivery receipt, or a documented confirmation from the vendor.
Record the method used for the delivery check. Useful methods include a test message to the new contact, a confirmation from the vendor's accounts payable contact, or a check of the sent-folder and bounce record for the most recent request. Keep the method consistent across the sample so the result is comparable.
For each request, record the age at the time of the contact change, the status after the change, and the number of days until the next action. Age matters because an older request usually carries more close risk. A change that affects a request from three days ago is a different problem from one that affects a request from three weeks ago.
Use a small sample when the vendor list is long. Select every changed vendor for the record review, then select a documented subset for the delivery check. Define the selection rule in advance and record the sample size. If the team expands the sample after seeing a failure, mark the expansion and report the original result separately.
Data quality checks
Confirm that the contact change was recorded against the correct vendor. Duplicate vendor records are common, and an edit to one record may leave the other unchanged. Check whether the vendor has more than one active record and whether the request points to the record that was updated.
Check the audit trail for the change date. A note added later may describe the change but not establish when it happened. Use the system timestamp where it is available, and record the source of the date.
Look for requests that were closed around the same time as the contact change. A request closed without evidence may have been marked complete because the team lost the thread rather than because the document arrived. Compare the close reason with the attachment or decision record.
Finally, check the destination itself. An address that accepts mail but is not monitored is not a working destination. If the team cannot confirm monitoring, code the request as unverified and follow up before the close.
Interpretation limits
A successful delivery check does not prove that every future request will arrive. Contact changes, mailbox rules, and vendor staffing can shift after the test. The result describes the requests observed during the review window, not a permanent guarantee.
A failed delivery does not prove that the vendor is unresponsive. The request may have reached the right company but the wrong person, or the message may have been filtered. The test should identify the broken path and the owner who will repair it, not characterize the vendor's intent.
The sample size also limits the conclusion. A handful of changed vendors can reveal a process gap, but it cannot support a precise failure rate. Report the count and the observed cases rather than a percentage that implies more precision than the data supports.
Review cadence
Run the test after any vendor contact change that affects an open request, and run a broader review at the next close. A short check at the time of the change catches the immediate break. The close review catches patterns, such as repeated changes from one vendor or a contact field that is updated without a follow-up task.
End each review with a decision record: update the request destination, assign a new owner, add a confirmation step to the vendor change workflow, or escalate the vendor contact issue. Name the owner and the date. Archive the change list, the request sample, the delivery evidence, and the notes so a later reviewer can repeat the test.
The strongest outcome is not a perfect pass rate. It is a repeatable way to see whether a vendor record change quietly breaks receipt collection before the gap reaches the close package. That visibility lets the team repair the path while there is still time to collect the document.