Stripe Adaptive Pricing in QuickBooks: What Actually Syncs

A customer in Toronto emails to ask why they were charged CA$13.70 when your site says $10. A customer in Amsterdam pays with iDEAL, which you have never enabled. Your bookkeeper searches QuickBooks for CA$13.70 and finds nothing, because the sales receipt says 10.00 USD.

Nobody changed a setting. Stripe's Adaptive Pricing was already on.

This post covers what Adaptive Pricing does to the records that reach QuickBooks Online, which turns out to be both less and stranger than most people expect. If you want the sync itself handled while you read, Acodei posts Stripe charges, refunds, fees and payouts into QuickBooks Online with the record type and the accounts under your control.

The setting you probably did not turn on

Adaptive Pricing is Stripe's local-currency presentment feature. Stripe describes it plainly: it "lets your customers pay in their local currency in more than 150 countries," and "Stripe uses machine learning to determine the most relevant presentment currency, then automatically calculates the localized price and handles all currency conversion."

The part that surprises finance teams is the default. Stripe's documentation states that "Adaptive Pricing is always enabled for Payment Links." For Checkout, it is a toggle in your payment settings. So if you sell through a Payment Link, an international buyer has been seeing your prices in their own currency whether or not anyone in your company decided that.

Turning it off later does not rewrite history. Stripe notes that "Disabling Adaptive Pricing doesn't affect Checkout Sessions that have already been converted or active subscriptions paid in customers' local currencies."

What Stripe actually sends your books

Here is the sentence that decides everything downstream, from Stripe's own reporting documentation:

The Checkout Session and the underlying PaymentIntent objects reflect what your customer paid in your integration currency and amount, which is the currency you specified for your prices.

Read that twice if you run the close. The customer paid in Canadian dollars. The objects your accounting integration reads are in your currency.

The local amount is not lost. It moves into a side field. On checkout.session.completed and payment_intent.succeeded, Stripe attaches a presentment_details hash:

{
  "currency": "usd",
  "amount_total": 1000,
  "presentment_details": {
    "presentment_amount": 1370,
    "presentment_currency": "cad"
  }
}

One sale, two truths. amount_total is 1000, meaning $10.00 USD, and that is what your balance transaction, your payout and your books will carry. presentment_amount is 1370, meaning CA$13.70, and that is what the customer's card statement will say.

So your books do not go multicurrency

This is the useful, counterintuitive part, and it is the opposite of what the phrase "local currency" suggests.

Ordinary Stripe multicurrency means a charge is genuinely created in another currency. That is the situation covered in Stripe multicurrency in QuickBooks: three rates at three moments, a settlement conversion, and an exchange gain or loss you have to record. Under Adaptive Pricing none of that applies to you, because the conversion happened before the charge object existed and it was charged to the customer.

It also means the customer-splitting behaviour that multicurrency selling normally triggers does not fire here. Acodei's multicurrency handling works by comparing currencies: when a transaction arrives, it checks whether the Stripe transaction currency matches the QuickBooks customer's assigned currency, uses the existing customer record when they match, and creates a second record in the format CustomerName - CAD when they do not. That second record is QuickBooks working as designed, since QuickBooks assigns one currency per customer, and it is not a sync defect.

Under Adaptive Pricing the transaction currency is your own. The mismatch branch is never reached, so one buyer stays one QuickBooks customer no matter which of the 150-plus supported countries they bought from.

The same logic settles a question worth raising before someone else does. Acodei's multicurrency support does not handle zero-decimal currencies such as Japanese yen. Adaptive Pricing lists Japan among its supported markets, so it is fair to worry. It does not bite here, because the recorded transaction currency stays yours and JPY only ever appears as a presentment figure.

If you were hoping Adaptive Pricing would be the feature that finally forces you into QuickBooks multicurrency, it is not. If you were dreading exactly that, you can stop.

The number your customer quotes does not exist in QuickBooks

Every consequence of Adaptive Pricing that actually costs you time comes from this one gap.

Your customer knows one number: CA$13.70. It is on their statement, in their email, and in the message they send when they want a refund or a receipt. Your books know a different number: $10.00. Searching QuickBooks for the amount the customer gave you returns nothing, and neither does searching your Stripe payments list by amount, because that list is in your currency too.

The lookup that works is by customer, by email, or by charge ID, and then reading presentment_details on the payment. In the Dashboard the local amount appears on the payment detail page for converted payments. It is worth telling whoever answers support that a mismatched amount is not a sign of a double charge or a pricing error, because that assumption is expensive.

Three practical habits help:

1. Reconcile on your currency, never on theirs. Your deposit, your holding account and your sales receipts are internally consistent. The only inconsistent number is the one in the customer's inbox.
2. Quote the charge ID in support replies. It is the one identifier that means the same thing on both sides.
3. Expect the FX difference on their side, not yours. If a customer says the amount changed slightly between checkout and their statement, that is their bank, not your books.

Who pays for the conversion

Stripe's pricing page for the feature is unusually blunt about who bears the cost:

You pay 0%

Your customers pay 2–4%

And the mechanism: "The Stripe-provided exchange rate you present to your customers includes a 2–4% conversion fee, increasing their purchase price by a corresponding amount. Stripe determines the fee, which varies for the purposes of increasing customer conversion." On the rate itself, Stripe says it "uses the mid-market exchange rate and applies a fee to guarantee the rate through settlement," with the rate held for 24 hours. Stripe's general currency conversion documentation covers the cases where Stripe converts on your behalf instead.

For your general ledger this is good news and it is worth being precise about why. There is no conversion cost of yours to book and no rate movement between sale and settlement to explain in a reconciliation. Stripe's stripe_fx_fee is the balance transaction type for a conversion Stripe performs on your funds, and Acodei folds it into the Stripe fee total when one appears. Adaptive Pricing is not a conversion of your funds, so it is not the thing that would generate one. If you do see FX fees on your account, look at your settlement setup rather than at this feature.

There is a commercial consequence, though, and it belongs to marketing rather than accounting. Your Toronto customer sees a price 2 to 4 percent above the mid-market conversion of your list price. Your revenue per unit does not change. Their perception of your price does.

Refunds are the easy half

Refunds under Adaptive Pricing behave better than most people assume. Stripe:

You can issue a refund in your integration currency, and Stripe refunds your customer in the currency they used to make the payment. The refund uses the same exchange rate as the original transaction, so there are no extra costs for you, and your customer gets back the exact amount they paid.

So a full refund of a $10.00 charge is a $10.00 refund in your books and a CA$13.70 credit on the customer's card. In QuickBooks that is an ordinary Refund Receipt against the customer, drawn from the holding account, with lines mirroring what was refunded. No FX loss, no residual cent, no journal entry to square a rate that moved.

Compare that to a genuine cross-currency refund, where the rate on the refund date differs from the rate on the sale date and someone has to book the difference. Adaptive Pricing removes that problem by freezing the rate to the original transaction.

What does change in your books: the payment method mix

Adaptive Pricing is not only a display feature. Stripe is explicit that it "can increase the usage of local payment methods by ensuring customers have the option to pay in their local currency," and the docs list what it unlocks, including iDEAL, Bancontact, BLIK, EPS, P24, Pix, SEPA Debit, TWINT, Satispay, MB WAY, Alipay, WeChat Pay, PayPal, Revolut Pay, Klarna in the EU and UK, and UPI. Stripe's own example is that "70% of all e-commerce transactions in the Netherlands use iDEAL, but it only works with EUR."

This is the real accounting change, and it is a fee-mix change rather than a currency change. Bank-debit and local-scheme methods do not carry card economics. Some of them generate network_cost balance transactions, which Stripe passes through from the payment network. Acodei imports network_cost and treats it as a Stripe fee, so it lands in your Stripe Fees expense along with the rest, aggregated onto the daily summary. If your effective fee rate moves after Adaptive Pricing goes on and no price changed, the payment method mix is the first place to look. There is more on how these standalone fee rows differ from the fee field on a charge in non-transactional Stripe fees.

Settlement timing is worth a thought too. Card payments and bank debits do not clear on the same schedule, so a shift toward SEPA Debit changes when money reaches your balance even though the recorded revenue is unchanged. Stripe Link payments are the exception in that list, since Stripe states Link settles on the same timeline as cards.

The amount-rule question, answered

If you map revenue by transaction amount, Adaptive Pricing sounds alarming. It is not, and the reason is the same sentence as before.

Amount matching in Acodei compares the gross amount before fees against a numeric value you set, and in a multicurrency context it checks the currency first. A rule written for 9.99 USD does not match 9.99 CAD. That is real, and it is a genuine hazard for merchants who create prices in several currencies through currency_options.

Adaptive Pricing does not put you in that situation. The charge arrives in your integration currency at your integration amount, so a rule set to 9.99 USD still matches a sale to a customer who saw CA$13.68. Nothing to change.

That said, amount matching is the most fragile of the mapping strategies for reasons that have nothing to do with currency. A promotion, a coupon or a price change breaks it, because the charged total stops equalling the number in the rule. Mapping on the Stripe product and price ID is steadier, since Acodei stores references to both and those identifiers do not move when the amount does. The full comparison of mapping strategies sits in the Stripe settings that change your books.

When Adaptive Pricing does not apply

Stripe lists the exclusions, and each one is a case where a sale you expected to be converted simply is not:

• Elements with the Payment Intents API. Stripe states Adaptive Pricing "isn't available for businesses using Elements with the Payment Intents API."
• Indian businesses. Not supported.
• Prices outside your settlement currencies. Stripe "requires the currency for your prices to be one of your settlement currencies."
• Prices that already define that currency. If a price has currency_options for EUR and GBP, Adaptive Pricing will not convert to EUR or GBP, though Stripe notes "it can still convert to other currencies like CAD or JPY."
• Manual capture. Sessions using capture_method as manual are excluded.

In all of these, Stripe says the session presents "prices in the original currency that you've set your prices in." That matters for reconciliation because it means Adaptive Pricing is not uniform across your traffic. Some international sales are converted and some are not, and both land in your books identically.

Subscriptions carry the currency forward

Recurring billing has one wrinkle worth knowing before renewals start arriving. When a subscription is created in a local currency, Stripe puts presentment_details on the customer.subscription.created event, and the presentment_currency there "reflects the local currency that will be used for off-session payments." Each renewal invoice then carries its own presentment_details on the payment_intent.succeeded event.

So the presentment currency is sticky for the life of that subscription. Your invoices and the QuickBooks records built from them stay in your currency throughout. Stripe also limits the methods available on these: "For cross-border subscriptions, Adaptive Pricing supports only card payments, Link, Apple Pay, and Google Pay."

A short checklist

• Check your Adaptive Pricing setting in the Dashboard and remember it is always on for Payment Links regardless.
• Tell support that a customer-quoted amount will not match QuickBooks, and give them the charge ID as the lookup key.
• Do not add QuickBooks multicurrency for this. Your records stay in your own currency.
• Watch your effective fee rate for a month after enabling it, because the payment method mix is what moves.
• If you map by amount, you are fine here, but consider moving to product and price ID mapping anyway.
• Pull presentment_details if you ever need to report on local pricing, since it is the only place the buyer's number lives.

Frequently Asked Questions

Does Stripe Adaptive Pricing change the currency of my QuickBooks records?

No. Stripe states that the Checkout Session and the underlying PaymentIntent "reflect what your customer paid in your integration currency and amount, which is the currency you specified for your prices." The customer's local amount is carried separately in a presentment_details hash. Because the transaction currency reaching your accounting integration is your own, the records created in QuickBooks Online stay in your currency and no per-currency customer record is created.

Do I need to enable multicurrency in QuickBooks Online for Adaptive Pricing?

Not for this. QuickBooks multicurrency is needed when you sync transactions that are genuinely in a non-home currency, and Adaptive Pricing does not produce those. Turning multicurrency on in QuickBooks is irreversible, so it is not a setting to enable speculatively.

Why does my customer say they paid a different amount than QuickBooks shows?

Because both are right. Under Adaptive Pricing the customer is charged in their local currency at a Stripe-provided rate that includes a 2 to 4 percent conversion fee they pay, while your charge, balance transaction and payout are all in your integration currency. Look the payment up by charge ID or customer rather than by amount, and read presentment_details for the local figure.

Does Adaptive Pricing cost me anything in Stripe fees?

Stripe's stated pricing is "You pay 0%" and "Your customers pay 2–4%." The conversion fee is built into the exchange rate shown to the buyer. You will not see a stripe_fx_fee generated by Adaptive Pricing, since Stripe is not converting your funds. Your effective fee rate can still move, because Adaptive Pricing unlocks local payment methods with different economics.

How do refunds work with Adaptive Pricing?

You refund in your currency and Stripe refunds the customer in theirs, at the original transaction's exchange rate. Stripe states "there are no extra costs for you, and your customer gets back the exact amount they paid." In QuickBooks this is an ordinary Refund Receipt with no exchange gain or loss to record.

Will Adaptive Pricing break my amount-based product mapping rules?

No. Amount rules check the currency as well as the number, but the charge arrives in your integration currency at your integration amount, so a rule set in USD still matches. Amount matching remains fragile for other reasons, including discounts and price changes, so mapping on the Stripe product and price ID is a steadier choice.

Which Stripe products support Adaptive Pricing?

Stripe documents it for Checkout, Payment Links, the hosted invoice page and Elements-based Checkout surfaces, and it is always enabled for Payment Links. It is not available for businesses using Elements with the Payment Intents API, and it is not supported for Indian businesses.

The takeaway

Adaptive Pricing is the rare Stripe feature that makes your customer's experience international and leaves your ledger domestic. Your charge, your fee, your payout and your QuickBooks records all stay in one currency. What changes is the number in the customer's inbox and, quietly, which payment methods they reach for.

Acodei syncs Stripe charges, refunds, fees and payouts into QuickBooks Online, with product mapping on the Stripe product and price rather than the amount, and fee handling you configure rather than inherit. Start a free trial.