Stripe Shipping in QuickBooks: Where the Income Goes

A customer orders $180 of goods and pays $12 to have them shipped. Stripe collects $192. A week later, the $12 you charged for shipping does not exist as a separate number anywhere in QuickBooks. There is no shipping income figure to look at, because nothing ever wrote one.

Nothing failed. The total ties to the deposit and reconciliation passes. The money is all there. What is gone is the distinction between selling something and delivering it, and that distinction is the one your gross margin depends on.

Shipping is the second field where the same structural question shows up with a different answer. We wrote about the first one, what happens to Stripe discounts in QuickBooks, where the choice is whether a discount is a subtraction or a line. Shipping asks the same question and adds a complication that discounts do not have: in Stripe, shipping is not a line item at all.

Start a free trial and see how your Stripe activity lands in QuickBooks before you commit to a chart of accounts.

In Stripe, shipping is not a line

This is the fact everything else follows from, and it is easy to miss because invoices render shipping as a row.

A Stripe invoice has a lines collection, which Stripe describes as "The individual line items that make up the invoice". Shipping is not in it. Stripe carries the shipping money in a separate top-level field on the invoice object, amount_shipping, documented in Stripe's invoice reference with one sentence: "This is the sum of all the shipping amounts."

You can see the same separation in how Stripe defines the invoice subtotal. It is "Total of all subscriptions, invoice items, and prorations on the invoice before any invoice level discount or exclusive tax is applied". Three things are enumerated there. Shipping is not one of them.

Alongside the amount sits an object. Stripe describes shipping_cost as "The details of the cost of shipping, including the ShippingRate applied on the invoice". A ShippingRate is its own thing in Stripe's data model, with its own reference page, and it carries a display_name "meant to be displayable to the customer", a fixed_amount that "Describes a fixed amount to charge for shipping", and two tax fields we will come back to.

There is also a third shipping field that is not about money at all. shipping_details is documented as "Shipping details for the invoice", where "The Invoice PDF will use the shipping_details value if it is set, otherwise the PDF will render the shipping address from the customer". That is an address. It is worth naming because the confusion between the shipping address and the shipping charge causes real configuration mistakes, and we will get to why.

So on the Stripe side, shipping is an amount, plus a rate object, plus an address. It is not a product, it has no price ID, and it is not a member of the collection that everything else on the invoice belongs to.

QuickBooks only has lines

QuickBooks has no equivalent of amount_shipping in the place Acodei is writing to. Revenue on a sales form exists as lines, each line pointing at a Product/Service, and each Product/Service pointing at an income account. That is how a number reaches an account at all. If shipping is going to land in a shipping income account, it has to become a line.

Which means something has to invent one.

Acodei's documentation describes exactly this. The admin toggle is Enable Shipping Cost Tracking, and its documented behaviour is to break out "Stripe shipping (amount_shipping) as its own line". The stated reason to turn it on is to "Track shipping income separately". Its documented dependency is the part that gives the game away: it "Needs designated 'Shipping' product; relies on Stripe shipping field."

Read that dependency next to what Stripe actually sends and it stops looking like configuration boilerplate. Every other line on a synced invoice can be routed by looking at what Stripe says the line is. A shipping amount has nothing to look at. There is no Stripe product on it, so you cannot say "map product X to QuickBooks item Y". The Shipping product has to be designated in advance, once, because there is nothing arriving that could imply it.

The second half of the dependency, "relies on Stripe shipping field", is the other half of the same point. The toggle reads one specific field. If your shipping money is not in that field, the toggle has nothing to do.

That case is more common than it sounds. Plenty of stores add shipping as an ordinary line item with a price, either through their storefront or by hand. If you do that, shipping already is a line, it already carries a product, and it will map like any other product. The toggle is for the case where Stripe is carrying shipping in its shipping field, which is what happens when you use Stripe's shipping rates in Checkout or on an invoice. Before turning anything on, look at an actual invoice in your Stripe dashboard and find out which of those two worlds you are in.

Why your mapping rules cannot solve this

This is where the structural fact starts costing people time, because the instinct is to write a mapping rule and the instinct does not work.

Acodei's product mapping supports six matching techniques, and its documentation is specific about each: the Stripe description field, the transaction value, the Stripe product with a pricing tier, the Stripe product without one, Stripe metadata, and the Stripe account the charge arrived on. Every one of those reads something off the transaction.

Now try each one against a shipping amount.

Description matching has nothing to read. The documented lookup order for descriptions goes to the charge or payment description, the PaymentIntent, or the invoice line item description. A shipping amount is not a line item, so it has no line item description. The ShippingRate's display_name is a customer-facing label on a different object.

Transaction value matching is worse than useless here, because it "compare[s] the gross amount (before fees)" against a number you configure. That is the whole charge, $192 in our example, not the $12. A rule that matched it would route the entire sale to your shipping account.

Product and price matching need a prod_ or price_ identifier. Shipping has neither. Metadata matching needs metadata, and Acodei documents reading it from the charge, PaymentIntent, invoice or subscription, none of which gives you a shipping-specific key unless your engineers put one there. Account matching would only work if you ran a separate Stripe account for shipping, which nobody does.

There is a further limitation that closes the last door. Acodei documents that it does "not allow matching of multiple lines from the same transaction", giving the example of mapping three different products at different amounts within a single sales receipt. So the workaround of writing one rule for goods and another for shipping inside the same order is not available either.

This is why shipping gets its own toggle rather than a mapping rule. It is not a gap in the mapping engine. It is that mapping operates on lines, and shipping is not one until something makes it one.

Two settings with "shipping" in the name that do different jobs

Acodei documents two toggles here, and mixing them up is a cheap mistake to make and an annoying one to diagnose.

Enable Shipping Cost Tracking is the money one, described above.

Enable Shipping Address Tracking is documented as syncing "customer.shipping.address to QBO shipping fields", for "Sellers that need separate ship vs bill addresses", and it "Falls back to billing address if shipping missing".

They have nothing to do with each other. One decides which income account $12 lands in. The other decides which address prints on the form. Turning on address tracking and then looking for a shipping income figure is a wasted afternoon, and the naming makes it an easy afternoon to lose. If you are trying to answer "what did we earn on shipping", the address toggle is not the one.

The tax question, and where the documentation runs out

Here is the part that makes shipping different from discounts rather than a rerun of the same argument.

Shipping is frequently taxed differently from the goods it delivers. Some jurisdictions tax it, some do not, and some tax it only when the goods are taxable. Stripe models this properly. A ShippingRate carries its own tax_behavior, documented as specifying "whether the rate is considered inclusive of taxes or exclusive of taxes. One of inclusive, exclusive, or unspecified", and its own tax_code, where Stripe states plainly: "The Shipping tax code is txcd_92010001."

That is a distinct tax code for shipping, listed among Stripe's tax codes. Stripe is deliberately treating shipping as its own taxable category rather than as part of the product.

Now the QuickBooks side, and this is where the naive fix bites.

The obvious move, once you have a Shipping product in QuickBooks, is to mark it taxable so QuickBooks calculates tax on it. Acodei's documentation forbids this, and not as a style preference. Its product mapping documentation states that "All QuickBooks products used in Acodei mapping must be marked as non-taxable", that "Tax calculated by Stripe can sync to QuickBooks with the Stripe Tax Feature", and that "Making products Taxable in QBO conflicts with sales and payout math."

So the Shipping product is non-taxable in QuickBooks like every other mapped product, and tax arrives through Stripe Tax rather than being recalculated by QuickBooks.

How does it arrive? Acodei documents two approaches. Under the Tax Product approach, you "create a non-inventory product (e.g., 'Sales Tax') mapped to a liability account", and then "All Stripe Tax amounts get rolled into a single line item on your QBO invoices or receipts". Under QuickBooks Tax Rate mapping, you map each Stripe tax rate ID to a QBO tax code, and Acodei's documentation says that when syncing "each product line is matched to the correct QBO tax rate".

The choice between them is mostly not a choice. Acodei's documentation says that for U.S.-based QuickBooks, "QBO's built-in 'Sales Tax Center' does not allow third-party creation of official QBO tax rates. Hence we map all tax to a liability 'product.'" Its own summary is blunter: for US-based QBO, "'Tax Product' is usually the only workable method."

Follow that through. If you are a US seller, every dollar of tax Stripe calculated arrives in QuickBooks as one aggregated line against a liability account. The tax on the goods and the tax on the shipping are the same line. Stripe carefully preserved a distinction that the destination, on the path most US sellers are on, does not have a place to put.

And now the honest part. Acodei's tax documentation does not discuss shipping. It covers the tax approaches, inclusive versus exclusive handling, refunds, daily summaries and their limitations, and it never addresses how the shipping portion of a Stripe tax calculation is treated. So I am not going to tell you what happens to it. What I can tell you is what is documented: tax reaches QuickBooks through the Stripe Tax feature, mapped products must be non-taxable, and on the Tax Product path all tax lands as a single aggregated amount. If the shipping tax split matters to your filing, verify it against your own synced records rather than against any article, including this one, and ask us directly. We have raised it internally to get the behaviour documented properly.

That is a smaller answer than "here is exactly what happens", and it is the accurate one.

What this actually costs you

It is worth being concrete about why any of this matters, because "shipping is in the wrong account" sounds like a tidiness problem.

Your product margin includes money that was never product revenue. Wherever the $12 lands, it is not identified as shipping, so it sits inside the revenue figure you calculate margin against. Meanwhile your shipping costs, the labels and the carrier invoices, are sitting in expenses where they belong. One side of that comparison has been quietly padded and the other has not. The distortion scales with how much you ship, which means it is largest exactly when shipping is a real part of your business.

Shipping stops being a decision you can evaluate. Free shipping over $50, flat-rate shipping, charging actual cost: these are pricing experiments, and you cannot measure one without a shipping income figure to compare against shipping expense. Folded into product revenue, the number does not exist to trend.

It is not retroactive. Acodei documents that mapping rules are not versioned, and that a change "takes effect for future transactions only". The same principle applies to a setting that decides where a line goes. Turning on shipping tracking in October does not produce shipping income for January through September. Whatever you have already booked stays booked the way it was.

That last point is the argument for deciding early rather than deciding well. A wrong choice made now and corrected in six months leaves six months of books that cannot answer the question.

How to decide

Ask whether shipping is revenue you want to see, or a pass-through you do not care about.

Break it out if you charge for shipping and it is a meaningful line of income, if you want to compare shipping charged against shipping paid, or if shipping's tax treatment differs from your goods in the states you file in. Configure a Shipping product in QuickBooks first, pointed at a shipping income account, keep it non-taxable, then have the toggle enabled.

Leave it folded if shipping is a small rounding item, if you almost always ship free, or if you have no separate shipping cost to compare it against. There is nothing wrong with folded shipping when nobody will ever ask the question. The mistake is folding it in and then being asked.

One thing to know before either: Acodei documents this as an admin panel toggle rather than a setting in your own dashboard, so turning it on means asking rather than clicking. The full survey of which sync settings change your financial statements puts this one in context alongside the others that move money between accounts.

And check your Stripe data first. If your shipping is already arriving as an ordinary priced line item rather than in Stripe's shipping field, you do not need the toggle at all. You need a product mapping rule like any other product, and a QuickBooks Product/Service to point it at.

FAQ

Does Stripe treat shipping as a line item?

No. Stripe carries shipping in a separate top-level field on the invoice, amount_shipping, described as "the sum of all the shipping amounts", plus a shipping_cost object holding the ShippingRate that was applied. The invoice's lines collection is "The individual line items that make up the invoice", and shipping is not part of it. Stripe's definition of the invoice subtotal enumerates subscriptions, invoice items and prorations, and does not include shipping.

Where does my Stripe shipping charge end up in QuickBooks by default?

Without shipping tracking enabled, it is not separated into a shipping income account. Acodei documents a toggle, Enable Shipping Cost Tracking, whose purpose is to break out "Stripe shipping (amount_shipping) as its own line" so you can "Track shipping income separately". The documentation does not state a default value for this toggle, so check yours rather than assuming.

Why can I not just write a mapping rule for shipping?

Because mapping rules match on things a shipping amount does not have. Acodei's six documented techniques match on the Stripe description, the transaction value, the Stripe product with or without a pricing tier, metadata, or the Stripe account. A shipping amount carries no product, no price ID and no line item description, and matching on transaction value would match the entire charge rather than the shipping portion. Acodei also documents that it does not support matching multiple lines from the same transaction.

Can I make the QuickBooks Shipping product taxable so QuickBooks calculates shipping tax?

No. Acodei's documentation states that "All QuickBooks products used in Acodei mapping must be marked as non-taxable" and that "Making products Taxable in QBO conflicts with sales and payout math." Tax reaches QuickBooks through the Stripe Tax feature instead.

Does shipping tax sync separately from product tax?

Stripe distinguishes them at the source: a ShippingRate has its own tax_behavior and its own tax_code, and Stripe publishes a specific shipping tax code, txcd_92010001. What Acodei's documentation covers is how tax reaches QuickBooks in general, and on the Tax Product approach, which its documentation calls "usually the only workable method" for US-based QuickBooks, "All Stripe Tax amounts get rolled into a single line item" against a liability account. The documentation does not address the shipping portion specifically, so we are not going to claim a behaviour for it. Verify against your own synced records.

What is the difference between Shipping Cost Tracking and Shipping Address Tracking?

They are unrelated. Shipping Cost Tracking is about money and breaks the shipping amount out as its own line. Shipping Address Tracking is about the form, syncing customer.shipping.address to the QuickBooks shipping fields and falling back to the billing address when the shipping one is missing.

If I turn shipping tracking on now, will my old transactions be fixed?

No. Acodei documents mapping changes as taking effect "for future transactions only". Historical records keep whatever treatment they were created with, which is the reason to decide this early rather than after a year of orders.

---

Shipping is a small number that answers a question your product revenue cannot. Whether it is worth separating depends entirely on whether anyone is going to ask, and the awkward part is that people usually start asking after the books are already a year deep in the other choice.

If you are setting up a Stripe to QuickBooks sync and want the chart of accounts right before the volume arrives, start a free trial and configure it while you still have nothing to migrate.