Sales Tax Rounding: Why Checkout Totals Differ by a Cent

When to use this workflow

This article explains how to investigate the arithmetic. It does not prescribe one calculation method for every state. The relevant jurisdiction's instructions and the transaction facts determine which method your checkout should use.

See the difference with two small items

Imagine two items priced at $0.99 each, both fully taxable at a hypothetical 7% rate. Tax on one item is $0.0693. If each item's tax is rounded to the nearest cent first, each contributes $0.07, producing $0.14 total tax.

If the system first adds the taxable prices, the subtotal is $1.98. Multiplying $1.98 by 7% produces $0.1386, which also rounds to $0.14. In this basket the methods agree. That agreement does not prove they will always agree.

Now use two $0.05 items at the same illustrative 7% rate. Each item's tax is $0.0035, which rounds to $0.00 under ordinary nearest-cent rounding. Adding those rounded results produces $0.00. Calculating on the $0.10 subtotal produces $0.007, which rounds to $0.01. The different sequence explains the cent; it does not establish which sequence is legally appropriate.

New York instructs sellers to multiply the taxable sale amount by the applicable combined rate and round tax to the nearest cent. Use the state's full guidance for its rate and calculation requirements rather than treating this example as a nationwide rule. New York sales tax rates and calculation guidance.

Check the taxable base before blaming rounding

Two systems can display the same rate while taxing different amounts. A shipping charge may have been included in one calculation, a discount allocated differently, or an exempt item classified as taxable. These are tax-base differences, even when the final discrepancy is small.

Export the unit price, quantity, discount, shipping allocation, taxable amount, and tax for each line. Confirm that both calculations use the same currency and tax-inclusive or tax-exclusive pricing mode. Then compare the unrounded arithmetic. If the inputs differ, resolve that difference before adjusting precision settings.

Our shipping tax article and product bundle explanation help separate classification questions from arithmetic questions. A blanket rounding adjustment cannot repair incorrect product treatment.

Inspect combined rates and individual components

A displayed percentage can represent several jurisdiction components. Software may store the components individually while showing one combined rate to the customer. Another system may store only the combined percentage. Depending on where rounding happens, recalculating and rounding components separately can produce a different sum.

Request the actual calculation details rather than inferring them from the displayed percentage. Record the component rates, the taxable amount assigned to each, the precision retained, and whether the final amount was rounded before or after aggregation. Do not change the legal rate to force a match with a receipt.

Look for precision loss in exports

A spreadsheet formatted to show two decimals may retain more precision internally, while a CSV export may contain only the displayed value. Conversely, a system may round values before export, leaving no way to reconstruct the original intermediate amounts from that file alone.

Keep original transaction exports unchanged. Perform analysis in a separate working copy and document any rounding applied there. In software, use a suitable decimal or minor-unit money representation and an explicit rounding policy. The technical choice should implement the required business rule, with examples that demonstrate how half-cent cases and negative amounts are handled.

Refunds need the original transaction context

A partial refund introduces another allocation problem. If the original invoice rounded at basket level, the tax associated with one returned item may not equal a fresh standalone calculation for that item. Recalculating at a newer rate can create an additional mismatch.

Retain links from each refund to the original order, line item, and tax amount. Compare the refund engine's allocation with the original calculation and the applicable adjustment rules. Check that successive partial refunds do not cumulatively refund more tax than was originally collected. Read the returns and exchanges article for the wider workflow.

Build a useful discrepancy report

For each mismatch, capture the order ID, transaction date, jurisdiction, pricing mode, expected tax, actual tax, difference, and reason. Useful reason codes include taxable-base mismatch, incorrect rate, rounding stage, discount allocation, refund allocation, and incomplete export.

Review patterns as well as individual amounts. Differences concentrated in one product category suggest a mapping issue. Differences appearing only on small multi-item baskets suggest a rounding sequence worth inspecting. A sudden change after a checkout release should be compared with the previous configuration and transaction sample.

Do not automatically write every small difference to a generic rounding account. First establish its cause and agree on an accounting treatment. A tolerance used to prioritize investigation is not an exemption from collecting or reporting the correct tax.