Taxually ML corrections need a named acceptance record

Treat each proposal as its own decision object

Taxually's official page says uploaded data is checked and that machine learning corrects tax errors. It also presents a later user review and approval step. Those claims establish provider positioning, not the evidence structure between a machine-generated change and a person's approval. The narrow control question is whether one proposed field change can be inspected and accepted on its own terms rather than disappearing into a broadly approved data set.

Give every proposal a durable identifier and record the affected record key and field, the value before the proposal, the proposed value, the model or rule identifier and exact version, the time generated, confidence when the system produces one, and a reason or evidence reference. The artifact should remain in a proposed state until a named decision occurs. If a newer run supersedes it, link the two proposals instead of silently replacing the first.

Make acceptance named, scoped, and reproducible

An acceptance record should name the reviewer, the role or authority used, the decision time, and the disposition: accept, reject, or override. An override needs its replacement value and reason. A policy-based acceptance still needs a named policy owner, the policy version, qualifying conditions, and the execution identity that applied it. A generic approved badge cannot show whether the person considered this proposal or merely approved a larger screen.

Scope the decision to the exact proposal identifier and version. When the affected value, rule version, confidence, reason, or supporting evidence changes, the old acceptance should no longer authorize the new proposal. Preserve the earlier disposition and open a fresh decision. This makes the acceptance reproducible without treating reviewer identity as proof that the proposed value was substantively correct.

Do not turn confidence into tax authority

A confidence value describes a system output only if the system actually generates and defines that measure. It does not establish that evidence is complete, that a legal characterization applies, or that a reviewer has authority. Record the confidence's scale, threshold, and versioned calculation context where available. If no confidence exists, mark it not provided rather than inventing a percentage for reporting convenience.

The reason should be specific enough to test: for example, a named validation rule, a detected inconsistency, or a referenced classification basis. Keep an unknown open when the reason is insufficient. This correction-level artifact records only what the machine proposed and who accepted, rejected, or replaced it; it does not absorb unrelated workflow decisions or evidence objects.

Demonstrate the proposal-to-acceptance record

A buyer demonstration should begin with a known field value and produce one machine-generated correction. Inspect the proposal identifier, before-and-after values, model or rule version, confidence and its scale, reason, and evidence reference. Have one authorized person reject it, another authorized person accept a fresh version, and a third case use an explained override. Export the records and confirm that each disposition remains tied to the proposal actually reviewed.

Then change the rule version, revise the reason, lower the confidence, and present a proposal after the reviewer's authority has expired. The prior acceptance should not migrate to any of those cases. Indirect Tax Monitor reviewed Taxually's registered official page on September 8, 2026. The page supports the stated machine-learning correction and user-review positioning, but it does not disclose field-level proposals, model or rule versions, confidence, reason records, named correction acceptance, customer configuration, correction accuracy, or tax outcomes. No dated material change after the prior daily cutoff was established.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Indirect Tax Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.