Sales Tax Payable Looks Wrong Under Cash-Basis Accounting in QuickBooks Desktop
A sales tax liability report that pulls invoices from the wrong month often traces back to the cash or accrual setting in QuickBooks Desktop.
QuickBooks Desktop users sometimes open the sales tax payable report and find figures that refuse to line up. Taxable sales look too high or too low, or invoices from an earlier month surface inside the current filing period. A question from the vendor’s French-language community space points to a cause unrelated to damaged data. We walked through the accepted explanation, and it comes down to timing. The basis used to build the report, cash or accrual, decides both the amount and the month in which sales tax appears.
The accounting method sets the clock
Desktop treats sales tax as a workflow: set the tax up, collect it on invoices, review the liability report, then remit to the agency. The accepted answer here, published by the software vendor, stresses a detail many users miss. The accounting method chosen for the report controls when the program counts tax as owed.
Under accrual, tax is counted the moment an invoice goes out. The full amount lands in the month the invoice was created, no matter when the customer pays, or whether they pay at all. Under cash, nothing registers until money arrives. A fully paid invoice drops its entire tax into the month the payment was received.
That timing difference has real consequences. An accrual-based figure can force a remittance before the customer has paid a cent. A cash-based figure holds the tax back until collection, which helps cash flow but splits the liability across months.
Why does a partial payment split the tax?
Partial payments are where the cash method gets interesting. Picture a fully taxable invoice for $1,000 and a customer payment of $200. The program applies the payment against taxable sales first, then calculates the tax on that slice. One fifth of the invoice’s tax becomes payable in the month of the partial payment. The other four fifths stay off the report until later payments land.
Each later payment repeats the pattern. A customer who pays in three installments across three months spreads the tax across those same three months. Nothing is lost; it is simply deferred until the cash shows up. To anyone expecting the full figure at once, the output looks broken. It is arithmetic, not corruption.
The cases that complicate the math
Three situations add friction under cash accounting, according to the same guidance. Invoices that mix taxable and non-taxable lines make the proration less clean, because a payment may not map neatly onto taxable sales. Credits shrink the amount that counts as collected. Discounts do the same. Each one shifts how much of a payment the program treats as taxable cash in a given month.
For monthly filers, the effect is sharpest at period boundaries. A payment that lands a few days after a month closes pushes its share of tax into the next filing window.
How do you confirm which basis the report used?
This is the practical resolution the accepted answer lands on. Before assuming a data problem, check whether the sales tax report was generated on the cash basis or the accrual basis. In Desktop, the liability report can be produced on either basis, so the choice made at report time governs the output. The same period will show different figures under each method.
A report on the wrong basis looks wrong even when every transaction behind it is correct. It also helps to keep the basis consistent from one filing period to the next. Figures produced on different bases will not compare cleanly, and the mismatch has nothing to do with sales activity. Run the report on the basis you intend before you file, and the numbers stop contradicting each other.
The short version
If taxable sales seem off, or old invoices appear in the current period, the accounting basis is the first thing to verify. Expect prorated tax on partially paid invoices under cash accounting, and expect extra complexity when untaxed items, credits, or discounts share an invoice with taxable ones. Once the logic is clear, the alarm fades. The report is not miscounting; it is answering a different question than the one you thought you asked.