On this page Jump to section
Question and scope
When a recurring transaction template is copied into a new QuickBooks Online company file, do the class and location values on the template survive, or does the new file silently drop them? The test compares the source template, the copied template, and the first generated transaction in the target file. It covers templates for invoices, bills, journal entries, and checks where class or location tracking is enabled. The scope is one source file and one target file during a defined migration window. The result shows whether the copied values are reliable enough for reporting, not whether the migration itself was wise.
Why templates carry hidden assumptions
A recurring template is a stored instruction that encodes account, class, location, customer, vendor, and timing choices. Those values may refer to list items that exist in the source file but not in the target file, so a copy can succeed while a dimension quietly resets. The risk is highest when the target file uses different names, inactive list entries, or a simpler tracking setup. A bookkeeping VA who tests the template before using it avoids discovering the loss after a month of reports has been posted. The template is not just a convenience; it is part of the reporting control.
The template also carries the original poster's assumptions about how the business is organized. A class named after a department in the old file may not exist in a new file with a different reporting structure. A location may be blank because the source file never used location tracking, even though the target file requires it for sales tax or management reports. Testing the copy surfaces those differences while they are still easy to correct. It also gives the owner a concrete reason to confirm the reporting structure before the first new transaction posts.
Population and unit
Build a list of every recurring template active in the source file before the migration. Record the template name, transaction type, interval, next date, account, class, location, and the person who owns it. Treat one template in one file pair as the unit of analysis. A template copied to two target files produces two observations, because the list setup in each target can differ. Exclude templates that were already inactive for a full cycle and record the exclusion so the population can be rebuilt.
Keep the list stable during the test. If a template is edited after the copy, note the edit date and test the version that was actually copied. Save the source list as a read-only export and compare it with the target list by template name and transaction type. Names are not always unique, so add the next date and amount to the matching key. That prevents a test from pairing two templates that happen to share a label. A frozen list is the difference between a test and a tour of whatever looks interesting.
Test setup
Create the target template through the same path the business will use in production. If the migration tool copies templates automatically, run one manual copy as a control and compare the results. Enable class and location tracking in the target file before the copy so a missing value cannot be blamed on a disabled preference. Record the user role that performed the copy and the date and time of the action. The setup should be repeatable by a second reviewer without asking the first person what they clicked.
Prepare a source set that includes templates with a class only, a location only, both dimensions, and neither dimension. Add a template whose class or location is inactive in the source file, and one whose value does not exist in the target. Include a template with a split line and a template with a discount or markup if the file uses them. The mix should expose both silent drops and outright copy failures. A sample made only of simple templates will miss the cases that cause reporting drift.
Definitions and measures
A preserved value means the target template shows the same class or location as the source template after the copy is saved and reopened. A dropped value means the target template is blank where the source had a value. A substituted value means the target shows a different class or location, even if the label looks similar. Record each field separately so a preserved class cannot mask a missing location. The categories must be exclusive at the field level, because a template can preserve one dimension and lose the other.
Also test the first generated transaction, not only the template screen. A template can display the right value while the generated transaction posts without it. Compare the generated transaction's class and location with the template and with the source transaction pattern. Record the posting date, transaction number, and the report that would be affected. The measure is complete only when the template and the posted transaction agree. A green check on the template screen is not evidence about the ledger.
Procedure
Copy one template at a time and save it before opening the next. Capture a screenshot of the source template and the target template with the relevant fields visible. Generate one transaction from the target template in a test period, then open the transaction and record its class and location. Reverse or delete the test transaction through the file's normal process, and document the cleanup. Working one template at a time keeps a failed copy from being confused with the next template in the queue.
Repeat the procedure for every template in the population. If a value is dropped, try a manual correction and record whether the correction survives a save and reopen. Do not assume that a correction made on the template will reach future generated transactions. Test the next generated transaction after the correction, because some templates regenerate from a stored schedule rather than from the edited screen. The repair is complete only when the posted transaction carries the corrected value.
Worked example
Suppose a source invoice template bills a customer monthly and assigns the class "North" and the location "Warehouse." The target file has a class named "North" but no location with that name. After the copy, the template shows the class but the location is blank. The first generated invoice also posts without a location, so a location-based sales report understates the warehouse activity. The reviewer records a dropped location at both the template and transaction levels.
A second template may show the opposite pattern. The target file has a location called "Main" that was inactive in the source, and the copy substitutes it because the original location name no longer exists. The template screen looks complete, but the posted transaction now points at a different reporting unit. The reviewer records the substitution as a failure even though no field is blank. The distinction matters because a blank field is easy to notice, while a plausible substitute can survive several closes before anyone questions the report.
Evidence standard
Each observation needs the source template export, the target template view, the generated transaction, and the report or list that defines the expected class and location. Keep the screenshots or PDFs in one folder keyed by template name and copy date. Record the person who performed the copy and the person who reviewed the result. If a value was corrected, keep both the before and after evidence and note the approval. The evidence should be readable by someone who did not witness the migration.
The evidence should let a second reviewer repeat the comparison without access to the original bookkeeper's memory. Include the list of active classes and locations in both files at the time of the test. Record any list item that was created, renamed, or inactivated during the migration. A template test that cannot show the list state at the moment of the copy is only a guess about what happened. Save the list export with the test folder rather than relying on a later screenshot.
Interpretation limits
A preserved value does not prove the target template is correct for the new file. The class or location may exist but no longer match the business's reporting structure. A dropped value may be intentional if the target file does not use that dimension, so the reviewer must confirm the reporting requirement before calling it a defect. The test also cannot detect a value that is present but applied to the wrong line of a split transaction unless each line is checked. Report the field-level result and the intended reporting use together.
The result applies to the templates and files tested, not to every QuickBooks Online migration. Different copy methods, user roles, and list states can produce different outcomes. Report the method, the file versions, and the list state so the finding is not overread. Pair the test with a review of the first month's reports to confirm that the dimensions behave as expected in practice. A migration that preserves the field but changes the reporting meaning is still a control problem.
Review cadence
Run the template test before any migration that changes the company file, the chart of accounts, or the class and location lists. Repeat it after a bulk list rename or a change in the person who maintains recurring transactions. A quarterly spot check fits a stable file, while a monthly check fits a business that relies on recurring billing for most of its revenue. Keep the sample rule and the definitions stable so two periods can be compared. The cadence should follow the risk, not the calendar alone.
Close the review with a named owner, a specific repair, and a date to retest. If the copy method changes, record a new baseline instead of mixing the old and new results. Link the test to the handoff record and the month-end close checklist so the next reviewer inherits the context. A template that cannot be tested should be flagged as an open migration risk, not counted as preserved. The report is finished when the owner knows which dimensions are safe to rely on.