Run a Sales Tax Code Exception Queue

BLUF: Sales tax code errors are a data quality problem before they are a tax problem. A monthly exception queue finds transactions with missing, inconsistent, or overly broad codes and routes them to the person who owns the tax decision.

The queue does not calculate tax, interpret nexus, or decide exemptions. It reduces the number of surprises that reach a filing.

Start with the code field, not the return

A return shows the total. The transactions show where the total came from. Reviewing the transaction level first makes the return easier to trust.

Export the sales transactions for the period with the customer, ship-to location, product or service, tax code, tax amount, and source document. Add the channel: invoice, sales receipt, or imported order.

Look for three states: a code is present, a code is missing, or the code conflicts with another field. All three matter.

Define what counts as an exception

Write the rules down so the queue is consistent month to month.

• A taxable product with no tax code
• A non-taxable product with a tax code applied
• A customer marked exempt but charged tax, or the reverse
• A ship-to jurisdiction that does not match the code
• A code that was retired or replaced in the tax setup
• A manual override with no note

Add a rule for high-value transactions even when the code looks right. Those are the ones worth a second look.

Build the evidence for each item

For each exception, capture the transaction number, date, amount, customer, code, and the source document. Link the invoice or receipt so the reviewer does not have to search.

Record what the customer record says about exemption and jurisdiction. If the exemption certificate is missing, say so. A missing certificate is a decision for the tax owner, not something to fix silently.

Mark the item as observed, needs evidence, or awaiting decision. Avoid a single "error" label, because the fixes are different.

Route the decision to the right owner

The tax adviser decides code treatment. The bookkeeper decides how to record the correction. The assistant prepares both with the same evidence packet.

Set a response target, such as five business days, and a review date for anything unresolved. A queue that never closes becomes a list nobody trusts.

When the owner decides, record the decision and the date beside the transaction. The next reviewer should not have to reopen the question.

Repair in the right order

Correct the transaction before you correct the return. Fixing a return without fixing the source means the error returns next period.

For code changes, check whether the customer or product default should also change. A single transaction fix that leaves the default wrong will regenerate the exception every month.

Re-run the queue after the fixes to confirm the item is gone, and note any exception that was accepted as a known risk with an end date.

Keep the queue small and visible

Review the queue monthly, before the filing deadline rather than after it. Report the count, the value, and the age of open items.

Track the top three causes. If most exceptions come from one product category or one sales channel, fix the default or the import mapping instead of reviewing the same items every month.

Boundaries

The assistant does not register the business in a new jurisdiction, sign exemption certificates, or advise on taxability. Those decisions carry legal and financial risk and belong to the owner and their adviser.

The assistant's value is a clean, dated record: what was found, what evidence exists, who decided, and what changed.