On this page Jump to section
Question and scope
When a purchase order is converted to a bill in QuickBooks Online, do the class and location values on the order follow the transaction to the bill at both the header and the line level? The scope is one company file and a defined set of purchase orders converted during a review window. The test compares the order and the bill as separate records, line by line, rather than relying on a total or a header field. It does not decide whether the original coding was correct, because that depends on the job, department, and reporting structure of the business. The test shows whether the conversion preserved the coding that the reviewer approved.
Why conversion needs its own test
A purchase order is a commitment, while a bill is a payable, and QuickBooks Online treats them as different transaction types. The conversion can carry some fields forward and rebuild others from the vendor, the item, or the company default. A team that checks only the bill total can conclude the conversion worked while the class and location quietly reset. Those fields drive job costing, departmental reporting, and owner dashboards, so a silent reset can distort a margin report for months.
The problem is easy to miss because the bill still looks complete. It has the right vendor, the right amount, and the right due date, so nobody opens the line detail. The error surfaces later when a class-based profit and loss report shows an expense in the wrong department or a job cost report shows a missing cost. Testing the coding at conversion time is cheaper than rebuilding the allocation after the period closes, when the original intent is harder to reconstruct.
Population and unit
Start with a dated export of purchase orders converted to bills during the review window. Record the purchase order number, the bill number, the vendor, the conversion date, the person who converted it, and the approval reference for the original order. The unit is one converted line, paired with the purchase order line it came from. A bill with five lines therefore produces five observations, because a partial carry-forward is exactly the failure the test is designed to detect.
Exclude purchase orders that were closed without a bill attached and record the exclusion so the population can be rebuilt. If a purchase order was split across several bills, keep one row per bill line and note the split. Freeze the list before opening the transactions, because a moving list makes it too easy to select only the conversions that already look correct. Use internal references in the working file and store the export beside the test notes.
Definitions and measures
A preserved value means the bill line carries the same class and location as the purchase order line it came from, with no manual edit between conversion and observation. Record the purchase order header class and location, the purchase order line class and location, the bill header class and location, and the bill line class and location as separate fields. The separation matters because a header can carry one value while the lines carry another. A reviewer needs to see which level changed before deciding whether the conversion or a later edit caused the difference.
Also record whether the value is blank, inherited from a default, or explicitly set. A blank field on both records is consistent, but it may still mean the coding was never applied. An explicit value on the order that becomes blank on the bill is a preservation failure, even if the bill total is unchanged. Capture the reporting period and the report run date so a period cutoff does not look like a conversion effect. Keep the measure at the line level, because a header-only comparison can hide a mixed result.
Test design
Use a census when the number of conversions is small, and a documented sample when the list is large. Include at least one order with a single line and one with several lines, one where every line shares a class, and one where lines carry different classes or locations. Add an order with a billable line, an order with a inventory or service item, and an order converted after a vendor record change. Include a conversion completed in the current open period and one from a closed period if both exist.
Document how the sample was selected and which conversions were left out. A sample built only from the largest orders will miss the routine purchases that create most of the coding work. If the business uses projects or customer jobs, include an order where the class represents the job rather than a department. Record whether the conversion was done from the purchase order screen, a copy action, or an import, because the entry point can change which fields are carried forward.
Data collection
Use the purchase order list, the bill list, the transaction detail report, and the audit log as the source set. Capture the purchase order number, bill number, line description, item, amount, class, location, and the conversion date. Export the purchase order and the bill before making any correction, and keep those files even if the bill is later edited. Mark any reconstructed value and name the person who reconstructed it. Do not overwrite the original export columns when adding analysis fields.
Save the supporting files in one folder keyed by the purchase order reference. Include the approved order, the bill, the transaction detail report, and any approval note that explains why the coding was chosen. If the conversion was part of a batch, record the batch reference and the time it was completed. A reviewer should not have to search across the audit log and three reports to reconstruct one conversion. 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 converts an order with three lines: two office supplies charged to administration and one job-specific material charged to a customer project. The bill arrives with the correct vendor and total, but the job-specific line loses its class. The reviewer records the order line class, the bill line class, the amount, and the conversion date. That sequence shows whether the value was dropped during conversion or changed by a later edit.
A second case may show a different pattern. All line classes survive, but the bill header location resets to the company default while the lines keep the original location. A report grouped by header location then disagrees with a report grouped by line location. The reviewer should report the header and line results separately rather than declaring the conversion a pass or a failure. These examples show why the test treats each field and each line as its own observation.
Evidence standard
Each row needs the purchase order before conversion, the bill after conversion, the transaction detail view, and the source of each value. Keep the approval for the original order with the internal record so the reviewer can see who authorized the coding. If the bill was edited after conversion, retain the before-edit and after-edit views and record the dates. Protect vendor and customer details by using internal references in the working file. A test that cannot show the original order line is only a recollection of what someone intended.
Interpretation limits
A preserved class does not prove the coding was correct, because the order itself may have carried the wrong value. A changed value does not always mean the conversion failed, because a person may have edited the bill deliberately after it was created. A blank field on both records may reflect a business that does not use class or location tracking at all. Report the conversion method, the item type, and the report used so the finding is not overread. Pair this test with a review of the order approval and a comparison of the job cost report.
Review cadence
Run the test after any change to the purchase order workflow, the item setup, or the class and location list. A quarterly check fits a business with stable purchasing, while a monthly check may be needed during a system migration or a job-costing cleanup. Keep the sample rule and the definitions stable so two periods can be compared. If the conversion process changes, record a new baseline instead of mixing the old and new methods. End the review with a named owner, a specific repair, and a date to retest.
For related evidence, compare the purchase order commitment review and the class and location tracking review. For platform context, use Intuit's QuickBooks Online help center. Record the repair in the same evidence folder as the test rows. Retest the changed conversion path before the review is closed.