The TaxJar for WooCommerce plugin calls TaxJar's API at checkout, calculates sales tax, and stores the result against the order. The tax amount lands in the standard WooCommerce tax line, but jurisdiction breakdown, API-response status, and rate snapshot live in wc_orders_meta keys (typically _taxjar_ prefixed). The default WooCommerce orders screen doesn't show any of that.

SleekView reads wc_orders and joins those TaxJar meta keys as columns. A tax-ops view shows order ID, total, tax amount, jurisdiction (state, county, city), API-call status, and rate source side by side. Filter to orders where the TaxJar call failed and the order fell back to manual rates, or to orders shipping to nexus states only, without writing SQL.

Inline edits route through WooCommerce CRUD where supported, so adjusting a tax exemption flag fires the order-update hooks TaxJar listens for. For schema-level reconciliation, view-level filters (jurisdiction, period, exemption) make month-end reporting a saved view instead of a recurring export.

Sales-tax compliance in the US lives or dies on whether the right rate applied to the right address at the right time, and whether that decision is auditable months later. TaxJar handles the calculation, but the proof of calculation (jurisdiction, rate source, API status) is in wc_orders_meta, where the default WooCommerce admin can't show it. SleekView pulls those meta keys into the orders list as real columns, so a finance team running monthly reconciliation works inside a saved view instead of producing yet another export.

Compliance teams audit nexus states by filter, support teams answer customer tax disputes by glancing at one row, and tax-ops teams catch API-fallback orders before they become a filing problem. None of this requires modifying TaxJar's plugin code. SleekView reads what TaxJar already writes, exposes it as columns and filters, and writes back through WooCommerce CRUD when an edit is needed.

The audit trail stays inside WordPress.