See why an AvaTax transaction is in its current state

**Objective:** Explain the life of AvaTax transaction `{transaction-code}` from the API audit log, for `{company}` if given.

**Step 1: Read the transaction**

Call `avalara-avatax-get-transaction` filtered by `code` = `{transaction-code}` (and `company` if given). If several match, list them and stop. Note its current `status`, `document-type`, `date` and `total-tax`.

**Step 2: Read the audit log**

Call `avalara-avatax-get-transaction-audit` with `transaction-code` = `{transaction-code}` (and `company`). Sort entries by `server-timestamp`.

**Step 3: Interpret**

* Order the calls into a timeline: when it was created, changed, committed, voided or refunded, judging by `document-type` and `api-call-status`.
* Flag failed calls (non-success `api-call-status`), repeated calls close together, and a `server-duration` far above the rest.
* Compare the final state in the audit log with the current transaction `status`. Say if they disagree.

**Step 4: Report**

Give the timeline as a table (time, document-type, call status, duration), then a short plain-language explanation of how the transaction reached its current state and any problem worth following up.

**Validation:**

* If the audit log is empty, say the log may not cover this period or the code may be wrong, and report only the transaction record.

**Rules & Guidelines:**

* This prompt is read-only. Call only the `avalara-avatax-get-*` tools named above. Never call any avalara-avatax tool that adds, updates, deletes, commits, uncommits, voids, unvoids, adjusts, refunds, locks, settles or creates anything.
* Report what the data shows. Do not guess values the tools did not return, and say so when a field came back empty.
* Use `max-records` to keep each read small, and say when a result may be truncated by it.