Originally published March 9, 2026. Substantially rewritten and editorially reviewed September 8, 2026.
When an ERP, storefront and tax engine disagree about the same product, buying another tool can move the disagreement downstream. A sales tax data governance plan should identify who owns each fact, how a reviewed tax treatment becomes effective, and how a transaction can be reconstructed later.
Use this checklist when selecting sales tax software or planning an integration. It is a proposed evaluation method, with the state examples limited to the jurisdictions cited.
Start with one transaction and its source records
Ask each vendor to trace an agreed sample transaction from the source order through the calculation result, accounting entry and period export. Include a correction so the demonstration covers change history as well as the happy path.
Keep the business facts separate from tax conclusions. A product description, delivery address and sales channel are inputs. Taxability, sourcing and collection responsibility are decisions that need their own basis. A clean address does not establish whether an item is taxable, and a product tax code does not establish nexus.
Create a field ownership worksheet before comparing features:
| Data group | Questions to resolve | Evidence to request in a demonstration |
|---|---|---|
| Product | Who owns descriptions, bundle components and tax classifications? | Original product identifier, reviewed treatment and effective date |
| Customer and location | Which system supplies the address and how are conflicting values handled? | Submitted address, changes and review history |
| Exemption | Which document supports which purchaser, transaction and jurisdiction? | Retrievable certificate, scope and review status |
| Channel | Which party is responsible for the marketplace transaction? | Channel identity, supporting agreement and reviewed treatment |
| Transaction | What links an order, adjustment and accounting entry? | Stable identifiers, original amounts and correction history |
These are procurement checks, not a claim that every business needs a separate MDM platform. A governed existing system may meet the requirement. Compare that option with a shared data service using the same sample and acceptance criteria.
Keep evidence accessible when master data changes
Master data is usually current-state information. An audit or reconciliation may concern a prior period. Test whether changing a product mapping today leaves the earlier transaction and the treatment used then retrievable. Ask how an authorized correction is recorded and which downstream records it changes.
A file hash can help detect a changed document; it cannot reconstruct the document. Keep the underlying records accessible under the applicable retention policy. California's recordkeeping guidance includes original transaction documents and the schedules used to prepare returns. CDTFA Publication 116: Types of Records.
Texas generally requires sales and use tax records for at least four years and describes longer retention while an audit, appeal or refund matter remains unresolved. An automatic deletion rule must account for those circumstances. Texas Comptroller: Keeping Records.
For exemption data, a filled customer field is not the same as supporting documentation. Texas specifically distinguishes a customer's permit number or permit copy from a resale certificate. Ask a vendor to demonstrate the document and review workflow, including incomplete and mismatched records. Texas Comptroller: Resale Certificates.
Test five failures before approving an integration
Use a controlled sample that your tax and accounting reviewers understand. These are suggested test cases, not reported customer results.
- Import the same order twice. Confirm how the system identifies the duplicate and whether totals change.
- Supply conflicting product classifications. Confirm that the conflict is visible and assigned to someone who can resolve it.
- Change a classification's effective date. Verify which transactions use the change and how the prior result is preserved.
- Remove a required source field. Inspect the exception and recovery path instead of assuming an empty value means zero or exempt.
- Export a corrected period. Reconcile the original amount, adjustment and final amount, and retrieve the supporting records without relying on a screenshot.
Write down the expected result before running the demonstration. Record an unresolved result as an open requirement, with an owner and a proposed resolution. A successful test of one connector does not establish the behavior of a different connector.
Measure the work your team actually performs
Choose measures tied to the workflow you tested: unresolved mapping conflicts, duplicate transactions, missing supporting records, corrections after close and time spent retrieving evidence.
Measure a baseline and use the same definition after a pilot. Avoid borrowing unexplained targets such as a universal accuracy percentage. A high percentage can hide the few exceptions that account for most of a period's value.
For the business case, separate software and implementation costs from documented labor changes and separately supportable recoveries. Tax collected from a customer is not automatically a saving to your business. Record the assumptions behind any projected benefit and compare them with observed pilot work.
Bring the worksheet to a software evaluation
For calculation integration, review the Prophit.ai sales tax API overview and ask for a demonstration using the exact fields, corrections and exceptions in your worksheet.
For the downstream export test, use the sales tax audit evidence checklist. It focuses on what an evaluator can retrieve and reconcile.
Use the software cost calculator to compare quoted fees and usage assumptions. Keep your measured internal work and implementation assumptions alongside that comparison. Approve the integration only after the people who own the source data and the tax review can explain the sample's result.