Stripe QuickBooks Sync Settings That Change Your Books

Turn on one setting called Record Fee as Purchase and your Stripe fees stop being a negative line inside each sales receipt. They become their own expense records instead. Gross sales on your profit and loss goes up. Expenses go up by the same amount. Net income does not move a cent, and every report anyone reads for revenue now says something different.

Nothing about your workflow changed. Nobody clicks anything new. The books just say a different thing than they said yesterday.

That setting sits in the same list as one that adds a payment method label to a receipt.

This is the problem with how integration settings get documented, including by us. They are presented as a flat list of preferences, sorted by where they happen to sit in the interface, with a one-line description of what each one does. What that list never tells you is which ones you must decide deliberately before you sync a single transaction, and which ones you can flip on a Tuesday afternoon two years in without consequence.

So here is that list, sorted by consequence instead. Three tiers: settings that change the numbers on your financial statements, settings that change which records exist in QuickBooks at all, and settings that only change how those records look. Then the part nobody writes down, which is the hidden prerequisites and mutual exclusions that make some of these settings impossible to combine.

If you are still choosing a Stripe to QuickBooks integration, start a free trial of Acodei and you can look at these decisions against your own transaction data rather than in the abstract.

Tier 1: settings that change what your financial statements say

These change reported numbers. Not the workflow, not the presentation, the numbers. Get one wrong at onboarding and you will be restating something later.

Stripe fees as an expense, or as a negative line

By default, Acodei records the Stripe fee as a negative line on the sales receipt itself, using your mapped Stripe fee product. The receipt nets to the amount that actually entered your Stripe balance. A $200 charge with a $6.10 fee produces one receipt worth $193.90.

Turn on Record Fee as Purchase and the fee instead posts as a separate Purchase or Expense, and the receipt stays gross at $200.

Both are defensible. Only one lets you see your effective processing cost as a line on the profit and loss, which is the reason most accountants want the second. But the choice moves your reported gross revenue for every transaction you ever process, which makes any comparison across the switch date meaningless unless you know it happened.

It also carries a prerequisite that is easy to miss, covered in the constraints section below.

Refunds against one product, or against the original items

By default a refund reverses the products that were sold, which nets your revenue by product back down.

Turn on Always process refund to default refund product and every refund routes to a single Refunds product instead. Your revenue by product stops netting. You see gross sales in one place and gross refunds in another.

This is the right setting if you want to know your return rate, and the wrong one if you want revenue by product to reflect what customers actually kept. It is a reporting question with a real answer for your business, not a preference, and switching it later leaves you with a history recorded two different ways.

Coupons and shipping as their own lines

Enable Coupon Tracking posts coupons and discounts as a separate line item rather than folding them into the sale. Enable Shipping Cost Tracking breaks out Stripe's shipping amount as its own line. Stripe's invoice object exposes amount_shipping as "the sum of all the shipping amounts", per Stripe's API reference, which is what that setting reads.

Both change which income accounts your money lands in, which is why they belong in this tier rather than in presentation. Both also need a destination product configured first, a Discounts product for the first and a Shipping product for the second.

The five dating settings

This is the group that surprises people, because dating decisions move revenue across period boundaries. A sale dated December 31 and a sale dated January 2 are the same sale and different fiscal years.

Acodei has five settings that touch dates:

• Add Invoice Date as Service Date copies the invoice date into QuickBooks' Service Date field.
• Use Stripe Supply Date as QBO Invoice Date back-dates the QuickBooks invoice to the Stripe supply date, for EU time of supply compliance.
• Use Stripe Supply Date as QBO Service Date writes the supply date into Service Date only.
• Use Due Date as Invoice Date dates the QuickBooks invoice on the Stripe due date.
• Use effective_at as Invoice Date dates it on Stripe's effective_at field when that field is present.

Two of these depend on Stripe fields whose behavior is worth knowing before you turn anything on.

Stripe's reference describes effective_at as "the date when this invoice is in effect", and adds that it is the "same as finalized_at unless overwritten". So unless something in your billing setup is explicitly setting effective_at, that setting selects a date identical to the one you already had. It is a no-op you can spend a week being confused by.

The due date is sharper. Stripe states that due_date "will be null for invoices where collection_method=charge_automatically". Subscription billing that charges a saved card automatically is exactly that case. If your Stripe invoices are all charged automatically, there is no due date on them to date anything by. The setting is meaningful for invoices you send and wait to be paid, and worth checking against your own Stripe data before you assume it will do anything.

These do not combine freely. The invoice date and supply date settings are mutually exclusive with each other, and the due date setting is mutually exclusive with the supply date one, where the admin interface disables one option while the other is checked. You will find out, in other words, but you will find out by clicking rather than by reading.

Payout dating

Use created_date for payouts dates the QuickBooks deposit on the payout's creation timestamp rather than its arrival date. That is a month-end cutoff tool: a payout created on the 31st and arriving on the 2nd lands in different months depending on this setting.

The tradeoff is stated plainly in our own documentation, and it is real. Your bank feed shows the arrival date. Choose creation date and the deposit in QuickBooks will not match the date on the bank line, so reconciliation gets harder in exchange for a cleaner cutoff.

Multicurrency

Enable Multicurrency Support creates per-currency customer records and attaches an exchange rate to each transaction. This one is enabled by the Acodei team rather than in your own settings, and the per-currency customer records ("Acme - CAD" alongside "Acme") are how QuickBooks requires multicurrency to work rather than a quirk of ours. If you are running Invoice Sync there is an Invoice Multicurrency sub-toggle that goes with it.

The full picture of why multicurrency payouts do not match is its own subject, covered in why Stripe multicurrency payouts do not match QuickBooks.

Tier 2: settings that change which records exist

These do not change totals directly. They change what QuickBooks contains, which changes what you can report on and what your accountant sees.

Process Sales as Receive Payment-only is the big one. It switches the whole connection from the sales receipt workflow to an invoice plus payment workflow, so Stripe activity becomes accounts receivable in QuickBooks instead of direct sales. Our own documentation calls it a big mode change and says to use it at onboarding only, which is unusually blunt language for a settings description and should be read as written. Which record a given charge becomes, and why the account setting rather than the charge decides it, is worked through in sales receipt vs payment for a Stripe charge.

Enable $0 Invoice lets invoices with a zero balance but non-zero lines sync, which matters for full-discount and freemium flows where the line detail is the point. A genuinely empty invoice with no lines is still skipped.

"Paid outside Stripe" to Undeposited Funds creates a QuickBooks payment when a Stripe invoice is manually marked paid, for businesses that invoice in Stripe but accept wires and checks. It applies to Undeposited Funds configurations and is set per company.

Create Credit Memo on Void replaces voiding a QuickBooks invoice with a same-day credit memo. The reason to want this is period protection: voiding an invoice reaches back into a month you may have closed, while a credit memo dated today does not. It reverses itself if the invoice is later paid.

Enable Fee Mapping lets you map Stripe fees by account or product rather than to one destination, which is what you want if you run several Stripe accounts and need fee expense split between them.

Tier 3: settings that change presentation only

Totals do not move. These are worth turning on when you need the reporting granularity and worth leaving alone when you do not.

• Enable Payment Method on Sales adds the payment method to each sales receipt, so you can report by method in QuickBooks.
• Enable Payment Method on Refund does the same for refund receipts. It has no effect on credit memos.
• Enable Qty tracking on Invoice writes the actual Stripe quantity instead of a hard-coded 1, which is what makes unit and inventory reporting work.
• Enable Shipping Address Tracking syncs the customer's shipping address to QuickBooks' shipping fields, falling back to the billing address when Stripe has no shipping address.
• Skip "Applied Balance" line on Invoice hides the Stripe credit balance line, for when that line confuses whoever reads the invoice.
• Enable Location Tracking adds a QuickBooks Location tag to every sales line, for businesses running multi-entity reporting through Locations. It is a beta feature, so it needs a conversation with support rather than a checkbox.

One note that belongs here rather than in a release log. Enable Refund Mapping was removed from the admin panel in July 2026. If you are reading an older guide that tells you to configure it, that guide is stale. Refund routing now follows the standard product and account mapping rules plus the default refund product setting described above.

The constraint layer nobody documents

This is the section I would read first, because these are the rules that turn a five-minute settings change into an afternoon.

Some settings have prerequisites inside Acodei:

• Record Fee as Purchase requires a non-Undeposited-Funds holding account. This is the one that catches people, and it is explained in the next section.
• Enable Payment Method on Sales works only in the sales receipt flow. Turn on Invoice Sync and it stops applying.
• Skip "Applied Balance" line is relevant only in Invoice Sync mode, for the same reason in reverse.
• Enable Qty tracking on Invoice is incompatible with inclusive tax invoices. If your Stripe invoices carry tax inclusive of the price, this one is off the table. The mechanics of inclusive versus exclusive tax are covered in inclusive vs exclusive tax on Stripe invoices.
• Coupon Tracking and Shipping Cost Tracking each need a destination product configured first, or there is nowhere for the line to go.
• Enable GST requires either Stripe Tax or admin QuickBooks tax mapping to be in place.

And two reach outside Acodei entirely, which is why they are the easiest to get wrong.

QuickBooks' Service Date field is optional, and you turn it on inside QuickBooks. Intuit lists it alongside Shipping, Discount and Tags in the fields you can toggle on a sales form, and describes the effect: "When you turn on Service date, QuickBooks adds a date column to each product or service line on the form", where on printed invoices "this column appears as Date". That is from Intuit's guide to customizing sales forms. So if that field is not enabled in your QuickBooks sales form settings, you can turn on a service date setting in Acodei, have it work exactly as intended, and see nothing at all. Check QuickBooks first, then the setting.

Stripe has to be populating the field you are dating from. The due_date and effective_at cases above are the examples. A setting that reads a null field is not broken, it is just inert.

The setting that is not a setting

Record Fee as Purchase requires a non-Undeposited-Funds holding account. That sounds like a minor prerequisite until you look at what the holding account choice actually is.

The holding account is the QuickBooks account standing in for your Stripe balance. Under Undeposited Funds, each payout becomes an itemized deposit that sweeps the individual payments into the bank, and every underlying transaction has to already exist in QuickBooks or the payout fails with a mismatch error. Under a regular asset clearing account, each payout is a single transfer for the net amount and does not depend on anything else having synced first.

That choice shapes nearly every record Acodei writes. It is also not a toggle you flip.

Acodei tracks a one-shot permission for changing the holding account, and that permission is granted only when a connection has zero transactions at synced status. It is revoked once a transaction reaches synced status. So the permission exists while a connection has synced nothing, and is gone after the first transaction lands.

Changing modes after that is a supported migration rather than a settings change. A dedicated job reverses and re-books the affected records against a saved settings backup, driven by a support command. It works, and it is not something you do while you are curious about an option.

So the honest ordering is: the holding account decision comes first, and it constrains the fee decision, which is the single largest change to your reported revenue on this entire list. Two of the three most consequential choices in a Stripe to QuickBooks integration are made before you have synced anything. The clearing account pattern and how it should behave is covered in setting up a Stripe clearing account in QuickBooks, and it is worth reading before you choose.

What to decide when

Decide at onboarding, deliberately: the holding account, fee as expense or negative line, sales receipts or the Receive Payment-only workflow, multicurrency, and the refund product question. These change your numbers or your record structure, and changing them later means your history is recorded two different ways.

Decide when you need them, safely: payment method labels, shipping address tracking, applied balance line, location tracking, quantity tracking. These change presentation going forward and leave your existing records alone.

Decide by checking Stripe first: the dating settings. Look at whether your invoices actually carry a due date or an effective_at before turning a setting on to read one.

The general rule is simple enough to hold onto. If a setting changes which account a number lands in, or whether a record exists at all, it is an accounting decision wearing a checkbox. If it changes what a record looks like once it exists, it is a preference. The interface does not distinguish between the two, so you have to.

FAQ

Which Stripe to QuickBooks sync settings change my financial statements? The ones that move numbers between accounts: recording Stripe fees as an expense rather than a negative line on the sale, routing refunds to a single refunds product instead of the original items, breaking out coupons and shipping as their own lines, and every setting that changes the date on a record. Date settings matter because they move revenue across period boundaries.

Does recording Stripe fees as an expense change my revenue? It changes reported gross revenue, not net income. With fees as a negative line, the sales receipt nets to what entered your Stripe balance. With fees as an expense, the receipt stays gross and the fee posts separately, so both revenue and expenses go up by the fee amount and net income is unchanged.

Why can I not turn on fee as expense? It requires a non-Undeposited-Funds holding account. If your connection uses Undeposited Funds, the holding account has to change first, and that is a supported migration run with Acodei rather than a setting you can flip yourself.

Can I change the holding account after I have started syncing? Not as a settings change. The permission to change it is granted only while a connection has zero synced transactions and is revoked after the first successful sync. Switching afterwards is a migration that reverses and re-books the affected records, so it is a support conversation rather than a checkbox.

Why is my service date setting not showing anything in QuickBooks? Most likely because the Service Date field is not turned on in QuickBooks. Intuit treats it as an optional sales form field, and enabling it adds a date column to each product or service line. Turn it on in QuickBooks, then check the record again.

Which settings can I safely turn on later? The presentation ones: payment method on sales and refunds, shipping address tracking, skipping the applied balance line, location tracking, and quantity tracking. They change how records look going forward without changing totals or restating anything already synced.

Is Enable Refund Mapping still available? No. It was removed from the admin panel in July 2026. Refund routing now follows the standard product and account mapping rules, plus the setting that routes all refunds to a default refunds product if you want that behavior.

Getting the consequential ones right the first time

Most of the damage in a Stripe to QuickBooks integration is not caused by settings being wrong. It is caused by settings being changed halfway through a fiscal year by someone who read a one-line description and reasonably concluded it was a display option.

Sort them by consequence before you sort them by convenience. Decide the holding account and the fee treatment first, because those are the two the rest hang off. Check what Stripe is actually sending before you turn on a setting that reads a Stripe field. And leave the presentation settings for when you have a reporting question that needs them.

Acodei syncs Stripe to QuickBooks transaction by transaction, and the settings above are what shape the records it writes. Start a free trial and you can see what each of them does to your own data before you commit to it, or read the full Stripe to QuickBooks sync guide for how the pieces fit together.