Stripe Tax Itemized Export

What the columns mean

The identifying columns come first. id is the object that created the tax transaction, such as an invoice ID. tax_transaction_id is the Stripe Tax transaction itself. type says what kind of object it was (checkout, credit_note, external, invoice, payment_intent or refund), and transaction_type says whether the row is a transaction or a reversal of an earlier one. Reversals point back to the original in reversal_original_tax_transaction_id.

Dates come in pairs. transaction_date is when the tax liability was assumed or reduced, and tax_date is the date used to pick the tax rules and rates. Each appears in UTC and in the time zone you chose.

Then the jurisdiction: jurisdiction_name, jurisdiction_level (country, state, county, city or district), country_code, state_code, taxability, taxability_reason, tax_rate and tax_type. Then the amounts: subtotal, total, gross_amount, taxable_amount, non_taxable_amount and tax_amount in the currency you price in, with filing_tax_amount and its siblings in the tax authority's currency. Origin, destination and performance-location addresses follow, along with invoice, customer and product details.

You can add metadata columns from credit notes, invoices, PaymentIntents, refunds and tax transactions. Each one appears as section[key], for example invoice_metadata[order_id]. That is the easiest way to carry your own order numbers into the export.

The two columns that are safe to sum

Stripe's reconciliation guide is direct about this. The itemized export has one row per tax jurisdiction, not one per transaction, and most amount columns (gross_amount, total, taxable_amount and non_taxable_amount) repeat the line item's value on every row. Sum those columns across a file and the total is inflated by the number of jurisdictions on each line item.

A $100 sale taxed by a state, a county and a city appears on three rows, each showing a gross_amount of $100. Summing gross_amount gives $300 of sales. The tax is different: each row's tax_amount belongs to that jurisdiction alone, so the three rows add up to the sale's real tax.

Only tax_amount and filing_tax_amount are unique per row. For sales-side amounts, group by jurisdiction first, or deduplicate on id and line_item_id and sum the unique rows. This is the most common way an itemized total gets inflated before it reaches a reconciliation.

What it includes, and how it ties to the summarized export

Like every Stripe Tax export, it only covers transactions Stripe Tax calculated. That means invoices, subscriptions, Checkout Sessions and Payment Links with automatic tax enabled, Stripe Tax API transactions, and transactions you import from other platforms. Raw charges without an invoice and invoices with manual or no tax are absent.

Within that scope it keeps non-taxable rows that the other reports drop: sales where you aren't registered, where Stripe Tax isn't supported, or where no jurisdiction imposes tax. The Exclude non-taxable transactions toggle removes five taxability reasons. The summarized export always removes eight. To match the two, also drop rows whose taxability_reason is not_collecting, not_subject_to_tax or not_supported, then group by country, state, jurisdiction name, jurisdiction level, tax rate and transaction currency and sum.

Imported transactions show up here in full. The provider column names the platform from the import, or stripe for Stripe's own transactions. applied_tax_calculation_type is external for imported rows. Where Stripe had to adjust an imported sale's taxable amounts to fit the tax you supplied, determination_method reads back_calculated.

Using it against your QuickBooks liability account

Most of the time the summarized export is the easier report to tie to a sales tax liability account. The itemized export is where you go when the tie-out fails. Export the same period in the time zone your books use and apply the same filters as for the summarized export. Then sum tax_amount over transaction rows and subtract the sum over reversal rows. That is Stripe's net tax for the period, and it should equal the summarized export's tax collected minus tax refunded.

If Stripe and the books still disagree, sort by tax_amount and work down from the largest rows. Look for one that is missing from QuickBooks or recorded with a different amount. The invoice_id, payment_intent_id and customer columns get you to the matching record in Stripe and then in QuickBooks.

Two cautions apply. Stripe Tax reports use accrual timing, so tax counts when an invoice finalizes, not when it is paid. And sales that bypassed Stripe Tax aren't in the file at all, so tax charged some other way will sit in the liability account with nothing here to match it.

Getting the export, and the API versions

In the Dashboard, the export starts from the Locations page. You can filter by jurisdiction before exporting, which keeps large files small. That matters most for EU One Stop Shop registrations, where Stripe also reminds you to remove domestic transactions an OSS return doesn't need. You can also schedule the export to run daily, weekly or monthly.

Through the Reports API, tax.transactions.itemized.2 returns the rows for transactions the platform itself is liable for. Connect platforms use connected_account_tax.transactions.itemized.2, with the connected account set, for accounts that are liable for their own tax. Stripe notes that both API versions are a subset of the Dashboard export: some fields, such as the origin-level address, the UTC timestamps and refund_id on voids, aren't included. The grouping and summing rules above still work on the columns they do include.