On this page Jump to section
Question and scope
When a user changes the income account on a QuickBooks Online product or service item, do previously posted sales transactions keep their original account, or does the historical reporting change with the item? The scope is one company file and a defined set of item changes, not every QuickBooks edition or every item type. The test separates the item's current setup from the account used on transactions that were already posted. It does not judge whether the new account is better, because that is a chart-of-accounts decision. The narrow purpose is to show whether history stays stable when the item master changes.
Why item account changes need a controlled test
An item's account setting is used when a transaction is entered, but the transaction may store its own account reference after it is posted. A change to the item can therefore affect new sales without rewriting old ones, or it can appear to move history when reports are rebuilt from the item. The difference matters at month-end, when a bookkeeper compares the sales report with the general ledger. A team that tests only new invoices may never see a historical shift until a prior-period comparison fails. Testing the historical side separately keeps the close from relying on an assumption.
Item types also behave differently. A service item may post to one income account, while an inventory item can involve income, inventory asset, and cost of goods sold accounts. A change that is safe for a service item may be unsafe for an inventory item or a bundle. Record the item type and the accounts involved before testing, so a result from one type is not applied to another. The test should also distinguish a change to the item from a change to the transaction itself.
Population and unit
Start with a dated list of item master changes made during the review window. Record the item reference, item type, old account, new account, change date, and the person who made the change. The unit is one item-account change paired with one historical transaction that used the item before the change. A single item may need several rows when it appears on sales receipts, invoices, and credit memos. Exclude items with no posted sales in the window and record the exclusion so the population can be rebuilt.
Freeze the list before opening the historical transactions. If an item is changed again during the test, keep the first observation and add a dated note rather than replacing the earlier state. A moving list makes it too easy to select only the items that already show the expected account. Use internal item codes and transaction references in the working file instead of customer names. Store the export with the test notes so a later reviewer can retrace the exact population.
Definitions and measures
History is stable when a posted transaction still reports the income account that was used when it was created, after the item master changes. Record the account on the transaction before the change and after the change as two separate observations. Do not treat a change in the item's current account as proof that history moved, because the item screen and the transaction report are different views. Also record whether the transaction amount, tax code, and class stayed the same. The measure should let a reviewer see the item setting and the posted transaction side by side.
Capture the report used, the date it was run, and any filters applied. A sales by product or service report may group by the item's current account, while a transaction detail report may show the account stored on the line. Record both views when they disagree, because the disagreement is itself a finding. Keep the measure at the item-transaction pair so one item with many sales cannot hide a single changed line. A clear definition prevents a reviewer from comparing an item list with a ledger total and calling the difference an error.
Test design
Use a census when the number of changed items is small, and a documented sample when the list is large. Include at least one service item, one inventory item, one item used on an invoice, and one item used on a sales receipt. Include a transaction from a closed period and one from the current open period if both exist. Freeze the sample before opening the historical reports and compare the transaction detail, the item setup, and the ledger in that order. A second reviewer should recheck a subsample and record disagreements before the team resolves them.
Document how the sample was selected and which items were left out. A sample built only from high-revenue items will miss the low-volume items that often carry stale accounts. If the business uses bundles or grouped items, include at least one bundle that contains a changed item. Record whether the change was made through the item edit screen, an import, or a third-party app, because the entry point can affect what is updated. The selection note is what lets a later reader judge whether the result applies beyond the tested rows.
Data collection
Use the item list, the transaction detail, the sales by product or service report, and the general ledger as the source set. Capture the item reference, the transaction date, the account shown, the amount, and the report run date. Export the historical view before the item change when possible, and keep that file even if the change is later reversed. Mark any reconstructed value and name the person who reconstructed it. Do not overwrite the original export columns when adding analysis fields, because the original values are the evidence.
Save the supporting files in one folder keyed by the item reference. Include the item setup before and after, the transaction detail, and the report that shows the account. If the change was made in a batch, record the batch reference and the time it was posted. A reviewer should not have to search across the item list and the ledger to reconstruct one change. The folder can be small, but it must let another person follow the same path without asking the preparer what happened.
A worked example
Suppose a business changes a consulting item from professional fees to advisory revenue and then reviews an invoice posted two months earlier. The transaction detail may still show professional fees, while a sales by product report grouped by the item may show advisory revenue. The reviewer records both views, the report run dates, and the item change date before deciding whether history moved. That sequence shows whether the difference is a display choice or an actual reclassification.
A second case may show the opposite pattern. The transaction detail keeps the old account, but the general ledger for the current period shows a reclassification entry that was posted separately. The item change did not rewrite history, yet the ledger still moved because someone made a journal entry. The reviewer should report the journal entry as a separate event rather than attributing it to the item edit. These examples show why the test records the item, the transaction, the report, and the ledger as separate observations.
Evidence standard
Each row needs the item setup before and after, the original transaction, the report view, and the source of each value. Keep the change approval with the internal record so the reviewer can see who authorized the new account. If the change was reversed, retain both the original and the reversal and record the dates. Protect customer details by using internal references in the working file. A test that cannot show the original item setup and the posted transaction is only a recollection of the change.
Interpretation limits
History that appears to move may be a reporting behavior rather than a ledger change, especially when a report groups by the item's current account. History that stays stable does not prove the chart of accounts is correct, because the new account may still be wrong for future sales. Pair this test with a review of the change approval and a comparison of the current-period ledger. Compare the result with the negative invoice line review when an account change and a credit appear together. Report the item type, report used, and QuickBooks configuration so the finding is not overread.
Review cadence
Run the test after any change to the item list, the chart of accounts, or the reporting package. A quarterly check fits a business with a stable catalog, while a monthly check may be needed during a cleanup or a system migration. Keep the sample rule and the definitions stable so two periods can be compared. If the item structure changes, record a new baseline instead of mixing the old and new catalog. End the review with a named owner, a specific repair, and a date to retest; for a related control, compare the class tracking duplication test.