Inventory Setup in Business Central: Decisions Before Implementation

Inventory is not configured successfully by filling in item cards. Before anyone opens Dynamics 365 Business Central, the organisation needs to decide how it identifies items, how it uses locations, how it records movements and units of measure, how adjustments are approved and how inventory value is reviewed. SCSB puts these questions to the people who own the process and the data rather than to whoever is available to do the configuration, because one of the decisions cannot be undone by changing a setting later — and it is the one most often made by default.

Settle the costing method first, because it is effectively one-way

Of every inventory setting, the costing method deserves the most attention before go-live. Microsoft states it without qualification in its costing methods documentation: "You can't change an item's costing method if item ledger entries exist for the item." Its companion guidance puts the same point in terms of activity rather than entries — the method cannot be changed after the item has been included in a transaction, for example once it has been bought or sold.

Two things follow, and SCSB separates them deliberately. First, the costing method is an accounting policy decision, not a technical preference. It should be confirmed with the organisation's accountants or auditors against the applicable reporting framework, not selected by whoever is configuring the item card. Second, the method must be workable for the people running the process daily; a method that the warehouse and finance teams cannot apply consistently will produce unreliable inventory values however well it was justified on paper.

One small configuration step prevents most of the damage. Microsoft documents a Default Costing Method field on the Inventory Setup page, which suggests a method whenever someone creates a new item. Setting it correctly on day one is the cheapest control described in this article.

What each method assumes, and where manufacturers usually land

Business Central supports five methods — FIFO, LIFO, Average, Specific and Standard — and Microsoft documents both how each values inventory decreases and the circumstances each suits.

• FIFO — the unit cost is the actual value of a receipt, selected by the FIFO rule. Microsoft indicates it suits environments where product cost is stable, and items with a limited shelf life where the oldest goods must move first.
• LIFO — the mirror assumption. Microsoft notes it is disallowed in many countries and regions. Whether it is available under the framework an organisation reports under is a question for its accountants and auditors, not a configuration choice.
• Average — the unit cost is the average at each point in time after a purchase. Microsoft indicates it suits unstable product costs and inventory that is piled or mixed and cannot be differentiated, giving chemicals as an example.
• Specific — the unit cost is the exact cost at which that unit was received. Suited to identifiable items with fairly high unit costs, serialised items and items subject to regulation.
• Standard — the unit cost is preset, with actual cost reconciled later through variances. Microsoft indicates it suits repetitive manufacturing and situations where cost control is critical, and notes it requires the discipline and staff to maintain the standards.

For a manufacturer the choice is rarely uniform across the business, and it should not be. Applying Standard cost to produced items while using FIFO for bought-in goods is a coherent design, not an inconsistency. The qualifying condition is the one Microsoft attaches to Standard: someone has to own and update the standards. Where no one does, Standard costing degrades into a growing variance balance that nobody can explain.

Two behaviours are worth knowing before the choice is locked, because they surface during month end rather than during configuration. Microsoft documents that under FIFO, back-dating an inventory decrease does not cause existing entries to be reapplied to give a correct FIFO cost flow. Under Average, back-dating an increase or decrease recalculates the average cost and adjusts all affected entries — as does changing the average cost period or calculation type. Teams that routinely post late deserve to know which of those two worlds they are choosing.

One common misconception is worth correcting directly, because it drives unnecessary configuration. Microsoft states that specific item tracking can be used without using the Specific costing method — in that case the cost does not follow the lot number, but follows the cost assumption of the selected method. Traceability and costing are separate decisions.

What it actually takes to change a costing method later

Because the change is not a settings change, it is worth knowing the size of the remedy before relying on being able to correct a mistake.

Microsoft's guidance on changing costing methods describes the recommended approach as replacing the item that has the incorrect costing method with a new item, and using an assembly order to transfer inventory from the old item to the new. The documented sequence runs to eight steps: renumber the existing items, create replacements under the original numbering, copy the master data, manually copy related data the copy function does not carry, determine the quantity to convert, post assembly orders to transfer it, handle quantities already allocated to demand, and block the original item.

The manual portion is the part that surprises people. Microsoft lists stockkeeping units, item substitutions, analysis reports, standard journals, sales and purchase prepayment percentages, bin contents, project prices, service resource skills and components, production BOMs and assembly BOMs as data that may need to be transferred by hand. It also notes that an assembly order handles only one stockkeeping unit at a time, and recommends proving the process on a single item or a small set first.

SCSB's reason for setting this out is not to alarm. It is that the cost of getting the costing method right at design time is a conversation with the organisation's accountants; the cost of getting it wrong is a controlled data migration across every item affected. The asymmetry justifies spending the time up front.

Item type is a structural choice, not a label

The Type field on the item card is frequently treated as classification. It is closer to a capability switch. Microsoft documents three types — Inventory, Non-Inventory and Service — and states that the Service and Non-Inventory types do not let you track inventory quantities and values, with only selected transaction types and features supported.

The practical effect is considerable. Microsoft's feature table records that non-inventory and service items do not support inventory costing, item tracking, physical counting, inventory revaluation, location transfer, reservation, warehousing or planning. It also documents that cost for these types is recorded in the Cost Amount (Non-Invtbl.) field, and that costs for them are not reconciled to the general ledger.

That last point is the one to weigh. Choosing Non-Inventory for low-value consumables is a legitimate simplification that removes real administrative burden. Choosing it for something the business later wants to count, trace or reconcile is a structural decision that has to be revisited rather than adjusted.

Decide the location and tracking model deliberately

Locations, bins and item tracking are often enabled because they are available rather than because a requirement was identified. Each carries a permanent operational cost.

• Locations — establish whether separate locations are genuinely needed for reporting, responsibility or physical separation, and how transfers between them will be recorded and reconciled.
• Serial and lot tracking — valuable where traceability, recall, warranty or expiry management is a real requirement; burdensome where it is not. Enabling tracking commits the organisation to capturing it accurately at every transaction, on every shift, indefinitely.
• Units of measure — confirm the base unit and any purchase or sales units, and how conversions round. Rounding differences accumulate quietly and are tedious to unpick.

Build a test set from real activity

Use representative receipts, sales, transfers, returns, adjustments, counts and corrections, and define the expected records and reports before testing rather than after. Then deliberately test the cases most likely to expose a costing or tracking misconfiguration:

1. A receipt posted after the related sale.
2. A purchase invoice arriving at a different price from the receipt.
3. A negative adjustment on a tracked item.
4. A stock count variance.
5. A return of an item whose cost has since moved.
6. A back-dated movement, which behaves differently under FIFO and Average.
7. A period-end valuation compared against the general ledger inventory account.

The last is the one that matters most. If the inventory subledger and the general ledger do not reconcile in testing, they will not reconcile in production, and the gap will be harder to diagnose once volume has built.

Control item master data and change

Assign owners for item master data, locations, costing choices, configuration changes and periodic review, and record why a setting was chosen, who approved it and how the result was tested. A new configuration cannot resolve weak data ownership or undefined operational rules.

Item master data deserves particular discipline: agree who may create an item, which fields are mandatory, how items are named and categorised, and how obsolete items are retired. In SCSB's experience most inventory reporting complaints trace back to inconsistent master data rather than to a system limitation, and no amount of reporting configuration compensates for it.

When the simpler configuration is the right one

Not every organisation needs the model described here. A business holding a modest range of stable, untracked items at a single location, with no manufacturing and no traceability obligation, needs a defensible costing method, clean item data and a working reconciliation to the general ledger. Locations, bins, stockkeeping units, variants and item tracking can all be left alone until a requirement genuinely calls for them, and adding them speculatively creates daily work that produces nothing.

The threshold for the heavier configuration is a real requirement — a traceability or expiry obligation, physically separate stock that must be reported separately, production that needs its own cost treatment, or an outside party that requires the detail. SCSB would rather implement the smaller configuration well than the larger one because it was available.

Next step

For an agreed Dynamics 365 Business Central implementation scope, SCSB's Business Central implementation service can be discussed. The organisation remains responsible for its inventory policies, data and operational acceptance, and its accountants or auditors remain responsible for the applicable accounting treatment of inventory and its valuation.

This article is general information about Business Central configuration. It is not accounting, tax or regulatory advice, and it does not determine the costing or valuation treatment appropriate to any organisation. Microsoft's product documentation changes over time; confirm the current position against Microsoft's own published material.

Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.