On this page Jump to section
Published November 2, 2026
Question and scope
A duplicate bill can be caught in two minutes or two months. The difference matters because the longer a duplicate stays in the workflow, the more likely it is to affect an approval, a payment, or an aging report. A team that says it reviews duplicate bills has not said much until it can describe how long detection takes and which step usually catches the problem.
This note asks a narrow operational question: for a defined population of duplicate vendor bills in QuickBooks Online, what is the elapsed time between bill entry and the first recorded detection? The measure describes the review process. It does not estimate financial loss, assign fault, or prove that the duplicate would have been paid.
Population and unit
Start with a dated export of vendor bills for a fixed period, plus the duplicate review log if one exists. Record the report filters, extraction time, and the person who prepared the export. Keep the list stable for the measurement; if a later review changes the population, preserve the earlier version and explain the change.
The unit of analysis should be one duplicate event, not one bill. A duplicate event consists of an original bill and a second bill that represents the same obligation. If three bills represent the same purchase, that is still one duplicate event with three records. Counting every extra bill as a separate event can make a small problem look larger and can distort the average.
Use a stable key that combines vendor, invoice number, amount, and service period where those fields are available. Do not rely on the vendor name alone, because a vendor may issue several legitimate bills with similar descriptions in the same month.
Defining detection
The start point is the posting date of the second bill, because that is when the duplicate enters the workflow. The stop point is the first dated evidence that someone identified the duplication. That evidence can be a review note, a hold status in the bill record, a message to the vendor, or a correction that removed the bill from the payable list.
Be careful with the stop point. A conversation in a hallway is not a recorded detection. A note that says "looks familiar" without a date is not a usable stop point. If the team cannot establish when the duplicate was first noticed, code the event as detection date unknown and report it separately rather than guessing.
Also distinguish detection from resolution. A bill can be flagged as a possible duplicate on day three and remain open for three weeks while the vendor confirms the invoice number. Latency to detection and latency to resolution are different measurements, and mixing them hides where the delay actually sits.
Measurement design
A practical design combines a census of the duplicate review log with a sample of corrected or voided bills that never appeared in that log. The census captures known duplicates. The sample looks for duplicates that were handled quietly during payment review or reconciliation.
Record the review method for each event. Useful categories include vendor invoice number match, amount and date match, payment review hold, reconciliation review, vendor confirmation, and owner question. Keep the list short and define each category so two reviewers apply it the same way.
Compute latency in whole days from the posting date of the second bill to the detection date. Report the median and the distribution by age band rather than only the average. A single very old duplicate can pull an average far away from the typical experience, and the old case may be the one that reveals a control gap.
Separate the elapsed time into stages where the evidence allows it. Entry to first review, first review to hold, and hold to resolution are useful stages. If the team cannot reconstruct the stages for every event, reconstruct them for the largest or oldest cases and say so in the note.
Data quality checks
Confirm that the duplicate review log and the bill export use the same identifiers. Duplicate rows, split bills, and credits applied to the wrong bill can inflate the count. Check whether a bill was edited after posting; an edited bill may show a later date than the event that actually created the duplicate.
Look for bills that were reversed and re-entered. The reversal may look like a detection when it was really a correction of an unrelated error. The review note should state why the bill was removed, not only that it was removed.
Check the audit trail for deleted bills. A deleted bill may leave less evidence than a voided bill, and the team should record that limitation. If the approved system does not retain the deletion history, note it and rely on the review log rather than inventing a date.
Interpretation limits
A short detection time does not prove that the control is strong. A reviewer may be catching duplicates quickly because the vendor sends very few bills, or because the same person enters and reviews every bill and remembers the earlier entry. Those conditions can change without warning.
A long detection time does not prove that the process is careless. The duplicate may have arrived during a system migration, a vendor portal change, or a period when the review log was unavailable. The measurement should describe the conditions that were present during the observation window.
Avoid using latency as an individual performance metric. The same review step can behave differently depending on bill volume, vendor mix, and staffing. The useful management question is which stage catches duplicates and whether that stage has enough capacity and evidence to keep doing so.
Review cadence
Run a small baseline measurement, then repeat it after any change to the bill intake or duplicate review process. A quarterly review is usually enough for a stable workflow. A monthly review is more useful during a cleanup, a system change, or a period of rapid vendor growth.
End each review with a decision record: keep the current review step, add a duplicate check at entry, change the hold rule, or improve the vendor invoice number requirement. Name the owner and the effective date. Archive the export, the review log, the coding sheet, and the notes so another reviewer can repeat the measurement.
The value of the measure is not a single number. It is a repeatable way to see where duplicates are caught and how much time passes before they are. That visibility lets the team strengthen the earliest practical control instead of relying on a late catch during payment review.