You’re right , the customer-level Customer.taxSettings.taxId path is only a partial workaround here, and it does not give apps a clean order-level signal in orders/create or the REST Order JSON.
The public path available from 2026-07 is Customer.taxSettings.taxId with read_customers or read_taxes. That can help if the order is tied to a customer record, but it still means an extra Admin API lookup and it does not prove which VAT ID was used for that specific order.
I also would not use tax_exempt as the trigger here. For reverse charge cases, you would be left checking the tax outcome on the order and the customer’s tax settings, which is the awkwardness you are calling out for invoicing integrations.
I’ve raised the order-level exposure gap with the relevant team, and I agree the webhook payload is where this would be most useful for event-driven integrations. The related customers/update/updatedAt behavior for tax ID changes is also being looked at in this related thread. I don’t have a timeline to share, but your point about this needing to be available from the order event itself has been passed to the right people internally