Your statement total froze but its PDF kept recalculating

A monthly statement went out with a subtotal of, say, $1,240. The customer paid it. Months later someone opens the same statement's PDF to check a line and the numbers don't match — the line items now add up to $1,310, but the total still reads $1,240, and that's what was collected. Nobody edited the statement. What changed was a product price, quietly, somewhere else in the system. The stored total was frozen at issue time. The PDF was not — it rebuilt each line from whatever the price is today.

That gap is the bug. The document is telling you two different stories depending on which part you read, and the paid amount followed the wrong one.

How the mismatch happens

Most billing tools store a statement as a record with a total field. The trap is how the PDF gets drawn. If the template loops over the line items and pulls each price by looking up the current product, the PDF becomes a live report instead of a frozen document. As long as prices never change, nothing looks wrong. The day a price moves, the PDF and the stored total silently diverge.

The reason it hides for months is that the total field looks authoritative. It's a real stored number. You'd only catch it by adding the visible lines by hand and noticing they don't match the total — which nobody does on a document already marked paid.

Check whether you have it right now

1. Open a statement or invoice from at least a couple of months ago that has been paid.
2. Add up the line items shown in the PDF with a calculator.
3. Compare that sum to the total printed on the same PDF, and to the amount actually recorded as paid.
4. If all three agree, do it again with an item whose price you know has changed since. That's where the crack shows.
5. If any two disagree, your document is recalculating instead of remembering.

Freeze the snapshot

The fix is a rule, not a setting: the moment a statement is issued, every number on it becomes a stored value that nothing else can touch. Line quantities, unit prices, per-line totals, subtotal, tax, and grand total all get written down together. Editing a product price afterward changes future documents only.

A paid document is a receipt of what was agreed, not a live report of what things cost now.

What to do this afternoon

• Confirm your invoicing tool stores line-item prices on the invoice, not by reference to the product. Most reputable platforms (QuickBooks, Xero, Wave) do this by default — check the vendor's help page rather than assuming.
• If your documents are generated by a custom or spreadsheet-driven template, audit whether the PDF pulls prices live. That's the usual culprit.
• Reconcile the last several months: any paid statement where lines and total disagree needs a corrected document, and possibly a top-up invoice or refund.
• Check whether any GST you remitted was calculated on the frozen total versus the real line sum.

Where DIY stops

Auditing your own invoices and reading the vendor docs, you can do today. If the documents come out of a custom-built app, someone needs to look at the template code and the data model — specifically whether line items are copied at issue time or joined to the product table at render time. That's a developer task, and if money has already been under-collected across many statements, it's also a bookkeeper-and-accountant task to sort out the GST and the customer corrections cleanly.