Stripe Tax Imports: Off-Stripe Sales Without Double Counting

If you sell through Stripe and somewhere else, Stripe Tax only sees part of your business. A Shopify store, a market stall, wholesale invoices paid by check: none of those reach Stripe, so none of them count toward Stripe's registration thresholds, its reports, or the returns its automated filing prepares. Stripe's answer is a CSV import that loads those outside sales into Stripe Tax.

The import fixes Stripe's view of your sales tax. It doesn't touch your books, and it isn't meant to. The sales you import are already in QuickBooks, entered through whatever channel they came from. The common mistake is to treat the import file as a second set of sales and post them again. The liability account then runs ahead of every Stripe report, and income is overstated by the same sales.

This guide covers Stripe Tax imports from the bookkeeper's side: what the import is for, how the CSV works, how corrections and voids behave when nothing can be deleted, where imported sales show up in Stripe's reports, and how to tie the result to the QuickBooks liability account. A worked October example follows the numbers all the way through.

Start a free trial to bring the Stripe side of your sales tax into QuickBooks automatically, so the only part you import is the part Stripe never saw.

What a Stripe Tax import is for

Stripe's import documentation describes the tool as a way to "consolidate sales data from multiple platforms to get a unified view of your tax obligations." Imported transactions feed three things:

• Reports. Imports appear in Stripe Tax's itemized and summarized exports alongside your Stripe sales.
• Obligation monitoring. Stripe's threshold monitoring only counts "Stripe-processed sales or imported transactions." If half your sales into a state come through another channel, the threshold warning is working from half the number until you import the rest. We cover what happens after a threshold trips in Stripe Tax threshold monitoring and the QuickBooks work that starts when you register.
• Filing. If Stripe files your returns, its filing guide tells you to import transactions from other platforms into the filing period you're reviewing. Stripe can't file tax it never saw. Our guide to reviewing Stripe's automated sales tax filing before it runs shows where the import fits in that monthly window.

Stripe is just as specific about what the tool is not for:

• Not for Stripe transactions. The import "exclusively supports importing transaction data from external sources. Don't use it to correct or modify transactions that were originally processed through Stripe."
• Not for purchases. Don't import VAT reportable purchases. Stripe says doing so "inaccurately inflates gross sales figures and doesn't correctly adjust tax liability."
• Not for anything outside Stripe Tax. Imported transactions "only appear in Stripe Tax reports and interfaces." They aren't payments, they don't create invoices, and other products such as Revenue Recognition need their own import.

During the public preview, Stripe charges no fee for imports, and they don't count against entitlements or API usage limits.

Why the import should never change your QuickBooks file

Take each kind of sale and ask where it entered your books.

Stripe sales with Stripe Tax. On a US QuickBooks company, Acodei's documentation describes the Tax Product method, the only one Intuit's rules allow for US accounts. You create a non-inventory product such as "Sales Tax" tied to a liability account. Acodei rolls the Stripe Tax on each synced invoice or receipt into that product as a single line. The tax lands in the liability account as each sale syncs.

Sales from other channels. These already reach QuickBooks through their own route: another connector, a daily journal entry, or sales receipts keyed by hand. Their tax went wherever that route puts it. If the other channel is another payment processor, running Stripe alongside PayPal or Square in one QuickBooks file covers how to keep the two sets of records apart.

The import itself. Acodei works from Stripe's webhook events. Charges, refunds, invoices, credit notes and payouts each become QuickBooks records. An import creates none of those objects, so it gives Acodei nothing to sync. The import adds information to Stripe Tax and nothing to your ledger.

So the rule is simple. Import to Stripe, never from it. The CSV you upload is a tax-reporting copy of sales your books already hold. Never key it into QuickBooks, and don't hand it to anyone as a list of sales to enter.

There's one trap in the other direction. A payment that went through your Stripe account without Stripe Tax is not an outside sale, even if it came from a custom checkout or a third-party app. Stripe says not to import it. Acodei syncs that charge like any other. But Acodei's tax tracking reads the amounts Stripe Tax calculated, and this charge has none, so there is no Stripe Tax amount to carry into QuickBooks. The fix there is to put those payments on Stripe Tax, not to import them.

How the import CSV works

You build one CSV file with a header row, up to 50MB, and upload it from Tax, then Quick actions, then Import transactions, then Import CSV. If you're in the middle of reviewing an automated filing, you can also use Import under Transactions in this filing. A drawer shows progress. If rows fail validation, you can download a CSV of the failed rows with the error for each one.

The rule that catches most first imports: each row is a line item, not a transaction. A two-item sale is two rows. Those rows must match exactly on source_transaction_id, transaction_type, provider, tax_rules_at, currency, every tax_ids.* field and every shipping_line_item.* field. A transaction can carry only one shipping line item.

The columns that matter most to a bookkeeper:

Column	What goes in it
source_transaction_id	Your order or receipt number from the other channel. This is the key Stripe uses for corrections.
transaction_type	Sale, Refund or Void.
transaction_version	Optional, defaults to 1. Raise it to correct a row.
provider	Where the sale happened, for example shopify. Shown later in the itemized export's provider column.
liable_transaction_id	Required on refunds and voids: the source_transaction_id of the original sale.
posted_at	"The date that liability is assumed or reduced." This decides the reporting period.
tax_rules_at	The date Stripe uses for tax rules and rates.
line_item.product_tax_code	A Stripe product tax code. Required, and it drives the taxability Stripe reports.
line_item.unit_amount	One unit's price before discounts, and before tax if exclusive.
line_item.amount_tax	The tax you actually collected on the line.
line_item.amount	The line total after discounts and including tax. Optional, but if you send it, it includes the tax.

Addresses come last. merchant_address.country and buyer_address.country are required, and postal codes are required for the US and Canada. Dates use the format yyyy-MM-dd HH:mm:ss z, so every timestamp carries its own time zone. Amounts are decimals in the main currency unit, so 10.00 means $10.00.

Here is a two-item market sale and a later refund of one item, showing only the columns that change between rows. The example uses an 8% combined rate.

source_transaction_id	transaction_type	liable_transaction_id	posted_at	line_item.id	unit_amount	quantity	amount_tax	amount
MKT-1031	Sale		2026-10-11 15:20:00 MDT	mug	36.00	2	5.76	77.76
MKT-1031	Sale		2026-10-11 15:20:00 MDT	vase	110.00	1	8.80	118.80
MKT-1031-R1	Refund	MKT-1031	2026-10-24 10:05:00 MDT	vase	-110.00	1	-8.80	-118.80

For refunds and voids, Stripe's instructions are to use negative values for the amount fields, keep the currency the same as the original, and point liable_transaction_id at the original sale. The refund gets its own posted_at, so it reduces liability in the period it happened.

Corrections, voids and re-uploads: nothing gets deleted

Stripe is blunt about this: "You can't remove imported transactions." That shapes every fix.

To correct a row, copy it with the same source_transaction_id, transaction_type and provider. Change what was wrong, raise transaction_version (from 1 to 2, for example), and import again. Stripe keeps every version and uses the highest one in its calculations and reports. In the Dashboard's Tax Transactions page you will then see three records for that sale: the original, an invalidation that cancels it, and the corrected version. That trail is expected, not a duplicate.

To undo an import made by mistake, import a Void against it. Stripe says a void "removes any tax liability" for that transaction.

To re-upload a file, you don't need to strip out rows you've already sent. Stripe skips records that are identical to ones already imported. Stripe documents two cases: an identical row is skipped, and a row with a higher version replaces the old one. A row that changes but keeps the same version falls between those, and Stripe doesn't say what happens to it. So whenever a row changes, raise its version.

Two timing rules apply to all of this:

• Backfills land in past periods. Stripe's reconciliation guide notes that imports, including corrected re-uploads, "are dated by the values in the file." A correction to a June sale changes June's totals the next time you run a June report, even if you already filed June.
• Processing takes time. Stripe says it can take up to 2 days for imported transactions to reach some reports, and you can import data for any period on or after October 1, 2023.

Imported tax amounts, and the gross-adjusted warning

Stripe doesn't recalculate tax on imported sales. It reports "the tax amount you provide in the CSV file, regardless of whether you have an active Stripe Tax registration for that location." What Stripe does do is run its own engine to decide jurisdictions, rates, taxability and taxability reasons, and it keeps those decisions "even when they conflict with the tax amount provided in the import."

Most of the time the two agree. When they don't, for example because the other platform charged tax on a product Stripe treats as exempt, Stripe gross-adjusts the jurisdiction's taxable and non-taxable amounts to fit the tax you imported and its own rate. Stripe calls these "best-effort approximations." A report can then show an exemption with a taxable amount of zero next to a tax amount that isn't zero, so the rate times the taxable amount no longer equals the tax.

Stripe shows a warning when a report contains gross-adjusted amounts. To find the rows behind it, open an itemized export and filter the determination_method column for back_calculated. The itemized export also carries the full, unadjusted imported amounts, so you can see what you sent next to what Stripe made of it. Review those rows before anything is filed. A mismatch usually means the product tax code in your CSV is wrong, or the other platform collected tax it shouldn't have. Either is worth knowing before a return goes in.

Where imported sales show up, and a contradiction to know about

Stripe's two export types agree on imports. The import guide says itemized exports "include the full, unadjusted imported amounts" and summarized exports "include the corresponding jurisdiction-level reporting data." In the itemized export, the provider column holds the platform you named in the CSV (stripe for Stripe's own transactions), and applied_tax_calculation_type is external for imported rows.

The location report is where Stripe's documentation disagrees with itself. The import guide says location reports include imported transactions. The report-choosing guide says they "don't include imported transactions" and sends you to the itemized or summarized export instead. Both pages were live when we checked.

Until Stripe settles it, work from the exports. If you file from a location report, open it after an import and check whether the totals moved. If they didn't, add the imported totals from the summarized export yourself.

Two more effects of imports worth knowing:

• Imports don't change your Stripe numbers. Stripe says imported transactions "don't impact your calculations or reporting for transactions processed through Stripe." Your Stripe-side tax is the same with or without them.
• The summarized export can drop some imported rows. It always excludes eight non-taxable taxability reasons. Stripe says three of them (not_collecting, not_subject_to_tax and not_supported) appear on imported transactions. If the summarized export comes in lower than your imported total, look for those rows in the itemized export. Our summarized export entry covers the full filter.

Tying the import to the QuickBooks liability account

With the import in place, Stripe's net tax for a period should equal the tax your books hold for the same period from every channel. On a US QuickBooks company using Acodei's Tax Product method, that splits into two parts:

1. The Stripe part: what Acodei posted to the liability account through the tax product on your synced Stripe invoices and receipts.
2. The outside part: whatever each other channel's route into QuickBooks put there.

Stripe's side is one number: the summarized export's filing_tax_payable summed across every row for the period, which is tax collected minus tax refunded. Run it in the time zone your books use. If you need the split by channel, the itemized export's provider column separates it.

If both channels post to the same liability account, the comparison is a single tie-out. If the outside channel posts its tax somewhere else, for example to an account created by QuickBooks' own sales tax feature, you're comparing Stripe's one number to the sum of two accounts. That works, but write down which accounts are in the sum so the next person doesn't count one twice or miss one.

Acodei's documentation sends you to Stripe's reports for the state-by-state breakdown and to the liability account to pay from. Imports keep that arrangement intact when some of your sales never touch Stripe.

A worked October: three channels, one liability account

A ceramics studio sells three ways:

• Online through Stripe, with Stripe Tax on Checkout and invoices. Acodei syncs these to QuickBooks, and the tax product puts $1,284.60 of October tax into Sales Tax Payable.
• A Shopify store using Shopify's own payments: 46 orders, $611.25 of tax, plus one refund carrying $14.40 of tax. These reach QuickBooks through the store's connector, which posts tax to the same Sales Tax Payable account. Net: $596.85.
• A holiday market: 9 cash and check sales totaling $1,215.00, plus $97.20 of tax at an 8% combined rate, keyed into QuickBooks as sales receipts against Sales Tax Payable.

QuickBooks holds $1,284.60 + $596.85 + $97.20 = $1,978.65 of October sales tax.

On November 3 the bookkeeper imports the Shopify orders (61 rows, since some orders have several items), the Shopify refund, and the 9 market sales (12 rows). Two days later the summarized export for October shows $2,325.15. That is $346.50 more than the books.

The itemized export, filtered to provider = shopify and sorted by tax_amount, finds the cause in one row. Order SH-2207 was imported with line_item.amount_tax of 385.00 instead of 38.50. The Shopify record and QuickBooks both say $38.50. The bookkeeper copies the row, fixes the tax, sets transaction_version to 2 and imports again. The Tax Transactions page now shows the original, an invalidation and the corrected record for SH-2207. The next summarized export shows $1,978.65, matching the books to the cent.

The same studio, in a different month, shows the opposite mistake. A new assistant was handed the market CSV and keyed the 9 sales into QuickBooks from it, not knowing they were already there. Sales Tax Payable rose by another $97.20, income by another $1,215.00, and the books ran $97.20 ahead of Stripe's export. Nothing in Stripe was wrong. The fix was to delete the second set of sales receipts in QuickBooks. Nothing about the import needed to change.

Both mistakes show up the same way: a gap between Stripe's export and the liability account. The direction of the gap tells you which side to look at. Stripe higher than the books points at the import file. Books higher than Stripe points at a sale that is missing from the import, or one that was entered twice.

A routine that keeps the import honest

1. Decide which outside channels you import, and import every one of them every period. A channel imported in some months and skipped in others makes every comparison meaningless.
2. Export each channel's orders for the period, including refunds, using the channel's own order number as source_transaction_id.
3. Build one row per line item, with a real product tax code and the tax the channel actually collected.
4. Set posted_at to when liability arose or fell: the sale date for sales, the refund date for refunds.
5. Import before your filing review, so automated filing and threshold monitoring both see the full month.
6. Wait up to 2 days, then download the error CSV if any rows failed and fix those rows.
7. Filter the itemized export for back_calculated rows and review every one.
8. Compare filing_tax_payable in the summarized export to the liability account or accounts in QuickBooks.
9. Fix Stripe-side gaps with a higher transaction_version or a Void. Fix QuickBooks-side gaps in QuickBooks.
10. Keep each CSV you upload. Since Stripe keeps every version, your file history is the only record of what you sent and when.

Frequently asked questions

Can I import sales from other platforms into Stripe Tax?

Yes. Stripe Tax accepts a CSV of sales, refunds and voids from other platforms, uploaded from Tax, then Quick actions, then Import transactions. Each row is one line item. Imported sales count toward threshold monitoring and appear in Stripe Tax's exports, and Stripe's automated filing can include them.

Do imported Stripe Tax transactions appear in QuickBooks?

No, and they shouldn't. An import exists only inside Stripe Tax: it creates no payment, invoice or payout, so a Stripe sync has nothing to carry. The imported sales should already be in QuickBooks through their own channel. Posting them again from the CSV double-counts both the sales and the tax.

How do I fix or remove an imported transaction in Stripe Tax?

You can't delete it. To correct one, import it again with the same transaction ID, type and provider, the fixed values, and a higher transaction_version. Stripe uses the highest version. To cancel an import made by mistake, import a Void against it, which removes its tax liability.

Does Stripe recalculate tax on imported transactions?

No. Stripe reports the tax amount in your CSV, even where you aren't registered. It does apply its own jurisdictions, rates and taxability. Where those conflict with your tax amount, it gross-adjusts the taxable amounts and shows a warning. Filter the itemized export for back_calculated rows to find them.

Can I import Stripe payments that were made without Stripe Tax?

No. Stripe says the import tool is for transactions from external sources only, not for correcting or modifying transactions processed through Stripe. If some Stripe payments skip Stripe Tax, the fix is to move them onto Stripe Tax so the tax is calculated when they happen.

Where this leaves you

A Stripe Tax import gives Stripe the full picture of your sales tax: thresholds that count every channel, exports that cover every sale, and filings that don't leave part of your business off the return. It isn't a way to get sales into QuickBooks, and treating it as one is the most expensive mistake you can make with it.

Acodei handles the Stripe part. On a US QuickBooks company, it rolls the Stripe Tax on your synced invoices and receipts into the tax product tied to your liability account. You import only what Stripe never saw, and you compare one Stripe number against your books each month.

Start a free trial and connect your Stripe account to QuickBooks Online.