On this page Jump to section
Question and scope
When a customer invoice is duplicated in QuickBooks Online, do the class and location assignments remain attached to the new invoice and stay correct for reporting? The duplicate is a convenience, but it can quietly carry a prior period's coding into a new billing context. This test asks whether the copied fields survive and whether a reviewer can prove the result. It does not decide whether the original coding was right or whether the duplicate should exist at all. The narrow purpose is to compare the original and copied invoice at the field level and at the report level.
Population and unit
Start with a dated list of customer invoices duplicated during the review window. Record the original invoice, the duplicate, the customer, the service period, the preparer, and the duplication date. The unit is one original invoice that produced at least one duplicate. An invoice duplicated twice remains one unit, but each duplicate needs its own evidence row because the copies may have been edited differently. Exclude invoices with no class or location assignment and invoices that were deleted rather than duplicated, and record those exclusions so the population can be reproduced.
Freeze the list before testing. If a duplicate is edited during the review, keep the original observation and add a note about the later change. A moving list makes it too easy to select only the copies that still look correct. Use an internal reference rather than a customer name in the working sheet, and store the source export beside the test notes. The frozen list is the evidence that the test covered a defined population instead of a convenient sample chosen after the result was known.
Definitions and measures
A class survives when the duplicate carries the same class assignment as the original at the time of duplication, and a location survives under the same rule. Correctness is a separate question: the duplicate may keep the original class and still need a different one because it covers a new period or a different service line. Record survival and correctness separately. An assignment that survives but is wrong is not a success, and an assignment that changes on purpose is not automatically a failure. The distinction keeps the test from rewarding mere field copying.
For each invoice, capture the original class, the duplicate class, the original location, the duplicate location, and the person who reviewed the comparison. Note whether the duplicate was created from the invoice action or rebuilt by hand. A manual rebuild is a different control path and should be reported separately. Also record the transaction date and service period, because a class may be period-specific. These fields let the reviewer see whether a mismatch came from copying or from a deliberate recoding decision.
Report survival and correctness in separate columns so the reader cannot mistake one for the other. A duplicate that kept an outdated class should appear in both the survival count and the exception list. A duplicate that changed class on purpose should show the approval reference beside the change. If an approval cannot be found, treat the change as unexplained rather than assuming it was intentional. This reporting shape keeps the test useful to both the preparer and the owner who relies on the class report.
Test design
Use a census when the number of duplicates is small, and for a larger set select a documented sample that includes duplicates from different preparers, customers, and service periods. Include at least one duplicate that was edited after creation and one that fed a report used by the owner. Freeze the sample before opening the invoices. Have one reviewer compare the fields and a second reviewer check a subsample. Record disagreements before resolving them, since a different view of what counts as the same class can change the result.
Run the comparison in the transaction detail first, then in a class-based report. The report step matters because a field can look correct on the invoice while the report groups it differently due to a filter or a renamed class. Export the original and duplicate rows from the report and compare the totals. If a class was renamed during the period, note the old and new labels. Do not assume that a matching label in two screens proves the same underlying class identifier.
A worked example
Suppose an invoice for January carries class "North" and location "Warehouse A." The team duplicates it in February for the same customer but changes the service period. The duplicate keeps both fields. Survival is complete, but correctness depends on whether February work still belongs to North and Warehouse A. The reviewer should record the survival result, then ask the owner whether the coding still fits the new period. A copied field is evidence of continuity, not proof that the coding decision was reviewed.
Now suppose the duplicate carries the class but loses the location. The report for Warehouse A will understate February revenue while the invoice detail looks nearly complete, which is the kind of silent gap this test is designed to catch. If the location was removed on purpose, the reviewer should record who approved the change and why. The useful outcome is not a perfect survival rate. It is a clear list of copies that need a coding decision before the next report is issued.
Evidence standard
Each row needs the original invoice reference, the duplicate reference, the class and location on both, the duplication date, and the review date. If the duplicate was edited after creation, retain the first observed state and the later state. A screenshot is useful, but the transaction export and audit log are stronger evidence because they preserve the field history. Keep the original and duplicate links in the working sheet rather than copying customer documents into it. The reviewer must be able to reopen the evidence without relying on a remembered screen.
Protect customer names, billing addresses, and contract details. Use internal references in the analysis file and limit access to the evidence folder. Do not place the full invoice PDF in a shared spreadsheet when a link to the approved system will do. If a class or location name contains a sensitive customer identifier, redact it in the summary while keeping the original reference in the restricted file. The test should improve reporting confidence without creating a new privacy exposure.
Interpretation limits
A surviving class does not prove that the duplicate is correctly coded. It shows that the copy preserved the original field, which may be exactly the wrong outcome for a new period. A lost class does not prove that the preparer was careless, because the duplicate may have been rebuilt deliberately or the class may have been retired. Report both the observed state and the documented reason when one exists. Avoid turning the result into a preparer scorecard.
The same invoice can behave differently depending on how the duplicate was created and whether the class list changed between periods. A small sample can produce a survival rate that moves sharply after one unusual invoice. Report the count and the individual exceptions, not only a percentage. If the population is too small to support a stable rate, say so. The useful question is whether the team has a review step that catches a missing or outdated class before the report is used.
Review cadence
Run the test after any change to the invoice duplication process, the class list, or the location list. A monthly check fits a business that duplicates invoices often, while a quarterly check may be enough for a small billing team. Repeat the same definitions and the same exclusion rules so the comparison remains meaningful. If the team changes what counts as a correct class, start a new baseline and record the reason. A stable test is more useful than a perfect one.
End each review with a decision record. The team might add a class check to the duplication checklist, require owner approval for a changed location, rename a confusing class, or leave the process unchanged. Name the owner and the recheck date. Archive the frozen list, the comparison sheet, the report export, and the notes. A test that ends without a decision becomes another report in a folder, while a decision record turns the observed gap into a control the team can actually maintain.