On this page Jump to section
Question and scope
When an invoice that already has a customer payment applied is edited in QuickBooks Online, does the recorded sales tax recalculate, and does any change reach the payment and the sales tax report? The scope is one company file and a defined set of paid invoices. The test separates three observations: the invoice line and tax amount, the payment application, and the sales tax report for the period. It does not decide whether a tax rate is legally correct, because that depends on the customer's location and applicable rules. The test shows whether an edit changes the accounting record in a way a reviewer can see.
Why a paid invoice needs its own test
An unpaid invoice can be edited and reissued without disturbing cash, but a paid invoice already has a payment applied to a specific balance. If the edit changes the tax amount, the invoice total and the applied payment may no longer agree, and the difference has to go somewhere. A team that tests only draft invoices may never see that mismatch until a customer statement or a tax filing fails to reconcile. Testing the paid path separately keeps the review from assuming that every edit behaves like a pre-payment correction.
The payment method also matters. A bank payment, a credit card payment, and a credit memo may each affect the invoice balance differently when the total changes. A small edit to a taxable line can produce a rounding difference that looks harmless on the invoice but creates an unapplied balance on the customer record. Record the payment type and the application before the edit so the reviewer can tell a tax recalculation from a payment application problem.
Population and unit
Start with a dated export of paid invoices edited during the review window. Record the invoice number, customer reference, original total, original tax amount, payment date, payment amount, edit date, and the person who made the edit. The unit is one edited invoice paired with the payment applied to it before the edit. An invoice with several payments needs one row per payment so a partial change is visible. Exclude invoices with no payment applied and record the exclusion so the population can be rebuilt.
Freeze the list before opening the invoice history. If the invoice is edited 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 invoices that already show the expected tax amount. Use internal customer and invoice references in the working file instead of names and addresses. Store the export with the test notes so another reviewer can retrace the exact population.
Definitions and measures
A recalculation occurs when the invoice's recorded tax amount changes after the edit, compared with the amount stored before the edit. Record the tax amount before and after as separate observations, and record the taxable line amount and tax code at the same time. Do not treat a change in the invoice total as proof of a tax recalculation, because a price or quantity edit can move the total without changing the tax rate. The measure should let a reviewer compare the tax line, the taxable base, and the invoice total side by side.
Also record whether the payment balance changed. If the invoice total moves but the payment stays the same, the difference may appear as an open balance or an unapplied credit. Capture the customer's open balance before and after the edit, and note whether the payment was reapplied automatically or remained linked to the old amount. Keep the measure at the invoice-payment pair so one large invoice cannot hide a single misapplied payment.
Test design
Use a census when the number of edited paid invoices is small, and a documented sample when the list is large. Include at least one invoice with a single taxable line, one with a mix of taxable and exempt lines, one with a discount, and one with a partial payment. Include an invoice from a closed filing period and one from the current open period if both exist. Freeze the sample before opening the tax reports and compare the invoice history, the payment application, and the sales tax report in that order.
Document how the sample was selected and which invoices were left out. A sample built only from the largest invoices will miss the routine edits that create most of the tax noise. If the business uses progress invoicing or retainers, include at least one invoice tied to a prior billing document. Record whether the edit was made through the invoice screen, an import, or a third-party app, because the entry point can change which fields are recalculated. The selection note is what lets a later reader judge whether the result applies beyond the tested rows.
Data collection
Use the invoice history, the customer payment record, the sales tax report, and the general ledger as the source set. Capture the invoice reference, the edit date, the before-and-after tax amount, the payment application, and the report run date. Export the invoice and the tax report before the edit when possible, and keep that file even if the edit 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 invoice reference. Include the invoice before and after, the payment record, the tax report, and any customer message that explains the edit. If the edit was part of a batch correction, record the batch reference and the time it was posted. A reviewer should not have to search across the invoice list and the tax center 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 edits a paid invoice to remove a line that was billed twice. The invoice total falls, but the recorded sales tax may stay at the original amount if the edit does not touch the tax calculation. The reviewer records the original tax, the new tax, the payment amount, and the customer balance before deciding whether the edit recalculated tax or left a stale figure. That sequence shows whether the difference is a tax behavior or a payment application issue.
A second case may show the opposite pattern. The tax amount falls with the removed line, but the payment remains applied to the old total, leaving a credit on the customer record. The reviewer should report the credit as a separate event rather than treating it as proof that the tax recalculated correctly. These examples show why the test records the invoice, the payment, the report, and the ledger as separate observations.
Evidence standard
Each row needs the invoice before and after, the original payment, the tax report view, and the source of each value. Keep the edit approval with the internal record so the reviewer can see who authorized the change. If the edit 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 tax amount and the applied payment is only a recollection of the edit.
Interpretation limits
A tax amount that stays the same may reflect a correct no-change edit rather than a failure to recalculate. A tax amount that moves may reflect a changed taxable line, a changed tax code, or a changed customer address, not only a rate change. History that appears stable does not prove the filing is correct, because the original tax may have been wrong. Pair this test with a review of the edit approval and a comparison of the filed return. Report the invoice type, tax configuration, and report used so the finding is not overread.
Review cadence
Run the test after any change to the tax engine, the chart of accounts, or the invoice template. A quarterly check fits a business with stable tax settings, 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 tax configuration changes, record a new baseline instead of mixing the old and new settings. End the review with a named owner, a specific repair, and a date to retest; for a related control, compare the negative invoice line review.