Locations and transfer routes in Business Central

How Business Central handles multi-location inventory — location cards, in-transit, transfer routes, transfer orders, and the integration with warehouse management.

Updated 2026-10-23

A multi-location business — multiple warehouses, branches, store back-of-house, manufacturing-to-distribution flows — needs Business Central configured to model the locations and the movements between them. The location card, in-transit location, transfer route, and transfer order machinery cover most patterns.

Location cards. A location is a Dataverse-like record representing a physical (or sometimes logical) inventory point. Each carries:

  • Code and Name — short identifier and label.
  • Address — physical location for ship-to.
  • Bin tracking — enabled or not (basic vs full WMS).
  • Receive / Ship requirements — whether warehouse documents are required.
  • Posting groups — inventory posting group per location.
  • Default bin codes — for receiving, shipping, adjustment.
  • Warehouse settings — directed put-away, pick configuration, advanced wave processing.

Locations can be production, distribution, storage, transit, or any business meaning. Most tenants have a handful of locations matching real warehouses; some have many representing zones or sub-locations.

Default location. Each user can have a default location for filtering and posting. Each customer can have a default shipping location; each vendor a default receiving location. Items can have stockkeeping units (SKUs) that override item defaults per location.

Stockkeeping units (SKUs). An SKU is the item-at-a-location record. Where an item has global defaults (costing method, base UoM, default replenishment), an SKU lets you set per-location overrides:

  • Different vendor at this location.
  • Different reordering policy at this location (Min/Max here, Lot-for-Lot elsewhere).
  • Different safety stock per location.
  • Different lead time per location.

Not every item needs an SKU per location — only where the local behaviour differs from the global default.

Transfer orders. Moving inventory from Location A to Location B uses a transfer order:

  • Header — transfer-from location, transfer-to location, dates, shipping method, in-transit location.
  • Lines — items being moved with quantities.
  • PostingPost Shipment moves inventory from the from-location to in-transit, Post Receipt moves it from in-transit to the to-location.

The two-step posting (ship then receive) captures the physical reality — goods are out of one warehouse but not yet at the other for some period. The in-transit location is a logical location that holds value but is not pickable for new orders.

Transfer routes. A transfer route is a defined path between two locations with default fields — shipping agent, shipment method, in-transit location, lead time. Configuring transfer routes means new transfer orders between those locations default cleanly without manual field entry.

Lead times. Transfer lead time is recognised by master planning — when an item needs to be at Warehouse B but inventory is at Warehouse A, the planning engine suggests a transfer order with the route's lead time, ensuring the supply lands in time.

Inter-company transfers. For multi-company tenants, transfers between companies (rather than within a single company's locations) are typically modelled as intercompany sales / purchase orders, not transfer orders. The two patterns are different and not interchangeable.

Reporting.

  • Inventory by location — stock value and quantity per location.
  • Transfer order status — open, in-transit, completed.
  • Items in transit — value of in-flight goods.
  • Location performance — picking efficiency, stockouts, returns.

Pitfalls.

  • Skipping in-transit — using single-step transfers loses visibility of goods in flight. Use the in-transit pattern.
  • Wrong location on transactions — items received to wrong location require correction with reversing transfer orders.
  • Stockkeeping unit overlap — when SKUs override global defaults, audit that the overrides are intentional.

Operational reality. Multi-location is one of the most common Business Central scenarios after the basic single-location setup. Done well, locations are invisible infrastructure; done poorly, they're a daily source of inventory confusion.

Related guides