Tax and freight discrepancies: how AI agents resolve them
Tax and freight discrepancies are invoice exceptions in which the tax or shipping charges on a supplier's invoice disagree with the amounts the buying company's own systems computed – the sales tax its tax engine determined, or the freight its contract and shipping terms allow. The goods lines can match the purchase order perfectly and the invoice still stops, because the add-on charges fail their own checks. Resolving one means reconciling two calculations, the supplier's and the company's, and establishing which side used a wrong input.
This wiki explains source-to-pay concepts for teams where AI agents carry the operational work – checking rates, reading contracts, clearing holds – while people keep the calls that require judgment. A standard glossary treats a tax or freight mismatch as a line item for a clerk to chase; this page treats it as a case an agent investigates against the company's own controlling records.
Tax and freight discrepancies are computation exceptions
Most invoice exceptions are document disagreements. A price mismatch compares the invoice against the purchase order; a quantity mismatch compares it against the goods receipt, the record confirming what physically arrived. The types of invoice exceptions page catalogs that family. Tax and freight belong to a different class, because the reference is a calculation rather than a document. On the tax side, the company's tax determination engine already computed what this transaction should carry, from jurisdiction, taxability, and rate. On the freight side, the contract and shipping terms define what freight, if any, the supplier may bill and at what price. The supplier's billing system ran its own version of the same math and produced a different answer.
That difference in shape matters for automation. A document comparison ends at "these two figures disagree" and someone goes hunting. A computation comparison can be re-executed: rerun the company's calculation step by step, trace the inputs the supplier appears to have used, and the divergent input surfaces – a wrong address, an expired certificate, a shipping term applied to the wrong party. The rest of this page walks each half.
Tax discrepancies resolve against the determination log
A tax engine – Vertex, ONESOURCE, or the ERP's native tax module – produces a number and a record of how it got there. That record, the determination log, captures the jurisdiction the engine selected, the taxability decision for the material or service, the rate it applied, and any exemption it honored. When the invoiced tax disagrees with the calculated tax, the determination log is the controlling record, and an agent works the case by auditing both calculations against it.
In practice, that looks like this. A manufacturer headquartered in Dallas buys $48,200 of conveyor components for its plant in Ohio. The supplier's invoice charges 8.25% Texas sales tax, $3,976.50. The company's engine computed $0. The agent reads the determination log: jurisdiction Ohio, because sales tax follows the ship-to address; taxability exempt, because the plant holds a manufacturing exemption certificate – a state-issued document certifying that purchases used directly in production are not taxable – covering this commodity code. The agent pulls the certificate from the exemption repository, confirms it is unexpired and covers the material group, and confirms the invoice ship-to matches the actual delivery. The supplier's error is now specific: its billing system taxed to the bill-to address in Texas and never applied the certificate. The agent short-pays the tax or requests a corrected invoice per policy, and transmits the certificate to the supplier so the next invoice arrives clean.
The reverse case is just as common and closes differently. A supplier charges no tax on a taxable purchase, usually because it has no registration in the buyer's state. The company then owes use tax – tax a buyer self-assesses and remits directly when the supplier did not collect it. Nothing needs correcting on the supplier side; the agent's job is confirming the engine accrued the use tax and that the supplier is not also charging sales tax on a later line, which would produce double payment. Ship-to versus bill-to confusion drives a large share of both cases: multi-site companies buy centrally and ship everywhere, and any supplier that taxes to the billing address will be wrong whenever the two addresses sit in different jurisdictions.
Freight discrepancies resolve against incoterms and the carrier agreement
Freight has its own controlling records, and the first is the shipping term on the order. Incoterms are the standardized trade terms that assign transport cost and risk between buyer and seller: under DDP (delivered duty paid) the supplier pays freight to the buyer's door, while under EXW (ex works) the buyer bears every cost from the supplier's dock. Domestic contracts often use plainer language – freight prepaid, freight collect, or prepaid and add, where the supplier pays the carrier and passes the actual cost through on the invoice. Where the charge is billed matters too: some suppliers put freight on the goods invoice as a line item, while others route it through a carrier that bills separately, and that separate carrier bill typically arrives as a non-PO invoice with no order behind it at all. On top of the base charge ride accessorials – fees carriers add beyond line-haul transport, such as fuel surcharges, liftgate service, detention, and residential delivery.
Take a concrete case. A goods invoice for $12,940 of fasteners carries a $612 freight line and an $87 fuel surcharge. The agent reads the PO's shipping term: DDP. It opens the supplier contract's freight clause and confirms the term, which makes both charges the supplier's to bear. It disputes the $699 with the clause cited, and the goods lines post on schedule. Had the term been prepaid and add, the investigation changes shape: the agent rates the shipment itself, taking the weight from the bill of lading – the carrier's receipt for the shipment – and applying the contracted rate from the carrier agreement, then checks each accessorial against the agreement's fee schedule. Many companies hold tax to a zero tolerance but give freight a small band inside their match tolerances, since fuel surcharges float with published indexes; a passthrough within the band posts without dispute.
The deciding fact is sometimes written down nowhere
The slowest tax and freight discrepancies to clear are the ones whose deciding fact appears in no system. One supplier always bills freight on a separate invoice, so a freight line on its goods invoice is nearly always a duplicate of a carrier bill already sitting in the queue. Another moved its shipping warehouse from Indiana to Kentucky two years ago while the vendor master kept the old address, so the engine's jurisdiction pick is stale and the "discrepant" supplier tax is actually correct. A third ships through a third-party logistics warehouse, so the ship-to on paper differs from the true taxable destination. Experienced analysts carry these facts in their heads; an agent acquires them by reading years of resolution history and by having its early calls corrected, after which the knowledge persists instead of leaving with the analyst.
Genuine tax judgment stays with people. Whether an ambiguous item is taxable in a particular state can be a real tax-department question, and the agent's contribution there is the workup: the determination log, the certificate, both computations, and the one open question, attached to an escalation a specialist can decide in minutes.
Fragment builds AI agents that work tax and freight discrepancies this way – rerunning the determination, pulling the certificate, rating the shipment against the carrier agreement – inside the SAP or Ariba environment a company already runs, with no rip and replace. See how the workflows run or request a demo.