QuickBooks Product/Service Item

The four item types, and what they actually decide

QuickBooks Online offers four types. Intuit defines them as follows.

**Inventory**: "Products you sell and track quantities for." Inventory features are available in QuickBooks Online Plus and Advanced, so this type is not available on every plan.

**Non-inventory**: "Products or items you buy or sell but don’t need to track quantities for." Intuit’s example is nuts and bolts used on an installation job but not sold directly.

**Service**: "Services you provide to customers."

**Bundle**: "Several products or services sold together as a single item, such as a gift basket."

Here is the part that trips people up. The type does **not** decide the accounting destination. It decides whether QuickBooks tracks quantity and cost of goods for the item. The destination is set separately, on the item, by the account you attach to it.

Acodei’s own tax setup is the cleanest demonstration. For United States QuickBooks companies, the documented approach is to create a **non-inventory** product called something like "Sales Tax" and map it to a **liability** account. Collected tax then arrives as a single line on the invoice or receipt, and the balance accumulates as tax owed rather than as revenue. A non-inventory item pointing at a liability account is nobody’s idea of a product, and it works exactly as intended, because the two choices are orthogonal.

One practical note on changing your mind later: non-inventory and service items can be converted to other types, but bundles cannot be converted at all, and inventory items cannot be changed to a different type once created.

Why the item is where sync problems become visible

When a Stripe charge syncs into QuickBooks, something has to decide which item the resulting line uses. In Acodei that decision is made by your mapping rules, which are evaluated in order until one matches.

The rule and the item are two different objects, and this is the distinction worth holding onto: **the rule decides which item, and the item decides which account.** A mapping can be completely correct and the money still land in the wrong place on the profit and loss statement, because the rule pointed at the right item and the item pointed at the wrong account.

That single sentence explains a whole category of "the sync is broken" report that turns out not to be a sync problem at all. Mapping rules are configured by item, so a rule can be verifiably correct while the item it names is quietly attached to an account you did not intend. Two similarly named items, one of them wired to the wrong income account, will look identical from the mapping side.

The fix is on the QuickBooks side, not the mapping side. Open the item on the Products and Services list and check the account it points at.

There is a second consequence. Because the item supplies the account, the granularity of your reporting is capped by the granularity of your items. If every Stripe sale routes to one item, your profit and loss statement has one revenue line no matter how many mapping rules you write. Separating digital subscriptions from physical goods in QuickBooks means separate items pointed at separate income accounts, and only then rules that route to them.

The non-taxable rule

This one is worth stating on its own, because it is easy to get wrong and it corrupts the numbers rather than raising an error.

**All QuickBooks products used in Acodei mapping must be marked non-taxable.** Making them taxable in QuickBooks conflicts with the sales and payout math.

The reasoning is structural. Tax calculated on the Stripe side is synced across as its own amount, through whichever tax approach the account uses. If the QuickBooks item is also flagged taxable, QuickBooks applies its own tax logic on top of a line that already had tax accounted for upstream, and the totals stop agreeing with what Stripe actually collected.

The same principle applies to items that hold Stripe fees and the tax on those fees. Stripe remits that tax itself, so counting it as sales tax payable in your books would overstate what you owe.

If you are setting up items specifically for a Stripe sync, treat non-taxable as the default and let the dedicated tax mechanism handle tax, rather than letting two systems each take a turn at the same line.

Naming, deletion, and the failures they cause

Items are matched by name and by ID, which makes the Products and Services list a shared surface between two systems. Three documented failure modes follow from that.

**Duplicate names.** If QuickBooks contains multiple items with identical names, the sync can fail. Unique naming is the fix, and it is worth enforcing as a convention before the list grows rather than after.

**Renaming after mapping.** Changing an item’s name in QuickBooks after it has been mapped in Acodei can break the sync for the same reason. Renaming feels harmless inside QuickBooks. It is not harmless to anything holding a reference to that item.

**Deletion and scope.** Two of Acodei’s documented mapping errors point at the item rather than at the rule: "QBO product doesn’t exist or has been deleted," and the product being out of scope after the QuickBooks credentials change. If a rule that worked last month is failing now and nothing about the rule changed, check whether the item it targets still exists and is still reachable.

The ordering that avoids all three: create and name the item in QuickBooks first, point it at the account you want, and only then map to it in Acodei. Verifying that a test transaction produced the expected item and hit the expected income account is the check worth running once, at setup, rather than discovering the answer at close.