What Are Stockkeeping Units in Business Central (and Why You Probably Should Be Using Them)

Quick Answer: In Microsoft Dynamics 365 Business Central, a Stockkeeping Unit (SKU) is a configuration record that ties an existing item to a specific Location (and optionally a Variant). It lets a single item behave differently at each location—its own planning parameters, replenishment method, production BOM, routing, and cost—without creating a second item number. Think of it this way: the item is what the product is; the SKU is how that product behaves at a particular location.

Spend enough time in Business Central and you will eventually meet the Stockkeeping Unit. And if the first thing you thought was “wait, don’t we already have item numbers—what is this?”, you are in good company. It is one of the most quietly useful configuration tools in the product, wearing one of its least intuitive names.

Here is the good news: once the concept clicks, SKUs give you a surprising amount of flexibility across multiple locations—no customization required. Here is the risk if it doesn’t click: teams reach for the wrong workaround, duplicate item numbers to force location-specific behavior, and end up with a bloated item master and costing surprises that surface at month-end when they are hardest to unwind.

Let’s fix that.

Why the Name Throws Everyone Off

“Stockkeeping Unit” is borrowed from retail, where a SKU is a product identifier—the thing behind the barcode. That’s not what it means here.

In Business Central, a SKU is not a new product and not a new item number. It is a configuration record attached to an item you already have, scoped to a location (and optionally a variant). Same item identity, different behavior depending on where it lives.

If you want an analogy: the item is the actor, and each SKU is the role that actor plays on a specific stage. Same person underneath—different lines, different blocking, different costume—depending on the location.

Once you see it that way, the purpose stops being mysterious.

Where SKUs Came From—and What They Do Now

Historically, SKUs existed for planning and replenishment. You might want an item to behave one way in one warehouse and differently in another:

• Location A manufactures the item and carries higher safety stock.
• Location B replenishes by transfer from A and holds a leaner buffer.

Rather than inventing separate item numbers to represent those differences, you let one item wear two SKUs.

Today SKUs control far more than planning. On current Business Central, a SKU can define location-specific:

• Planning parameters — reordering policy, safety stock, reorder point and quantity, order modifiers, and planning time buckets.
• Replenishment method — Purchase, Prod. Order, Assembly, or Transfer. (More on that last one in a second—it’s SKU-only.)
• Manufacturing configuration — Production BOM, Routing, and manufacturing policy, so the same finished good can be built differently at different plants. (See the version note below—this behavior depends on your Business Central version and a Manufacturing Setup toggle.)
• Cost — a location-specific standard cost, plus location-level costing visibility. (Look for a post on this coming soon.)
• Vendor relationships — one location buys directly from a vendor while another receives the item by transfer.

All of it lives against a single, clean item master.

One replenishment method only lives on the SKU

Purchase, Prod. Order, and Assembly are all available on the Item Card. Transfer is not. If you want one location to be replenished by moving stock in from another—the classic “central bulk warehouse feeds the satellites” pattern—you need a SKU with a Transfer-from Code and a transfer route between the locations. That single capability is often reason enough to adopt SKUs.

Version note on manufacturing BOMs and routings

If you run a modern Business Central and want production orders to actually use a SKU’s Production BOM, Routing, and standard cost, turn on Load SKU Cost on Manufacturing in Manufacturing Setup. Standard-cost-by-SKU roll-up for manufacturers was rounded out in the 2025 Release Wave 1 update. With that toggle off, production orders fall back to the item’s standard cost and calculate variances against the item’s cost shares—regardless of what’s sitting on the SKU. If you’re on an older or on-premises build, confirm the behavior in your version before you promise a plant its own routing.

For the full walkthrough of location-specific production BOMs as newer Business Central functionality, see locaton-specific BOMs in Business Central.

A Simple Two-Plant Example

Picture a manufacturer with two plants:

• New York Plant
• Texas Plant

Both build the same finished good, ITEM-1000. But the build differs slightly by site—different components sourced locally, different equipment on the floor.

Instead of creating ITEM-1000-NY and ITEM-1000-TX (and doubling your item master forever), you keep one item and add two SKUs:

Item	Location
ITEM-1000	NY
ITEM-1000	TX

Each SKU carries its own Production BOM, Routing, and planning parameters. Create a production order at NY, and Business Central uses the NY configuration. Create it in TX, and it uses TX. One item. Two realities. No customization.

A Brief Word on Costing by Location

Here’s a question that comes up the moment finance gets involved: can the same item cost differently at different locations?

Short answer: yes, in a few distinct ways—and they’re easy to confuse, which is exactly why this topic deserves its own article.

• Average cost per location. When the Average Cost Calc. Type in Inventory Setup is set to Item & Location & Variant, Business Central calculates average cost separately for each location instead of one blended number across the company.
• Standard cost by SKU. A standard-costed item can carry a different standard cost on each SKU, so a plant with different inputs can hold a different unit cost (paired with the manufacturing toggle noted above).
• Cost visibility by location. In Inventory Posting Setup, you assign accounts per combination of location and inventory posting group—so inventory value posts to different G/L accounts by location and you can read the value of each site separately.

One caveat worth flagging now, because it isn’t a costing method at all: the Costing Method field itself (FIFO, LIFO, Average, Standard, Specific) lives on the item, not the SKU. You cannot run FIFO at one location and Standard at another for the same item.

How to Create SKUs

You have two paths, and the one you pick depends on how many you need.

One at a time (Item Card). Open the item, then from the Related menu choose Item → Stockkeeping Units. Add a record, set the Location Code and optional Variant Code, and configure the location-specific settings—replenishment system, planning parameters, production BOM, routing, standard cost. The moment your first SKU exists, the Stockkeeping Unit Exists checkbox lights up on the Item Card.

In bulk (batch job). For a real multi-location operation, creating SKUs one by one is a slow afternoon you’ll never get back. Use the Create Stockkeeping Unit batch job (Actions → Functions → Create Stockkeeping Units). Filter to the items you want, choose whether to generate a SKU per location, per variant, or per combination, and Business Central seeds each SKU from the item’s values—which you then refine per site.

The Override Rule (and the Pitfall That Bites People)

The governing principle is simple: the SKU card has priority over the Item Card. For reference and option fields—Production BOM No., Routing No., Replenishment System, planning parameters—Business Central loads the item’s values first, then overrides them with any SKU field that isn’t blank. Leave one of those fields blank on the SKU and it falls back to the item.

Standard cost is the exception—and it’s where the most common SKU mistake hides, because it doesn’t follow the blank-fallback rule at all.

The stale-standard-cost trap: Standard Cost on the SKU is a numeric field, so its unset state is 0, not blank—there’s nothing to “fall back” to. When you create a SKU (manually or via the batch job), it copies the item’s standard cost at that moment, and the two are never synchronized again. Update the item’s standard cost later and the SKU quietly keeps its original figure. Compounding it: running Calc. Production Std. Cost on the item rolls up the item cards only—not the SKU cards—so you have to roll up standard cost on the SKU itself.

Here’s the sting. Turn on Load SKU Cost on Manufacturing, and production orders value the finished good at the SKU’s standard cost. A SKU carrying a stale—or zero—standard cost will happily post production at that figure while the item card looks perfectly correct. (Leave the toggle off and production uses the item’s standard cost instead, which sidesteps the trap but also gives up per-location cost.) The habit that prevents the awkward month-end reconciliation: maintain and roll up standard cost on the SKU, not just the item.

When You Should Use SKUs

SKUs earn their place when behavior genuinely differs by location:

• Items are manufactured differently at different plants.
• Planning parameters—safety stock, reorder policy, lead time—vary by warehouse.
• Replenishment strategy changes by site (buy here, transfer there).
• You need inventory availability, planning, or cost read per location.

In those situations, SKUs let you keep one clean item master while honoring the operational reality on the ground.

When You Don’t Need Them

If an item behaves identically everywhere—same planning, same sourcing, same build—the Item Card alone is enough. Don’t manufacture complexity you don’t need. But the instant a location starts doing something different, the SKU is almost always the cleanest answer—and a far better one than a duplicate item number.

Final Thoughts

Stockkeeping Units may have the least intuitive name in Business Central, but they solve a very common problem elegantly: how to let one item behave differently across locations without cloning items or bolting on custom logic. Get the mental model right—item is what it is, SKU is how it behaves here—maintain your cost fields, and mind the version-specific manufacturing behavior, and SKUs become one of the most dependable tools in your multi-location toolkit.

---

Frequently Asked Questions

Is a Stockkeeping Unit a new item number in Business Central? No. A SKU is a configuration record attached to an existing item and scoped to a location (and optionally a variant). The item number stays the same; the SKU only changes how that item behaves at that location.

What’s the difference between an item and a SKU? The item defines what the product is—its identity, base unit of measure, costing method, and tracking. The SKU defines how that item behaves at a specific location: its planning parameters, replenishment method, production BOM, routing, and standard cost.

Can I set a different Production BOM or Routing per location? Yes, on current Business Central. To have production orders use the SKU’s BOM, routing, and standard cost, enable Load SKU Cost on Manufacturing in Manufacturing Setup; standard-cost-by-SKU roll-up was completed in the 2025 Release Wave 1 update. Behavior varies on older or on-premises versions, so verify before relying on it.

Can the same item cost differently at different locations? Yes—through average cost per location (Average Cost Calc. Type set to Item & Location & Variant), standard cost held on each SKU, or location-based accounts in Inventory Posting Setup. The Costing Method itself, however, is set on the item and can’t differ by location.

How do I create many SKUs at once? Use the Create Stockkeeping Unit batch job (Actions → Functions → Create Stockkeeping Units). Filter to the items you want and generate SKUs per location, per variant, or per combination, then refine each one.

Want more Business Central deep-dives like this one? Subscribe to Dynamics Power Play and stay in the loop—new practitioner-to-practitioner posts land regularly.