QuickBooks Online has no native landed cost allocation feature. There is no built-in mechanism to take a freight invoice, a customs duty entry, and a broker fee, attach them to a specific shipment, and roll them into per-SKU item cost the way QuickBooks Enterprise Platinum and Diamond do. Enterprise distributes other-charge items across inventory by quantity, value, weight, or volume from inside the same product. QBO does not.
That means QuickBooks Online landed cost allocation is a workflow problem, not a settings problem. Importers, ecommerce operators, and distribution finance teams on QBO allocate freight, customs duty, broker fees, tariffs, insurance, and inbound handling outside QBO, then post the resulting bills and adjusted item costs back into the file. There are three real paths to do that: a controlled worksheet alongside QBO, a third-party inventory or landed-cost app that syncs with QBO, or an upgrade to QuickBooks Enterprise. The right choice turns on shipment cadence, SKU count, multi-currency exposure, and audit posture — not on which path the loudest vendor page recommends.
The QBO-versus-Enterprise framing matters, but it is also where most existing reading on this topic stops. The harder problem sits upstream: getting the right fields out of supplier invoices, freight-forwarder bills, customs/broker entries, and POs, at the right row grain, in the right currency, so that whichever allocation path you pick has clean inputs to work from. The rest of this guide covers that data layer, the row-grain decision that drives downstream output, the four standard allocation bases, the three workflow paths with their actual decision criteria, and how the result lands back in QBO as bills and adjustments an auditor will accept.
Source Documents and the Fields Landed Cost Requires
A shipment's landed cost is assembled from four document types that arrive at different times, in different currencies, often from different inboxes. Before any allocation worksheet, app, or Enterprise feature is relevant, those documents have to be normalized into a structured table keyed by shipment or PO. Skipping that step is what makes most QBO landed cost workflows collapse: the allocation logic is fine; the data feeding it is a mess.
The supplier (commercial) invoice is the anchor document for value. It carries the invoice number, a PO or shipment reference, line items with SKU or item description, quantity, unit price, and line total, the currency, freight or insurance if the supplier billed those directly, the invoice total, the document date, and the vendor. The line-item detail matters: even when the worksheet is going to allocate at the shipment level, the SKU mix is what determines how landed cost components fan out across items.
The freight-forwarder invoice carries the shipment reference, the container or AWB number, ocean or air freight, fuel surcharge, port and terminal fees, handling charges, document date, and the freight forwarder's billing currency — usually USD for international moves into the US, often the home currency for domestic legs. The shipment reference is what ties the freight bill back to the supplier invoice; without it, allocation has nothing to group on.
The customs/broker invoice carries the entry number, duty, merchandise processing fee, harbor maintenance fee, the tariff classification used to assess duty, broker fees, and any disbursements the broker fronted on behalf of the importer. For formal entries into the US, MPF and HMF sit alongside duty as distinct line items rather than blended into a single import charge — extract them separately, because they reconcile differently and may be reportable separately.
The purchase order carries the expected SKUs, quantities, agreed unit costs, currency, supplier reference, and the expected receipt or shipment date. The PO is the document the other three documents should reconcile against — supplier invoice value should match PO value plus or minus agreed variances, the freight bill should correspond to the shipment the PO triggered, and the broker entry should match the goods listed.
The fields above mean almost nothing in isolation. What makes them useful is the shipment-or-PO key tying them together. Real shipments rarely share a clean identifier across all four documents — the supplier uses its own PO number, the freight forwarder uses a booking reference, the broker uses an entry number. The data layer's job is to add a shipment key the importer controls (a normalized shipment ID) so the allocation step has something to group on.
Currency is the other place where landed cost workflows quietly break. Importing rarely happens in one currency. Supplier invoices may be in EUR, CNY, or GBP; freight forwarders often bill in USD; customs and broker bills are in the importer's home currency. Each landed cost row needs both an amount and a currency, and the worksheet or app needs an explicit exchange-rate convention — typically the rate at the date of the supplier invoice for supplier value, and the rate at the date of each freight or broker bill for those components. Mixing conventions is what makes the inventory valuation report disagree with the worksheet later.
The landed cost components are not an optional bookkeeping detail. Customs valuation defines imported value the same way upstream: under the WTO Customs Valuation Agreement, customs value of imported goods includes the cost of transport to the place of importation, loading, unloading and handling charges associated with that transport, and the cost of insurance. The accounting concept of landed cost — supplier value plus the inbound charges that brought the goods to the warehouse door — is the bookkeeping reflection of how the goods were valued for customs purposes in the first place. The components that have to come out of the source documents are the components that already define the imported value.
A competent extraction step turns these documents into rows that carry the fields above with the shipment key attached and the currency preserved. The fields a commercial invoice data extractor should capture is a more detailed treatment of the supplier-invoice side; freight forwarder and customs broker invoices carry analogous structures with different field names.
This is where Invoice Data Extraction fits, and it fits narrowly. The product is a way to extract supplier, freight, and customs invoice data to clean Excel and CSV rows — the user uploads PDFs, describes which fields are needed and at what row grain in a prompt, and downloads structured XLSX, CSV, or JSON. The same prompt works whether there are 20 PDFs or 6,000 in a batch, and the prompt itself can be saved and reused for the next shipment cycle. The product does not calculate landed cost, allocate components across SKUs, or replace QBO. It produces the structured table that whichever downstream path you pick — worksheet, app, or Enterprise — consumes as its input. Treat it as the data layer, not the allocation engine.
Row Grain: One Row Per Invoice, Component, or Product Line
The same four source documents can produce three valid tables, and the right one depends on what happens next. Picking the wrong grain — usually by collapsing too early to one row per invoice for AP entry — is what forces the worksheet step to redo extraction work later. Decide the grain before the extraction step runs, not after.
One row per invoice is the natural shape for AP bill entry. Each row carries header-level fields: invoice number, vendor, date, total, currency, posting account. It is what QBO's bill record wants. It is also useless for allocation, because the SKU mix, the per-line value, and the per-component charges are collapsed into totals. A table at this grain can support posting a supplier bill into QBO, but it cannot support apportioning $4,200 of freight across thirty-eight SKUs in the same shipment — the SKU rows that allocation needs are gone.
One row per landed cost component is the natural shape for the allocation worksheet. Each row represents a single charge — a supplier invoice line, a freight forwarder fuel surcharge, a duty entry, a broker fee — keyed by shipment or PO. This grain is what lets the worksheet (or the app, or Enterprise) group every charge for a shipment together, classify each charge as supplier value or landed cost component, and apply the allocation basis. Without it, allocation cannot happen at all — there is nothing to group.
One row per product line is necessary for item-level inventory costing. Each row is a SKU-quantity-unit-price tuple tied to a shipment, ready for the allocation step to fan landed cost components across SKUs by the chosen basis. The output of allocation — landed cost per SKU per shipment — has to land somewhere, and the product-line table is where it lands. Importers who need per-SKU cost accuracy for COGS, margin reporting, or duty drawback claims need this grain alongside the component-level table; one without the other does not produce per-SKU landed cost.
The grain choice is not exclusive. A worksheet workflow may need an invoice-level table for AP entry into QBO and a component-level table for the worksheet and a product-line table for the final costing step — all derived from the same source PDFs. A competent extraction step produces all three when needed; an extraction step that locks the user into one grain forces a second extraction pass to produce another.
The practical implication is operational rather than conceptual: the grain decision belongs at the start of the workflow, when the prompt or template that extracts the fields is being defined. Retrofitting grain from a table that has already been collapsed to one row per invoice means going back to the source PDFs and running extraction again. That is one of the most common ways landed cost allocation in QBO Online breaks down — not because the allocation logic is hard, but because the data was extracted at the wrong grain the first time.
Allocation Basis: Quantity, Value, Weight, or Volume
Once the data layer is in shape and the grain is right, the allocation step is mechanically simple: take the landed cost components for a shipment, distribute them across the SKUs in that shipment by a chosen basis, and write the result back as per-SKU landed cost. The choice of basis is where importers diverge, and the right answer depends on what is being allocated and what the shipment looks like.
Value-based allocation apportions landed cost components in proportion to the supplier value of each SKU in the shipment. If the supplier-value subtotal is $80,000 and one SKU represents $20,000 of that, the SKU absorbs 25% of every shipment-level landed cost component. Value is the default for most importers because it tracks the way value is usually distributed across mixed-SKU shipments, aligns with how customs duty is itself assessed on most commodities (duty is typically ad valorem — a percentage of declared value), and produces results that reconcile cleanly against COGS.
Quantity-based allocation apportions in proportion to units. It is reasonable when items in the shipment are roughly homogeneous in size and value — a single SKU at varied pack configurations, or a tight family of similarly priced items. It breaks down quickly when the shipment carries one $200 item and one $4 item in equal quantities: each absorbs the same freight charge, which understates the freight load on the high-value item and overstates it on the low-value item.
Weight-based allocation apportions in proportion to weight. It is the right choice for ocean and air freight when high-density and low-density items ship together, because actual freight cost tracks weight (chargeable weight, for air freight specifically) more closely than value. A shipment carrying both heavy machinery components and lightweight packaging materials will misstate freight cost per SKU on a value basis; weight is the basis that lines up with what the freight forwarder actually charged for.
Volume-based allocation apportions in proportion to cubic measure. It applies where freight pricing is by volume — LCL ocean freight billed on cubic meters, parcel shipments billed on volumetric weight — and the shipment carries items of widely different densities. Bulky, light items that would underpay under weight-based allocation pick up their fair share under volume-based.
The basis does not have to be uniform across components within the same shipment. A defensible setup is freight by weight or volume (whichever the carrier actually charged against), duty by value (because the customs assessment itself was value-based), insurance by value (because it is priced as a percentage of insured value), broker fees by value or flat-allocated across line items (broker fees are not naturally proportional to anything, and a flat per-line distribution often defends as well as a forced basis would). The worksheet or app has to support per-component basis selection. If it does not, the importer ends up forcing one basis across all components and absorbing the resulting distortion in COGS.
The other operational reality is that landed cost components arrive on different timelines. The supplier invoice usually accompanies the goods or precedes them; the freight forwarder's invoice often arrives a week to two weeks after receipt; the customs broker's bill may show up a week later still. The allocation cannot complete until every component is known. The standard handling is to post the supplier bill on receipt at the supplier value, then either adjust unit cost or post a separate landed cost journal entry as each subsequent bill arrives and gets allocated. The worksheet path makes this explicit in the GL. The app path absorbs it into the app's own posting logic. Enterprise's landed cost feature handles it natively in the same screen.
This late-arriving pattern is the same problem importers in adjacent industries face, and the resolution looks similar across them. For deeper treatment of allocation methods and late-arriving freight and duty invoices in a manufacturing context, the underlying mechanism — partial cost on receipt, adjustment as bills arrive, full landed cost only when allocation closes — is identical to what QBO importers handle. The freight allocation in QuickBooks Online problem is not unique to QBO; QBO just lacks the native scaffolding that makes the late-arriving piece easy to manage in one place.
Three Paths for QBO Users: Worksheet, Inventory App, or Enterprise
The three paths are not symmetric, and the right choice is rarely universal. Five criteria drive the decision: shipment cadence, SKU count, multi-currency exposure, audit burden, and whether item-level cost accuracy is a regulatory or operational requirement. Apply them to the operation rather than to a vendor's marketing page, and the right path usually surfaces clearly.
Worksheet alongside QBO
The lowest-cost, lowest-control path. The pattern community threads describe, in working form, looks like this: post the supplier bill in QBO at supplier value, route freight, duty, broker, and other inbound charges to a freight-in or landed-cost clearing account as those bills arrive, allocate the clearing-account balance across the shipment's SKUs in a worksheet outside QBO, then post an inventory adjustment (or a journal entry that debits inventory and credits the clearing account) to roll the allocated landed cost into per-SKU item cost.
It works when shipment cadence is low — a handful per month at most — SKU count per shipment is modest, currency exposure is limited to one or two non-home currencies, and the audit team is comfortable with a worksheet trail backed by attached source documents on the related bills. For an importer running ten to thirty shipments a quarter with a manageable SKU mix, this is often genuinely the right answer. It is also the QBO landed cost workaround the community threads keep returning to, because for a meaningful share of QBO users the operational match is real.
It scales badly. The manual reconciliation between QBO inventory adjustments and the worksheet becomes a bottleneck around the point where the number of shipments per month exceeds what one person can reconcile in a half-day. When the worksheet trail starts disagreeing with QBO inventory because a freight bill was posted to the wrong clearing subaccount or an FX rate was applied inconsistently, the cost of running this path quietly exceeds what an app would cost.
Inventory or landed-cost app integrated with QBO
The middle path, and a category rather than a specific product. These apps generally pull POs and bills from QBO, hold the shipment-level allocation in their own data model (which is the system of record for cost composition), support per-component basis selection, post landed-cost adjustments back to QBO inventory items, and maintain an allocation history that an auditor can trace from the source bill to the per-SKU posting. The strong ones support multi-currency natively and handle the late-arriving-bill problem without manual journal entries.
An inventory app for QBO landed cost earns its monthly fee when shipment volume is moderate (tens to low hundreds per month), item-level costing accuracy is operationally required, multi-currency exposure is real, and the audit posture is normal — meaning the audit team will accept the app's allocation history as supporting evidence for cost composition, with the source PDFs attached to the bills in QBO. For most growing import operations on QBO, this is the path that buys back time without forcing a platform migration.
The practical signal that this path has stopped fitting: accounting and inventory drift far enough — because the app's posting back to QBO has timing gaps, or because the app's data model diverges from how the audit team thinks about cost composition — that the audit team will not accept the app's records as a clean trail. That is when migration becomes the next conversation.
Upgrade to QuickBooks Enterprise
The right answer when shipment volume, SKU count, and audit burden cross a threshold that neither the worksheet nor the middleware can carry cleanly. Enterprise's landed cost feature lives in the Platinum and Diamond tiers; it distributes other-charge items across inventory by quantity, value, weight, or volume, in the same product handling AP and inventory accounting, without the cross-system reconciliation an app introduces.
The cost is real — Enterprise is materially more expensive than QBO, the migration burden across the chart of accounts, item list, and historical data is non-trivial, and the user experience is closer to legacy desktop than to QBO's web UI. For genuinely large importers — hundreds of shipments a month, thousands of SKUs, audit teams that expect cost composition to be queryable from one place — it is often the right destination, not because Intuit recommends it on landing pages but because the operational match at that scale is real and the cost of running anything else has exceeded what Enterprise costs.
Where each path quits being the right one
The signal for outgrowing the worksheet path is reconciliation time. When the time spent reconciling the worksheet against QBO inventory exceeds the time saved over a more automated path, the worksheet has stopped being cheap. The signal for outgrowing the app path is audit acceptance — when the audit team starts pushing back on the app's records as the system of record for cost composition, the cross-system arrangement has stopped being defensible. The signal for staying on Enterprise is volume crossing the band where neither the worksheet nor an app handles the operation without persistent friction.
The same three-way decision shows up across import-heavy industries, not just in distribution. The landed cost accounting workflow for distributors walks the same path in the distribution context, and the criteria that drive the choice — shipment volume, SKU count, audit posture — are the criteria that drive it here. The QBO platform constraint is what makes the decision sharper for QBO users: the worksheet and app paths exist precisely because the native feature does not, and the Enterprise path requires leaving the platform.
Posting Clean Bills Back into QuickBooks Online
Whichever path runs the allocation, QBO ends up holding the bills, the adjusted item costs, and the supporting documents. That record has to be clean enough that an AP audit two quarters later can reconstruct cost composition from QBO alone, with the source PDFs attached and the math reconcilable against the worksheet or app.
What posts back, regardless of path, is the same set of records. The supplier bill posts at the supplier value with the correct currency and the exchange rate applied at the invoice date — match the FX convention the worksheet or app used, or the inventory valuation report will not reconcile later. The freight forwarder's bill posts to a freight-in or clearing account on the worksheet path, or gets absorbed into item cost through the app or Enterprise mechanism on the other two. The customs broker's bill posts similarly: duty, MPF, HMF, and broker fees should land as separate line items on the bill record where they need to be visible for tax or compliance reporting, rather than collapsed into a single "import charges" line. The inventory cost adjustment is the entry that closes the loop — an explicit journal entry on the worksheet path, the app's own posting on the middle path, or the native landed cost mechanism on Enterprise — bringing per-SKU cost into agreement with the allocated total.
QBO supports attachments on bill records, and the AP audit trail for importers needs them. The supplier invoice belongs on the supplier bill, the freight bill PDF belongs on the freight-in bill, the customs entry summary belongs on the broker bill. This is not optional housekeeping; the audit team will ask for the source document for any allocated charge, and the easiest place to keep them is on the bill record they reconcile to. Attachments also matter because they survive personnel changes: the bookkeeper who ran the allocation may not be the one defending it later.
After the bills are posted and the cost adjustment is in, the inventory valuation report in QBO should agree with the shipment-level cost total from the worksheet or app. When it does not — and it will not, sometimes — the cause is almost always inconsistent currency conversion between the supplier bill and the freight/broker bills (different rates applied at different dates, or rates pulled from different sources), or a missing landed cost component bill because the freight forwarder or broker has not invoiced yet. Both are worth checking before going deeper into the GL.
Getting the supplier bills into QBO-ready shape is its own step before any of the posting above can happen. The standard pattern is to convert PDF supplier invoices to QuickBooks Online through structured extraction, then enter the bills in QBO with the fields already in the right shape, rather than retyping from the PDF. The same data layer that fed the allocation worksheet feeds the bill entry — invoice number, vendor, date, line items, totals, currency — which is why getting the extraction step right at the start pays back in every later step.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.
Related Articles
Explore adjacent guides and reference articles on this topic.
Best Invoice Scanning Software for QuickBooks (2026)
Compare 10 invoice scanning tools for QuickBooks. Covers OCR accuracy, line-item extraction, batch processing, pricing, and integration methods.
QuickBooks Online Receipt Capture Review (2026): Honest Look
An honest review of QuickBooks Online receipt capture: what Receipt Snap does well, where official limits and OCR errors hurt, and when you need a scanner.
Restricted Fund Tracking in QuickBooks and Xero
How nonprofits code restricted-fund supplier bills in QuickBooks and Xero, including classes, tracking categories, split invoices, and import checks.