Odoo Inventory Consultant, USA

Receiving and dispatch the way US docks work

In most American warehouses I review, inbound and outbound traffic splits into two very different kinds of work. Inbound, a container or a full trailer arrives with a packing list, sometimes an advance ship notice, and the crew unloads, counts, checks for damage and stages pallets before anyone decides where they go. Outbound, the same building may pick small parcel orders for consumers all day and build pallets for a retail or wholesale customer that a freight carrier collects on a bill of lading.

Odoo Inventory lets you set receipts and deliveries per warehouse, from a single step to an input, quality and stock sequence on the way in, and a pick, pack and ship sequence on the way out. I rarely apply the same choice everywhere. A busy import building often benefits from an input step so the dock count is separate from putaway, while a small 3PL-supported site might receive straight to stock because nobody is there to scan twice.

For dispatch, I usually design separate operation types or routes for parcel and freight so packing rules, package weights and paperwork follow the right path. Cross-docking, where goods for a known order go from the receiving dock to the outbound lane without being stored, is possible with routes, but I test it with real orders first because it depends on purchasing and sales discipline as much as on configuration.

Every step must match a physical action. If nobody validates it on the floor, it should not exist in Odoo.

Warehouses in several states, 3PLs and the tax questions they raise

Once stock lives in more than one state, the structure in Odoo matters beyond operations. I typically set up each building you control as its own Odoo warehouse, each 3PL relationship as a warehouse or a location depending on how much visibility the provider gives you, and marketplace fulfillment balances as locations that are replenished by transfer and reconciled from the marketplace's own reports.

Moving goods between your own warehouses in different states is an internal transfer, not a sale, and Odoo treats it that way. The tax angle is different. Holding inventory in a state, including stock at a 3PL or a fulfillment center you do not operate, may contribute to a sales tax obligation there, and some states also tax business personal property that can include inventory. I do not advise on whether either applies to you. What I do is make sure Odoo can answer the questions your tax advisor will ask: what stock sat in which state, on which dates, at what value.

That means locations named and grouped by state, inventory valuation reports you can filter by warehouse, and transfer history that is not overwritten by quick manual adjustments. It is a small design effort at the start, and much harder to reconstruct afterward.

Customs duty, broker fees and landed cost on US imports

Many of the US companies that look at Odoo import a large share of what they sell. A shipment collects charges from several parties: the ocean or air carrier, the customs broker who files the entry, the duty itself, port and terminal fees, drayage to your building and sometimes storage while the container waits. These bills arrive at different times, often after the goods have been received and some of them sold.

Odoo handles this through landed costs, which add extra charges to the value of received goods and spread them across products by quantity, value, weight or volume. I check early that your edition and setup include the feature as you expect, because it shapes the whole purchasing design. I then agree with your team which split method suits each kind of charge: duty usually follows value, freight often follows volume or weight.

The practical trap is timing. If the broker invoice arrives after half the shipment is sold, the extra cost can only be applied to stock still on hand, and the rest needs an accounting treatment your controller signs off. I build a routine for collecting shipment costs promptly and reviewing open shipments, so duty changes show up in item cost while it still matters for pricing.

Choosing a costing method with your controller and CPA

Odoo values inventory per product category using standard cost, average cost or first in, first out, with valuation posted to the ledger automatically or handled periodically. Which combination you choose is an accounting decision, not an inventory setting, and in the US it often touches tax reporting and lender reporting as well.

I do not give tax or accounting advice. I set out how each option behaves in Odoo, using your own products and a sample month of receipts and sales, so your controller and CPA can choose with real numbers in front of them. A few points usually come up:

• Standard cost suits manufacturers and businesses that review costs on a schedule; variances need someone to own them.
• Average cost is simple to explain and smooths out swings in purchase price and duty.
• First in, first out tracks cost layers closely and makes landed cost timing more visible.
• If your company has used a last in, first out method for tax purposes, raise it early: as far as I know Odoo does not offer it as a costing method, so your CPA needs to decide how that is handled outside the system.

Whatever is chosen, I write it into the design document and test the postings with finance before go-live. See my Odoo Accounting work for US companies for the ledger side.

Scanners, carriers, 3PL links and traceability

Barcode scanning is where warehouse staff feel an Odoo project most. Odoo offers a Barcode app that runs on mobile computers and phones, and in my understanding it is part of Enterprise rather than Community, so I confirm the edition before anyone buys hardware. I test scanners on your floor with your labels, because a device that works in a demo can still struggle with glossy cartons or poor lighting.

For parcel shipping, Odoo has connectors for several large carriers, again mostly tied to Enterprise, and regional carriers or freight brokers usually need a third-party connector or some API work. Many US businesses already use a shipping platform for rate shopping and labels; sometimes the better design is to keep it and integrate rather than replace it.

3PL connections vary widely. Some providers exchange files, some offer an API and larger ones expect EDI. I define the messages, the timing and a reconciliation routine before any developer is engaged. Retail customers may add their own demands, such as advance ship notices and compliant carton labels, which belong in requirements early.

Lot and serial tracking, expiry dates and removal strategies such as first expired, first out are available in Odoo. I apply them only to the product lines that genuinely need them, such as food, supplements, cosmetics or serialized equipment.

When a US warehouse needs a dedicated WMS instead

Odoo Inventory serves many US distributors, ecommerce brands and light manufacturers well. There are situations where I tell clients that a specialist warehouse management system, integrated with Odoo for orders and accounting, will serve them better:

• You are the 3PL. If you store goods for many client companies and bill them for storage and handling, you need client-facing portals and activity-based billing that Odoo is not built around.
• Very high order volume. Large parcel operations rely on wave and zone picking optimization, labor standards and slotting that go beyond standard Odoo.
• Automation on the floor. Conveyors, sorters, pick-to-light or robotics need control software that talks to the equipment directly.
• Heavy retail compliance. If most of your volume goes to large retailers with strict routing guides and chargebacks, an EDI and compliance layer usually sits beside Odoo.

In those cases Odoo can still own purchasing, sales, costing and the ledger. I help you draw the boundary, write the integration specification and compare the options neutrally. For the wider platform picture, see my page on Odoo for US companies, my notes for US trading businesses, and the ERP integration service.